[U-Boot-Users] simplify bootm command

[Kumar Gala]

[snip]

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

that might be true in a custom board port but for reference boards  
like we produce at FSL its difficult to know what a customer might  
want so we effective have the kitchen sink.

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

which means I'll have to keep the old method around.

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

but I doubt we will be able to remove those as they should be dealing  
with the ARCH specific boot methods.

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

Fair point but I have yet to see how the new approach is going to get  
rid of the old one.  What's the point in adding code if we can't get  
rid of the old code?

- k