This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: flash driver organization
- From: "Andy Hare" <ahare at ap-systems dot co dot uk>
- To: "Eric Smith" <eric-ecd at brouhaha dot com>,<ecos-devel at sources dot redhat dot com>
- Date: Tue, 6 May 2003 23:23:44 +0100
- Subject: Re: flash driver organization
- References: <34764.64.169.63.74.1051433185.squirrel@ruckus.brouhaha.com>
Eric,
I actually have a driver for the SST39VF160 and am waiting for my copyright
assignment to be cleared by Redhat before I can post the driver back into
eCos. I have created a new directory under packages/devs/flash called sst to
hold the 39vf160 driver based on the same scheme as the AMD and Intel
directories.
I will post the patches once I get clearence from Redhat to tell me they
have accepted my assignment. Maybe someone at eCosCentric could gee up
Redhat and also let me know the progress. It was sent 6+ weeks ago.
Cheers
Andy Hare
www.ap-systems.co.uk
----- Original Message -----
From: "Eric Smith" <eric-ecd@brouhaha.com>
To: <ecos-devel@sources.redhat.com>
Sent: Sunday, April 27, 2003 9:46 AM
Subject: flash driver organization
> Why are some flash drivers composed of code in include/foo.inl files
(e.g.,
> amd, atmel, intel 28f), and others as src/foo.c files (e.g., intel
> bootblock, strata)? Which is preferred for new drivers?
>
> I need to cons up support for some SST parts, mainly the SST39VF400A.
> SST30VF800A, and SST39VF160. They use JEDEC-standard commands, the
> same as the AMD 29x parts, but with smaller, uniform sector sizes.
> Is it reasonable to simply add the SST parts to the AMD driver rather
> than creating a new driver? I see that the AMD driver already supports
> some Toshiba and ST parts. (And Fujitsu parts, but those and the AMD
> parts are both made by FASL, so they're identical other than the vendor
> ID.)
>
> Thanks,
> Eric
>