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


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_28fxxx.inl	12
> Dec 2002 21:15:27 -0000	1.8
> +++ packages/devs/flash/intel/28fxxx/current/include/flash_28fxxx.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]