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