Re: [ECOS] Redboot_ROM config_data corrupted by flash_erase

[Sergei Gavrikov <w3sg at SoftHome dot net>]

On Tue, Jul 17, 2007 at 10:12:41AM -0300, Tales Toledo wrote:
> On 7/16/07, Sergei Gavrikov <w3sg@softhome.net> wrote:
> >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.
> 
> This is the printf code used @ fconfig.c
> 
> diag_printf("\nconfig->key1 = 0x%lx, config->key2 = 0x%lx,
> config->cksum = 0x%lx\n", config->key1, config->key2, config->cksum);
>        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));
>        } else {
>            diag_printf("\nconfig->key1 = 0x%lx, config->key2 = 0x%lx,
> config->cksum = 0x%lx\n", config->key1, config->key2, config->cksum);
>            conf_endian_fixup(config);
>            diag_printf("\nconfig->key1 = 0x%lx, config->key2 = 0x%lx,
> config->cksum = 0x%lx\n", config->key1, config->key2, config->cksum);
>            if ((stat = FLASH_PROGRAM(cfg_base, config, sizeof(struct
> _config), (void **)&err_addr)) != 0) {
>                diag_printf("Error writing config data at %p: %s\n",
>                            err_addr, flash_errmsg(stat));
>            }
>            diag_printf("\nconfig->key1 = 0x%lx, config->key2 = 0x%lx,
> config->cksum = 0x%lx\n", config->key1, config->key2, config->cksum);
>            conf_endian_fixup(config);
>        }
> 
> this is the fconfig -i
> 
> RedBoot> fconfig -i
> Initialize non-volatile configuration - continue (y/n)? y
> Run script at boot: false
> Use BOOTP for network configuration: false
> Gateway IP address: 192.168.1.1
> Local IP address: 192.168.1.100
> Local IP address mask: 255.255.255.0
> Default server IP address: 192.168.1.1
> DNS domain name: <Not a string: 0x1FE32F5>
> DNS server IP address: 192.158.1.1
> Network hardware address [MAC]: 0x7C:0x71:0x43:0xA6:0x7C:0x92
> GDB connection port: 9000
> Force console for special debug messages: false
> Network debug at boot time: false
> Update RedBoot non-volatile configuration - continue (y/n)? y
> 
> and here are the results...
> 
> config->key1 = 0xbadface, config->key2 = 0xdeaddead, config->cksum = 
> 0x8d640ef3
> ... Erase from 0x407e0000-0x407e1000: .
> 
> config->key1 = 0xbadface, config->key2 = 0xffffffff, config->cksum = 
> 0xffffffff
> 
> config->key1 = 0xbadface, config->key2 = 0xffffffff, config->cksum = 
> 0xffffffff
> ... Program from 0x01fe3000-0x01fe4000 at 0x407e0000: .
> 
> config->key1 = 0xbadface, config->key2 = 0xffffffff, config->cksum = 
> 0xffffffff
> 
> The data at config_data is being corrupted during flash_erase, isnÂt it?

I see, but that data should not be used by flash_erase(). Are you sure
what your RedBoot sources are still so good is they were a few weeks
ago?  Well, I did insert same debug outputs there just to show my values
by the stages, see an Appendix below.

...I suggest you, please, make an undo to origin sources and try all
from scratch. I have a mind, If eCos PowerPC community still is silent,
it seems they don't believe in any RedBoot FIS bug ;-) I don't remember,
Did I ask you about your eCos tree date? Is that a freshmeat?  Had your
platform been included in anon CVS tree? And at the end, try to correct
a mail subject, put there something like this, "PowerPC <your platform>
RedBoot 'fconfig -i' issue". Make an accent on your hardware family.  I
think that would awake the target/platform experts (I promise that I
won't shadow your asks in future :)


Sergei

---------------------------------------------------------------------
Appendix

line 805 -- before erase
line 809 -- after erase
line 811 -- after endian fixup
line 816 -- after program
line 818 -- after endian fixup

Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Console baud rate: 38400
Update RedBoot non-volatile configuration - continue (y/n)? y
... Unlock from 0x803e0000-0x803e1000: .
line: 805, *config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 805, *backup_config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 805, *cfg_base = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
... Erase from 0x803e0000-0x803e1000: .
line: 809, *config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 809, *backup_config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 809, *cfg_base = {0xffffffff, key2 = 0xffffffff, crc = 0xffffffff}
line: 811, *config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 811, *backup_config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 811, *cfg_base = {0xffffffff, key2 = 0xffffffff, crc = 0xffffffff}
... Program from 0x810e3000-0x810e4000 at 0x803e0000: .
line: 816, *config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 816, *backup_config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 816, *cfg_base = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 818, *config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 818, *backup_config = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
line: 818, *cfg_base = {0xbadface, key2 = 0xdeaddead, crc = 0xba13f4de}
... Lock from 0x803e0000-0x803e1000: .



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