Selecting serial device for console

[Simon Glass]

Hi Mark,

On Tue, 6 Aug 2024 at 16:33, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Tue, 6 Aug 2024 15:50:44 -0600
>
> Hi Simon,
>
> > Hi Fiona,
> >
> > On Thu, 1 Aug 2024 at 08:07, Fiona Klute <fiona.klute at gmx.de> wrote:
> > >
> > > Hi everyone,
> > >
> > > how can I configure which of the available serial devices U-Boot will
> > > use for its serial console?
> > >
> > > Background: I have a device based on a Raspberry Pi CM4, which has 6
> > > UARTs (UART1 is a mini UART, the others PL011) [1]. In the default
> > > configuration (including the mainline Linux broadcom/bcm2711-rpi-cm4-io
> > > device tree) the Bluetooth module is attached to UART0. Unless I either
> > > completely disable UART0 (status = "disabled" in the device tree) or
> > > reconfigure it to be a serial console (e.g. using the RPi disable-bt
> > > DTBO) U-Boot fails to boot, I assume (it doesn't get far enough to show
> > > messages over netconsole) because it tries and fails to set up a serial
> > > console where there's a BT chip listening.
> > >
> > > That happens even if another serial console is available: With the RPi
> > > bcm2711-rpi-cm4 DTB plus "disable-bt" (disable the Bluetooth module,
> > > reconfigure UART0 as a serial console) and "uart1" (set up a serial
> > > console on UART1) DTBOs I can see that U-Boot discovers the serial
> > > device on UART1 (serial at 7e215040):
> > >
> > > U-Boot> dm uclass serial
> > > uclass 108: serial
> > > 0   * serial at 7e201000 @ 3af3b200, seq 0
> > > 1     serial at 7e215040 @ 3af3b2d0, seq 1
> > >
> > > However, I can't find a way to make it *use* it instead of UART0
> > > (serial at 7e201000). I tried to set CONFIG_CONS_INDEX=1 but didn't see any
> > > change (unfortunately the help does not describe exactly how the number
> > > is mapped to DT UART definitions). If I completely disable UART0 in the
> > > DT as mentioned above U-Boot uses UART1 just fine, so it's not an issue
> > > with UART1 as such.
> > >
> > > To make matters slightly more complicated, the specific device I have is
> > > a RevPi Connect 4, where a vendor overlay [2] describes how to set up an
> > > RS485 serial console using UART5. The pins defined there are wired to
> > > the outside of the box [3], so eventually I'll actually want to use
> > > UART5 for the serial console. Which means I really need a (build-time or
> > > preferably DT-based) way to configure which serial device to use.
> > >
> > > My goal is to create a single DTS which both U-Boot and Linux can use,
> > > and get it upstreamed if possible. If there are configuration options
> > > and they're just missing from the documentation, I'd be happy to send a
> > > patch to add them once I have a solution.
> >
> > You should be able to update /chosen/stdout-path (in the devicetree)
> > to specify the UART you want, using its alias. So if you have a
> > 'serial1' alias, you can set stdout-path to 'serial1'. This should
> > work in Linux too.
> >
> > The code in question is serial_find_console_or_panic().
>
> While this may reflect how modern Linux handles things, this doesn't
> actually make a lot of sense to me.  And the clue is really in the
> name of the node under which the stdout-path resides.  That property
> is supposed to communicate to the OS what the firmware/bootloader
> picked as the console device rather than indicate to the
> firmware/bootloader what the console device should be.  This was how
> things worked back in the days of OpenFirmware where the firmware
> would pick an input and an output device based on firmware variables
> and whether a keyboard was plugged in or not and would set "stdin" and
> "stdout" properties under /chosen to reflect the choice made by the
> firmware.
>
> With this in mind it would make total sense to have U-Boot set
> /chosen/stdout-path based on some environment variable or other
> information.  Of course it might still make sense that the device tree
> used by U-Boot sets /chosen/stdout-path to indicate the default choice
> for the console device.  But it doesn't make senso to me to tell users
> that if they want to use a different console device they should go and
> edit the device tree...

Yes it is strange. I believe it comes from a time where U-Boot was not
allowed its own devicetree properties, so the 'console' alias used by
U-Boot back in 2015 was not allowed. The 'console' alias does not
support a baud rate as U-Boot's CONFIG_BAUDRATE handles that.

The theory was (if I remember correctly) that U-Boot can just use the
Linux information since it is presumably correct. I agree it is odd
and a bit backwards. There is code in fdt_support.c to set
linux,stdout-path but it seems pretty old and perhaps only used on
sunxi.

Would you like to create a series to tidy this up, assuming that we
can figure out an acceptable way to specify the UART in U-Boot?

Regards,
Simon