[U-Boot-Users] simplify bootm command

[Kumar Gala]

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