[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after ft_board_setup()
and before the tree is handled to the kernel.

The idea is that users may want to add or manipulate nodes w/changing the u-boot
binary.  The current point in the code we do this we have yet to determine the
final size and have yet to do the final fixup of the initrd information.

If its desirable for the 'fdtcmd' support to have the proper initrd information
a bit of code reorder will be in order.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 common/fdt_support.c  |   21 +++++++++++++++++++++
 include/fdt_support.h |    1 +
 lib_ppc/bootm.c       |    1 +
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 93b144e..b1aa7df 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -30,6 +30,10 @@
 #include <fdt_support.h>
 #include <exports.h>

+#ifdef CFG_HUSH_PARSER
+#include <hush.h>
+#endif
+
 /*
  * Global data (for the gd->bd)
  */
@@ -529,3 +533,20 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
 		       fdt_strerror(err));
 }
 #endif /* defined(CONFIG_MPC83XX) || defined(CONFIG_MPC85xx) */
+
+int ft_env_setup(void *blob, bd_t *bd)
+{
+	int rcode = 0;
+
+	working_fdt = blob;
+
+#ifndef CFG_HUSH_PARSER
+	if (run_command (getenv ("fdtcmd"), 0) < 0)
+		rcode = 1;
+#else
+	if (parse_string_outer (getenv ("fdtcmd"),
+			FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+		rcode = 1;
+#endif
+	return rcode;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index a7c6326..a60b5f0 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -67,6 +67,7 @@ void ft_board_setup(void *blob, bd_t *bd);
 void ft_cpu_setup(void *blob, bd_t *bd);
 void ft_pci_setup(void *blob, bd_t *bd);
 #endif
+int ft_env_setup(void *blob, bd_t *bd);

 #endif /* ifdef CONFIG_OF_LIBFDT */
 #endif /* ifndef __FDT_SUPPORT_H */
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..d7a1236 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -194,6 +194,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 		/* Call the board-specific fixup routine */
 		ft_board_setup(of_flat_tree, gd->bd);
 #endif
+		ft_env_setup(of_flat_tree, gd->bd);
 	}

 	/* Fixup the fdt memreserve now that we know how big it is */
-- 
1.5.5.1

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Wolfgang Denk]

In message <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net> you wrote:
> Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
> that the user can supply to manipulate the device tree after ft_board_setup()
> and before the tree is handled to the kernel.

Where exactly is the needed, i. e. which spoecific situation  do  you
have  in  mind  where  this function cannot be implemented as part of
either a "preboot" or a standard "bootcmd" command sequence?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly  (Ni-klows  Virt),  Americans  invariably  mangle  it  into
(Nick-les  Worth).  Which  is to say that Europeans call him by name,
but Americans call him by value.

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net>  
> you wrote:
>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>> commands
>> that the user can supply to manipulate the device tree after  
>> ft_board_setup()
>> and before the tree is handled to the kernel.
>
> Where exactly is the needed, i. e. which spoecific situation  do  you
> have  in  mind  where  this function cannot be implemented as part of
> either a "preboot" or a standard "bootcmd" command sequence?

The situation is if we are fixing up or adding properties or nodes via  
the ft_board_setup() how do I go about modifying that before the  
device tree is handed to the kernel.

An example would be if we start adding the i2c node via code in u-boot  
and after we have done that we want to add a frequency property at  
runtime w/o changing the u-boot code.

- k

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
> 
>> In message <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net>  
>> you wrote:
>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>>> commands
>>> that the user can supply to manipulate the device tree after  
>>> ft_board_setup()
>>> and before the tree is handled to the kernel.
>> Where exactly is the needed, i. e. which spoecific situation  do  you
>> have  in  mind  where  this function cannot be implemented as part of
>> either a "preboot" or a standard "bootcmd" command sequence?
> 
> The situation is if we are fixing up or adding properties or nodes via  
> the ft_board_setup() how do I go about modifying that before the  
> device tree is handed to the kernel.
> 
> An example would be if we start adding the i2c node via code in u-boot  
> and after we have done that we want to add a frequency property at  
> runtime w/o changing the u-boot code.
> 
> - k

My original way long ago initial cut didn't do the board and /chosen 
fixups as part of the bootm execution.  My original intent was that we 
would run "fdt chosen" and "fdt bd" and whatever else was necessary 
before running "bootm", including addressing Kumar's need.

Unfortunately, it would have also broken backwards compatibility and so 
the concept was sacrificed for backwards compatibility.  :-/

Is there a better way of doing this... perhaps have a flag that says if 
"fdt chosen" and/or "fdt bd" is run, don't re-run it as part of bootm? 
Maybe have an env variable that suppressed the calling of "fdt chosen" 
and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but it would 
maintain backwards compatibility but also allow us finer grained control 
of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and allow our 
users to wedge additional fdt stuff in the boot sequence.

gvb

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>> In message <Pine.LNX. 
>>> 4.64.0808041346350.3885 at blarg.am.freescale.net>  you wrote:
>>>> Added the 'fdtcmd' environment variable as a way to provide  
>>>> 'fdt'  commands
>>>> that the user can supply to manipulate the device tree after   
>>>> ft_board_setup()
>>>> and before the tree is handled to the kernel.
>>> Where exactly is the needed, i. e. which spoecific situation  do   
>>> you
>>> have  in  mind  where  this function cannot be implemented as part  
>>> of
>>> either a "preboot" or a standard "bootcmd" command sequence?
>> The situation is if we are fixing up or adding properties or nodes  
>> via  the ft_board_setup() how do I go about modifying that before  
>> the  device tree is handed to the kernel.
>> An example would be if we start adding the i2c node via code in u- 
>> boot  and after we have done that we want to add a frequency  
>> property at  runtime w/o changing the u-boot code.
>> - k
>
> My original way long ago initial cut didn't do the board and /chosen  
> fixups as part of the bootm execution.  My original intent was that  
> we would run "fdt chosen" and "fdt bd" and whatever else was  
> necessary before running "bootm", including addressing Kumar's need.
>
> Unfortunately, it would have also broken backwards compatibility and  
> so the concept was sacrificed for backwards compatibility.  :-/
>
> Is there a better way of doing this... perhaps have a flag that says  
> if "fdt chosen" and/or "fdt bd" is run, don't re-run it as part of  
> bootm? Maybe have an env variable that suppressed the calling of  
> "fdt chosen" and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but  
> it would maintain backwards compatibility but also allow us finer  
> grained control of when "fdt chosen" and "fdt bd" (add "fdt cpu"?)  
> is run and allow our users to wedge additional fdt stuff in the boot  
> sequence.

Is that really any better than having the ability to "execute" an  
environment variable that has 'fdt' commands in it as part of bootm?

- k

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>>> In message 
>>>> <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net>  you wrote:
>>>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>>>>> commands
>>>>> that the user can supply to manipulate the device tree after  
>>>>> ft_board_setup()
>>>>> and before the tree is handled to the kernel.
>>>> Where exactly is the needed, i. e. which spoecific situation  do  you
>>>> have  in  mind  where  this function cannot be implemented as part of
>>>> either a "preboot" or a standard "bootcmd" command sequence?
>>> The situation is if we are fixing up or adding properties or nodes 
>>> via  the ft_board_setup() how do I go about modifying that before 
>>> the  device tree is handed to the kernel.
>>> An example would be if we start adding the i2c node via code in 
>>> u-boot  and after we have done that we want to add a frequency 
>>> property at  runtime w/o changing the u-boot code.
>>> - k
>>
>> My original way long ago initial cut didn't do the board and /chosen 
>> fixups as part of the bootm execution.  My original intent was that we 
>> would run "fdt chosen" and "fdt bd" and whatever else was necessary 
>> before running "bootm", including addressing Kumar's need.
>>
>> Unfortunately, it would have also broken backwards compatibility and 
>> so the concept was sacrificed for backwards compatibility.  :-/
>>
>> Is there a better way of doing this... perhaps have a flag that says 
>> if "fdt chosen" and/or "fdt bd" is run, don't re-run it as part of 
>> bootm? Maybe have an env variable that suppressed the calling of "fdt 
>> chosen" and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but it 
>> would maintain backwards compatibility but also allow us finer grained 
>> control of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and 
>> allow our users to wedge additional fdt stuff in the boot sequence.
> 
> Is that really any better than having the ability to "execute" an 
> environment variable that has 'fdt' commands in it as part of bootm?
> 
> - k

I don't like it that bootm is calling out to all sorts of functions that 
could better be scripted.  It complicates the bootm code (badly!), it 
prevents users from doing clever things (because it hard codes the calls 
and sequences of the calls to loosely related functions), and it 
violates the unix principle of doing only one thing and doing it well 
(bootm code is one big ugly awkward swissarmyknife[tm] tool).

Best regards,
gvb

P.S. This battle was probably lost many years ago, but it still makes me 
feel better to pound the desk and shout.  Oh-oh, people are looking...

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
>>>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>>>> In message <Pine.LNX.4.64.0808041346350.3885@blarg.am.freescale.net 
>>>>> >  you wrote:
>>>>>> Added the 'fdtcmd' environment variable as a way to provide  
>>>>>> 'fdt'  commands
>>>>>> that the user can supply to manipulate the device tree after   
>>>>>> ft_board_setup()
>>>>>> and before the tree is handled to the kernel.
>>>>> Where exactly is the needed, i. e. which spoecific situation   
>>>>> do  you
>>>>> have  in  mind  where  this function cannot be implemented as  
>>>>> part of
>>>>> either a "preboot" or a standard "bootcmd" command sequence?
>>>> The situation is if we are fixing up or adding properties or  
>>>> nodes via  the ft_board_setup() how do I go about modifying that  
>>>> before the  device tree is handed to the kernel.
>>>> An example would be if we start adding the i2c node via code in u- 
>>>> boot  and after we have done that we want to add a frequency  
>>>> property at  runtime w/o changing the u-boot code.
>>>> - k
>>>
>>> My original way long ago initial cut didn't do the board and / 
>>> chosen fixups as part of the bootm execution.  My original intent  
>>> was that we would run "fdt chosen" and "fdt bd" and whatever else  
>>> was necessary before running "bootm", including addressing Kumar's  
>>> need.
>>>
>>> Unfortunately, it would have also broken backwards compatibility  
>>> and so the concept was sacrificed for backwards compatibility.  :-/
>>>
>>> Is there a better way of doing this... perhaps have a flag that  
>>> says if "fdt chosen" and/or "fdt bd" is run, don't re-run it as  
>>> part of bootm? Maybe have an env variable that suppressed the  
>>> calling of "fdt chosen" and "fdt bd" in bootm ("nofdtfixup"?)?   
>>> Still ugly, but it would maintain backwards compatibility but also  
>>> allow us finer grained control of when "fdt chosen" and "fdt  
>>> bd" (add "fdt cpu"?) is run and allow our users to wedge  
>>> additional fdt stuff in the boot sequence.
>> Is that really any better than having the ability to "execute" an  
>> environment variable that has 'fdt' commands in it as part of bootm?
>> - k
>
> I don't like it that bootm is calling out to all sorts of functions  
> that could better be scripted.  It complicates the bootm code  
> (badly!), it prevents users from doing clever things (because it  
> hard codes the calls and sequences of the calls to loosely related  
> functions), and it violates the unix principle of doing only one  
> thing and doing it well (bootm code is one big ugly awkward  
> swissarmyknife[tm] tool).
>
> Best regards,
> gvb
>
> P.S. This battle was probably lost many years ago, but it still  
> makes me feel better to pound the desk and shout.  Oh-oh, people are  
> looking...

I think this was lost long ago.  If we went with simple it would have  
just done the register setup and transfer and thats it.  leaving it to  
other commands to do decompression of images, etc.

Also we already have a number env vars that impact how bootm works.

- k

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Wolfgang Denk]

