U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 2/3] fdt: Fixup compile error and add a new OF manipulation option
Date: Tue, 12 Feb 2008 08:27:14 -0500	[thread overview]
Message-ID: <47B19EB2.8080400@ge.com> (raw)
In-Reply-To: <20080212011159.769c0edb@neuromancer.mindspace>

Bryan O'Donoghue wrote:
> Greetings.
> 
> This patch fixes up a compile error that crept with with debug switched on.
> Introduces CONFIG_OF_CHOSEN_UPDATE - which is useful if you have a /chosen
> entry in the dts - which doesn't contain a bootargs entry - in which case you'd
> want u-boot's version of this.
> 
> Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
> ---
> 
> diff --git a/README b/README
> index 26f93c2..bc7a6a4 100644
> --- a/README
> +++ b/README
> @@ -375,6 +375,11 @@ The following options need to be configured:
>  		This define fills in the correct boot cpu in the boot
>  		param header, the default value is zero if undefined.
>  
> +		CONFIG_OF_CHOSEN_UPDATE
> +
> +		This define adds or updates a bootargs field to the /chosen
> +		entry.
> +

Hi Bryan,

I don't think CONFIG_OF_CHOSEN_UPDATE is needed.  If it *is* needed, I 
don't think it *should be* needed and we need to discuss scenarios.

Initially, we did not touch the /chosen node *at all* if it already 
existed.  That was where the "force" flag came from - the criteria 
wasn't fine grained enough.  That behavior was changed in the 1.3.1 time 
frame to be fine grained: if /chosen exists, but /chosen/<prop> doesn't, 
that property is created and set to the required value.

If /chosen/<prop> exists, it is overwritten only if the "force" flag is 
set.  What you have added with CONFIG_OF_CHOSEN_UPDATE it a compile time 
"force" flag setting.

Maybe that is desirable, but I'm going to challenge you to justify it.  :-)

The problem / limitation with adding CONFIG_OF_CHOSEN_UPDATE is that it 
is a compile time option.  If we compile "force" to be TRUE, why not 
just compile it in as a '1' bit (below)?  I guess my problem is that I 
don't see the usefulness of nearly hardcoding it to be '1' or '0' (e.g. 
via a #define) vs. absolutely hardcoding it to be '1' or '0'.

If we *do* need to support a force/noforce option (and I have not 
conceded that point yet ;-), I think it should be an env variable, 
something the user can control at run time.

[snip]

> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 9546729..c729f52 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -975,7 +975,11 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int flag,
>  	 * if the user wants it (the logic is in the subroutines).
>  	 */
>  	if (of_flat_tree) {
> -		if (fdt_chosen(of_flat_tree, initrd_start, initrd_end, 0) < 0) {
> +#ifdef CONFIG_OF_CHOSEN_UPDATE
> +	if (fdt_chosen(of_flat_tree, initrd_start, initrd_end, 1) < 0) {
> +#else
> +	if (fdt_chosen(of_flat_tree, initrd_start, initrd_end, 0) < 0) {
> +#endif

Compile time selection is pretty inflexible.  Note also that this is a 
pretty big hammer - *everything* in the fdt_chosen() routine 
(potentially) gets forced.

Do we really need the "force" flag any more?

[snip]

Best regards,
gvb

  reply	other threads:[~2008-02-12 13:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12  1:11 [U-Boot-Users] [PATCH 2/3] fdt: Fixup compile error and add a new OF manipulation option Bryan O'Donoghue
2008-02-12 13:27 ` Jerry Van Baren [this message]
2008-02-12 14:16   ` Bryan O'Donoghue
2008-02-12 14:58     ` Jerry Van Baren
2008-02-12 15:26       ` Stefan Roese
2008-02-12 16:12       ` Bryan O'Donoghue

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=47B19EB2.8080400@ge.com \
    --to=gerald.vanbaren@ge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox