Re: V2 flash - new AM29xxxxx driver

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "David" == David Vrabel <dvrabel@arcom.com> writes:

    David> Bart Veer wrote:
    >> 
    >> 2) instead the device size and boot block layout can be
    >> provided statically in the platform HAL,

    David> How is this going to work when a board supports a range of
    David> chips (e.g., 29LV128 and 29LV256)? Will CFI have to be used
    David> in this case?

As per the documentation, there are two ways of addressing this. The
first is to use CFI. This will add a bit of code size overhead, but
any scheme that involves run-time support adds overhead. I haven't
done any measurements, but suspect that past two devices CFI will
actually be the most efficient solution. Two devices may be
borderline. CFI will also give you long-term manufacturing
flexibility.

The second approach is to write a custom init function which calls
cyg_am29xxxxx_read_devid_XX() to figure out what device is actually
present. Pick one device as the default and use its boot block layout
and size values in the static data. If at run-time you discover you
have picked the wrong device, replace the default settings with the
correct ones.

The custom init function becomes more important if the flash devices
offer different functionality, e.g. if one device supports buffered
writes and the other device doesn't. The init function can modify the
table of device functions, replacing the straightforward program
function with one that supports buffered writes (although my current
V2 driver does not yet have a function for buffered writes). This
situation is not going to arise very often but the driver design
allows for it.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts