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