[U-Boot-Users] simplify bootm command

[Kumar Gala]

On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:

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

If this is what Wolfgang was aiming I'm all for it.  is it?

I think we should start with a detailed 'script' to mimic existing  
bootm behavior to know what commands we need to add beyond the builtin  
change.

- k