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: >> 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. 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 ------------------------------------------------------------------------- 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