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: >>> 1. verify and uncompress kernel image >>> 2. relocate fdt (if needed) >>> 3. ft_board_setup() >>> 4. verify and uncompress ramdisk >>> 5. update initrd info in device tree >>> 6. 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 [1] <http://en.wikipedia.org/wiki/Minor_characters_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Gogrilla_Mincefriend> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users