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

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

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

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
participants (2)
-
Jerry Van Baren
-
Kumar Gala