From: Deepak Saxena <deepak_saxena@mentor.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Date: Fri, 10 Dec 2010 10:04:34 -0800 [thread overview]
Message-ID: <4D026BB2.6020609@mentor.com> (raw)
In-Reply-To: <20101208223405.6AC07CF5CA6@gemini.denx.de>
On 12/08/2010 02:34 PM, Wolfgang Denk wrote:
>
> I guess we can argue that the normal situation is that U-Boot will
> know how to update the DT such as needed to boot the OS. So what we
> are dealing with is a small percentage of cases where we need special
> behaviour, and where it may be acceptable if the solution is only
> semi-perfect ;-)
>
> My current thinking is to introduce something like
>
> dt_skip=memory,mac-address
>
> including eventually "dt_skip=ALL". This should cover most of the
> current use cases.
>
> If someone gets fancy he can add wildcard support.
>
> And if we need even more flexibility, we can add some "dt_include"
> with higher priority, so one could do for example
>
> dt_skip=ALL
> dt_include=memory
I imagine this being rather ugly to implement and to keep the code clean
and maintained. Who parses these variables? Does each and every piece of
code in U-Boot that now touches a piece of the DT need to check for this
variable? I could see something like this working
if there was a central DT handler that read nodes and then called
platform-specific over-ride function, i.e.:
for_each_node_in_dt() {
if (dt_include(node->type))
platform_of_dt_node_process(node, boot_stage);
}
where boot_stage tells us whether we are at early init, about to
boot an OS image, or in some other step in the process.
This would provide a consistent method of handling that variable.
Without something like this, I think and environment variable is just
going to create confusion for users and developers.
~Deepak
next prev parent reply other threads:[~2010-12-10 18:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 0:56 [U-Boot] [PATCH] Honor /memory/reg node in DTB files Deepak Saxena
2010-12-07 6:52 ` Wolfgang Denk
2010-12-07 18:05 ` Deepak Saxena
2010-12-07 19:09 ` Wolfgang Denk
2010-12-08 18:30 ` Hollis Blanchard
2010-12-08 20:53 ` Wolfgang Denk
2010-12-08 21:08 ` Hollis Blanchard
2010-12-08 21:38 ` Wolfgang Denk
2010-12-08 22:08 ` Dan Malek
2010-12-08 22:34 ` Wolfgang Denk
2010-12-08 23:33 ` Peter Tyser
2010-12-08 23:59 ` Dan Malek
2010-12-09 10:00 ` Wolfgang Denk
2010-12-10 18:04 ` Deepak Saxena [this message]
2010-12-12 21:19 ` Wolfgang Denk
2010-12-08 18:59 ` Deepak Saxena
2010-12-08 21:00 ` Wolfgang Denk
2010-12-07 18:40 ` Hollis Blanchard
2010-12-07 19:21 ` Wolfgang Denk
2010-12-07 21:22 ` Scott Wood
2010-12-08 18:59 ` Deepak Saxena
2010-12-08 19:11 ` Scott Wood
2010-12-08 19:22 ` Dan Malek
2010-12-08 19:33 ` Scott Wood
2012-03-31 19:32 ` Marek Vasut
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=4D026BB2.6020609@mentor.com \
--to=deepak_saxena@mentor.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.