This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]