[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> 
> 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]

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

My assumption is that a given board/config/user will likely be using 
exactly one of the n!/k!(n-k)! possibilities implemented in the current 
"bootm" (I don't know what n and k are, but n is pretty large and k is 
hard to determine :-O).  I figure, in the worst case, a given user may 
want two or three possibilities.

By selecting from a (smallish) set of "simple" bootX scripts, I'm 
speculating that each script will not need conditional logic other than 
"&&" to bail out if an error occurs.  I'm also suspicious that replacing 
"bootm" with a simplified "bootm" with a (single) "bootm" script isn't 
going to be workable (as you contend - script complexity)... the 
solution I would propose if that happens is to maintain "bootm" as is as 
a backwards compatible CONFIG_ option and create a new "bootsimple" (or 
some such) command that is what bootm would have been if we had hush 
scripting (and prescience[1]) a few years ago.

> Unless there is some believed simplification I'm missing I don't think 
> going through all this effort produces anything that is significantly 
> better.

To make an omelet, you have to break some eggs. :-)  I see Wolfgang 
illustrated the current complexity with a list of bootm hack^H^H^H^H 
customizations in a separate message.

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

That is the practical approach for now, but that is also how we got to 
here - incrementally adding complexity to bootm.

Best regards,
gvb

[1] 
<http://en.wikipedia.org/wiki/Minor_characters_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Gogrilla_Mincefriend>