[ECOS] RE: AT91 patches

Koeller, T. Thomas.Koeller@baslerweb.com
Thu Jan 30 12:22:00 GMT 2003


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 Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390


> -----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

More information about the Ecos-discuss mailing list