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