-1

How does U-Boot change how the kernel is communicating through UART?

I'm trying to add U-Boot to our project. We build a custom Linux 64 bit kernel with initRAM linked into the kernel.

I have access to the U-Boot shell but when I'm trying to boot the uncompressed Image

mmc dev 0
fatload mmc 0:1 ${kernel_addr_r} Image
fatload mmc 0:1 ${fdt_addr} bcm2710-rpi-cm3.dtb
setenv bootargs console=serial0,115200 console=tty1
booti ${kernel_addr_r} - ${fdt_addr}

I get no kernel output after Starting kernel ...

What confuses me is that if I start the kernel directly through config.txt I do get the expected behavior.

The kernel command line is in both cases console=serial0,115200 console=tty1 Set either by cmdline.txt or through boot.scr.

Is U-Boot changing somehow the routing of the UART's? Why would the kernel have different behavior solely by starting it through U-Boot? Shouldn't U-Boot be completely out of the picture after the kernel is started, thus have no impact on the kernel output?

sawdust
  • 16,103
  • 3
  • 40
  • 50
obvg
  • 129
  • 12
  • You're focusing in the wrong place. U-Boot code has no affect on the console because the kernel performs its own, full initialization of the serial port. No kernel output usually means the kernel failed to boot (e.g. panicked) before various drivers completed initialization to start the serial console. Sometimes `earlycon` or `earlyprintk` helps. Your use of an uncompressed Image file is unusual. That puts a strict requirement on the value of **kernel_addr_r** (that a zImage would not have). Exactly what is in that `config.txt` or `cmdline.txt` or `boot.scr`? – sawdust Apr 30 '22 at 20:18
  • See https://stackoverflow.com/questions/24237673/why-is-kernel-boot-too-late/24337389#24337389 But beware that your kernel could be configured to *ignore* the command line provided by U-Boot; see https://stackoverflow.com/questions/68307458/how-to-set-linux-kernel-command-line-on-arm/68340492#68340492 If that still fails to generate any console output, then boot failure may be occurring very early in kernel code. Again, look at **kernel_addr_r** (and **fdt_addr**), or simply use a zImage instead. – sawdust Apr 30 '22 at 20:30
  • 1
    **Edit** Didn't see the second comment. Comma check that out on monday!**Edit** The point is that if I start the kernel just with raspberry pi infrastructure (e.g. bootcode.bin, start.elf) everything works just fine. But if I put U-Boot in the equation the kernel suddenly fails to boot. From my understanding U-Boot should have no impact on how the kernel boots, further than initiating the boot itself. The use of uncompressed Image is due to 64 bit kernel. The zImage format just exists for 32-bit (Am I wrong?) Compression needs to be done by the user. (Later step) – obvg May 01 '22 at 06:44
  • "*From my understanding U-Boot should have no impact on how the kernel boots ...*" Your understanding is simplistic. Note that other people had similar issues: see https://www.google.com/search?q=u-boot+%22Starting+kernel%22 The reasons for kernel boot failure with no console output are numerous. – sawdust May 02 '22 at 01:07
  • `serial0` does not look like a typical Linux serial device name. They generally start with the letters `tty`. What is the value of the `compatible` string for the serial port in the kernel's device tree? That can be checked against the kernel sources to determine the kernel device naming pattern for the matching devices. – Ian Abbott May 04 '22 at 15:32
  • Try `console=ttyS0,115200`. That should work for RPi 3 and RPi Zero W onwards. For older RPis without bluetooth, try `console=ttyAMA0,115200` instead. – Ian Abbott May 04 '22 at 15:47
  • @IanAbbott Like always other tasks took away from me. But somehow while revisiting I managed. I used `console=ttyAMA0,115200 printk.devkmsg=on usbcore.autosuspend=-1 fsck.mode=force fsck.repair=yes` on my cm3. I'm pretty sure I used that already without success, but here we are... I'm answering my question in more detail. But thanks for the productive input! Also serial0 and serial1 are official aliases for primary and secondary uart. Comes handy when your uarts change, as serial0 always defaults to the primary uart. – obvg Aug 02 '22 at 08:40

1 Answers1

0

After some time with other tasks at hand I revisited the problem and literally magically found a working config. I still don't understand how the same kernel command line worked coming from cmdline.txt but not from u-boot's bootargs. Until further proof I'll assume gross negligence on my side. ^^

So now I'll post my boot.cmd for our cm3 and 3B+ in hopes it helps others.

cm3

setenv fdtfile bcm2710-rpi-cm3.dtb

mmc dev 0
fatload mmc 0:1 ${kernel_addr_r} Image
fatload mmc 0:1 ${fdt_addr} ${fdtfile}
setenv bootargs console=ttyAMA0,115200 printk.devkmsg=on usbcore.autosuspend=-1 fsck.mode=force fsck.repair=yes
booti ${kernel_addr_r} - ${fdt_addr}

3B+

setenv fdtfile bcm2710-rpi-3-b.dtb

fatload mmc 0:1 ${kernel_addr_r} Image
fatload mmc 0:1 ${fdt_addr} ${fdtfile}
setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
booti ${kernel_addr_r} - ${fdt_addr}

Disclaimer: This is a rough cut. But as I fell into despair making this work I wanna get this solution out as fast as possible

obvg
  • 129
  • 12