Open manuel-wagesreither opened 3 years ago
The netboot firmware seems to take enable_uart=1
into account only when the whole string resides below the 0x1000
boundary. It gets ignored if the final 1
character is at ≥ 0x1000
of config.txt
. This does not apply when usb-booting the device.
Here's a config.txt which boots the device but will result in 8250.nr_uarts=0
. Serial console will not work.
00000fe0 61 64 20 74 68 65 20 45 44 49 44 20 64 61 74 61 |ad the EDID data|
00000ff0 20 66 72 0a 65 6e 61 62 6c 65 5f 75 61 72 74 3d | fr.enable_uart=|
00001000 31 0a 23 23 20 20 20 20 20 64 65 76 69 63 65 0a |1.## device.|
00001010 23 23 0a 23 23 20 20 20 20 20 56 61 6c 75 65 20 |##.## Value |
When you remove any character before the enable_uart=1
at line 119, 8250.nr_uart
will be 1
and serial console will work as expected.
00000fe0 61 64 20 74 68 65 20 45 44 49 44 20 64 61 74 61 |ad the EDID data|
00000ff0 20 66 0a 65 6e 61 62 6c 65 5f 75 61 72 74 3d 31 | f.enable_uart=1|
00001000 0a 23 23 20 20 20 20 20 64 65 76 69 63 65 0a 23 |.## device.#|
The is a difference in the two lines. The top one (broken) is
fr.enable_uart=1
The bottom on is
`f.enable_uart=1'
Looks like there is a typo, but it probably should be able to handle if the line is >_ 0x1000
@adudek16 The .
here is used because the 0x0A character (a newline) cannot be printed in the hex view. Here the .
is where the line starts, so they both say enable_uart=1
, there is no typo.
I had the exact same problem with RaspberryPI3 booting over PXE and your issue saved my time.
I confirm that if we remove all of the comments in config.txt file, it works fine.
Did someone know where is the limit of 0x1000 exactly ? Raspberry PI bootcode ?
IIRC its somewhere deep down in the file handling code in the bootloader, which we haven't touched in ten years, so people are reluctant to make changes to it. Could be wrong, sure someone will correct me if so!
Thank you for posting this issue - it's a couple years later, but the same/similar issue still appears to be present with the serial console during a PXE boot, and shortening the config.txt resolved it for me as well, so this report was a real lifesaver. Your attention and diligent work tracking this down saved me a bunch of time, so again, thank you very much!
Problem description
When booting my Raspberry Pi 4B using a USB drive, I receive diagnostic information via UART while booting and can login through said UART afterwards. When netbooting the device and providing the exact same set of boot files (verified with
md5sum
) through TFTP, the device stops to send data through UART early during boot.It seems to me, some part of the firmware forces the kernel parameter
8250.nr_uarts
to0
when netbooting. Even when I set8250.nr_uarts=1
incmdline.txt
, I get8250.nr_uarts=0
in/proc/cmdline
of the netbooted system. This is not the case when usb booting the device.Expected behaviour
While netbooting, the kernel sends diagnostic information over serial. After boot, it provides a console interface over serial interface.
Actual behaviour
Kernel neither sends diagnostic information, nor does it provide a console interface over UART when netboot is used.
How to reproduce
/proc/cmdline
and notice that8250.nr_uarts=1
./proc/cmdline
and notice that8250.nr_uarts=0
.System information
vcgencmd version
:Feb 25 2021 12:10:40 version 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) (release) (start)
Linux raspberrypi4-64 5.4.59-v8 #1 SMP PREEMPT Fri Aug 28 21:04:05 UTC 2020 aarch64 GNU/Linux
Configuration
cmdline.txt
:dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=/dev/sda2 rootfstype=ext4 rootwait 8250.nr_uarts=1
config.txt
:Logs
/proc/cmdline
of netbooted device:/proc/cmdline
of usb booted device:Serial mappings on both the netbooted and usb booted system
/proc/device-tree/aliases/serial0
:/soc/serial@7e215040pi
/proc/device-tree/aliases/serial1
:/soc/serial@7e201000
Received UART data when netbooting:
For comparison, received UART data when usb booting:
Additional tags for search indexer