On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
In message 48982523.4030706@gmail.com 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