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.
[2] There's a big difference between fdt_addr and fdt_addr_r,
depending on whether you're running mainstream u-boot or rpi u-boot.
What should "mainstream" U-Boot refer to here? "fdt_addr" is the U-Boot
internal variable that it stores the location of the device tree to that
was passed into it from a previous stage. "fdt_addr_r" is what the
distro boot framework passes into whatever you load from within U-Boot.
There's also another one: "fdtcontroladdr". That's the one that U-Boot
consumes itself.
[3] RPI3 is not really fully upstream, various bits always need to be
added. In other words, RPi, like a lot of Arm boards has its own
mediated kernel tree, u-boot tree etc
That's not really true. We have a lot of happy customers running SLES
(and openSUSE) off a fully upstream U-Boot + Linux kernel stack. It only
gets hairy when you want to use things like the camera interface. Also
from my experience the vc4 driver is very unstable.
Alex
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
