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.
As I look at this more and more I think trying to re-encode the control flow of the bootm command in a script is just insane. There are too many special cases we have to deal with that we'd just being moving from C code into the script.
Unless there is some believed simplification I'm missing I don't think going through all this effort produces anything that is significantly better.
My needs are meet with the simple ft_env_setup() call out. Beyond that trying to rework bootm for legacy images, CONFIG_FIT, booting w/ dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work w/o any real benefit.
- k