In message <48976A3F.8060207@ge.com> you wrote:
>
> I don't like it that bootm is calling out to all sorts of functions that 
> could better be scripted.  It complicates the bootm code (badly!), it 
> prevents users from doing clever things (because it hard codes the calls 
> and sequences of the calls to loosely related functions), and it 
> violates the unix principle of doing only one thing and doing it well 
> (bootm code is one big ugly awkward swissarmyknife[tm] tool).

I agree 100%.

> P.S. This battle was probably lost many years ago, but it still makes me 
> feel better to pound the desk and shout.  Oh-oh, people are looking...

Ther is two of us. I'm your ally when it comes to ripping out
unnecessary and complicted stuff out of bootm :-)

Just send patches...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Children are natural mimics who act like their parents despite  every
effort to teach them good manners.

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Wolfgang Denk]

In message <A9365AF6-497C-403B-8580-2E8B9BCD20C3@kernel.crashing.org> you wrote:
> 
> >> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
> >> commands
> >> that the user can supply to manipulate the device tree after  
> >> ft_board_setup()
> >> and before the tree is handled to the kernel.
> >
> > Where exactly is the needed, i. e. which spoecific situation  do  you
> > have  in  mind  where  this function cannot be implemented as part of
> > either a "preboot" or a standard "bootcmd" command sequence?
> 
> The situation is if we are fixing up or adding properties or nodes via  
> the ft_board_setup() how do I go about modifying that before the  
> device tree is handed to the kernel.
> 
> An example would be if we start adding the i2c node via code in u-boot  
> and after we have done that we want to add a frequency property at  
> runtime w/o changing the u-boot code.

