[U-Boot] [PATCH 1/2] efi_loader: Pass fdt address directly to bootefi cmd

[Stephen Warren <swarren@wwwdotorg.org>]

On 04/14/2016 07:48 AM, Alexander Graf wrote:
> On 04/14/2016 01:20 AM, Stephen Warren wrote:
>> On 04/13/2016 03:22 PM, Alexander Graf wrote:
>>> The bootefi cmd today fetches its device tree pointer from either the
>>> location appointed by "fdt addr" with a fallback to the U-Boot control
>>> fdt.
>>>
>>> This integration is unusual for U-Boot and diverges from the way we
>>> usually handle parameters to boot commands. So let's pass the fdt
>>> directly into the bootefi command instead and move the control fdt
>>> logic into the distro boot script.
>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>
>>> @@ -155,13 +154,7 @@ static unsigned long do_bootefi_exec(void *efi)
>>>        */
>>>       efi_save_gd();
>>>
>>> -    /* Update system table to point to our currently loaded FDT */
>>> -
>>> -    /* Fall back to included fdt if none was manually loaded */
>>> -    if (!fdt && gd->fdt_blob)
>>> -        fdt = (void *)gd->fdt_blob;
>>> -
>>> -    if (fdt) {
>>> +    if (fdt && !fdt_check_header(fdt)) {
>>>           /* Prepare fdt for payload */
>>>           fdt = copy_fdt(fdt);
>>>
>>> @@ -185,7 +178,7 @@ static unsigned long do_bootefi_exec(void *efi)
>>>           efi_add_memory_map(fdt_start, fdt_pages,
>>>                      EFI_BOOT_SERVICES_DATA, true);
>>>       } else {
>>> -        printf("WARNING: No device tree loaded, expect boot to
>>> fail\n");
>>> +        printf("WARNING: Invalid device tree, expect boot to fail\n");
>>
>> I'm not familiar with this code, so I'm not really sure what the
>> implication of this if/else is.
>>
>> Still, this looks like it's a move in the right direction. I do agree
>> the FDT address parameter likely should be optional, and if not
>> specified by the user default to whatever other bootz/booti default
>> too (I suspect $fdt_addr_r).
>
> So what bootz/booti do is to either take the 3rd parameter as fdt, have
> the fdt included in the image you boot (FIT or legacy combined images)
> and when it's loaded, they call
>
>    set_working_fdt_addr((ulong)images.ft_addr);
>
> which basically does the same as my previous "fdt addr". But I see no
> fallback to $fdt_addr_r. It just doesn't use an fdt if no fdt parameter
> / fit image was provided.

Ah yes, I guess that's true. No DTB parameter to the command means ATAGS 
boot for bootz at least, right? I'd expect booti to be different, but I 
haven't looked at that.