RE: [ECOS] RE: AT91 patches

["Koeller, T." <Thomas dot Koeller at baslerweb dot com>]

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