Linux: U-boot: cannot boot rpi kernels

[alexxy]

Hi!

I seems have problems booting rpi kernels with u-boot (mainline kernels boots fine) while rpi ones seems freezes right after u-boot loads them

HW is rpi2 rpi3(64bit mode)

[pelwell]

1. We don't provide support for UBoot, but with enough information we might be able to help.
2. You don't provided nearly enough information about how you've built and configured UBoot. I'm suspicious that the Device Tree isn't being located correctly - there may be some clues in this thread: https://www.raspberrypi.org/forums/viewtopic.php?p=1168070#p1168070

Hooking up a serial port to GPIOs 14 & 15 would probably help to diagnose the problem.

[alexxy]

Ok.

I use mainline u-boot
u-boot config is

setenv bootargs "earlyprintk dwc_otg.lpm_enable=0 root=/dev/mmcblk0p3 rootfstype=ext4 rootflags=commit=100,data=writeback elevator=deadline rootwait console=tty1 cma=256M@512M console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 net.ifnames=1"
setenv dtbfile boot/bcm2836-rpi-2-b.dtb
setenv machid 0x00000c42
saveenv
ext4load mmc 0:3 ${kernel_addr_r} boot/vmlinuz
ext4load mmc 0:3 ${fdt_addr_r} ${dtbfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}

So basicaly i use u-boot to laod device tree file

Layout of boot directory is

rpi /boot # LANG=C ls -l
total 15972
-rw-r--r-- 1 root root 2767563 Jul 13 01:05 System.map-4.12.0-gentoo
-rw-r--r-- 1 root root 1790248 Jul 13 10:52 System.map-4.12.0-raspberrypi-rpi+
lrwxrwxrwx 1 root root 48 Jul 13 21:30 bcm2836-rpi-2-b.dtb -> dtbs/4.12.0-raspberrypi-rpi+/bcm2709-rpi-2-b.dtb
-rw-r--r-- 1 root root 139850 Jul 13 01:05 config-4.12.0-gentoo
-rw-r--r-- 1 root root 138240 Jul 13 10:52 config-4.12.0-raspberrypi-rpi+
drwxr-xr-x 4 root root 4096 Jul 13 10:56 dtbs
drwxr-xr-x 6 root root 16384 Jan 1 1970 firmware
lrwxrwxrwx 1 root root 31 Jul 13 10:52 vmlinuz -> vmlinuz-4.12.0-raspberrypi-rpi+
-rw-r--r-- 1 root root 6054656 Jul 13 01:05 vmlinuz-4.12.0-gentoo
-rw-r--r-- 1 root root 5428336 Jul 13 10:52 vmlinuz-4.12.0-raspberrypi-rpi+

[DieterReuter]

I've just tested it today and can confirm, that U-Boot isn't able to boot a RPi linux kernel. The kernel image will be loaded and started but no kernel output appears on the UART console:

U-Boot 2017.07-bee42 (Jul 23 2017 - 11:52:23 +0000)

DRAM:  944 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e300000: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr.uimg
reading /boot.scr.uimg
431 bytes read in 17 ms (24.4 KiB/s)
## Executing script at 02000000
reading bcm2710-rpi-3-b.dtb
17867 bytes read in 18 ms (968.8 KiB/s)
reading Image
12567040 bytes read in 768 ms (15.6 MiB/s)
## Flattened Device Tree blob at 00000100
   Booting using the fdt blob at 0x000100
   reserving fdt memory region: addr=0 size=1000
   Loading Device Tree to 000000003ab46000, end 000000003ab4d5ca ... OK

Starting kernel ...

Tested with kernel 4.9.39 built in 64bit for RPi.

I thought we had resolved this issues in February when @Electron752 introduced a fix for it, seen in this issue #1788.

[pelwell]

Reading your u-boot config again I see that you are loading bcm2709-rpi-2-b.dtb. Shouldn't that be bcm2837-rpi-3-b.dtb built from the arch/arm64 tree?

[DieterReuter]

I've tested both versions of the .dtb with the same result.

[pelwell]

Have you tried 32-bit kernels?

[DieterReuter]

No, I'm right now only interested in building a 64bit OS for the RPi. And I know we did resolved this issue back in January, see this comment https://github.com/raspberrypi/linux/issues/1788#issuecomment-272188442. But maybe the fix from @Electron752 wasn't completely merged into upstream (I'm just guessing).

[pelwell]

I'm afraid I can't offer you any support - we don't use U-boot and we don't support it (or the 64-bit kernel) beyond answering questions about the kernel and firmware and cooperating when a problem is found.

You have much more chance of getting help in a U-boot forum.

[6by9]

Silly question, but I assume you've built the 64 bit version of u-boot. rpi_3 vs rpi_3_32b.
AIUI Once the ARM has been booted in 32 bit mode it can't be switched to 64 bit (or vice versa).

[DieterReuter]

@6by9 yes, u-boot is built in 64bit using rpi_3_defconfig. The Pi bootloader boots the CPU in 64bit mode and loads the u-boot. Then you're able to load and boot a 64bit Linux kernel via u-boot. And yes, you can't switch the CPU from 32 to 64bit mode, this has to be done by the Pi bootloader.

[Electron752]

On Tue, 2017-07-25 at 16:36 +0000, Dieter Reuter wrote:

@6by9 yes, u-boot is built in 64bit using rpi_3_defconfig. The Pi
bootloader boots the CPU in 64bit mode and loads the u-boot. Then
you're able to load and boot a 64bit Linux kernel via u-boot. And
yes, you can't switch the CPU from 32 to 64bit mode, this has to be
done by the Pi bootloader.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi,
Just to let everyone know I don't have any plans to contribute much
more to the Pi.  
64 bit has always been experimental, and I've been spending more time
on other things in my life ATM.   Part of the issue is that it's just
too time consuming for me to deal with the process part of things such
as getting changes merged.
Perhaps someone else may be willing to pick up where I left off and
continue onward.
Thanks.

  
  

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/raspberry
pi/linux","title":"raspberrypi/linux","subtitle":"GitHub
repository","main_image_url":"https://cloud.githubusercontent.com/ass
ets/143418/17495839/a5054eac-5d88-11e6-95fc-
7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent
.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-
b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/raspberrypi/linux"}},"updates":{"sn
ippets":[{"icon":"PERSON","message":"@DieterReuter in #2123: @6by9
yes, u-boot is built in 64bit using rpi_3_defconfig. The Pi
bootloader boots the CPU in 64bit mode and loads the u-boot. Then
you're able to load and boot a 64bit Linux kernel via u-boot. And
yes, you can't switch the CPU from 32 to 64bit mode, this has to be
done by the Pi bootloader."}],"action":{"name":"View
Issue","url":"https://github.com/raspberrypi/linux/issues/2123#issuec
omment-317794352"}}}

[JamesH65]

Welcome to the world of trying to get new code in the Linux kernel....not an easy or pleasant experience.

Small bug fixes? Usually OK. Big code changes? A nightmare of Brobdingnagian proportions.

[pabiagioli]

Hi, I have a Raspberry Pi 3 configured to work with 64-bit and made the following:
This is my boot script for uboot, the issue for me was the ${fdt_addr_r} variable, so I loaded the dtb file in the address 0x2000000
boot.cmd

setenv ipaddr 192.168.7.101
setenv serverip 192.168.7.100
setenv bootargs "8250.nr_uarts=1 console=ttyS0,115200 root=/dev/nfs ip=192.168.7.101 nfsroot=192.168.7.100:/srv/nfs-root rw rootwait"
fatload mmc 0:1 0x2000000 bcm2710-rpi-3-b.dtb
fatload mmc 0:1 ${kernel_addr_r} Image
booti ${kernel_addr_r} - 0x2000000

This is my config.txt

arm_control=0x200
enable_uart=1
kernel=u-boot.bin
#have a properly sized image
disable_overscan=1

# Uncomment this to disable the Bluetooth module on /dev/ttyAMA0
dtoverlay=pi3-miniuart-bt

gpu_mem=128

Now it works and I'm able to load rootfs through NFS
You'll need to tune bootargs with your own values
Cheers

[Electron752]

HI, I just also wanted to let others know since I keep getting pinged about the PI from time to time. I'm focusing my attention on a different platform for now. It's the BeagleBone from TI.

Even though for raw computing the PI blows the BeagleBone out of the water, the BeagleBone appears to be more suited for my interests at this time. The focus of the PI appears to be more about a low cost desktop or set top box replacement with some ability to do hardware tinkering. The BeagleBone appears to be a bit more for the DIY hardware types.

As far as I can tell, the only part of the BeagleBone that isn't documented is the 3D acceleration, which is completely optional. You can get video through HDMI without it. Everything else is 100% documented in the over 100 page board level manual and the 4,000 page soc manual.

I'm really digging the PRU units which as 100% deterministic and have alot of the feel of traditional 8 bit MCUs, but are integrated on the chip and run at 200MHz. Quite awesome for controlling external devices with bit banging...

[JamesH65]

Closing, as this thread is not supposed to be an advert for the BB

[pabiagioli]

Hi @JamesH65
I was hoping to get the issue closed because of a fix, not because of bad advertisement. Can we open another issue referencing this one? I'm really interested in this bug to be closed as well but for the right reasons.

Cheers
Pablo

[JamesH65]

We don't support 64 bit OS's (we don't supply one) so the amount of support we can give on it is limited. Others may be able to help, so have reopened the issue.

What is it though, that you actually need a fix for? You last post seems to say things are working OK.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.

[atanasi]

In my case, the FDT file provided in the firmware package was incorrect and caused the kernel to hang. When booting, the firmware passes an internal version of the FDT to u-boot, and this one worked. So, instead of loading the FDT from a file, I had to pass the version provided by the firmware. The address of the provided FDT is in the variable fdtcontroladdr.

fatload mmc 0 ${kernel_addr_r} kernel.img
setenv bootargs console=ttyS0,115200n8 console=ttyAMA0,115200n8 console=tty0
booti ${kernel_addr_r} - ${fdtcontroladdr}

If one prefers to load the FDT from a file, for example to apply overlays, u-boot can save the FDT from the memory to a USB stick. Saving to the SD card did not work for me, it received an error condition and got stuck.