Selecting serial device for console

[Fiona Klute]

Hi Simon, Mark,

thanks for your replies!

Am 08.08.24 um 16:28 schrieb 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().

I can see there that it *should* be using the serial device from
/chosen/stdout-path with CONFIG_OF_CONTROL=y (which I have set), but if
I set it in the described form (alias to UART5:baudrate, I can share my
DTS if that helps) U-Boot doesn't start. Unfortunately without the
console it's hard to see *why*, I'll have to see if anything appears if
I connect an HDMI display.

In general, should U-Boot be able to use an RS485 output via UART
configured via DT (like [1]), or would I need to do board-specific
config for that? With the RevPi Connect 4 device I have it's the only
serial console that's accessible without opening the box. I have also
noticed that both drivers/serial/serial_bcm283x_mu.c and
drivers/serial/serial_bcm283x_pl011.c contain some odd checks on whether
a serial UART is usable as a console, but I'm not sure if they'd
interfere here (because GPIO 15 is part of the RS485 setup).

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

In general I agree, on RPi-based devices having the bootloader apply DT
overlays is pretty normal though (whether that's a good idea may be up
for debate). That said, another issue I see is that U-Boot seems to fail
to boot without a valid serial console even though
CONFIG_REQUIRE_SERIAL_CONSOLE is not set. If I had a way around that
it'd be enough for my immediate issue, even though a working serial
console would be very much preferable. ;-)

Best regards,
Fiona

[1]
https://gitlab.com/revolutionpi/linux/-/blob/4ae9a35871799004300f83694a24359a7b4ef8fa/arch/arm/boot/dts/overlays/revpi-connect4-overlay.dts#L281-292