[U-Boot-Users] simplify bootm command

[Kumar Gala]

On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

> In message <48982523.4030706 at 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