Hi Niteesh, I tried your firmware, booting directly instead of using u-boot. I was able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I still cannot get the master/6 branch to run. I need some time to do additional tests. I was also going to re-try your patch and see if I can run the master branch and your firmware with the Pi 3.
Our GSOC student just started a RPi improvement project, so I think the first step should be to sort all of this out. I'm pretty busy right now, but I'll see if I can continue testing in the next few days. I want to try loading from u-boot next. Alan On Thu, May 20, 2021 at 12:52 AM Niteesh G. S. <niteesh...@gmail.com> wrote: > > ping. > > On Tue, May 11, 2021 at 1:09 AM Niteesh G. S. <niteesh...@gmail.com> wrote: >> >> Hello Gedare, >> >> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom <ged...@rtems.org> wrote: >>> >>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S. <niteesh...@gmail.com> wrote: >>> > >>> > Hi Alan, >>> > >>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore <alan.cudm...@gmail.com> >>> > wrote: >>> >> >>> >> Hi Niteesh, >>> >> >>> >> I was hoping to try this out as soon as I get some time. No later than >>> >> weekend. So if nobody else is able to check it out, I will be able to >>> >> provide some feedback soon. >>> >> >>> >> I should be able to bring up the console on a RPi Zero W and RPi3, >>> >> correct? >>> > >>> > the consoles should work on Zero W and Pi3 by default. They only fail to >>> > work when CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER >>> > this option is used. This is because when that option is used it calls >>> > console_initialize which checks if any boot options were present if none >>> > were >>> > given it defaults to pl011 which is the secondary UART in Zero w and Pi3 >>> > so we get no output. This patch defaults to the primary UART instead of >>> > pl011 depending on the board. >>> > Also, this patch should be applied on RTEMS 5 since we started supporting >>> > Pi3 and Zero w from RTEMS 5. >>> > >>> You'll need to provide a separate patch with a ticket to close on 5 >>> for a backport. Wait until you get the approval for the master branch >>> though. >> >> OK. I'll create a ticket and request for a backport once this is pushed on >> to the current master >> >> Thanks, >> Niteesh. >>> >>> >>> > Thanks, >>> > Niteesh. >>> > >>> > >>> >> >>> >> Thanks, >>> >> >>> >> Alan >>> >> >>> >> >>> >> >>> >> From: Niteesh G. S. >>> >> Sent: Thursday, May 6, 2021 4:29 AM >>> >> To: Joel Sherrill; Christian Mauderer >>> >> Cc: rtems-de...@rtems.org >>> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device >>> >> >>> >> >>> >> >>> >> ping. >>> >> >>> >> >>> >> >>> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S. <niteesh...@gmail.com> >>> >> wrote: >>> >> >>> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill <j...@rtems.org> wrote: >>> >> >>> >> >>> >> >>> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. <niteesh...@gmail.com> wrote: >>> >> >>> >> Just to provide more context, >>> >> >>> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used >>> >> >>> >> and no --console option is provided, the console driver defaults to >>> >> PL011. >>> >> >>> >> In raspberry pi 3 and other models whose primary UART is not PL011, we >>> >> get no output. >>> >> >>> >> This patch fixes that by linking the primary UART to the console device. >>> >> >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> Niteesh >>> >> >>> >> >>> >> >>> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu <niteesh...@gmail.com> >>> >> wrote: >>> >> >>> >> When no console argument is given, the driver defaults to pl011 >>> >> this results in no output in case of Rpi3 whose primary uart is >>> >> miniuart. >>> >> This patch fixes that by defaulting to the primary uart when no >>> >> console option is provided. >>> >> >>> >> >>> >> >>> >> Does the default need to vary by model? >>> >> >>> >> Yes, the primary UART is different across models. >>> >> >>> >> >>> >> >>> >> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth >>> >> >>> >> the PL011 is used to talk to the Bluetooth and miniuart acts as the >>> >> primary UART. >>> >> >>> >> Now we can change this by adding miniuart-bt to config.txt but the >>> >> miniuart is >>> >> >>> >> based on the VPU core and requires to add another option which sets the >>> >> core to >>> >> >>> >> a fixed freq. >>> >> >>> >> >>> >> >>> >> --- >>> >> bsps/arm/raspberrypi/console/console-config.c | 12 +++++++++--- >>> >> 1 file changed, 9 insertions(+), 3 deletions(-) >>> >> >>> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c >>> >> b/bsps/arm/raspberrypi/console/console-config.c >>> >> index 6b8eb80aa4..bd3a8d34c2 100644 >>> >> --- a/bsps/arm/raspberrypi/console/console-config.c >>> >> +++ b/bsps/arm/raspberrypi/console/console-config.c >>> >> @@ -165,10 +165,16 @@ static void console_select( void ) >>> >> } >>> >> }else { >>> >> /** >>> >> - * If no command line option was given, default to PL011. >>> >> + * If no console option was given we default to the primary uarts. >>> >> + * The initialization of the uart's and BSP_output_char is already >>> >> done >>> >> + * in the uart_probe function called before this. So now we can >>> >> safely >>> >> + * compare BSP_output_char. >>> >> */ >>> >> - BSP_output_char = output_char_pl011; >>> >> - link(PL011, CONSOLE_DEVICE_NAME); >>> >> + if (BSP_output_char == output_char_pl011) { >>> >> + link(PL011, CONSOLE_DEVICE_NAME); >>> >> + }else { >>> >> + link(MINIUART, CONSOLE_DEVICE_NAME); >>> >> + } >>> >> } >>> >> } >>> >> >>> >> -- >>> >> 2.17.1 >>> >> >>> >> _______________________________________________ >>> >> devel mailing list >>> >> devel@rtems.org >>> >> http://lists.rtems.org/mailman/listinfo/devel >>> >> >>> >> >>> > >>> > _______________________________________________ >>> > devel mailing list >>> > devel@rtems.org >>> > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel