From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by ozlabs.org (Postfix) with ESMTP id A38F3DDDDB for ; Thu, 15 Mar 2007 12:38:10 +1100 (EST) Message-ID: <45F8A374.9090200@freescale.com> Date: Wed, 14 Mar 2007 20:37:56 -0500 From: Timur Tabi MIME-Version: 1.0 To: Jerry Van Baren Subject: Re: [dtc] Add support for flat device tree format version 17 References: <20070313062240.GA22737@localhost.localdomain> <45F863DF.5050709@freescale.com> <45F864E8.40501@smiths-aerospace.com> <45F86C25.1070301@freescale.com> <45F8A229.7040602@comcast.net> In-Reply-To: <45F8A229.7040602@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Jerry Van Baren wrote: > Actually, I believe that is how the existing code works: it opens the > original blob and copies it to a newly created dft. It then augments > the new dft with a "chosen" node and optionally additional nodes (bd_t, > env variables) and passes the new dft blob to linux. Theoretically, the > existing code will read a v17 blob and create a new v16 blob from it > (without the additional v17 length field - the header would be created, > not copied). I'll check out the code and see what it does, since I'm not really familiar with it. > > Trivia: the current code is kinda dumb about it: if the original blob > had a "chosen" node, the code *adds another* "chosen" node. Yes, I have this bug on my to-do list to fix. > Back to libdft: with a v16 blob, libdft has to either modify in place > (no size change) or you have to create a new blob and copy the original > data over (like the existing code). With the v17 blob, libdft is able > to expand and contract the contents of the blob (with limitations, I'm > sure). I agree that it would be nice if U-Boot had a robust DTB parser, but I don't have the time to do that work.