On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote: > Unless I missed some recent discussion, this case is not easy to handle. > Yes, I know that these kind of things should be handled by a > next-generation bootloader, but in our case, we want to avoid a loader > update of already shipped hardware by all means.
There was some discussion about appending multiple DTBs recently. I can't actually recall anything about it though so that's not an entirely helpful thing... > As a solution, I'm thinking of a small framework that could for example > work as follows. > a) A small mechanism allows storing multiple DTB binary files inside the > kernel binary at compile time, and a simple function can extract them > again by name at runtime (something like what the firmware framework > does, but I don't know if that one can be used at such an early stage in > the boot process). Another way of skinning this would be for either the kernel to contain a set of machine ID to compatible string mappings or for the device trees for the boards to have an additional properties giving the machine IDs that the boards match. The kernel could then look for multiple DTBs appended to the image and try to pick one based on ATAGs.
signature.asc
Description: Digital signature
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
