Re: [ECOS] Redboot_ROM config_data corrupted by flash_erase

[Sergei Gavrikov <w3sg at SoftHome dot net>]

On Mon, Jul 16, 2007 at 12:50:52PM -0300, Tales Toledo wrote:
> Hi,
> 
> can flash_erase corrupt my config_data (I'm running Redboot from ROM)?
> 
> I'm asking this because just before
> 
> if ((stat = flash_erase(cfg_base, cfg_size, (void **)&err_addr)) != 0) {
>                   diag_printf("   initialization failed at %p: %s\n",
> err_addr, flash_errmsg(stat));
> 
> at fconfig.c I can get all config-key1, config->key2, config->cksum
> with the right values.
> 
> After run flash_erase and before run conf_endian_fixup + flash_program
> the config_data is corruted and lost config->key2 and config->cksum.
> 

That's normal if you had meant a "corruption" of a copy is placed in
FLASH.  The `FLASH_BlankValue' values (io/flash/include/flash_dev.h)
should be there after flash_erase() ...  -> flash_erase_block () calls.
For the _most_ cases that area will be look as an array is filled by
0xff. These is an example of *config, *backup_config, and *(struct
_config *)cfg_base GDB displays for RedBoot 'fconfig -i' command, GDB is
stopped in a middle of the flash_erase_block() function. This is just a
demo for my platform

(gdb) n
324                 if (*b_v != FLASH_BlankValue ) {
3: *(struct _config *) cfg_base = {len = 0xffffffff, key1 = 0xffffffff, 
  config_data = 'ï' <repeats 4080 times>, key2 = 0xffffffff, 
  cksum = 0xffffffff}
2: *backup_config = {len = 0x1000, key1 = 0xbadface, 
  config_data =
"\001\f\001\0boot_script\0\0\0\0\0\004\021\001\fboot_script_data\0boot_script",
'\0' <repeats 513 times>,
"\002\024\001\fboot_script_timeout\0boot_script\0\0\0\0\0\002\022\001\0console_baud_rate\0\0\226",
'\0' <repeats 3450 times>, key2 = 0xdeaddead, cksum = 0xba13f4de}
1: *config = {len = 0x1000, key1 = 0xbadface, 
  config_data =
"\001\f\001\0boot_script\0\0\0\0\0\004\021\001\fboot_script_data\0boot_script",
'\0' <repeats 513 times>,
"\002\024\001\fboot_script_timeout\0boot_script\0\0\0\0\0\002\022\001\0console_baud_rate\0\0\226",
'\0' <repeats 3450 times>, key2 = 0xdeaddead, cksum = 0xba13f4de}
(gdb) 

So, the flash_erase() call does (should do) an erasing (look at the
GDB's display the *cfg_base , and then FLASH_PROGRAM() should do a real
programming the `config' struct into the FLASH. You see, what there is
such a sequence: flash_unlock (optional) -> flash_erase -> flash_program
-> flash_lock (optional) there, so, you can believe the flash function
naming. It's more interesting what will those values (key1, key2, crc)
be after the FLASH_PROGRAM() call.


Sergei


> Atte,
> TT

> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss