[PATCH] bsps/raspberrypi/console: Fix default console device
Niteesh G. S.
niteesh.gs at gmail.com
Thu May 27 16:38:34 UTC 2021
Hello Alan,
On Sun, May 23, 2021 at 9:06 PM Alan Cudmore <alan.cudmore at gmail.com> wrote:
> 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?
>
Yes. The image is built from RTEMS 5.1 because I wasn't able to
get RTEMS 6 working. There is some other issue not related to this patch
or console.
- 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?
>
I am not sure about RPi 1. Maybe Christian could help here.
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 too face the same issue with RTEMS 6.
- 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.
Hmm, that's odd
- 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?
I did no other modification to the 5 branch other than adding the define
I mentioned previously to trigger the issue.
Let me summarize once again.
In RTEMS - 5 as far as I have tested the default hello example should work
on all models without any issue. The problem occurs when someone uses
the *NEEDS_CONSOLE_DRIVER* option instead of the
*NEEDS_SIMPLE_CONSOLE_DRIVER*
This is because when the *NEEDS_CONSOLE_DRIVER* option is given,
the console_initialize function gets called, this, in turn, calls
console_select
which when no cmdline option is given selects the PL011 as the UART
irrespective of the model.
This patch fixes that. I was able to get the hello world example in RTEMS
with
both options working with no other modification.
Also, I was able to run the images with and without uboot.
In RTEMS - 6,
Seems like something broke Rpi in RTEMS 6 but it was later fixed by the
following
commit
https://devel.rtems.org/ticket/4395
But this isn't the case for me. I still can't get it running.
I tried some commits before and after the mentioned commit but I couldn't
get a
working image.
I don't know if it is a toolchain issue on my side or something else.
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.
>
This I am really sure about. AFAIR nothing is needed. Christian, can you
please
confirm this?
> - 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.
Since we have a GSoC student working the BSP I think our first goal should
be
to fix RTEMS 6 on Rpi. For Backporting the patch on RTEMS 5, Gadare
mentioned
creating a ticket. I am currently a bit occupied with my own GSoC project.
So can't
really work on figuring out why RTEMS is not working on RPI.
Regarding backporting, once you give me an acknowledgment that it works
fine on RTEMS5
I'll create a ticket for this.
Thanks,
Niteesh.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210527/de1179e1/attachment-0001.html>
More information about the devel
mailing list