[PATCH] bsps/raspberrypi/console: Fix default console device
Alan Cudmore
alan.cudmore at gmail.com
Sun May 23 15:36:15 UTC 2021
Hi Niteesh,
Here are my latest tests:
- Using your firmware and the rtems.img in your firmware repo, I can
see that it runs on my Raspberry Pi 3. The hello example reports RTEMS
5.1. Was this from the 5 branch?
- The same image does not seem to boot on the Raspberry Pi 1 modules,
but I think that's because I need to add the command line option. What
file should I add that in, and what command line option I should use?
With the code I build:
- I can get your patch to apply on the master/6 branch, and it builds
OK, but I cannot get the raspberrypi BSP to run on any of my boards
yet (with or without your patch and firmware)
- I can run the unmodified RTEMS 5 branch raspberry pi BSP on all of
the single core models I have (using your firmware). Interestingly,
the samples run on the Raspberry Pi Zero W (with wireless and
bluetooth) without a patch. I thought the Zero W would have the same
console problem as the RPI 3.
- I applied your patch to my RTEMS 5 branch (had to change the include
path for arm-pl011.h). It runs the same on the single core models
without the patch, and the console does not come up on the Pi 3 like
it does with your rtems.img. Is there something else that needs to be
done in RTEMS 5 to default to the pl011 uart?
All of my tests are not using u-boot.
What should be next?
- I can try the rest of my Raspberry Pi single core models with your
firmware and rtems.img, once I know the command line option I need.
- After that, maybe we should figure out how to configure the console
with your patch on the RTEMS 5 branch.
- Finally, we need to figure out how to get the master/6 branch working again.
Thanks!
Alan
On Thu, May 20, 2021 at 7:41 AM Alan Cudmore <alan.cudmore at gmail.com> wrote:
>
> 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.gs at gmail.com> wrote:
> >
> > ping.
> >
> > On Tue, May 11, 2021 at 1:09 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
> >>
> >> Hello Gedare,
> >>
> >> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom <gedare at rtems.org> wrote:
> >>>
> >>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
> >>> >
> >>> > Hi Alan,
> >>> >
> >>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore <alan.cudmore at 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-devel at 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.gs at gmail.com> wrote:
> >>> >>
> >>> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill <joel at rtems.org> wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. <niteesh.gs at 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.gs at 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 at rtems.org
> >>> >> http://lists.rtems.org/mailman/listinfo/devel
> >>> >>
> >>> >>
> >>> >
> >>> > _______________________________________________
> >>> > devel mailing list
> >>> > devel at rtems.org
> >>> > http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list