[U-Boot] granularity of bootm subcommands
Jerry Van Baren
gerald.vanbaren at ge.com
Fri Aug 8 16:42:51 CEST 2008
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
More information about the U-Boot
mailing list