On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: >> >> My current best thought is to create a new "boot simple" (boots? >> bootsm?) command that contains only the essence of bootm. I would >> then >> change the command "bootm" to do a hush script run of the env >> variable >> "bootm" (i.e. the command "bootm" would really just be "run bootm"). >> The env variable "bootm" would then have to be created with the >> complex >> (board/config appropriate) sequence that is currently hardcoded in >> the >> command "bootm", with the last command being "boots", of course. >> This >> would be selected by a new CONFIG_ configuration so that old boards >> would go on as is until or unless the maintainer chose to move >> forward. > > Hm... if we go to such efforts, we might even go one step farther and > solve the problem in a more general way. > > 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"). > > Then it's just a matter of defining the search order: if the variable > name space gets searched before the command names, we could redefine > all builtin commands. [Probbaly the search order (variables before or > after builtin commands) can be even mad selectable using an > environment variable :-) ]. > > A new "builtin" command would allow to stillr efer to the original > builtin commands. > > 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. - 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
