[U-Boot] granularity of bootm subcommands

[Jerry Van Baren]

Kumar Gala wrote:
>>>   bootm usb_stop
>>
>> This is "usb stop"
> 
> So this case is easy since its a compile time choice.
> 
>>>   bootm disable_caches
>>
>> This is "icache off && dcache off"
> 
> I assume you are suggesting new toplevel cache commands.

No, existing: cmd_cache.c

>>> "load_os" stays as is.
>>
>> Decompresses to a destination address?  I didn't see a gunzip/bz2 
>> command in my brief search.  I would rather have a "decompress" 
>> general purpose command (perhaps it is/should be part of the "image" 
>> (im*) command set?).
> 
> This is orthogonal to the bootm discussion.  We can refactor the code to 
> allow for such a toplevel command and reuse the code.

Agreed on the orthogonality.  Last night I started looking at image.c to 
how much "bootm" functionality is implemented in image.c.  My thought is 
that the image manipulation functions (iminfo, imtest, imls) should be 
factored out of cmd_bootm.c into a new cmd_image.c (or something like 
that) and I'm thinking we need some new "image" commands to do the image 
processing for OS images (various types), ramdisk images, and ?others?.

> But the bootm commands CAN NOT require control flow in the scripting
> lang.  Thus the desire to decompress or not, and what type has to be
> hidden inside a command like "load_os".  I'm ok w/providing and
> optional argument to the command to override the desired dest addr.

Wolfgang advocated supporting the old parser.  Personally, I'm OK with 
requiring hush in order to enable the New Improved bootm behavior and 
leaving users of the old parser with the old bootm (arrrr, more 
#ifdefs).  I'm not sure we can get to a reasonable state without /some/ 
hush conditionals.

I think it would be foolish to cripple or kill a bootm refactor simply 
because we were unwilling to require hush.

>>> "load_fdt" could be:
>>>   bootm load_fdt
>>
>> This is probably "fdt move"? (which is a misnomer: it actually is a 
>> copy - my bad)  The fdt source and destination addresses need to be 
>> determined (source from the image or "fdt address", malloc/lmb the 
>> destination?).  I would advocate an "image" (iminfo?) command that 
>> sets, as a side effect env variables or the image header structure you 
>> identified previously.
>>
>> Obviously, I have not thought through this very carefully.
> 
> Some of this can be dealt with in a second pass.
> 
>>>   bootm boardsetup_fdt
>>
>> Use "fdt boardsetup"
> 
> We can't use it directly.  Remember the unconditionality/control issues.

Either conditionals or have two scripts, one with fdt and one without 
(which still is a conditional, just SEP to implement the conditional).

My drive is to get bootm to only boot stuff out of memory and I'm 
fixating on getting bootm out of the business of rearranging and fixing 
up stuff in memory.  IMHO there are or should be other commands to do 
all the rearranging and fixing up.  Well, as much as possible anyway.

>>>   bootm fdt_resize
>>
>> "fdt move" with a size will do a resize.  Perhaps a new "fdt resize" 
>> command to make it more obvious.  Do we really need to resize, can we 
>> just make the fdt blob "big enough" (at the source or when we do the 
>> "fdt move") and not worry about it?  Note that I addressed this 
>> previously with the "-S" dtc flag (now deprecated, use -p instead) and 
>> forced the problem on whoever built the blob originally.  Not 100% 
>> satisfactory, but making it SEP is very effective. ;-)
> 
> Andy providing a patch that makes -S/-p not needed anymore.  I'd prefer 
> to keep that functionality.  So we should have resize support.

Yes, but I would like it to be built into the fdt command, not the bootm 
command.

While autoresizing is cool, I struggle seeing why we need to work so 
hard.  Adding 4K padding isn't /that/ bad (ducks as Wolfgang swings). 
Doing two passes is ugly IMHO.  Oh well, another dog, another day.

> The key to remember is in the first pass we have to be able to do all 
> the steps in order and it work regardless of the input differences.. 
> thus mimicking the current bootm functionality.  This means no 
> (if..than..else) which means we can't use any of the current commands 
> directly.
> 
> - k

Hush little baby, don't say a word...
gvb

<http://kids.niehs.nih.gov/lyrics/hushbaby.htm>