On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf <[email protected]> wrote: > > On 07/30/2018 02:39 PM, Alexander Graf wrote: > > On 07/30/2018 02:16 PM, David Rusling wrote: > >> Success. I now have a u-boot built on Arm64 that works. Along the > >> way I learnt various things: > >> > >> [1] Raspberry Pi's first stage loader generates the device tree. > >> Overlays are used to turn various things on (for example sound) at > >> boot time. > > > > Yes. In order for those to propagate into U-Boot you will want to > > enable CONFIG_OF_BOARD. That way the first stage generated DT gets > > consumed by U-Boot as well. This allows you to run on CM3 or have the > > same U-Boot binary for B and B+ for example. > > I forgot to mention that for this to work fully with propagation of that > same device tree to an upstream kernel, you will also want to add the > "upstream" overlay. Just add a line saying "dtoverlay=upstream" to > config.txt. Then plug in any installer or image that is UEFI enabled > (and works with DT) and it should boot.
Yuck. That's a fix-up applied to the RPi downstream dtb, right? I always just load my own (upstream) dtb. Who is providing the upstream overlay, and how do you do dtb updates in this case as what is upstream evolves? I'm just concerned this is very much RPi specific and how can EBBR define managing dtb updates/storage in a consistent way. Rob _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
