Re: flash driver organization

["Andy Hare" <ahare at ap-systems dot co dot uk>]

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
>