Re: [ECOS] RE: AT91 patches

[Daniel Leu <daniel_leu@inicore.com>]

Hi Jonathan,

First, I'm pleased to see some work on the AT91 port. THANKS!

I second Jani's statement. Couldn't we start with the AT91
rearchitecture. This is the basis of all the other AT91 based
platforms and I don't think that they need the Flash changes.

Thanks!
Daniel

At 02:24 PM 1/30/2003 +0200, Jani Monoses wrote:
>Jifl, Thomas
>can't the AT91 patch be merged without the flash changes initially?
>The existing EB40 is not using it's first half of the flash anyway
>being reserved for angel.
>So IMHO ther would be a more logical layout for other AT91 variants to
>be worked on and no regression introduced since the EB40 flash is not 
>multiple sector
>aware AFAIK.
>
>Jani.
> > 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


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss