[U-Boot] bootm state -- stateful vs stateless

[U-Boot] bootm state -- stateful vs stateless

[Kumar Gala]

One of the things that wasn't clear to me is if we are ok with  
maintaining state between 'bootm' subcommand inside u-boot or if we  
really require passing all state via arguments and env.

While I know it would be nice if the subcommands were stateless I dont  
think this is practical.

state we'd have to keep track of:
* arguments to the "top level" bootm command
* type of arguments (fit vs plain addresses)
* Image information, for FIT we get something like:

#if defined(CONFIG_FIT)
         const char      *fit_uname_cfg; /* configuration node unit  
name */

         void            *fit_hdr_os;    /* os FIT image header */
         const char      *fit_uname_os;  /* os subimage node unit name  
*/
         int             fit_noffset_os; /* os subimage node offset */

         void            *fit_hdr_rd;    /* init ramdisk FIT image  
header */
         const char      *fit_uname_rd;  /* init ramdisk subimage node  
unit name */
         int             fit_noffset_rd; /* init ramdisk subimage node  
offset */

#if defined(CONFIG_PPC)
         void            *fit_hdr_fdt;   /* FDT blob FIT image header */
         const char      *fit_uname_fdt; /* FDT blob subimage node  
unit name */
         int             fit_noffset_fdt;/* FDT blob subimage node  
offset */
#endif
#endif

and for legacy we get:

typedef struct image_header {
         uint32_t        ih_magic;       /* Image Header Magic  
Number    */
         uint32_t        ih_hcrc;        /* Image Header CRC  
Checksum    */
         uint32_t        ih_time;        /* Image Creation  
Timestamp     */
         uint32_t        ih_size;        /* Image Data  
Size              */
         uint32_t        ih_load;        /* Data  Load   
Address          */
         uint32_t        ih_ep;          /* Entry Point  
Address          */
         uint32_t        ih_dcrc;        /* Image Data CRC  
Checksum      */
         uint8_t         ih_os;          /* Operating  
System             */
         uint8_t         ih_arch;        /* CPU  
architecture             */
         uint8_t         ih_type;        /* Image  
Type                   */
         uint8_t         ih_comp;        /* Compression  
Type             */
         uint8_t         ih_name[IH_NMLEN];      /* Image  
Name           */
} image_header_t;

* entry point of OS image
* region tracking of memory regions used by previous subcommands (OS  
image, bd_t, fdt, initrd, etc.)

This seems like a lot of state to pass around in the env and via  
arguments to commands.  My vote is for stateful sub_commands.

- k

[U-Boot] bootm state -- stateful vs stateless

[Jerry Van Baren]

Kumar Gala wrote:
> One of the things that wasn't clear to me is if we are ok with 
> maintaining state between 'bootm' subcommand inside u-boot or if we 
> really require passing all state via arguments and env.
> 
> While I know it would be nice if the subcommands were stateless I dont 
> think this is practical.
> 
> state we'd have to keep track of:
> * arguments to the "top level" bootm command
> * type of arguments (fit vs plain addresses)
> * Image information, for FIT we get something like:

[snip of killer state information]

> * entry point of OS image
> * region tracking of memory regions used by previous subcommands (OS 
> image, bd_t, fdt, initrd, etc.)
> 
> This seems like a lot of state to pass around in the env and via 
> arguments to commands.  My vote is for stateful sub_commands.
> 
> - k

Useful info and analysis.  I agree, it looks like we will need to be 
stateful.

Best regards,
gvb

[U-Boot] bootm state -- stateful vs stateless

[Kumar Gala]

On Aug 7, 2008, at 9:37 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> One of the things that wasn't clear to me is if we are ok with  
>> maintaining state between 'bootm' subcommand inside u-boot or if we  
>> really require passing all state via arguments and env.
>> While I know it would be nice if the subcommands were stateless I  
>> dont think this is practical.
>> state we'd have to keep track of:
>> * arguments to the "top level" bootm command
>> * type of arguments (fit vs plain addresses)
>> * Image information, for FIT we get something like:
>
> [snip of killer state information]
>
>> * entry point of OS image
>> * region tracking of memory regions used by previous subcommands  
>> (OS image, bd_t, fdt, initrd, etc.)
>> This seems like a lot of state to pass around in the env and via  
>> arguments to commands.  My vote is for stateful sub_commands.
>> - k
>
> Useful info and analysis.  I agree, it looks like we will need to be  
> stateful.

Wolfgang do you agree?

- k