On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote:
> > > For that case we will also require a nailed-down boot
> > > protocol that allows for either DTB or ACPI.
> >
> > The latest documentation patch for the "arm/arm64 UEFI boot protocol"
> > implies that UEFI on ARM is already capable of passing a DTB to the
> > kernel:
> >
> > "The implementation depends on receiving information about the UEFI
> > environment in a Flattened Device Tree (FDT) - so is only available with
> > CONFIG_OF."
> >
> > Maybe we just need to better document it?
>
> Yes, we just need to document it.
Better document it than what is currently in Booting?
> As far as I'm aware, there are two ways we might boot the kernel:
Nope, just one.
> 1) Via the current boot protocol, passing a DTB in a particular
> register.
This is the only bit relevant to the kernel proper. It does not change
with UEFI/ACPI.
> 2) As an EFI application. As I understand it in this case the DTB will
> be saved in a system table (I may have got the terminology wrong here),
> and the EFI stub will need to look it up to pass it to the kernel.
This applies only to the stub itself, and relates to dealing with a
firmware that provides a preloaded tree. As well as an obscurity
relating to _stub_ command line passing.
It has also not been included in the patch sets sent out so far.
> As long as that's well defined and does not preclude ACPI, then I am
> happy.
This is already well defined. I'll agree it may not be explicit enough.
If we do need any documentation changes, I feel they belong in Booting,
to explain that a minimal DT will be used even with ACPI in order _not_
to break the existing boot protocol.
/
Leif
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
