[Bug 1001648] New: flash_init() behaves differently if CYGHWR_IO_FLASH_DEVICE==1

[Bug 1001648] New: flash_init() behaves differently if CYGHWR_IO_FLASH_DEVICE==1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001648

           Summary: flash_init() behaves differently if
                    CYGHWR_IO_FLASH_DEVICE==1
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Flash
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernd.edlinger@hotmail.de
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1884)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1884)
Patch for io/flash/current/src/flash.c

depending on the hardware layer, the define CYGHWR_IO_FLASH_DEVICE
may be ==1 or !=1.

If there are 2 or more flash devices say NOR, and SPI flash, the function
flash_init() tries to initialize all possible flash devices, and if all
flash devices fail to initalize there is a chance that it will succeed later.

But if there is only 1 flash device driver, and it fails to initialize on 
the first call, then all following tries to call flash_init() fail too,
without the flash driver's initialize function ever being called again.

Furthermore if you look at the function flash_sort_and_check(),
there is a static variable "flash_head" that is not initalized, if this
function happens to be called again. This may happen if the regions are
overlapping, then the second run of this function may corrupt the linked
list of initialized devices, entering for instance an endless loop.

Finally, when you look at the function cyg_flash_erase(),
there is a check that prevents the erase from being done,
if all bytes are already 0xFF.

This can make the JFFS2 driver fail, because there is code that
explicitly checks for blocks with all data bytes being 0xFF, but no
valid JFFS2 valid block Marker, and explicitly erases the Block, and writes
a JFFS2 valid block marker at the sector.

The reason behind this, is that the value 0xFF may be unstable, if the
flash device did not complete the full erase cycle, maybe because of a
power fail event.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001648] New: flash_init() behaves differently if CYGHWR_IO_FLASH_DEVICE==1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001648

           Summary: flash_init() behaves differently if
                    CYGHWR_IO_FLASH_DEVICE==1
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Flash
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernd.edlinger@hotmail.de
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1884)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1884)
Patch for io/flash/current/src/flash.c

depending on the hardware layer, the define CYGHWR_IO_FLASH_DEVICE
may be ==1 or !=1.

If there are 2 or more flash devices say NOR, and SPI flash, the function
flash_init() tries to initialize all possible flash devices, and if all
flash devices fail to initalize there is a chance that it will succeed later.

But if there is only 1 flash device driver, and it fails to initialize on 
the first call, then all following tries to call flash_init() fail too,
without the flash driver's initialize function ever being called again.

Furthermore if you look at the function flash_sort_and_check(),
there is a static variable "flash_head" that is not initalized, if this
function happens to be called again. This may happen if the regions are
overlapping, then the second run of this function may corrupt the linked
list of initialized devices, entering for instance an endless loop.

Finally, when you look at the function cyg_flash_erase(),
there is a check that prevents the erase from being done,
if all bytes are already 0xFF.

This can make the JFFS2 driver fail, because there is code that
explicitly checks for blocks with all data bytes being 0xFF, but no
valid JFFS2 valid block Marker, and explicitly erases the Block, and writes
a JFFS2 valid block marker at the sector.

The reason behind this, is that the value 0xFF may be unstable, if the
flash device did not complete the full erase cycle, maybe because of a
power fail event.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.