On 18/11/2016 14:49, Michal Suchanek wrote:

Hello,

this is like not part of this patch at all but is quite related.

There is a question that bugs me for a while.

I wanted to flash u-boot to an onboard memory (like a SPI NOR flash) alongside a devicetree for the device so I can load just bare zImage from anywhere the user points to and pass it the device tree from the flash.

I could probably modify the environment to just read the devicetree from the flash and be done with it for bare zImage.

But how do you do this when chainloading grub?

With EFI, there is something called "EFI tables". It's a list of various UUID identified blobs that are available to all EFI applications.

When booting an EFI grub2 application, you run "bootefi" with the address of the grub2 binary as well as an address to the device tree blob. The bootefi command will then push that device tree into a special dedicated DTB table.

Any program executed by grub2 (like Linux) will then also have access to that DTB table. Before running Linux, grub2 will also modify the dtb slightly to modify the command line property and initrd pointer.

On armv7, the flow described above is slightly different because upstream grub2 doesn't support running efi applications yet, so it directly jumps into zImage code. There is a patch in upstream grub2 that ensures grub2 passes the efi table dtb into zImage based boot.

Does that make sense so far?

Usually I don't expect people use the "bootefi" command directly. The usual code flow is using distro boot which automatically passed $fdt_addr to bootefi with fallback to the local u-boot device tree. So if you happen to have a board that can use the same device tree to drive U-Boot as well as Linux, you can seamlessly pass that all the way through.

Alex