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