From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 14 Mar 2007 17:07:49 -0400 Subject: [U-Boot-Users] [DNX#2007012542000021] [PATCH] Abort booting if the DTB version is incomp [...] In-Reply-To: <20070314203640.82C113525B0@atlas.denx.de> References: <20070314203640.82C113525B0@atlas.denx.de> Message-ID: <45F86425.5050400@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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