This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RE: AT91 patches
- From: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- To: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Cc: 'Doug Fraser' <dfraser at photuris dot com>
- Date: Thu, 30 Jan 2003 16:46:09 +0100
- Subject: RE: [ECOS] RE: AT91 patches
Hi Doug,
combining multiple small sectors into a larger one
does not help me, for reasons discussed earlier.
I cannot afford the huge RAM buffers required to
do this.
Thomas
-----------------------------------------------
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:Thomas.Koeller@baslerweb.com
http://www.baslerweb.com
> -----Original Message-----
> From: Doug Fraser [mailto:dfraser@photuris.com]
> Sent: Thursday, January 30, 2003 3:53 PM
> To: 'Koeller, T.'; ecos-discuss (E-Mail)
> Subject: RE: [ECOS] RE: AT91 patches
>
>
>
> Thomas,
>
> When you say 'variable sector size' support, are
> you talking about erase procedure only or actual
> information storage? I am not up to speed on JFFS2,
> but previous FFS I have used aggregated the smaller
> blocks in terms of large block groups, and treated
> the block grouping as a single large block.
>
> The only special treatment was that during an erase,
> the multiple small blocks were individually erased
> to effectively clear the virtual large block.
>
> Mostly just curious. I was looking at JFFS2 for a
> home project, but work and family life have gotten
> a bit nuts lately, so the hobby projects have to wait.
>
> Doug
>
> > -----Original Message-----
> > From: Koeller, T. [mailto:Thomas.Koeller@baslerweb.com]
> > Sent: Thursday, January 30, 2003 7:09 AM
> > To: ecos-discuss (E-Mail)
> > Cc: 'Jonathan Larmour'
> > Subject: [ECOS] RE: AT91 patches
> >
> >
> > Jonathan,
> >
> > as I see it, the ability to use flash chips with different
> > sector sizes is an important feature, the project I was
> > working on when I created the patch would have been doomed
> > if I had not been able to find a solution.
> >
> > The bulk of your arguments against including the patch is
> > about introducing incompatibilities into redboot. I designed
> > the patch so that the old scheme would still work without any
> > modifications, so any software using it can continue to
> > do so. This is also true for redboot. The modifications I made
> > to redboot are by no means essential, I only did this to
> > demonstrate how to use the new features, and because I did not
> > want to write a demo program from scratch, I used redboot.
> >
> > I still think my patch would be useful as a starting point for
> > adding variable sector size support. I do not claim it is
> > perfect, in fact I was hurrying when I wrote it. But if it
> > were in the ecos code base, then others could improve on it and
> > it would mature over time. I cannot see any fundamental
> > reasons why it cannot (or should not) be done the way I did it.
> >
> > To summarize it up: the patch maintains compatibility with
> > existing software. Only software that _wants_ to use the
> > extended interface has to be aware of the changes.
> >
> > We may wait for someone to come up with a perfect solution, or
> > someone willing to spend big bucks for this feature. But
> > then, we may have to wait for quite a while...
> >
> > Thomas
> > -----------------------------------------------
> > Thomas Koeller, Software Development
> >
> > Basler Vision Technologies
> > An der Strusbek 60-62
> > 22926 Ahrensburg
> > Germany
> >
> > Tel +49 (4102) 463-390
> > Fax +49 (4102) 463-46390
> >
> > mailto:Thomas.Koeller@baslerweb.com
> > http://www.baslerweb.com
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
> > > Sent: Thursday, January 30, 2003 8:01 AM
> > > To: eCos Patches List; Koeller, T.
> > > Subject: AT91 patches
> > >
> > >
> > > I have been working on trying to get the AT91 changes
> > > incorporated for the
> > > last while. The big problem, as described before, is the
> > > flash driver.
> > > Thomas's patch appeared to add support for different flash
> > > sector sizes.
> > > However it impacted flash device access in redboot that
> > > didn't need this.
> > >
> > > Now, support for differing flash sector sizes is a good thing
> > > when the
> > > hardware has it. The obvious benefit is the reduced
> > overhead for FIS
> > > directories and fconfig areas.
> > >
> > > With that in mind I tried to do what I could to fix this by
> > making it
> > > configurable at least. To that end I made a bunch of
> changes in the
> > > generic driver layer that were fine. I also made quite a
> > few changes
> > > analogous to what Thomas did in the redboot flash.c.
> > >
> > > However a few things became apparent:
> > >
> > > * I was making more and more changes that would be quite
> > > difficult to test
> > > in the absence of any hardware with differing sector sizes
> > > (although I
> > > realised I could spend some time getting the synth flash
> > > driver to pretend
> > > to do this). What's more the changes could well break normal
> > > targets, not
> > > just the AT91. That's unacceptable.
> > > * RedBoot's flash code has the idea of fixed block sizes
> very very
> > > ingrained. All the code can be changed only by breaking lots of
> > > fundamental design assumptions. It mixes numbers of sectors
> > > with sizes of
> > > sectors freely, including in CDL options and configuration
> > > from the drivers.
> > > * The more changes I had to make, the more it would end
> up being as
> > > invasive to fixed sized flash as Thomas's patch, just in a
> > > different way.
> > > * Thomas's patch wasn't complete anyway. It would loosely
> > > appear to work,
> > > but things would go wrong when flash limits exceeded certain
> > > boundaries
> > > (primarily where the sector size switches) or you want
> > > control over what
> > > goes into what sized blocks. It would end up as a somewhat
> > > schizophrenic
> > > RedBoot. It's fundamental really because RedBoot would still
> > > be oriented
> > > towards a fixed size.
> > >
> > > So my conclusion is that I can't see any way to reasonably
> > apply the
> > > existing flash driver with "true" mixed sector sizes at
> > all. The only
> > > sensible way to do it in the near term is to change the
> > > driver to use the
> > > same bootblock system as the existing drivers, which means
> > > they are read
> > > and written in chunks of the "larger" sector size.
> > >
> > > What's more that isn't something I can do either, not having
> > > an AT91 EB40
> > > board to test something like this. So unless someone out
> > > there is willing
> > > to donate one, I can't see the flash driver being included
> > > for a while
> > > until someone with one does it.
> > >
> > > I can do the rest of the eb40 port (and probably will soon),
> > > but without
> > > the flash driver, it's somewhat crippled in terms of
> > redboot support.
> > >
> > > Suggestions?
> > >
> > > In general, my recommendation is that in the not too distant
> > > future we
> > > will need a new flash system, designed from scratch to
> > > support multiple
> > > different devices any or each with different sector sizes,
> > > and NAND flash.
> > > To be honest, that requires a rewrite, mostly of the RedBoot
> > > code, and I
> > > can't foresee any compatibility with the existing hardware
> > > flash drivers
> > > as the layering isn't too good - too many dependencies and
> > > assumptions
> > > between the layers (e.g. passing _down_ the number of blocks
> > > in the device
> > > from the generic driver to the hardware one, and using the single
> > > flash_info global). At least not without a painful number
> > of ifdefs.
> > > Instead it would be a big switch between the old flash system
> > > and a new
> > > one - they could exist in the codebase at the same time, but
> > > new low level
> > > drivers would be needed for the new one. Based on the old
> > > ones for sure,
> > > so it's not really starting over, but the structure would be
> > > different.
> > >
> > > Of course no-one's likely to write such a system unless
> > > there's enough
> > > impetus, so I'm not going to hold my breath.
> > >
> > > Jifl
> > > --
> > > eCosCentric http://www.eCosCentric.com/
> > > <info@eCosCentric.com>
> > > --[ "You can complain because roses have thorns, or you ]--
> > > --[ can rejoice because thorns have roses." -Lincoln ]--
> > > Opinions==mine
> > >
> >
> > --
> > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > and search the list archive:
http://sources.redhat.com/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss