linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@comcast.net>
To: Timur Tabi <timur@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [dtc] Add support for flat device tree format version 17
Date: Wed, 14 Mar 2007 22:49:22 -0400	[thread overview]
Message-ID: <45F8B432.9010702@comcast.net> (raw)
In-Reply-To: <45F8A374.9090200@freescale.com>

Timur Tabi wrote:
> 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.

That is close to the top of my list.  My intent with the "fdt" command 
is to have a subcommand that creates the "chosen" node.  This will 
replace the auto-generation (with no opportunity to review or revise) 
the "chosen" node as part of the "bootm" command.

Downside: "bootm" becomes more than one command.  So script it.
Upside: MUCH cleaner, allows the user to review and revise the blob 
before booting linux.

These are my current thoughts for the "fdt" command:
=> help fdt
fdt addr   <addr>                  - Set the fdt location to <addr>
fdt get    <node> <property>       - Get the value of <node> <property>
fdt set    <node> <property> <val> - Set the value of <property> to <val>
     (creates a new property if necessary)
fdt mknode <node>                  - Create a new node <node>
     (the path must exist except for the last node name)
fdt rmnode <node>                  - Deletes the node <node>
     (the last node name in the path)
fdt print  <node> [<property>]     - Recursive print starting at <node>
     (if <property> is specified, prints only that property)
fdt chosen - Add/update the "chosen" branch to the tree
Hints:
  * "fdt print /" prints the whole tree.
  * If the property you are setting/printing has a '#' character,
      you MUST escape it with a \ character or quote it with " or
      it will be ignored as a comment.
  * If the value has spaces in it, you MUST escape the spaces with
      \ characters or quote it with "
Examples: fdt p /cpus "#address-cells"
           fdt s /cpus "#address-cells" "[00 00 00 01]"

I've actually implemented addr, set, and print (get is an alias for print).

>> 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.

libfdt.

David already did the work, I'm working on the integration (works but 
needs some cleanup).

gvb

  reply	other threads:[~2007-03-15  2:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13  6:22 [dtc] Add support for flat device tree format version 17 David Gibson
2007-03-13 21:10 ` Mark A. Greer
2007-03-14  0:02   ` David Gibson
2007-03-14 21:06 ` Timur Tabi
2007-03-14 21:11   ` Jerry Van Baren
2007-03-14 21:20     ` Timur Tabi
2007-03-14 23:07       ` David Gibson
2007-03-14 21:41     ` Timur Tabi
2007-03-15  1:32       ` Jerry Van Baren
2007-03-15  1:37         ` Timur Tabi
2007-03-15  2:49           ` Jerry Van Baren [this message]
2007-03-15  1:38         ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2007-03-14  0:02 David Gibson
2007-03-14 15:32 ` Timur Tabi
2007-03-14 20:41 ` Jon Loeliger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45F8B432.9010702@comcast.net \
    --to=gerald.vanbaren@comcast.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=timur@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).