From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] fdt_chosen()
Date: Thu, 19 Apr 2007 13:29:37 -0400 [thread overview]
Message-ID: <4627A701.3030506@smiths-aerospace.com> (raw)
In-Reply-To: <46279D4F.1080603@freescale.com>
Timur Tabi wrote:
> Jerry,
>
> I noticed that fdt_chosen() is called with force=0. Does that mean that
> if the DTB has a chosen node in it already, that it won't be
> overwritten? If so, I think that's wrong, because some DTBs have a
> bogus chosen section in them that has, in the past, always been
> overwritten by U-Boot. If the chosen node already exists, then it means
> that it was present in the DTS when it was compiled, and that means the
> DTS is probably old and the chosen node has bad data in it.
Hi Timur,
In the "old" code, if the dts had a "chosen" node bootm created _a
second_ "chosen" node which is just wrong.
I originally removed the auto-generation of the "chosen" node which
forced the user to use the "fdt chosen" command (manually or as a boot
script) to create the node if he really wanted it (and it would add
missing properties and overwrite existing properties the "chosen" node,
rather than creating a bogus node).
Forcing the user to create the "chosen" node (either manually/scripted
or through the dts) was deemed undesirable. In the discussion that
ensued, at least as I understood it, the compromise was to create the
node if it did not exist and not touch it if it did exist.
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27553>
The reason I chose to /not/ create/overwrite "chosen" properties as part
of the bootm command is that would potentially overwrite changes that
the user made before running bootm. Scenario:
fdt addr <address>
fdt chosen # create the default chosen node and properties
fdt set /chosen <someprop> <somevalue>
bootm # ...would be BAD if <someprop> were rewritten
I'm open to tuning the behavior, but I don't like automagic and I *hate*
automagic which it undoes something I just got done doing.
Best regards,
gvb
next prev parent reply other threads:[~2007-04-19 17:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 16:48 [U-Boot-Users] fdt_chosen() Timur Tabi
2007-04-19 17:29 ` Jerry Van Baren [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-04-20 18:29 Timur Tabi
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=4627A701.3030506@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.