This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]