[U-Boot] U-boot 2017.07 not working on Raspberry Pi
I'm currently testing U-boot 2017.07 on Raspberry Pi, both on a Model B+ and a Raspberry Pi 3. On both devices I'm seeing two issues with u-boot:
* U-boot can't boot the Linux kernel, it just hangs at "Starting kernel ...".
* U-boot doesn't recognise any input via a USB keyboard.
These issues were not present in U-boot 2017.05. I see them both when building U-boot via OpenEmbedded and when building using arm-linux-gnueabi-gcc on Debian Stretch (GCC 6.3.0).
After bisecting to identify the commits which introduced these issues, I've found I can get a working U-boot by doing the following:
* Start with U-boot 2017.07
* Revert "dm: arm: rpi: Move to driver model for USB" (25085236)
* Revert "dm: arm: rpi: Use driver model for Ethernet" (d90385be)
* Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
* Drop CONFIG_USB_STORAGE as leaving this enables gives a compile error when CONFIG_DM_USB is not set.
I've staged these changes here for testing: https://gitlab.com/toganlabs/u-boot/commits/pbarker/rpi
Reverting these commits is definitely a step backwards though so I'm hoping for another solution. Has anyone else has seen these issues and got any ideas? Or has anyone else got U-boot 2017.07 working on the Raspberry Pi?
Please let me know if you need any more details.
Thanks,
On Wed, Aug 02, 2017 at 01:13:30PM +0100, Paul Barker wrote:
I'm currently testing U-boot 2017.07 on Raspberry Pi, both on a Model B+ and a Raspberry Pi 3. On both devices I'm seeing two issues with u-boot:
U-boot can't boot the Linux kernel, it just hangs at "Starting kernel ...".
U-boot doesn't recognise any input via a USB keyboard.
These issues were not present in U-boot 2017.05. I see them both when building U-boot via OpenEmbedded and when building using arm-linux-gnueabi-gcc on Debian Stretch (GCC 6.3.0).
After bisecting to identify the commits which introduced these issues, I've found I can get a working U-boot by doing the following:
Start with U-boot 2017.07
Revert "dm: arm: rpi: Move to driver model for USB" (25085236)
Revert "dm: arm: rpi: Use driver model for Ethernet" (d90385be)
Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
Drop CONFIG_USB_STORAGE as leaving this enables gives a compile
error when CONFIG_DM_USB is not set.
I've staged these changes here for testing: https://gitlab.com/toganlabs/u-boot/commits/pbarker/rpi
Reverting these commits is definitely a step backwards though so I'm hoping for another solution. Has anyone else has seen these issues and got any ideas? Or has anyone else got U-boot 2017.07 working on the Raspberry Pi?
We had to revert 25877d4e4c45451c5398aec3de50e0d5befe0e9f to add CONFIG_OF_EMBED back to get OpenBSD to continue working on the rpi3.
70bfcdc6bb6f969babd69efc49e1dc7a1faeca54 efi_loader: disk: iterate only over valid block devices
which is part of master/2017.09-rc1 was also required for someone that was booting off USB after changes made between 2017.05 and 2017.07.
Date: Thu, 3 Aug 2017 19:02:06 +1000 From: Jonathan Gray jsg@jsg.id.au
On Wed, Aug 02, 2017 at 01:13:30PM +0100, Paul Barker wrote:
I'm currently testing U-boot 2017.07 on Raspberry Pi, both on a Model B+ and a Raspberry Pi 3. On both devices I'm seeing two issues with u-boot:
U-boot can't boot the Linux kernel, it just hangs at "Starting kernel ...".
U-boot doesn't recognise any input via a USB keyboard.
These issues were not present in U-boot 2017.05. I see them both when building U-boot via OpenEmbedded and when building using arm-linux-gnueabi-gcc on Debian Stretch (GCC 6.3.0).
After bisecting to identify the commits which introduced these issues, I've found I can get a working U-boot by doing the following:
Start with U-boot 2017.07
Revert "dm: arm: rpi: Move to driver model for USB" (25085236)
Revert "dm: arm: rpi: Use driver model for Ethernet" (d90385be)
Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
Drop CONFIG_USB_STORAGE as leaving this enables gives a compile
error when CONFIG_DM_USB is not set.
I've staged these changes here for testing: https://gitlab.com/toganlabs/u-boot/commits/pbarker/rpi
Reverting these commits is definitely a step backwards though so I'm hoping for another solution. Has anyone else has seen these issues and got any ideas? Or has anyone else got U-boot 2017.07 working on the Raspberry Pi?
We had to revert 25877d4e4c45451c5398aec3de50e0d5befe0e9f to add CONFIG_OF_EMBED back to get OpenBSD to continue working on the rpi3.
That revert is in particular necessary for passthrough of the device tree from the Raspberry Pi firmwre to work. I haven't investigated this further yet, but it seems some of the relocation code is conditionalized on CONFIG_OF_EMBED, and I suspect that when CONFIG_OF_EMBED is absent, u-boot overwrites the device tree when it relocates itself.
Hi,
On 3 August 2017 at 03:37, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Thu, 3 Aug 2017 19:02:06 +1000 From: Jonathan Gray jsg@jsg.id.au
On Wed, Aug 02, 2017 at 01:13:30PM +0100, Paul Barker wrote:
I'm currently testing U-boot 2017.07 on Raspberry Pi, both on a Model B+ and a Raspberry Pi 3. On both devices I'm seeing two issues with u-boot:
U-boot can't boot the Linux kernel, it just hangs at "Starting kernel ...".
U-boot doesn't recognise any input via a USB keyboard.
These issues were not present in U-boot 2017.05. I see them both when building U-boot via OpenEmbedded and when building using arm-linux-gnueabi-gcc on Debian Stretch (GCC 6.3.0).
After bisecting to identify the commits which introduced these issues, I've found I can get a working U-boot by doing the following:
Start with U-boot 2017.07
Revert "dm: arm: rpi: Move to driver model for USB" (25085236)
Revert "dm: arm: rpi: Use driver model for Ethernet" (d90385be)
Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
Drop CONFIG_USB_STORAGE as leaving this enables gives a compile
error when CONFIG_DM_USB is not set.
I've staged these changes here for testing: https://gitlab.com/toganlabs/u-boot/commits/pbarker/rpi
Reverting these commits is definitely a step backwards though so I'm hoping for another solution. Has anyone else has seen these issues and got any ideas? Or has anyone else got U-boot 2017.07 working on the Raspberry Pi?
We had to revert 25877d4e4c45451c5398aec3de50e0d5befe0e9f to add CONFIG_OF_EMBED back to get OpenBSD to continue working on the rpi3.
That revert is in particular necessary for passthrough of the device tree from the Raspberry Pi firmwre to work. I haven't investigated this further yet, but it seems some of the relocation code is conditionalized on CONFIG_OF_EMBED, and I suspect that when CONFIG_OF_EMBED is absent, u-boot overwrites the device tree when it relocates itself.
I'm not sure why it needs CONFIG_OF_EMBED. Certainly U-Boot does relocate the DT when this is not set. But it should not be set for production images, only for debugging.
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
Regards, Simon
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Hi Paul,
On 3 August 2017 at 11:42, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not sure what is going on or why this would prevent the kernel booting. But I believe rpi has a device tree pass-through from the pre-U-Boot boot loader, and I am booting with that, so perhaps it relies on CONFIG_OF_EMBED in some way?
I can also repeat the USB keyboard problem. It doesn't detect the keyboard at all. For me this can be fixed by enabling CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
Re the Ethernet thing, what changes when you disable that?
Regards, Simon
Hi,
On 20 August 2017 at 20:59, Simon Glass sjg@chromium.org wrote:
Hi Paul,
On 3 August 2017 at 11:42, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not sure what is going on or why this would prevent the kernel booting. But I believe rpi has a device tree pass-through from the pre-U-Boot boot loader, and I am booting with that, so perhaps it relies on CONFIG_OF_EMBED in some way?
I can see some code in board_fdt_blob_setup() but it does not seem to be enabled. For me I am able to boot Linux without CONFIG_OF_EMBED.
I can also repeat the USB keyboard problem. It doesn't detect the keyboard at all. For me this can be fixed by enabling CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
I have sent a patch for this.
Re the Ethernet thing, what changes when you disable that?
Regards, Simon
On Fri, Aug 25, 2017 at 2:46 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On 20 August 2017 at 20:59, Simon Glass sjg@chromium.org wrote:
Hi Paul,
On 3 August 2017 at 11:42, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not sure what is going on or why this would prevent the kernel booting. But I believe rpi has a device tree pass-through from the pre-U-Boot boot loader, and I am booting with that, so perhaps it relies on CONFIG_OF_EMBED in some way?
I can see some code in board_fdt_blob_setup() but it does not seem to be enabled. For me I am able to boot Linux without CONFIG_OF_EMBED.
I can also repeat the USB keyboard problem. It doesn't detect the keyboard at all. For me this can be fixed by enabling CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
I have sent a patch for this.
This patch looks good. I've now got working keyboard and network in u-boot along with a successful boot of Linux for the 2 devices I've tested (Original rpi and rpi3 32-bit) from the following:
* U-boot 2017.07 release * Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e) * Apply backported version of your patch
The rpi firmware does provide a device tree blob at boot and my only guess is that this is currently being overwritten or ignored. That's masked when CONFIG_OF_EMBED is enabled as we use an embedded device tree instead of the one provided by the rpi firmware.
For u-boot v2017.09 release is it possible to re-enable CONFIG_OF_EMBED until we can find and fix the underlying issue? Or is there some reason to avoid CONFIG_OF_EMBED?
Re the Ethernet thing, what changes when you disable that?
CONFIG_DM_ETH was disabled purely as it depends on CONFIG_DM_USB on the Raspberry Pi and I'd disabled that to work around the USB keyboard issue. With CONFIG_DM_ETH, CONFIG_DM_USB and CONFIG_DM_KEYBOARD enabled everything looks good.
Thanks,
On Fri, Aug 25, 2017 at 10:46:55AM +0100, Paul Barker wrote:
On Fri, Aug 25, 2017 at 2:46 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On 20 August 2017 at 20:59, Simon Glass sjg@chromium.org wrote:
Hi Paul,
On 3 August 2017 at 11:42, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not sure what is going on or why this would prevent the kernel booting. But I believe rpi has a device tree pass-through from the pre-U-Boot boot loader, and I am booting with that, so perhaps it relies on CONFIG_OF_EMBED in some way?
I can see some code in board_fdt_blob_setup() but it does not seem to be enabled. For me I am able to boot Linux without CONFIG_OF_EMBED.
I can also repeat the USB keyboard problem. It doesn't detect the keyboard at all. For me this can be fixed by enabling CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
I have sent a patch for this.
This patch looks good. I've now got working keyboard and network in u-boot along with a successful boot of Linux for the 2 devices I've tested (Original rpi and rpi3 32-bit) from the following:
- U-boot 2017.07 release
- Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
- Apply backported version of your patch
The rpi firmware does provide a device tree blob at boot and my only guess is that this is currently being overwritten or ignored. That's masked when CONFIG_OF_EMBED is enabled as we use an embedded device tree instead of the one provided by the rpi firmware.
For u-boot v2017.09 release is it possible to re-enable CONFIG_OF_EMBED until we can find and fix the underlying issue? Or is there some reason to avoid CONFIG_OF_EMBED?
There is also CONFIG_OF_BOARD that is supposed to do something similiar but adding that to rpi_3_defconfig resulted in nothing on serial and a coloured splash screen from the gpu firmware on hdmi.
The only way to use the device trees that come with the firmware seems to be adding CONFIG_OF_EMBED. Without it the dtb header is missing from where fdt_addr_r points to (0x100), libfdt rightfully complains and anything expecting a device tree breaks.
U-Boot> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 78271 bytes read in 27 ms (2.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
OpenBSD/arm64 BOOTAA64 0.8
boot> boot -a cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 3804004+574452+508392+674936 [283297+96+448008+238164]=0x80df08
On 08/25/2017 03:46 AM, Paul Barker wrote:
On Fri, Aug 25, 2017 at 2:46 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On 20 August 2017 at 20:59, Simon Glass sjg@chromium.org wrote:
Hi Paul,
On 3 August 2017 at 11:42, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not sure what is going on or why this would prevent the kernel booting. But I believe rpi has a device tree pass-through from the pre-U-Boot boot loader, and I am booting with that, so perhaps it relies on CONFIG_OF_EMBED in some way?
I can see some code in board_fdt_blob_setup() but it does not seem to be enabled. For me I am able to boot Linux without CONFIG_OF_EMBED.
I can also repeat the USB keyboard problem. It doesn't detect the keyboard at all. For me this can be fixed by enabling CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
I have sent a patch for this.
This patch looks good. I've now got working keyboard and network in u-boot along with a successful boot of Linux for the 2 devices I've tested (Original rpi and rpi3 32-bit) from the following:
- U-boot 2017.07 release
- Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
- Apply backported version of your patch
The rpi firmware does provide a device tree blob at boot and my only guess is that this is currently being overwritten or ignored. That's masked when CONFIG_OF_EMBED is enabled as we use an embedded device tree instead of the one provided by the rpi firmware.
As background information, note that there are two ways U-Boot can work:
1) Load a DTB from "disk", and pass that to the kernel. This is typically used for upstream kernels, since at least historically the DTBs supplied by the RPi Foundation and loaded/modified by the VideoCore firmware use a non-upstream schema, so need to be replaced with an upstream-compatible DTB by U-Boot.
2) Pass through the DTB from the VideoCore firmware to the kernel. This is almost certainly required when booting a downstream RPi Foundation kernel.
Historically, U-Boot has only implemented option 1. I think recent versions of U-Boot support option 2, although you'd have to make some configuration(environment) changes to use that method. That's because historically, U-Boot has been targeted at booting upstream kernels.
I haven't investigated whether any of this is related to the problem you're seeing.
Hello Tom,
Am 03.08.2017 um 19:42 schrieb Tom Rini:
On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
On 08/03/2017 07:45 AM, Simon Glass wrote: ...
I'm not sure if we have a Raspberry Pi in a test farm anywhere. I should be able to look next week if no one can figure these out beforehand.
I thought that Tom had some Pis in his test farm?
I have an RPi 3, but we don't have Linux boot tests atm. I'm talking with Kevin Hilman about how I might setup kernelci to test a few things in my lab, which might catch this kind of problem sooner rather than later.
You might try tbot? I just writting a guide [1] how to setup tbot for a beagleboneblack, so I hope it is easier to start with...
I have running a weekly linux test for the beagleboneblack [2] beside the weekly U-Boot mainline tests on the beagleboneblack [3].
[2] based on the linux tree from Robert Nelson, tbot does: "git clone --reference=/home/git/linux.git git@github.com:beagleboard/linux.git linux-bbb" compiles/boots it and does some very basic tests (for example check all SoC registers defined in the files [4] under linux) ... you can easy expand this tests, as tbot does cmdline tests ... new board configs/testcases are welcome ;-)
bye, Heiko
[1] http://www.tbot.tools/guide.html [2] http://xeidos.ddns.net/buildbot/builders/bbb_lx last result: http://xeidos.ddns.net/tests/test_db_auslesen.php#387 [3] http://xeidos.ddns.net/buildbot/builders/bbb_ub last result: http://xeidos.ddns.net/tests/test_db_auslesen.php#386 [4] https://github.com/hsdenx/tbot/tree/master/src/files/bbb
On Thu, Aug 3, 2017 at 2:45 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 3 August 2017 at 03:37, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Thu, 3 Aug 2017 19:02:06 +1000 From: Jonathan Gray jsg@jsg.id.au
We had to revert 25877d4e4c45451c5398aec3de50e0d5befe0e9f to add CONFIG_OF_EMBED back to get OpenBSD to continue working on the rpi3.
That revert is in particular necessary for passthrough of the device tree from the Raspberry Pi firmwre to work. I haven't investigated this further yet, but it seems some of the relocation code is conditionalized on CONFIG_OF_EMBED, and I suspect that when CONFIG_OF_EMBED is absent, u-boot overwrites the device tree when it relocates itself.
I'm not sure why it needs CONFIG_OF_EMBED. Certainly U-Boot does relocate the DT when this is not set. But it should not be set for production images, only for debugging.
I've tried reverting just "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e) but I'm still left without a working keyboard in u-boot - hitting keys during the countdown does not interrupt the boot process. However the kernel can be booted with just that one commit reverted.
I've also looking into the CONFIG_OF_BOARD option. This is currently disabled for raspberrypi devices which means that board_fdt_blob_setup() in board/raspberrypi/rpi/rpi.c is not called. Enabling CONFIG_OF_BOARD leads to a crash at boot with no output from u-boot, the monitor connected to the raspberrypi just shows the colour palette.
I can look into this further but it probably needs to wait until I can order some RS232 adaptors and get a serial port setup for early debug output.
Thanks,
From: Paul Barker pbarker@toganlabs.com Date: Fri, 4 Aug 2017 13:58:50 +0100
On Thu, Aug 3, 2017 at 2:45 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 3 August 2017 at 03:37, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Thu, 3 Aug 2017 19:02:06 +1000 From: Jonathan Gray jsg@jsg.id.au
We had to revert 25877d4e4c45451c5398aec3de50e0d5befe0e9f to add CONFIG_OF_EMBED back to get OpenBSD to continue working on the rpi3.
That revert is in particular necessary for passthrough of the device tree from the Raspberry Pi firmwre to work. I haven't investigated this further yet, but it seems some of the relocation code is conditionalized on CONFIG_OF_EMBED, and I suspect that when CONFIG_OF_EMBED is absent, u-boot overwrites the device tree when it relocates itself.
I'm not sure why it needs CONFIG_OF_EMBED. Certainly U-Boot does relocate the DT when this is not set. But it should not be set for production images, only for debugging.
I've tried reverting just "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e) but I'm still left without a working keyboard in u-boot - hitting keys during the countdown does not interrupt the boot process. However the kernel can be booted with just that one commit reverted.
I've also looking into the CONFIG_OF_BOARD option. This is currently disabled for raspberrypi devices which means that board_fdt_blob_setup() in board/raspberrypi/rpi/rpi.c is not called. Enabling CONFIG_OF_BOARD leads to a crash at boot with no output from u-boot, the monitor connected to the raspberrypi just shows the colour palette.
I can look into this further but it probably needs to wait until I can order some RS232 adaptors and get a serial port setup for early debug output.
FWIW, I tried to enable CONFIG_OF_BOARD as well as an alternative to re-enabling CONFIG_OF_EMBED and didn't see any output on serial console in that case either. So debugging this probably requires enabling some more debug output.
participants (7)
-
Heiko Schocher -
Jonathan Gray -
Mark Kettenis -
Paul Barker -
Simon Glass -
Stephen Warren -
Tom Rini