Kumar Gala wrote:
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]
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.
My assumption is that a given board/config/user will likely be using exactly one of the n!/k!(n-k)! possibilities implemented in the current "bootm" (I don't know what n and k are, but n is pretty large and k is hard to determine :-O). I figure, in the worst case, a given user may want two or three possibilities.
By selecting from a (smallish) set of "simple" bootX scripts, I'm speculating that each script will not need conditional logic other than "&&" to bail out if an error occurs. I'm also suspicious that replacing "bootm" with a simplified "bootm" with a (single) "bootm" script isn't going to be workable (as you contend - script complexity)... the solution I would propose if that happens is to maintain "bootm" as is as a backwards compatible CONFIG_ option and create a new "bootsimple" (or some such) command that is what bootm would have been if we had hush scripting (and prescience[1]) a few years ago.
Unless there is some believed simplification I'm missing I don't think going through all this effort produces anything that is significantly better.
To make an omelet, you have to break some eggs. :-) I see Wolfgang illustrated the current complexity with a list of bootm hack^H^H^H^H customizations in a separate message.
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.
That is the practical approach for now, but that is also how we got to here - incrementally adding complexity to bootm.
Best regards, gvb