RE: [ECOS] RE: AT91 patches

RE: [ECOS] RE: AT91 patches

[Koeller, T.]

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

Re: [ECOS] RE: AT91 patches

[Jonathan Larmour]

Koeller, T. wrote:
> Hi Jonathan,
> 
> could you give an update on the current state of affairs
> regarding the AT91/EB40 HAL split? I am about to start a new
> project, and I definitly would like to get rid of my
> patched source tree.

They haven't made it into 2.0 beta. I intend to review and check them in 
between beta and final, although depending on the scale, it may be trunk 
only. I haven't at all forgotten.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "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

RE: [ECOS] RE: AT91 patches

[Koeller, T.]

Hi Jonathan,

could you give an update on the current state of affairs
regarding the AT91/EB40 HAL split? I am about to start a new
project, and I definitly would like to get rid of my
patched source tree.

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 11:29 PM
> To: Daniel Leu
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] RE: AT91 patches
> 
> 
> Daniel Leu wrote:
> > 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.
> 
> Yes, I think will move forward with just the AT91 and EB40 
> changes, and 
> drop the flash driver for now. Doing that much at least for 
> the moment 
> should be uncontentious.
> 
> 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

Re: [ECOS] RE: AT91 patches

[Jonathan Larmour]

Daniel Leu wrote:
> 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.

Yes, I think will move forward with just the AT91 and EB40 changes, and 
drop the flash driver for now. Doing that much at least for the moment 
should be uncontentious.

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

Re: [ECOS] RE: AT91 patches

[Daniel Leu]

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

Re: [ECOS] RE: AT91 patches

[Jonathan Larmour]

Doug Fraser wrote:
> Agreed.
> 
> One of the drivers I used did allow the
> single FLASH array to be chopped into two sections,
> one section running in the large block mode and the
> other in small block mode, but you had to run
> two separate threads, so you had, in effect,
> two FFS running. The only difficulty was that the
> two threads had to coordinate access to the state
> machine to control erase/read/write modes.
> 
> So if the application area was running an erase in the
> large block arena, and the drivers wanted to read from
> the small block arena, you had to suspend/read/resume.
> Separate FFS, but the same chip, and the same control
> logic. Not that hard, you just have to be careful to avoid
> deadlock situations.
> 
> I am not sure (again, lack of time right now) if JFFS2
> can support the above situation. Does anybody know if
> that is supported? It is useful for things like 
> boot block flash....

JFFS2 supports multiple file system instantiations. Preventing 
simultaneous access is left to the lower layers.

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

RE: [ECOS] RE: AT91 patches

[Doug Fraser]

Agreed.

One of the drivers I used did allow the
single FLASH array to be chopped into two sections,
one section running in the large block mode and the
other in small block mode, but you had to run
two separate threads, so you had, in effect,
two FFS running. The only difficulty was that the
two threads had to coordinate access to the state
machine to control erase/read/write modes.

So if the application area was running an erase in the
large block arena, and the drivers wanted to read from
the small block arena, you had to suspend/read/resume.
Separate FFS, but the same chip, and the same control
logic. Not that hard, you just have to be careful to avoid
deadlock situations.

I am not sure (again, lack of time right now) if JFFS2
can support the above situation. Does anybody know if
that is supported? It is useful for things like 
boot block flash....

Doug

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
> Sent: Thursday, January 30, 2003 10:29 AM
> To: Doug Fraser
> Cc: 'Koeller, T.'; ecos-discuss (E-Mail)
> Subject: Re: [ECOS] RE: AT91 patches
> 
> 
> 
> For something like JFFS2 smaller sector sizes don't give you 
> anything so 
> that makes sense.
> 
> But at a driver level it's good to support for reasons like 
> efficient use 
> for configuration data (e.g. Redboot's FIS dir and fconfig data).
> 
> 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

Re: [ECOS] RE: AT91 patches

[Jonathan Larmour]

Doug Fraser wrote:
> 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.

For something like JFFS2 smaller sector sizes don't give you anything so 
that makes sense.

But at a driver level it's good to support for reasons like efficient use 
for configuration data (e.g. Redboot's FIS dir and fconfig data).

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

Re: [ECOS] RE: AT91 patches

[Jonathan Larmour]

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.

Yes, as I evidently didn't say clearly enough here:

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

:-)

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

RE: [ECOS] RE: AT91 patches

[Doug Fraser]

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

RE: [ECOS] RE: AT91 patches

[Koeller, T.]

Yes, of course, those two things are totally unrelated.

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: Jani Monoses [mailto:jani@iv.ro]
> Sent: Thursday, January 30, 2003 1:24 PM
> To: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] RE: AT91 patches
> 
> 
> 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.

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

Re: [ECOS] RE: AT91 patches

[Jani Monoses]

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

[ECOS] RE: AT91 patches

[Koeller, T.]

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