Boot interface for device trees on ARM
Jeremy Kerr
jeremy.kerr at canonical.com
Fri Jun 4 21:33:04 EDT 2010
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
More information about the linux-arm-kernel
mailing list