On Thu, 2014-07-10 at 10:33 -0700, Roy Franz wrote:
On Thu, Jul 10, 2014 at 12:58 AM, Ian Campbell Ian.Campbell@citrix.com wrote:
On Wed, 2014-07-09 at 11:24 -0700, Roy Franz wrote:
- if ( fdtfile->ptr )
fdt_size = fdt_totalsize(fdtfile->ptr);- else
- {
/* RFRANZ_TODO - missing fdt_create_empty_tree() in libfdt. */return NULL;- }
I don't think we currently support booting with no FDT at all, and even in the ACPI world we would get one. So I think this would be an error. IOW no need to worry about it.
I think that for the ACPI-only case, the EFI stub will be the one responsible for creating the FDT for passing the UEFI/ACPI to the XEN kernel. (I had overlooked the ACPI-only case when considering the no-FDT case - for Linux we support this since a kernel could be configured such that it needs nothing from the FDT other than UEFI stuff, so we need to support it.) So I think we will need this, but only for the ACPI-only case.
I think you probably know better than I but I thought that the way the presence of ACPI was communicated to the kernel (whether via zImage or UEFI stub) was via entries in the FDT's /chosen/ node containing the address of the RSDP. Am I wrong about that?
Or maybe I'm thinking about the UEFI services tables being referenced via /chosen/?
Ian.
The ACPI tables are all referenced from the EFI system table, which is put into the FDT by the EFI stub. The EFI stub itself is completely ACPI agnostic - it just passes along the EFI structures that may or may not contain ACPI tables. The kernel will determine if ACPI support is present by looking for the ACPI tables in the EFI system table.
Some folks at the Linaro ACPI sprint explained this to me. I think I was confusing the ACPI pointers with the EFI handle, but even then I was wrong since this can be passed as a formal parameter to the UEFI entry point without any DTB being required. So you are right ;-)
Ian.