* [PATCH] efi: efi-stub: notify on DTB absence
@ 2014-10-20 18:29 Mark Rutland
2014-10-20 18:32 ` Ard Biesheuvel
2014-10-20 18:49 ` Mark Salter
0 siblings, 2 replies; 5+ messages in thread
From: Mark Rutland @ 2014-10-20 18:29 UTC (permalink / raw)
To: linux-arm-kernel
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
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Salter <msalter@redhat.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Roy Franz <roy.franz@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,
--
1.9.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH] efi: efi-stub: notify on DTB absence
2014-10-20 18:29 [PATCH] efi: efi-stub: notify on DTB absence Mark Rutland
@ 2014-10-20 18:32 ` Ard Biesheuvel
2014-10-20 18:49 ` Mark Salter
1 sibling, 0 replies; 5+ messages in thread
From: Ard Biesheuvel @ 2014-10-20 18:32 UTC (permalink / raw)
To: linux-arm-kernel
On 20 October 2014 20:29, Mark Rutland <mark.rutland@arm.com> 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
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Matt Fleming <matt.fleming@intel.com>
> Cc: Roy Franz <roy.franz@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,
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] efi: efi-stub: notify on DTB absence
2014-10-20 18:29 [PATCH] efi: efi-stub: notify on DTB absence Mark Rutland
2014-10-20 18:32 ` Ard Biesheuvel
@ 2014-10-20 18:49 ` Mark Salter
2014-10-20 19:10 ` Roy Franz
1 sibling, 1 reply; 5+ messages in thread
From: Mark Salter @ 2014-10-20 18:49 UTC (permalink / raw)
To: linux-arm-kernel
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
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.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Matt Fleming <matt.fleming@intel.com>
> Cc: Roy Franz <roy.franz@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,
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] efi: efi-stub: notify on DTB absence
2014-10-20 18:49 ` Mark Salter
@ 2014-10-20 19:10 ` Roy Franz
2014-10-20 22:18 ` Mark Rutland
0 siblings, 1 reply; 5+ messages in thread
From: Roy Franz @ 2014-10-20 19:10 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 20, 2014 at 11:49 AM, Mark Salter <msalter@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@linaro.org>
> 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.
>
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Mark Salter <msalter@redhat.com>
>> Cc: Matt Fleming <matt.fleming@intel.com>
>> Cc: Roy Franz <roy.franz@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,
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] efi: efi-stub: notify on DTB absence
2014-10-20 19:10 ` Roy Franz
@ 2014-10-20 22:18 ` Mark Rutland
0 siblings, 0 replies; 5+ messages in thread
From: Mark Rutland @ 2014-10-20 22:18 UTC (permalink / raw)
To: linux-arm-kernel
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@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@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@arm.com>
> >> Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Cc: Mark Salter <msalter@redhat.com>
> >> Cc: Matt Fleming <matt.fleming@intel.com>
> >> Cc: Roy Franz <roy.franz@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,
> >
> >
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-10-20 22:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-20 18:29 [PATCH] efi: efi-stub: notify on DTB absence Mark Rutland
2014-10-20 18:32 ` Ard Biesheuvel
2014-10-20 18:49 ` Mark Salter
2014-10-20 19:10 ` Roy Franz
2014-10-20 22:18 ` Mark Rutland
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).