[ECOS] Amd flash + bootblock problem (Flash V1)

[Lars Povlsen]

As I've had no responses to this issue, I went on and fixed the issue...

So here's the fixes... - I case anyone's interested. I've thrown in the
MX29LV128M-T support as well where I hit the bug.

Comments?

---Lars

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Lars
Povlsen
Sent: 31. marts 2006 14:52
To: eCos Disuss
Subject: [ECOS] Amd flash + bootblock problem (Flash V1)



Hi there!

I am adding support for a Amd-compatible flash device - MX29LV128M-T. It
is a 255*64+8*8 device - the bootblocks at the top. I've added the
device like the other "bootblock" devices in flash_am29xxxxx_parts.inl -
the device is recognized, etc. etc. All good. Almost...

In the default setup, redboot uses the last (logical=64K) block as the
directory index (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK = -1). When I issue
a "fconfig -i", redboot tries write this sector - which is where the
(physical) bootsectors reside in.

To make a long story short, I've tracked down an issue in
flash_am29xxxxx_parts.inl - find_sector() gets called, but fails to
return the block size as appropriate for the boot sector size (returns
64K instead of 8K) - making the calling flash_program_buf() timeout when
it traverses the actual sector boundary without the needed sector setup.

Sooooh, while I'm making a stab at fixing this appropriately for at
least my satisfaction, I just wanted to know whether this has been
noticed by others - or if have gotten something wrong?

For the reference, all works like expected if I keep out of the
bootsectors area (i.e. setting CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK = -2).

And yes, the bootsectors are not really used as "boot sectors". Just a
matter of flash device availability. I can quite happily live with
"loosing" boot area with eCos, if eCos does not fully accommodate my
configuration...

Sincerely,

Lars Povlsen
Vitesse Semiconductor

PS: The Flash definition, in my case CYGNUM_FLASH_INTERLEAVE == 1:

#ifdef CYGHWR_DEVS_FLASH_AMD_MX29LV128
    {   // MX29LV128M-T
        long_device_id: true,
        device_id  : FLASHWORD(0x227e),
        device_id2 : FLASHWORD(0x2211),
        device_id3 : FLASHWORD(0x2201),
        block_size : 0x10000 * CYGNUM_FLASH_INTERLEAVE,
        block_count: 256,
        device_size: 0x1000000 * CYGNUM_FLASH_INTERLEAVE,
        base_mask  : ~(0x1000000 * CYGNUM_FLASH_INTERLEAVE - 1),
        bootblock  : true,
        bootblocks : { 0xff0000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       0x002000 * CYGNUM_FLASH_INTERLEAVE,
                       _LAST_BOOTBLOCK
                     },
        banked     : false,
        bufsiz     : 16
    },
#endif

 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: am29xxxxx.diff
Type: application/octet-stream
Size: 4957 bytes
Desc: am29xxxxx.diff
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20060404/ebe142d8/attachment.obj>
-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss