[PATCH] efi: efi-stub: notify on DTB absence

[Mark Rutland]

On Mon, Oct 20, 2014 at 08:10:38PM +0100, Roy Franz wrote:
> On Mon, Oct 20, 2014 at 11:49 AM, Mark Salter <msalter at redhat.com> wrote:
> > On Mon, 2014-10-20 at 19:29 +0100, Mark Rutland wrote:
> >> In the absence of an DTB configuration table, the EFI stub will happily
> >> continue attempting to boot a kernel, despite the fact that this kernel
> >> may not function without a description of the hardware. In this case, as
> >> with a typo'd "dtb=" option (e.g. "dbt=") or many other possible
> >> failures, the only output seen by the user will be the rather terse
> >> output from the EFI stub:
> >>
> >> EFI stub: Booting Linux Kernel...
> >>
> >> To aid those attempting to debug such failures, this patch adds a notice
> >> when no DTB is found, making the output more helpful:
> >>
> >> EFI stub: Booting Linux Kernel...
> >> EFI stub: Generating empty DTB
> >>
> >> Similarly, a positive acknowledgement is added when a user-specified DTB
> >> is in use:
> >>
> >> EFI stub: Booting Linux Kernel...
> >> EFI stub: Using DTB from command line
> >
> 
> Acked-by: Roy Franz <roy.franz at linaro.org>

Thanks.

> > Should we also include a positive acknowledgement of loader-provided
> > DTB? This could be UEFI itself or grub devicetree command or grub
> > generated minimal tree.
> 
> I could go either way on this.  We now identify the source of the DTB for 2 of
> the 3 sources, so there is some nice symmetry in always identifying where
> it is coming from.  I think that firmware or GRUB (ie from an EFI
> configuration table)
> will be the common/normal case, so I think it's also reasonable to
> just notify the user
> when something unusual is being done.

I think it's worthwhile adding a print along the lines of "Using DTB
from configuration table". It would make it easier to distinguish
between a current stub finding no DTB and a new stub finding a DTB
that's bogus. I'll respin with that added.

It might also make sense for the stub to announce the kernel version.
That would help with debugging because we would know the kernel version,
and from that we could derive the expected set out output in various
failure conditions.

Cheers,
Mark.

> 
> >
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> >> Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
> >> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> Cc: Mark Salter <msalter at redhat.com>
> >> Cc: Matt Fleming <matt.fleming at intel.com>
> >> Cc: Roy Franz <roy.franz at linaro.org>
> >> ---
> >>  drivers/firmware/efi/libstub/arm-stub.c | 9 ++++++++-
> >>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
> >> index 480339b..10abf24 100644
> >> --- a/drivers/firmware/efi/libstub/arm-stub.c
> >> +++ b/drivers/firmware/efi/libstub/arm-stub.c
> >> @@ -243,9 +243,16 @@ unsigned long __init efi_entry(void *handle, efi_system_table_t *sys_table,
> >>                       goto fail_free_cmdline;
> >>               }
> >>       }
> >> -     if (!fdt_addr)
> >> +
> >> +     if (fdt_addr) {
> >> +             pr_efi(sys_table, "Using DTB from command line\n");
> >> +     } else {
> >>               /* Look for a device tree configuration table entry. */
> >>               fdt_addr = (uintptr_t)get_fdt(sys_table);
> >> +     }
> >> +
> >> +     if (!fdt_addr)
> >> +             pr_efi(sys_table, "Generating empty DTB\n");
> >>
> >>       status = handle_cmdline_files(sys_table, image, cmdline_ptr,
> >>                                     "initrd=", dram_base + SZ_512M,
> >
> >
>