So just run the needed commands before you run "bootm" as part of your
boot command sequence.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:

> In message  
> <A9365AF6-497C-403B-8580-2E8B9BCD20C3@kernel.crashing.org> you wrote:
>>
>>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
>>>> commands
>>>> that the user can supply to manipulate the device tree after
>>>> ft_board_setup()
>>>> and before the tree is handled to the kernel.
>>>
>>> Where exactly is the needed, i. e. which spoecific situation  do   
>>> you
>>> have  in  mind  where  this function cannot be implemented as part  
>>> of
>>> either a "preboot" or a standard "bootcmd" command sequence?
>>
>> The situation is if we are fixing up or adding properties or nodes  
>> via
>> the ft_board_setup() how do I go about modifying that before the
>> device tree is handed to the kernel.
>>
>> An example would be if we start adding the i2c node via code in u- 
>> boot
>> and after we have done that we want to add a frequency property at
>> runtime w/o changing the u-boot code.
>
> So just run the needed commands before you run "bootm" as part of your
> boot command sequence.


This doesnt work.  Lets say I want to remove a node or property that  
ft_board_setup() adds.  If I do what you are suggesting the node or  
prop will get added back:

fdt addr <FOO>
fdt boardsetup (we assume this adds /bar/prop)
fdt rm /bar/prop
bootm (will call ft_board_setup and add /bar/prop back)

