On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
One idea that has been spinning in my mind for some time is to make the "run" command to execute the content of an environment variable optional. Instead, we could try and handle environment variable names similar to command names, i. e. instead of typing "run foo; run bar" you could just write "foo; bar" (I woull probably still keep the "run" command around to allow for the implicit error handling as used in "run foo bar" without forcing the user to use the hush shell to get the equivalent "foo && bar").
[snip]
With such an implementation, we could move the FDT handling into a command sequence stored in a "bootm" environment variable, and the last part of this variable would be "builtin bootm" to run the real (simplified) command.
What do you think?
While this is a cleaner implementation of what I've implemented w/ ft_env_setup() it still doesn't completely solve my problem. We'd need to have a command to deal with image loading separate from bootm since the 'fdt' processing that does occur today is in the middle of the bootm flow. bootm:
- verify and uncompress kernel image
- relocate fdt (if needed)
- ft_board_setup()
- verify and uncompress ramdisk
- update initrd info in device tree
- jump to kernel
I don't see how we can accomplish the same steps w/o breaking bootm down into a set of builtin commands to handle the various steps and providing enough information between the steps to accomplish the next step.
Yes, that is Wolfgang's (and my) proposal: rationalize the built-in "bootm" to do just #6. Steps 1-5 already exist as built-in commands or commands could be created almost trivially to invoke the existing code. The current "bootm" behavior would then be emulated by a bootm script chaining them together. All the different "bootm" behaviors would then be in the script (customizable by the user) rather than being hard-compiled into the actual bootm built-in command.
Rather than using the C preprocessor (and deductions based on parameters) to select the "appropriate" bootm behavior, an appropriate script would be used (there would be quite a few possible scripts, depending on _which_ "bootm" behavior is needed for a specific board/config). (Despite just having "dissed" cpp bootm behavior generation, I'm thinking that we would want to use the cpp to generate a default script that would emulate the current bootm behavior.)
If this is what Wolfgang was aiming I'm all for it. is it?
I think we should start with a detailed 'script' to mimic existing bootm behavior to know what commands we need to add beyond the builtin change.
- k