[U-Boot-Users] [PATCH v2] 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.
Signed-off-by: Kumar Gala galak@kernel.crashing.org ---
Moved 'fdt boardsetup' into the 'fdtcmd' environment by default thus removing the explicit ft_board_setup call and moving slightly towards the direction of having things be a bit more script driven.
- k
common/env_common.c | 3 +++ common/environment.c | 3 +++ common/fdt_support.c | 21 +++++++++++++++++++++ include/fdt_support.h | 1 + lib_ppc/bootm.c | 5 +---- 5 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/common/env_common.c b/common/env_common.c index d51c211..7544cca 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -127,6 +127,9 @@ uchar default_environment[] = { #if defined(CONFIG_PCI_BOOTDELAY) && (CONFIG_PCI_BOOTDELAY > 0) "pcidelay=" MK_STR(CONFIG_PCI_BOOTDELAY) "\0" #endif +#ifdef CONFIG_OF_BOARD_SETUP + "fdtcmd=" "fdt boardsetup" "\0" +#endif #ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS #endif diff --git a/common/environment.c b/common/environment.c index 3b9914f..39ed545 100644 --- a/common/environment.c +++ b/common/environment.c @@ -174,6 +174,9 @@ env_t environment __PPCENV__ = { #if defined(CONFIG_PCI_BOOTDELAY) && (CONFIG_PCI_BOOTDELAY > 0) "pcidelay=" MK_STR(CONFIG_PCI_BOOTDELAY) "\0" #endif +#ifdef CONFIG_OF_BOARD_SETUP + "fdtcmd=" "fdt boardsetup" "\0" +#endif #ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS #endif diff --git a/common/fdt_support.c b/common/fdt_support.c index 93b144e..25c42e4 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) +{ + 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..f9ed5a4 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);
#endif /* ifdef CONFIG_OF_LIBFDT */ #endif /* ifndef __FDT_SUPPORT_H */ diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c index a872d31..186e9b9 100644 --- a/lib_ppc/bootm.c +++ b/lib_ppc/bootm.c @@ -190,10 +190,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], fdt_error ("/chosen node create failed"); goto error; } -#ifdef CONFIG_OF_BOARD_SETUP - /* Call the board-specific fixup routine */ - ft_board_setup(of_flat_tree, gd->bd); -#endif + ft_env_setup(of_flat_tree); }
/* Fixup the fdt memreserve now that we know how big it is */

On Aug 5, 2008, at 11:50 AM, Kumar Gala 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.
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
Moved 'fdt boardsetup' into the 'fdtcmd' environment by default thus removing the explicit ft_board_setup call and moving slightly towards the direction of having things be a bit more script driven.
One of my intents was that this would be a stop gap until we have the "new script" method worked out. Also the idea is that would be compatible with the usage we are talking about and we'd just expand the default settings of 'fdtcmd' as part of the "new script" bootm method.
- k

In message Pine.LNX.4.64.0808051149250.6651@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.
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.
The current state of the bootm implementation is bad enough, but adding such a callback opens just another few cans of worms. Sorry, but I do not want to see that in mainline.
Best regards,
Wolfgang Denk

On Aug 5, 2008, at 4:40 PM, Wolfgang Denk wrote:
In message Pine.LNX.4.64.0808051149250.6651@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.
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.
The current state of the bootm implementation is bad enough, but adding such a callback opens just another few cans of worms. Sorry, but I do not want to see that in mainline.
I dont see how this is different than the proposal of moving to a script based mechanism for doing a large portion of what bootm does today.
I get not wanting to add the the complexity that is bootm. But I dont think the script mechanism is the right answer either.
- k
participants (2)
-
Kumar Gala
-
Wolfgang Denk