Hi Fiona, On Sat, 10 Aug 2024 at 04:14, Fiona Klute <fiona.kl...@gmx.de> wrote: > > 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.
Indeed. If you have JTAG access that can help, or you could enable a debug UART and use printch(), etc. to see where it gets to. If the serial driver dies, U-Boot will stop. I have the same issue on another board and created hacky patch[2] but have not got around to doing it properly. I suppose you can disable CONFIG_SERIAL_PRESENT but then you will need some other way to test the device. > > 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? I don't know...I thought that was a broadcast type of thing. In Linux I believe the UART gets put in a special mode, so U-Boot would need to support that too. > 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). I'm not sure > > >> 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. ;-) > Enabling DEBUG_UART on rpi would be a worthy goal. It can be a little tricky if there is pinmux, etc. But on another board I figured it out by tracking the register writes done in a normal startup, then writing new code to include those in the board_debug_uart_init() Regards, Simon > > [1] > https://gitlab.com/revolutionpi/linux/-/blob/4ae9a35871799004300f83694a24359a7b4ef8fa/arch/arm/boot/dts/overlays/revpi-connect4-overlay.dts#L281-292 > [2] https://patchwork.ozlabs.org/project/uboot/patch/20231101180447.99361-1-...@chromium.org/
