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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
