Wolfgang Denk wrote:
Dear Timur,
in message 45F853ED.2060005@freescale.com you wrote:
I don't want to be annoying, but if you're going to apply this patch, I think it needs to
Unfortunately there is a difference between the things I want to do, the things I am capable of doing, the things I can do, and the things I'm actually doing.
be applied now. There's a patch for the device tree compiler (DTC) that updates it to version 17, which claims to be compatible with V16. Soon, we're going to have V3, V16, and V16 DTBs flying around, so U-Boot needs to make a stand on what it considers compatible and what it doesn't.
If I'm realistic, I have to admit that I won't find much time for merging patches in the next days or maybe even weeks. Sorry.
Maybe we can find a custodian for the device tree related things?
Best regards,
Wolfgang Denk
Hi Timur, Wolfgang,
If I understand this, currently there is _no_ version checking and bootm will mysteriously fail if it is fed a version 3 blob and just as mysteriously work if fed a v16 (or v17) blob.
Version 17 is 100% compatible with version 16, it adds a new field in the header that is reserved (0x00000000) in v16 and sets the "comp_version" field to 17 instead of 16 ("last_comp_version" remains at 16).
Version checking is good. Having said that, if the patch is or is not applied, I don't see how anything changes materially from where we are right now, other than it will detect and abort if a v3 blob is passed in (which is good). Currently u-boot will accept and properly process a v16 or v17 blob (theoretically - I have not had a chance to run a v17 blob, but I've looked quite hard at the change).
I've been working with fdt blobs, implementing a "fdt" command. It currently can print individual properties, recursively print nodes starting at any point in the tree, and set property values (but if the size is the same).
I would consider being a fdt-related custodian, but I don't have a lot of time to work on it so I'm not sure my response time would be an improvement over Wolfgang's. :-(
gvb