[U-Boot] efi_loader: Add distro boot script for removable media

[Alexander Graf]

On 13.04.16 19:54, Stephen Warren wrote:
> I've spotted a couple of problems in 74522c898b35 "efi_loader: Add
> distro boot script for removable media". These help explain something I
> found strange in the commit description of the recently sent patch
> "jetson-tk1: Set fdtfile environment variable"; "The 4.5.0 kernel cannot
> cope with U-Boot's internal device tree".
> 
>>     "load_efi_dtb="                                                   \
>>         "load ${devtype} ${devnum}:${distro_bootpart} "           \
>>             "${fdt_addr_r} ${prefix}${fdtfile}; "             \
>>         "fdt addr ${fdt_addr_r}\0"                                \
>>     \
> 
> The "fdt addr" command shouldn't be there. That affects the DT that
> U-Boot's internal commands operate on internally. That is entirely
> unrelated to the the DT that is passed to the Linux kernel. Instead, the
> EFI code should pass the DTB at ${kernel_addr_r} to the kernel, just
> like all other boot mechanisms do.

I guess you mean $fdt_addr_r?

I wasn't sure which one to pick back when I implemented it. "fdt addr"
seemed like a nice fit because it gets you an explicit fdt rather than a
"this is an address, go and see whether there happens to be a dtb loaded
there".

But I don't think it'll hurt to move it to fdt_addr_r instead.

> If by some chance U-Boot is configured by DTB and that DTB is fully
> suitable to pass to the Linux kernel, then the board-specific code can
> arrange for ${kernel_addr_r} to point at that same DTB, thus removing
> the need to load one. However, that's unlikely to happen too often at
> present; the most complete DTBs are housed in the Linux kernel source
> tree, and DTB ABI still isn't really a thing, so in practice one mostly
> wants to load a DTB that was built as part of the kernel being booted,
> and hence U-Boot's DTB isn't relevant.

It depends on the camp you're coming from ;). If you come from the
traditional server camp that used to work with server class ppc in the
past, then device tree by firmware is a pretty natural concept. Also,
all ARM servers available today have a stable dtb ABI, because they all
provide dtb via uEFI.

In the embedded world this doesn't hold true quite as well
unfortunately. People only realize that their device trees are
incomplete / wrong when they write the respective drivers. So there we
see much more churn.

Over time however as a platform ages, the "embedded" style systems
should end up with stable dtbs as well, at which point having them
provided by U-Boot straight away is a nice compromise.


Alex