On 07/30/2018 06:02 PM, Rob Herring wrote:
On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf <ag...@suse.de> 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.

The downstream DT is actually derived from the upstream one. The upstream overlay is officially maintained in the downstream repo to bring compatibility back into upstream shape, without losing additional references that the downstream DT adds (that don't hurt upstream compatibility).

The main reason why I pushed for that model is that this way we can reuse the raspberry pi specific overlay mechanism and propagate a *single* device tree all the way from early boot to Linux.

EBBR itself isn't concerned with how the device tree gets into Linux, as long as firmware provides it one way or another and allows for updates. Whether firmware consumes it from yet another layer or not IMHO is out of scope of EBBR.


Alex

_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to