fdt: add fdtcmd env var to allow post processing of device tree before boot
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
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.
--- common/fdt_support.c | 21 +++++++++++++++++++++ include/fdt_support.h | 1 + lib_ppc/bootm.c | 1 + 3 files changed, 23 insertions(+), 0 deletions(-)
common/fdt_support.c +21 -0
@@ -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; +}
include/fdt_support.h +1 -0
@@ -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 */
lib_ppc/bootm.c +1 -0
@@ -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 */
Signature · 1 line
1.5.5.1
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 3 lines · In message <[email protected]> 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
Signature · 7 lines
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.
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 11 lines · Wolfgang Denk
In message <[email protected]>
Quoted 5 lines · you
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 17 lines · Kumar Gala
Quoted 10 lines · Wolfgang Denk
In message <[email protected]>
Quoted 5 lines · you
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_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.
Quoted 5 lines
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 30 lines · Jerry Van Baren
Quoted 13 lines · Kumar Gala
Quoted 7 lines · Wolfgang Denk
In message <Pine.LNX.
Quoted 5 lines · 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 afterft_board_setup()
and before the tree is handled to the kernel.Quoted 5 lines
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?Quoted 7 lines
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.
- kMy 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. :-/
Quoted 8 lines
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 39 lines · Kumar Gala
Quoted 28 lines · Jerry Van Baren
Quoted 11 lines · Kumar Gala
Quoted 10 lines · Wolfgang Denk
In message
Quoted 5 lines · <[email protected]> you wrote:
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_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?
Quoted 7 lines
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.
- kMy 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. :-/
Quoted 7 lines
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.
Quoted 4 lines
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...
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 53 lines · Jerry Van Baren
Quoted 40 lines · Kumar Gala
Quoted 31 lines · Jerry Van Baren
Quoted 13 lines · Kumar Gala
Quoted 7 lines · Wolfgang Denk
In message <[email protected]
Quoted 6 lines
you wrote:
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_board_setup()
and before the tree is handled to the kernel.Quoted 5 lines
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?Quoted 7 lines
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.
- kMy 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. :-/
Quoted 8 lines
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.
Quoted 3 lines
Is that really any better than having the ability to "execute" an environment variable that has 'fdt' commands in it as part of bootm?
- kI 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).
Quoted 6 lines
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
In reply to Jerry Van BarenQuoted 7 lines · In message <[email protected]> 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%.
Quoted 2 lines
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
Signature · 5 lines
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.
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
In reply to Kumar GalaQuoted 11 lines · In message <[email protected]> you wrote:
Quoted 10 lines
Quoted 6 lines
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_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?
Quoted 7 lines
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
Signature · 5 lines
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.
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 20 lines · Wolfgang Denk
In message
Quoted 18 lines · <[email protected]> you wrote:
Quoted 7 lines
Quoted 6 lines
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree afterft_board_setup()
and before the tree is handled to the kernel.Quoted 5 lines
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
theft_board_setup()how do I go about modifying that before the device tree is handed to the kernel.
Quoted 7 lines
Quoted 4 lines
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 8 lines · Kumar Gala
Quoted 2 lines · Wolfgang Denk
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:
Quoted 8 lines
fdt addr <FOO>
fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop
bootm (will callft_board_setupand 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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 16 lines · Scott Wood
Quoted 4 lines · Kumar Gala
Quoted 3 lines · Wolfgang Denk
So just run the needed commands before you run "bootm" as part of your
boot command sequence.Quoted 10 lines
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 callft_board_setupand 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.
Quoted 2 lines
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 6 lines · Kumar Gala
Quoted 2 lines · Scott Wood
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
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
In reply to Kumar GalaQuoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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
Signature · 7 lines
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 LeibovitchPATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
In reply to Kumar GalaQuoted 4 lines · In message <[email protected]> you wrote:
Quoted 3 lines
So just run the needed commands before you run "bootm" as part of your boot command sequence.
Quoted 8 lines
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 callft_board_setupand 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
Signature · 5 lines
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.
PATCH 1/1 fdt: add fdtcmd env var to allow post processing of device tree before boot
Quoted 16 lines · Wolfgang Denk
In message <F388F9D5-B685-4DD8-
Quoted 5 lines · ACAC-146A46A1F04E at kernel.crashing.org> you wrote:
Quoted 4 lines
So just run the needed commands before you run "bootm" as part of your
boot command sequence.Quoted 8 lines
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 callft_board_setupand add /bar/prop back)
Quoted 5 lines
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