On Mon, Sep 30, 2013 at 12:16:08PM -0700, Roy Franz wrote:
> >> So ... I guess that would modify the stub behaviour to:
> >> - Look for an FDT_GUID configuration table.
> >> - If there, use it.
> >> - If not there, require one to be loaded based on command line.
> >
> > Create a mostly empty one for passing freeform data to the kernel
> > proper; this is what it will look like on ACPI systems.
>
> So for ACPI systems the stub will package the ACPI data into the FDT?
> What would the stub be putting into the FDT that an ACPI/UEFI aware kernel
> couldn't get itself at runtime from UEFI?
No - it would just pass the EFI System Table pointer, just like it
does now.
> >> And the GRUB behaviour to:
> >> - If no FDT_GUID, require FDT if initrd.
> >> - If FDT_GUID, copy FDT + add initrd information.
> >>
> >> The x86 code uses bootparam to pass the kernel command line.
> >> Could we use the FDT exists) for the kernel command line
> >> too? This would make more code shared between x86 and ARM*, since
> >> otherwise we would need to explicitly implement (UCS?) command line
> >> passing to stub?
> >
> > Yes, I think that makes sense. That also means GRUB will need to
> > always create an FDT, even if it is empty.
> I'm not following something here - why would GRUB create an empty FDT?
Well, not empty - it would contain an empty command line string.
> Is GRUB going to be responsible for the complete FDT, or just passing the
> initrd and/or command line in an FDT?
If UEFI already had an FDT registered as a configuration table, it
would use that, and add a few nodes.
If not, it could either load one (and register as a UEFI configuration
table) or create one without any hardware description (and still
register it as a UEFI configuration table).
In either case, the stub would still be responsible to add the memory
map and system table pointer to the FDT.
> > The other option would be to pass the command line via the LoadOptions
> > from the EFI_LOADED_IMAGE protocol. I believe that is what Roy's
> > patches currently rely on for getting a command line.
>
> Yes, both my implementation and the x86 implementation get the command line
> from the EFI_LOADED_IMAGE protocol, and do conversion from UCS-2 (I think)
> to ASCII/UTF-8 to pass to the kernel. The format of the command line does not
> seem to be specified by UEFI.
So just to make things more fun - if we do the above, then you would
need to be able to deal with both cases:
- Command line through FDT.
- Command line through EFI_LOADED_IMAGE (as fallback), if using a
loader like rEFIned or Gummiboot.
/
Leif
_______________________________________________
boot-architecture mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/boot-architecture
