16-bit JEDEC Flash

[Jonas Holmberg]

I tried something like that before writing amd_flash.c, but I noticed that many non-CFI flashes don't support some of the things that CFI-flashes support (e.g. unlock bypass). And I think the safest way to know if a non-CFI flash has finished erasing or writing would be to check the toggle or data polling bit instead of udelaying.

If your 16-bit flash uses the AMD command set you can just add it to the table in amd_flash_probe() and it should work right away.

There are of course many similarities between cfi_cmdset_0002.c and amd_flash.c (a lot of it is stolen from cfi_cmdset_0002.c), and we ought to make some of the CFI-specific stuff non-CFI-specific so that it can be used from amd_flash.c also.

/Jonas

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2 at infradead.org]
> Sent: Wednesday, March 07, 2001 11:46 AM
> To: Erwin Authried
> Cc: 'mtd at infradead.org'
> Subject: Re: 16-bit JEDEC Flash 
> 
> 
> 
> eauth at softsys.co.at said:
> > From the comments in jedec.c I figure out that 16-bit JEDEC flash is
> > not supported. There are still several manufacturers that produce
> > flash without CFI (e.g., Atmel). If that's true, wouldn't 
> it be better
> > to use the already existing cfi implementation to emulate a CFI
> > device, instead of implementing all that stuff again for non-CFI
> > flash? I believe it wouldn't be much more than having a 
> table with the
> > JEDEC id's as an index  that contains all the CFI parameters. 
> 
> Yes please, that seems like a sensible plan. :)
> 
> --
> dwmw2
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> 


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org