Andrew Lunn writes:
> We don't need to follow the disk driver approach to partitioning. As
> Ross said, he used the name "partition" because he could not think of
> a better name. However the name does not imply we need to follow the
> normal ways for partitions. All we need is a suitable API whi
Ross Younger wrote:
Nick Garnett wrote:
What is the typical life of a
block? 1 erases? A developer may conceivably replace the kernel
10,000 times, but in a deployed product i doubt this will happen. So i
say forget about wear leveling for this case.
I have been thinking about
> Properly NAND-aware filesystems take both kinds of bad blocks in their
> stride; there's no point in adding the complexity if such a mapping if
> you're using such a filesystem.
>
> Even with something simpler, factory-bad blocks are straightforward: as you
> say, one can simply linear-map them
> Nick Garnett wrote:
>> I believe that an API that is partition-aware from the start is
>> preferable.
Andrew Lunn wrote:
> and i prefer an API which works well with and without partitions.
The partitions are already a pretty slim layer on top of the main code; I
don't think that thinning thing
On Fri, Jun 19, 2009 at 12:36:57PM +0100, Daniel Morris wrote:
> On Fri, Jun 19, 2009 at 10:07:47AM +0200, Andrew Lunn wrote:
> > This should help avoid reinventing the wheel and hopefully make it
> > cornerles and symmetric. So long as you follow the Linux development
> > process, post often and e
On Fri, Jun 19, 2009 at 10:07:47AM +0200, Andrew Lunn wrote:
> This should help avoid reinventing the wheel and hopefully make it
> cornerles and symmetric. So long as you follow the Linux development
> process, post often and early, and don't get flamed to a crisp it
> could be good advertising fo
> My main concern is that we avoid reinventing the wheel, or end up
> inventing a square wheel. Looking at the more mature Linux NAND
> support, no consensus seems to have emerged over NAND partitioning.
Maybe the correct way to approach this is to make a design study,
power on till Linux has its
On Thu, Jun 18, 2009 at 03:10:12PM +0100, Nick Garnett wrote:
> Andrew Lunn writes:
>
> > > It is sometimes best to think about a concrete example, and my
> > > thoughts on NAND use were informed by thinking about how to use the
> > > NAND on an Atmel AT91SAM9 based device.
> >
> > I agree with
Andrew Lunn writes:
> > It is sometimes best to think about a concrete example, and my
> > thoughts on NAND use were informed by thinking about how to use the
> > NAND on an Atmel AT91SAM9 based device.
>
> I agree with the sentiment. Lets take another couple of examples.
>
> Both Rutger and S
> It is sometimes best to think about a concrete example, and my
> thoughts on NAND use were informed by thinking about how to use the
> NAND on an Atmel AT91SAM9 based device.
I agree with the sentiment. Lets take another couple of examples.
Both Rutger and Simon have NOR flash to boot from. Th
Nick Garnett wrote:
Andrew Lunn writes:
There has been comments that Rutgers code has too many layers. Rutger
aims to allow as much code reuse between drivers as possible, which i
think is good. Simon commented that he thinks Ross's design may result
in a lot of code stuck in HALs where it is
Andrew Lunn writes:
> IMHO Ross's partitioning scheme/API is broken. I've tried to trigger
> discussion about this, but there has not been much interest. This is a
> shame, because to fix it will require API changes, so requiring
> changes to the YAFFS glue code etc. I'm also not the only one wi
Andrew Lunn wrote:
Date: Tue, 02 Jun 2009 19:17:58 +0100
From: John Dallaway
To: Andrew Lunn
CC: eCos Maintainers
Subject: Re: NAND & YAFFS
Have you been able to form a view on the relative merits of the VU
Amsterdam and eCosCentric implementations so far? Just wanting to ensure
that this pro
Andrew Lunn wrote:
The philosophical question for us all is whether NAND on its own should be
allowed to use malloc, given that a NAND array will probably always be used
in conjunction with a log-structured filesystem which will chew up
comparatively large amounts of RAM (and, of course, RAM is f
Andrew Lunn wrote:
The philosophical question for us all is whether NAND on its own should be
allowed to use malloc, given that a NAND array will probably always be used
in conjunction with a log-structured filesystem which will chew up
comparatively large amounts of RAM (and, of course, RAM is f
> The philosophical question for us all is whether NAND on its own should be
> allowed to use malloc, given that a NAND array will probably always be used
> in conjunction with a log-structured filesystem which will chew up
> comparatively large amounts of RAM (and, of course, RAM is forever gettin
Hi Andrew,
Thanks for the summary. If I may comment on a couple of technical points...
> IMHO Ross's partitioning scheme/API is broken. I've tried to trigger
> discussion about this, but there has not been much interest.
I've been quiet recently as I've been pushing to get YAFFS and RedBoot
in
> Date: Tue, 02 Jun 2009 19:17:58 +0100
> From: John Dallaway
> To: Andrew Lunn
> CC: eCos Maintainers
> Subject: Re: NAND & YAFFS
>
> Have you been able to form a view on the relative merits of the VU
> Amsterdam and eCosCentric implementations so far? Just wanting to ensure
> that this process
Ross Younger wrote:
> Gary Thomas wrote:
>> I don't know what/where you were looking to come to these conclusions :-(
>> Linux MTD has had the ability to use the RedBoot FIS directory for many (7+)
>> years.
>
> At the moment, as I understand things, FIS implies io/flash, which pretty
> much impl
> "Andrew" == Andrew Lunn writes:
Andrew> On Wed, May 20, 2009 at 07:55:58AM -0600, Gary Thomas wrote:
>> Andrew Lunn wrote:
>> >> FWIW, this is the approach taken by MTD with the BBT (Bad Block
Table).
>> >
>> > Hi Rutger
>> >
>> > You seem to know the MTD code
Gary Thomas wrote:
> I don't know what/where you were looking to come to these conclusions :-(
> Linux MTD has had the ability to use the RedBoot FIS directory for many (7+)
> years.
At the moment, as I understand things, FIS implies io/flash, which pretty
much implies NOR. I don't have any plans
> You could map these into eCos like concepts:
>
> Hard code -> Hard coded
> command line -> Redboot cfg block parameter?
> FIS Directory -> FIS Directory!
There is also one case we must support. If we don't chaos will result.
Imagine hard coded partitions in Redboot. This is used to boot a
On Wed, May 20, 2009 at 07:55:58AM -0600, Gary Thomas wrote:
> Andrew Lunn wrote:
> >> FWIW, this is the approach taken by MTD with the BBT (Bad Block Table).
> >
> > Hi Rutger
> >
> > You seem to know the MTD code. How does MTD handle partition
> > information? Where does it get it from?
>
> It
Ross Younger wrote:
> Andrew Lunn wrote:
>> Why cannot this partition information be configured by redboot?
>> Why must it be platform specific?
>
> When I was designing my NAND library, I was striving for compatibility with
> Linux - that is to say, the ability for an eCos app (RedBoot?) and a L
Andrew Lunn wrote:
> Why cannot this partition information be configured by redboot?
> Why must it be platform specific?
When I was designing my NAND library, I was striving for compatibility with
Linux - that is to say, the ability for an eCos app (RedBoot?) and a Linux
kernel to share the same
Andrew Lunn wrote:
FWIW, this is the approach taken by MTD with the BBT (Bad Block Table).
Hi Rutger
You seem to know the MTD code. How does MTD handle partition
information? Where does it get it from?
Well, I didn't read that part of MTD well. My guess would be that UBI
does it, on top of
Andrew Lunn wrote:
>> FWIW, this is the approach taken by MTD with the BBT (Bad Block Table).
>
> Hi Rutger
>
> You seem to know the MTD code. How does MTD handle partition
> information? Where does it get it from?
It can be hard coded, come from the command line, or use the RedBoot
FIS director
> FWIW, this is the approach taken by MTD with the BBT (Bad Block Table).
Hi Rutger
You seem to know the MTD code. How does MTD handle partition
information? Where does it get it from?
Thanks
Andrew
Simon Kallweit wrote:
Rutger Hofman wrote:
Jonathan Larmour wrote:
that). But I'm also concerned about possibly having too much
layering in Rutger's version for small simple implementations.
Well, there is one obvious candidate for being thinned out in my NAND
implementation: the ANC layer t
Bart Veer wrote:
"Andrew" == Andrew Lunn writes:
>> The partition definition is necessarily platform-specific, so
>> doesn't fit anywhere else.
Andrew> I simply don't get this.
Andrew> Take a case i recently had with a NOR based system. I had
Andrew> a linux kernel bug
> "Andrew" == Andrew Lunn writes:
>> The partition definition is necessarily platform-specific, so
>> doesn't fit anywhere else.
Andrew> I simply don't get this.
Andrew> Take a case i recently had with a NOR based system. I had
Andrew> a linux kernel bug i had to trace
Rutger Hofman wrote:
Jonathan Larmour wrote:
that). But I'm also concerned about possibly having too much layering
in Rutger's version for small simple implementations.
Well, there is one obvious candidate for being thinned out in my NAND
implementation: the ANC layer that hides the presence
Simon Kallweit wrote:
Jonathan Larmour wrote:
that). But I'm also concerned about possibly having too much layering
in Rutger's version for small simple implementations.
Well, there is one obvious candidate for being thinned out in my NAND
implementation: the ANC layer that hides the presence
Jonathan Larmour wrote:
Simon Kallweit wrote:
Well these are my first thoughts on the prereleased code. I hope more
people take a look at it and we can have a discussion and soon decide
which NAND framework we're going to use.
Just to clarify something here, I don't think it's a case of this
Simon Kallweit wrote:
Well these are my first thoughts on the prereleased code. I hope more
people take a look at it and we can have a discussion and soon decide
which NAND framework we're going to use.
Just to clarify something here, I don't think it's a case of this one or
that one. Provide
On Tue, May 19, 2009 at 10:27:05AM +0200, Simon Kallweit wrote:
> Hi there
>
> * Ross's code uses the directory 'io/nand' for the NAND framework and
> adds the NAND flash device drivers in 'devs/nand'. This is contrary to
> what was discussed on the mailing list a few months ago:
>
> http://eco
> The partition definition is necessarily platform-specific, so doesn't fit
> anywhere else.
I simply don't get this.
Take a case i recently had with a NOR based system. I had a linux
kernel bug i had to trace down. So that i had human readable kernel
opps information, i rebuilt the kernel to i
Hi Simon,
Thanks for the feedback.
> * [io/nand & devs/nand]
I took the view that the path to the driver package ought to imply what
subsystem it's for. Also, putting NAND drivers in devs/flash/nand/* just
doesn't feel right. The flash subsystem takes flash drivers, the nand
subsystem takes nand
38 matches
Mail list logo
