opened
gizero
username_0
Still nailing this down by bisecting poky repo (annoyingly lengthy task...), but looks like some recent commit on oe-core broke the capability of booting with u-boot in the chain... Anyone seeing this as well?

The boot hangs at 'Starting kernel ...' and at first glance the most evident difference w.r.t. a working sdcard image is that there is no mention of the dtb blob being used to boot.

A core-image-minimal built with both poky and meta-raspberrypi from their respective current master branches does show the issue.

To me the u-boot upgrade to 2017.07 (commit d2990a2da61b6a6078728cfa3715b3f4144398f7 in poky, b322e1b1cb4cd4d4cc53f868b53ca9b069772755 in oe-core) is a candidate to blame... I'll report back as soon as I finish bisecting this thing...
RPi not booting with latest u-boot from oe-core?
issue
created
gizero
username_0
Bisect confirmed it was the upgrade to u-boot v2017.07 to break the boot. I started digging into changes between v2017.05 and v2017.07 and it seems there is some meat on RPi side, most notably support for device tree overlay and configuration switch to driver model for both USB and MMC.
comment
created
betafive
username_1
I can confirm this on both raspberrypi and raspberrypi3. I also can't interrupt u-boot by hitting keys so it looks like it's ignoring the USB keyboard. I'm currently having a look upstream to see what's been changed.
comment
created
betafive
username_1
Upgrading the firmware to the latest commit from https://github.com/raspberrypi/firmware doesn't fix the issue.
comment
created
betafive
username_1
http://git.denx.de/?p=u-boot.git;a=commit;h=8b7d0924544156010a0b9e51dfa9b5985d136f64 is probably half the problem, support for Raspberry Pi devices is no longer maintained upstream.
comment
created
betafive
username_1
I've got a working u-boot by revering a couple of commits and dropping the CONFIG_USB_STORAGE option. See https://gitlab.com/toganlabs/u-boot/commits/pbarker/rpi if you want to test this.

I'm not going to merge these as patches against u-boot in meta-raspberrypi yet. I've sent an email to the u-boot list and will wait a couple of days to see what response I get.
comment
created
gizero
username_0
@username_1 Thanks for looking at it. I also tried the firmware upgrade way with no luck (used latest tagged release, not the master branch tip). From your reverts I realized my git grep was not catching all rpi related changes between the two u-boot releases: I'll look into it again while I already focused on DT and DM related changes... maybe I can figure out what really broke it. In the meanwhile, I'll keep an eye on the thread you opened on u-boot mailing list.
comment
created
gizero
username_0
Hi! I'd like to know what the general feeling is on this issue... @username_1 started [this](https://lists.denx.de/pipermail/u-boot/2017-August/300857.html) discussion on the the u-boot list a while ago: there was some feedback, but mostly focused on finding the minimal set of reverts required to make it functional again. Do you think it's time for crafting a patch/bbappend for meta-raspberrypi to overcome the problem or is it best stimulating the upstream again? Personally I don't think to have enough time/knowledge to look straight into the u-boot source for this: it has to do with apparently critical changes to how device tree and driver model get into the picture of current u-boot. More generally, loosing upstream maintenance for RPis will likely result in an increasing risk of breakage in builds that are based on oe-core master, since we rely on their u-boot recipe, which, as expected, is kept updated regularly. Not saying that i.e. pinning u-boot for meta-raspberrypi would be better, but maybe we can consider measures for having a stronger testing infrastructure to at least detect breakages early. @username_2 Are u-boot enabled configuration currently build tested by CI? Moreover, this specific issue was visible at runtime only, rendering it even sneakier... Looking forward to hearing your thoughts here...
comment
created
betafive
username_1
I've been a bit busy this week but going to look at this today. I'll put a set of minimal reverts in place in meta-raspberrypi so that we at least have something working for now.

I'm going to have a think about the upstream maintenance issue as well, I'm pretty heavily dependent on u-boot (as tftp boot saves so much time in testing) and don't want to see this stagnate.
comment
closed
agherzan
username_2
issue