All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: flattened device tree command
Date: Wed, 29 Nov 2006 09:01:49 -0500	[thread overview]
Message-ID: <456D92CD.9070203@smiths-aerospace.com> (raw)

Wolfgang, Grant, and gentle readers,

A while back I submitted a patch for a new command "oftdump".
<http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/24664>
While it was good in principle, it probably is premature and short 
sighted in implementation.

The command was hacked on top of ft_dump_blob() (common/ft_build.c) and 
required some changes to the same.   Grant objected to the changes as 
suboptimal - I contend they are locally optimal, but that ft_build.c is 
suboptimal.

The linux kernel has its own library functions for
handling flat device trees.  In addition, David Gibson has proposed 
another library (advertised as easier to use):
<http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028596.html>

My RFC has two parts:
1) Peoples' opinion of the relative merits of the current u-boot support 
library vs. the kernel's library vs. David Gibson's library.  My limited 
experience with ft_build.c is that it is suboptimal.  I don't have any 
experience with the linux or David's libraries to form an opinion of them.

2) I see more commands than just dumping the tree, allowing the user to 
manipulate the tree as well.  My current thoughts are to make a new 
command "fdt" (flattened device tree - the Open Firmware genesis appears 
to be depricated) with subcommands like the existing "mii" command.

fdt read <node> - does what my "oftdump" command does
fdt write <node> <value> - allow patching the fdt
   * Writing could get pretty complex with creating nodes
   * Initial implementation would be simply to change existing values

Related to the above discussion, the current ft_build.c/"bootm" code 
takes the blob and augments it with board configuration and env stuff as 
part of the "bootm" command.  The implementation is suboptimal 
(ft_build.c again) in that it is only done as a last thing before 
"bootm" transfers to linux, making it (almost) impossible to dump and 
definitely impossible to interactively poke around in the resulting fdt. 
  I would like to see this integrated done better in u-boot rather than 
simply pasted onto the fdt at the last moment before jumping into linux.

So, in conclusion,
1) I'm not sure if this is truly a RFC or just a brain dump of my 
current thoughts.  Either way, advice is welcome.

2) Wolfgang: Please don't apply my "oftdump" command patch yet.

gvb

             reply	other threads:[~2006-11-29 14:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29 14:01 Jerry Van Baren [this message]
2006-11-29 14:40 ` [U-Boot-Users] RFC: flattened device tree command Grant Likely
2006-11-29 14:43 ` Ben Warren
2006-11-29 15:32   ` Jerry Van Baren
2006-11-29 16:03     ` Grant Likely

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=456D92CD.9070203@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.