On Tue, Jan 20, 2015 at 07:20:06PM +0000, Stefano Stabellini wrote:
> On Tue, 20 Jan 2015, Hanjun Guo wrote:
> > How about the patch (just RFC, maybe it is horrible :) ) below:
> >
> > When system supporting both DT and ACPI but firmware providing
> > no dtb, we can use this linux,uefi-stub-generated-dtb property
> > to let kernel know that we can try ACPI configuration data.
> >
> > Signed-off-by: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
> > ---
> > Documentation/devicetree/bindings/chosen.txt | 19 ++++++++++++++++
> > arch/arm64/kernel/setup.c | 34
> > +++++++++++++++++++++++++++-
> > drivers/firmware/efi/libstub/fdt.c | 6 +++++
> > 3 files changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/chosen.txt
> > b/Documentation/devicetree/bindings/chosen.txt
> > index ed838f4..18776b9 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -44,3 +44,22 @@ Implementation note: Linux will look for the property
> > "linux,stdout-path" or
> > on PowerPC "stdout" if "stdout-path" is not found. However, the
> > "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> > should only use the "stdout-path" property.
> > +
> > +
> > +linux,uefi-stub-generated-dtb property
> > +--------------------------------------
> > +
> > +UEFI stub will generate this property in the chosen node to let linux kernel
> > +know that there is no DTB provided by firmware.
> > +
> > +There is a use case for system supporting both DT and ACPI, when firmware
> > +doesn't provide DT, we can try ACPI configration data to boot the system.
> > +
> > +Usage:
> > +
> > +linux,uefi-stub-generated-dtb = "true" means that it is true that the dtb
> > +is generated by uefi stub
> > +
> > +or
> > +
> > +linux,uefi-stub-generated-dtb = "false" is the reverse.
>
> I am sorry to have to make the discussion even more complex than already
> is, however we have one more use case to consider: Linux booting on Xen
> as Dom0.
>
> When booting as Dom0 on ACPI hardware, Linux doesn't have access to the
> UEFI firmware (no EFI stub). Xen passes a small device tree blob with
> a chosen node, memory information and a pointer to the ACPI tables.
> It looks similar to the DTB passed to Linux by the EFI stub but it is
> generated by Xen instead.
We have two (or even three) different use cases here. One of them is a
way to tell the kernel that there is no point in trying DT since it has
been generated by the EFI stub and it doesn't have any SoC information.
The kernel can bet on ACPI tables being present or just fail to boot.
What I want to avoid is "acpi=force" parameter being part of the
kernel/firmware ABI for using ACPI (whether DT is present or not).
We could call this something else ("linux,bare-dtb"?) if we want to use
it in other situations but not "enable_acpi" as we don't want to move
the ACPI enabling policy in the EFI stub or boot loader (or whatever
generates the chosen node).
The Xen case is close to the kexec one. For the latter (I haven't looked
at the current arm64 patches yet), I can see that you can pass an
"acpi_rsdp" argument to the kernel with the ACPI RSDP address. I don't
think that's ideal, we better have some defined DT bindings for such
information in the absence of EFI. But it basically means that we'll
allow ACPI on arm64 without EFI.
I have some questions for the ACPI and EFI folk:
1. When booting with ACPI, are the EFI run-time services required for
anything? If yes, Xen may have a bigger problem
2. Could a boot loader (either kernel doing kexec or Xen) emulate the
EFI system/config tables and still make them useful to the kernel but
without EFI_BOOT or EFI_RUNTIME_SERVICES? This way Xen could emulate
the EFI stub generated DT but without additional bindings for the
RSDB address
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
