Selecting serial device for console

Mark Kettenis mark.kettenis at xs4all.nl
Wed Aug 7 00:33:00 CEST 2024


> 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...

Cheers,

Mark


More information about the U-Boot mailing list