David Gibson wrote: > You don't. If your agent takes a dtb, dtb layout and agent must > match.
So what I would like to see is a way for the agent to validate the dtb. U-Boot could currently validate the SOC's compatible field. However, if we add a special node that contains rules for modifying the rest of the tree, the only possible way to block older, incompatible U-Boots from accepting the tree is to bump the version number. Since that is not the right thing to do, the best approach is to define a new node type that has conditional expression attached to it. Then we can bump the version. > In fact, in one way of looking at it that's always what happens: the > dtb format is defined for passing hardware information from the > bootloader to the kernel; nothing else. Passing a dtb *into* the > bootloader is just a bootloader implementation convenience, because > the possible variations on an output tree are small, so it's useful to > have a skeleton tree built-in. But in order for the bootloader to > process those variations correctly, the skeleton *must* be in the > right format. dtb input to a bootloader must match the bootloaders > expectations. This has always been true, and will continue to be > true. The problem with this approach is that you're replacing data with code, and that always makes things more difficult. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