This assumes I know the best location for the device tree before  
"bootm" which I'd argue isn't really true.  Especially if my dtb is in  
flash.

- k

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Scott Wood]

Kumar Gala wrote:
> On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
>> So just run the needed commands before you run "bootm" as part of your
>> boot command sequence.
> 
> This doesnt work.  Lets say I want to remove a node or property that  
> ft_board_setup() adds.  If I do what you are suggesting the node or  
> prop will get added back:
> 
> fdt addr <FOO>
> fdt boardsetup (we assume this adds /bar/prop)
> fdt rm /bar/prop
> bootm (will call ft_board_setup and add /bar/prop back)
> 
> This assumes I know the best location for the device tree before  
> "bootm" which I'd argue isn't really true.  Especially if my dtb is in  
> flash.

Why not?  Wouldn't it be just another environment variable, like the 
load address for the kernel?

-Scott

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 3:55 PM, Scott Wood wrote:

> Kumar Gala wrote:
>> On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
>>> So just run the needed commands before you run "bootm" as part of  
>>> your
>>> boot command sequence.
>> This doesnt work.  Lets say I want to remove a node or property  
>> that  ft_board_setup() adds.  If I do what you are suggesting the  
>> node or  prop will get added back:
>> fdt addr <FOO>
>> fdt boardsetup (we assume this adds /bar/prop)
>> fdt rm /bar/prop
>> bootm (will call ft_board_setup and add /bar/prop back)
>> This assumes I know the best location for the device tree before   
>> "bootm" which I'd argue isn't really true.  Especially if my dtb is  
>> in  flash.
>
> Why not?  Wouldn't it be just another environment variable, like the  
> load address for the kernel?

