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.kette...@xs4all.nl> wrote:
From: Simon Glass <s...@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.kl...@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@7e215040):
U-Boot> dm uclass serial
uclass 108: serial
0 * serial@7e201000 @ 3af3b200, seq 0
1 serial@7e215040 @ 3af3b2d0, seq 1
However, I can't find a way to make it *use* it instead of UART0
(serial@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
