No Serial console for u-boot until Linux has run

Hi folks,
I have a Connect Tech Astro carrier with TX2 hooked up to a serial console. When applying power, it boots into Linux. But I don’t see any bootloader output on the serial console: the first output is Linux kernel output.

If I reboot linux without power cycling, I see bootloader output and can interrupt u-boot loading to start PXE or similar.

How can I change things so as to get serial communication with u-boot without booting Linux first?
My guess is that something isn’t being initialised properly by one of the boot loader stages.

I do see serial output when flashing in recovery mode.

– Peter C

U-Boot and the Linux kernel set up serial console separately. U-Boot and Linux both probably need device tree changes to set up the serial UART correctly. I’m just guessing (and I have no experience with Connect Tech boards), but perhaps the U-Boot setup has something extra to do before it will work at that stage. In the dev carrier the regular 16550A mode is set up in U-Boot to the correct port, and then within Linux the older 16550A mode driver is also used. An alternate driver once in Linux is the NVIDIA DMA-capable driver (U-Boot doesn’t understand DMA so if you want continuity of service then both U-Boot and the kernel need to set up for ttyS0…the “high speed” DMA-capable UART would have used “ttyTHS0” instead of “ttyS0”).

Yes I know. The thing is, after the board undergoes a soft reboot, serial output comes from the first-stage bootloader (so I see,

[0000.195] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mobile-175b7c7b)

On power up this info doesn’t appear. I don’t have source to the early boot code, to see if it’s trying to set up the clocks and UART correctly. Linux can talk to /dev/ttyS0 perfectly well.

The Connect Tech carrier is meant to be compatible with the NVIDIA boards. The only DTS changes are for added peripherals; the basics for the UART and clocks are the same.

hello t50,

you may also refer to [TX2 Boot Flow] via [NVIDIA Tegra Linux Driver Package]-> [Development Guide]

If Connect Tech boards use the same device tree for serial console (and I don’t know if they do), then you would still have to disable serial console in U-Boot…and for this specific case (if the same device tree is used for serial console), then the disable of serial console in U-Boot would also be the same (the documents on boot flow would apply without modification).

This is a URL talking about alternate serial consoles…the idea would be the same, except you would not enable the new serial console port:

Maybe I’m not making myself clear. The problem is that on power up there is no serial console until Linux starts. Only after a warm reboot (sudo reboot in linux) do I see console output from the early bootloader and from U-Boot.

I want serial console for cboot and u-boot after a power cycle, without having to boot into Linux first.

The boot loader stages have their own device tree configuration and options. I don’t know what needs to be done for this particular board, but Connect Tech would probably need to supply an updated CBoot and U-Boot…or at least the part of the device tree those stages look at (I have no way to know what details are needed).

Early on in L4T history the device tree was stored as a regular file and loaded from “/boot” by U-Boot (but U-Boot only passed it to Linux and did not use the tree for its own purposes). When the TX1 and TX2 merged to use the same sample rootfs file system the device tree was moved into a partition. This partition is now read in early boot stages (and no longer ignored by early stages), and passed on from one stage to the next (after edits). Thus Connect Tech might have device tree options affecting serial console as early as CBoot. If this is the case, then flash of that device tree might do what you want (I have no experience with their boards, I can only tell you why you need to look into a device tree specific to their carrier board). Connect Tech would have to answer as to whether there is some customization allowing those early stages to show serial console.

Turns out this is a hardware issue. The RS485 transceiver is held in hi-Z state until around 45 seconds after power is applied. So the serial port is inoperative until then.

The device trees were obviously OK because they worked on warm-boot.