This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: Intel FLASH
- From: "Doyle, Patrick" <WPD at dtccom dot com>
- To: "'Jani Monoses'" <jani at iv dot ro>, ecos-patches at sources dot redhat dot com
- Date: Fri, 26 Sep 2003 10:50:57 -0400
- Subject: RE: Intel FLASH
Hmmm, from a (very) brief look at the, and extrapolating wildly from your
email, it appears that perhaps the strata driver was designed to
automatically work with a variety of Intel devices. I have worked with the
28Fxxxx and the AMD drivers in the past, where I had to fill in a table with
the device ID and other interesting parameters. I don't see a similar table
for the strata.
Pardon me for asking, but does this mean I should have been able to select
the "strata" driver and expect it to work without any changes? (Note my use
of the word "expect" up there -- if I were to assume that your changes to
the driver to specify the block address were in place).
If that is the case, then I'm with you -- why are there different drivers?
What are the costs & benefits of using one driver over the other?
--wpd
> -----Original Message-----
> From: Jani Monoses [mailto:jani@iv.ro]
> Sent: Friday, September 26, 2003 9:34 AM
> To: ecos-patches@sources.redhat.com
> Subject: Re: Intel FLASH
>
>
> Patrick,
> I added the same kind of support to the strata package and I am using
> the wireless flash model myself. I have one more patch to send in to
> treat lock/unlock operations the same i.e expicitley specify block
> addres and not XX. And also treat bootblock right as the erase op
> does.And I looked at the older datasheets too and I think
> it's safe what
> you do. Too bad there are 3 intel 28 generic flash drivers in ecos
> instead of one which works. So you can try the strata if you
> want and I
> can send you the rest of the patch which is not cleaned up
> yet, the part
> which detects it.
>
> Jani
>
> > While adding support for the 28F640W18 flash device from
> Intel, I ran
> > into a small problem. This device has multiple partitions and
> > supports Read-While-Write or Read-While-Erase. I am not (yet)
> > planning on adding support for these nifty features into
> eCos (I don't
> > need them yet), but one side effect of this feature is that, when
> > talking to the device, the write address for the first bus
> cycle must
> > be within the partition to be written/erased/etc...
> >
> > So, I found myself modifying flash_28fxxx.inl to
> accommodate this. I
> > made several changes similar to the one shown below:
> >
> > Index:
> >
> packages/devs/flash/intel/28fxxx/current/include/flash_28fxxx.inl====
> > =============================================================== RCS
> >
> file:/cvs/ecos/ecos/packages/devs/flash/intel/28fxxx/current/include/
> > flash_28fxxx.inl,v
> > retrieving revision 1.8
> > diff -u -5 -p -r1.8 flash_28fxxx.inl
> > ---
> packages/devs/flash/intel/28fxxx/current/include/flash_28f
> xxx.inl 12
> > Dec 2002 21:15:27 -0000 1.8
> > +++
> packages/devs/flash/intel/28fxxx/current/include/flash_28f
> xxx.inl 26
> > Sep 2003 13:22:17 -0000
> > @@ -289,23 +289,23 @@ flash_erase_block(void* block, unsigned
> >
> > while (len > 0) {
> > b_v = FLASH_P2V(b_p);
> >
> > // Clear any error conditions
> > - ROM[0] = FLASH_Clear_Status;
> > + b_v[0] = FLASH_Clear_Status;
> >
> > // Erase block
> > - ROM[0] = FLASH_Block_Erase;
> > + b_v[0] = FLASH_Block_Erase;
> > *b_v = FLASH_Confirm;
> >
> > timeout = 5000000;
> > - while(((stat = ROM[0]) & FLASH_Status_Ready) !=
> > FLASH_Status_Ready){
> > + while(((stat = b_v[0]) & FLASH_Status_Ready) !=
> > FLASH_Status_Ready){
> > if (--timeout == 0) break;
> > }
> >
> > // Restore ROM to "normal" mode
> > - ROM[0] = FLASH_Reset;
> > + b_v[0] = FLASH_Reset;
> >
> > if (stat & FLASH_ErrorMask) {
> > if (!(stat & FLASH_ErrorErase)) {
> > res = FLASH_ERR_HWR; // Unknown error
> > } else {
> >
> > Basically, instead of writing the "FLASH Block Erase" or "FLASH
> > reset", etc... Command to address 0 in the flash, I write
> it address 0
> > in the block to be erased, programmed, reset, etc...
> >
> > Before I submit a formal patch, I wanted to get some feedback from
> > folks. Can you think of any reason why this would break
> other "normal"
> > flash devices? I looked at the data sheet for the "C3" parts
> > (28F800C3, 28F160C3, etc...) and it lists the first bus
> cycle address
> > as "Don't care". So I anticipate that I won't break the driver for
> > those parts, but what about others?
> >
> > Comments, questions, snide remarks?
> >
> > --wpd
>
>