This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RE: AT91 patches
- From: Doug Fraser <dfraser at photuris dot com>
- To: "'Koeller, T.'" <Thomas dot Koeller at baslerweb dot com>, "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 30 Jan 2003 09:52:57 -0500
- 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