This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RE: AT91 patches
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