[U-Boot] U-boot 2017.07 not working on Raspberry Pi

[Jonathan Gray]

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 at chromium.org> wrote:
> > Hi,
> >
> > On 20 August 2017 at 20:59, Simon Glass <sjg at chromium.org> wrote:
> >> Hi Paul,
> >>
> >> On 3 August 2017 at 11:42, Tom Rini <trini at 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 at 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