[ECOS] Redboot_ROM config_data corrupted by flash_erase

[ECOS] Redboot_ROM config_data corrupted by flash_erase

[Tales Toledo]

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.

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

Re: [ECOS] Redboot_ROM config_data corrupted by flash_erase

[Sergei Gavrikov]

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

Re: [ECOS] Redboot_ROM config_data corrupted by flash_erase

[Tales Toledo]

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?

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

Re: [ECOS] Redboot_ROM config_data corrupted by flash_erase

[Sergei Gavrikov]

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