[U-Boot] granularity of bootm subcommands

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Kumar Gala wrote:
> So I proposed a set of subcommands that looked like:
> 
>    bootm start <args>
>    bootm prep
>    bootm load_os
>    bootm load_fdt
>    bootm load_initrd
>    bootm jump
>    bootm restore
> 
> is this the right granularity or should we go finer?
> 
> "prep" could be:
> 
>    bootm disable_interrupts
>    bootm usb_stop

This is "usb stop"

>    bootm disable_caches

This is "icache off && dcache off"

> "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?).

I'm speculating based on a very brief look at the code/structs that an 
image command could do a "load" on a kernel image and ramdisk image 
identically (filling out an image header struct as a side effect?).  For 
"FIT" images, there are potentially more pieces, but the concept would 
be the same.

I'm kinda hung up on how to use the image header struct.  I think we 
want to be able to reference values for scripting (e.g. fixing up fdt 
properties) which implies the values need to be put into env variables 
(ugh, lots of 'em) or we need a way for an "image" command (?) to pull 
values out of the image header struct?

<fill in clever ideas here>

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

>    bootm boardsetup_fdt

Use "fdt boardsetup"

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

> "load_initrd" could be:
>    bootm load_initrd

See "load_os" comments on it being an "image" command.

>    bootm fdt_initrd_fixup

This is fixing up the fdt blob to point to the initrd?  That should be 
doable with a couple of "fdt set <path> <value>" commands.

> "jump" stays as is.

YEAH!  The Core Functionality.

> "restore" could be:
>    bootm enable_interrupts
>    bootm usb_start

"usb reset" looks like it does this?

>    bootm enable_caches

icache on && dcache on

> Also I'm adding in:
>    bootm cmdline

Use "fdt set <path> $cmdline"?

>    bootm kbd (kernel bd_t)

I presume "kbd" is shorthand for "kernel bd", aka. legacy boot.  Maybe 
"bootm legacybd"?  (shortenable to "bootm legacy")

> Finally I'd like to change the subcommands to be prefixed with '_' to  
> make parsing easier:
>    bootm _start <args>
>    bootm _prep
>    bootm _load_os

Bleah, I dislike typing underscores, it requires me to use both hands 
and seriously impacts my ability to drink beer. :-P  Since these 
commands will all be scripted (normally), I can live with that.

Thanks,
gvb