Right now the fdt is placed at the first 4k page after the kernel is  
decompressed.  I don't now where that address is.

- k

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Scott Wood]

Kumar Gala wrote:
> On Aug 4, 2008, at 3:55 PM, Scott Wood wrote:
>> Why not?  Wouldn't it be just another environment variable, like the 
>> load address for the kernel?
> 
> Right now the fdt is placed at the first 4k page after the kernel is 
> decompressed.  I don't now where that address is.

Do we really need to do it that way, though?

-Scott

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Wolfgang Denk]

In message <8A440031-0ADE-4AC5-84C3-C0D58583493A@kernel.crashing.org> you wrote:
> 
> > Why not?  Wouldn't it be just another environment variable, like the  
> > load address for the kernel?
> 
> Right now the fdt is placed at the first 4k page after the kernel is  
> decompressed.  I don't now where that address is.

Who places it there?

We were talking  about  the  bootm  arguments,  which  are  different
things, I think?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That Microsoft, the Trabant of the operating  system  world,  may  be
glancing  over the Berlin Wall at the Audis and BMWs and Mercedes. In
their own universe Trabants and Ladas were mainstream too...
                                                   -- Evan Leibovitch

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Wolfgang Denk]

In message <F388F9D5-B685-4DD8-ACAC-146A46A1F04E@kernel.crashing.org> you wrote:
> 
> > So just run the needed commands before you run "bootm" as part of your
> > boot command sequence.
> 
> This doesnt work.  Lets say I want to remove a node or property that  
> ft_board_setup() adds.  If I do what you are suggesting the node or  
> prop will get added back:
> 
> fdt addr <FOO>
> fdt boardsetup (we assume this adds /bar/prop)
> fdt rm /bar/prop
> bootm (will call ft_board_setup and add /bar/prop back)

And exactly this has to be considered a bug in the current bootm
implementation.

Throwing out this design error would make more sense to me than adding
another quirk.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.

[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Kumar Gala]

On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote:

> In message <F388F9D5-B685-4DD8- 
> ACAC-146A46A1F04E at kernel.crashing.org> you wrote:
>>
>>> So just run the needed commands before you run "bootm" as part of  
>>> your
>>> boot command sequence.
>>
>> This doesnt work.  Lets say I want to remove a node or property that
>> ft_board_setup() adds.  If I do what you are suggesting the node or
>> prop will get added back:
>>
>> fdt addr <FOO>
>> fdt boardsetup (we assume this adds /bar/prop)
>> fdt rm /bar/prop
>> bootm (will call ft_board_setup and add /bar/prop back)
>
> And exactly this has to be considered a bug in the current bootm
> implementation.
>
> Throwing out this design error would make more sense to me than adding
> another quirk.

Ok.  What do we think 'bootm' at its lowest level should do?

- k