Skip to content

U-boot: cannot boot rpi kernels #2123

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alexxy opened this issue Jul 19, 2017 · 19 comments
Closed

U-boot: cannot boot rpi kernels #2123

alexxy opened this issue Jul 19, 2017 · 19 comments

Comments

@alexxy
Copy link
Contributor

alexxy commented Jul 19, 2017

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
Copy link
Contributor

pelwell commented Jul 19, 2017

  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
Copy link
Contributor Author

alexxy commented Jul 19, 2017

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
Copy link

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
Copy link
Contributor

pelwell commented Jul 25, 2017

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
Copy link

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

@pelwell
Copy link
Contributor

pelwell commented Jul 25, 2017

Have you tried 32-bit kernels?

@DieterReuter
Copy link

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 #1788 (comment). But maybe the fix from @Electron752 wasn't completely merged into upstream (I'm just guessing).

@pelwell
Copy link
Contributor

pelwell commented Jul 25, 2017

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
Copy link
Contributor

6by9 commented Jul 25, 2017

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
Copy link

@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
Copy link
Contributor

Electron752 commented Jul 25, 2017 via email

@JamesH65
Copy link
Contributor

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
Copy link

pabiagioli commented Sep 9, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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

@pabiagioli
Copy link

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 JamesH65 reopened this Sep 13, 2017
@JamesH65
Copy link
Contributor

JamesH65 commented Sep 13, 2017

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
Copy link
Contributor

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

@atanasi
Copy link

atanasi commented Jul 1, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants