This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Flash infrastructure rework
- From: vivek at employees dot org (Vivek Kumar)
- To: DAM at tt dot dk ("David Marqvar (DAM)")
- Cc: vivek at employees dot org (Vivek Kumar), andrew at lunn dot ch (Andrew Lunn),ecos-discuss at ecos dot sourceware dot org, Vivek dot Kumar at zeevo dot com
- Date: Mon, 9 Aug 2004 19:33:42 -0700 (PDT)
- Subject: Re: [ECOS] Flash infrastructure rework
Hi,
I am still trying to work with the company to give over there licenses. I
know this is not the right form to ask this but if someone has successfully
dealt with there company please send me an email.
Once I get that issue sorted out I will post my sources online and would
definitely need a lot of help with testing and proper integration to eCos
I am new to esco, and have never used these exact files with esco so I am
expecting some more challenging work for me, and of course all help would
be welcome
-vivek
>
> Hi,
>
> This is really great to hear.
> Vivek, please let me know if I can be to any help for you (testing,
> porting, .cdl-files, etc., etc.)
> I'm really looking out for CFI support. The chip-mess I know :-|
>
> Best regards,
> David Marqvar
>
> -----Original Message-----
> From: Vivek Kumar [mailto:vivek@employees.org]=20
> Sent: 6. august 2004 19:19
> To: David Marqvar (DAM); Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org; Vivek.Kumar@zeevo.com
> Subject: Re: [ECOS] Flash infrastructure rework
>
> Hi,
>
> The exact cfi specs can be downloaded from www.jedec.com (registration
> is probably required). AMD and Intel would cover all bases. SST has its
> own extensions (so does Mitsubishi) but they are almost similar to the
> AMD type.
>
> The implementation is really simple, but the the real pain was to take
> care of is the 'diversions' which the vendors take and not tell you.
>
> The things I remember offhand are
>
> - SST flash lists its sectors twice, so if you add all of them up=20
> you get double the flash size.
> - SST also needs some extended commands to enter the CFI mode.
> - AMD extensions V1.1 and below do not tell whether its a top boot
>
> flash or a bottom boot and the sectors are sometime stored as=20
> smallest first or the largest first. We had to read the Flash ID
>
> to determine what to do with the sectors.
> =20
> and on and on and on=20
>
>
> At one point we were thinking why the hell did we try cfi? But having
> one that I can say for sure its really good we did that. Marketing now
> does not now come to me every other day asking if I can add driver
> support for xxx flash, which most of the time meant reading the spec
> adding another table and testing it. Whew..
>
> -Vivek
>
> http://www.vivekkumar.net
>
> > -----Original Message-----
> > From: David Marqvar (DAM) [mailto:DAM@tt.dk]
> > Sent: Friday, August 06, 2004 6:45 AM
> > To: Andrew Lunn
> > Cc: ecos-discuss@ecos.sourceware.org
> > Subject: RE: [ECOS] Flash infrastructure rework
> >=20
> >=20
> > Sounds great.
> >=20
> > I've been wanting to make a general flash driver based on CFI which=20
> > would support the two main programming algorithm's around: Intel
> > (Strata) and AMD (don't know if it's really these companies that=20
> > invented the algorithm, anyway I think you know what I mean). Is SST=20
> > yet another programming algorithm or =3D=3D ADM?
> >=20
> > Though CFI I can read the physical layout of the flash and the=20
> > programming algorithm to use.
> > This way the flash-driver could be generel, not limited to one or more
>
> > certian devices.
> >=20
> > Do you see any show-stoppers for creating such driver?
> >=20
> > /David
> >=20
> > -----Original Message-----
> > From: ecos-discuss-owner@ecos.sourceware.org
> > [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew=20
> > Lunn
> > Sent: 6. august 2004 15:23
> > To: eCos Disuss
> > Subject: Re: [ECOS] Flash infrastructure rework
> >=20
> > > I put the code on a branch so that a few people can test it and so=20
> > > we get a better idea how stable the code is with hardware i don't=20
> > > have access to.
> >=20
> > This is what i decided to do. In cvs there is now a branch called=20
> > flash_v2. If you checkout/update to that branch you will get my new=20
> > flash code. There is also new generic drivers for SST and Strata.=20
> > Since so many targets use strata i did not want to modify them all to=20
> > use the new driver. So the strata driver is a new packets along side=20
> > the old one. For the SST driver i have modified all targets that use=20
> > it. That was easier since only the e7t and the aim711 use this driver.
> >=20
> > I've attached a hardware dependent driver for our platform which makes
>
> > use of the sst and strata device. This could be used as an example as=20
> > to how to modify the hardware dependent part of a flash driver to use=20
> > the new code.
> >=20
> > One thing to watch out for is that the hardware dependent driver has=20
> > to go into libextras.a. If you forget this the driver will be thrown=20
> > away at link time...
> >=20
> > And lastly a warning to testers.... There could be bugs which destroy=20
> > your boot loader etc. Make sure you can restore the device with jtag=20
> > before playing with this code.
> >=20
> > Thanks
> > Andrew
> >=20
> > --
> > Before posting, please read the FAQ:=20
> > http://ecos.sourceware.org/fom/ecos
> > and search the list archive:=20
> > http://ecos.sourceware.org/ml/ecos-discuss
> >=20
> >=20
> > _____________________
> > Confidentiality note: This email and any attachments may contain
> private, confidential, and privileged material for the sole use of the
> intended recipient. Any unauthorized review, use, disclosure or
> distribution is strictly prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all
> copies of the original message.
> >=20
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss