[U-Boot-Users] simplify bootm command

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

Kumar Gala wrote:
> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

[snip]

>> One idea that has been spinning in my mind for some time is  to  make
>> the  "run"  command to execute the content of an environment variable
>> optional. Instead, we could try and handle environment variable names
>> similar to command names, i. e. instead of typing "run foo; run  bar"
>> you  could  just  write  "foo;  bar" (I woull probably still keep the
>> "run" command around to allow for the implicit error handling as used
>> in "run foo bar" without forcing the user to use the  hush  shell  to
>> get the equivalent "foo && bar").

[snip]

>> With such an implementation, we could move the FDT  handling  into  a
>> command  sequence  stored  in a "bootm" environment variable, and the
>> last part of this variable would be "builtin bootm" to run  the  real
>> (simplified) command.
>>
>> 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.

Rather than using the C preprocessor (and deductions based on 
parameters) to select the "appropriate" bootm behavior, an appropriate 
script would be used (there would be quite a few possible scripts, 
depending on _which_ "bootm" behavior is needed for a specific 
board/config).  (Despite just having "dissed" cpp bootm behavior 
generation, I'm thinking that we would want to use the cpp to generate a 
default script that would emulate the current bootm behavior.)

Best regards,
gvb