Re: Boot interface for device trees on ARM

[Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

All,

> > With this, the kernel can remain largely backward compatible with the
> > legacy boot method, requiring _no_ change to the existing code, as the
> > ID is sufficient to distinguish between both boot types.  The machine
> > record remains largely relevant even for a DT boot as the majority of
> > its content is SOC specific anyway, and given a per SOC ID for DT usage
> > means that the early boot facilities are still usable as is even in the
> > DT context.  And then the init_machine method in the machine record is
> > naturally used to parse the device tree and do its work on multiple
> > machines' behalf instead of relying on compiled-in static data for a
> > specific machine.
> 
> There will still be instances of machine-specific setup code that
> needs to be chosen at boot (based on the top level 'compatible'
> property), but init_machine() appears to be early enough to handle
> this.
> 
> hmmm... however, things the device tree blob and the initrd both need
> to be marked as bootmem at paging_init() time, but init_machine()
> doesn't run until later.  There will still need to be some hooks for
> doing early DT processing, but none of that should be either board or
> SoC specific.

If we're planning to keep the machine IDs around (even if they are now per-
SoC), I'd like to know what would be left using them. The only thing that I 
can see that we currently use is io_pg_offset for the DEBUG_LL builds, and 
that isn't a convincing case to keep them.

Cheers,


Jeremy