On Mon, Sep 30, 2013 at 09:05:04PM +0100, Grant Likely wrote:
> > Handling the 2 cases is not a problem. I just don't want to handle
> > 'mixed' cases where
> > a command line and an FDT are passed to the stub, and information from
> > both is used.
> >
> > As I understand it, the two cases are:
> >
> > FDT_GUID present == GRUB case
> > * GRUB loads initrd if present
> > * GRUB provides complete FDT to stub (includes command line, hardware
> > description, initrd entry, etc.)
> > * EFI stub loads FDT using FDT_GUID, adds memory map and system table
> > pointer to FDT, starts kernel.
> > * (any command line present in EFI_LOADED_IMAGE is ignored.)
> >
> > FDT_GUID absent == current case
> > * stub loads FDT and initrd from system partition
> > * stub adds command line from EFI_LOADED_IMAGE to FDT
> > * stub adds initrd entry to FDT
> > * stub adds memory map and system table pointer to FDT, starts kernel.
> >
> > In the case of UEFI owning the FDT, and providing it to the stub,
> > where does the initrd come from? I think this adds
> > another case to handle...
> The stub will still need to process a command line if it is given one via the
> load image protocol. In that case the sub should override the setting in the
> FDT if the initrd argument is present.
Hmm, well, it's slightly worse than that - it will have one; only it
will be GRUB's command line.
The way that can be resolved is:
- FDT present?
- Commandline present in FDT chosen node?
- Yes
- Use that.
- No
- EFI_LOADED_IMAGE command line present?
- Yes
- Use that.
- No
- Fail miserably.
/
Leif
_______________________________________________
boot-architecture mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/boot-architecture
