public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: gary@mlbassoc.com, andrew@lunn.ch, rutger@cs.vu.nl,
		ecos-devel@ecos.sourceware.org
Subject: Re: NAND review
Date: Wed, 20 May 2009 15:34:00 -0000	[thread overview]
Message-ID: <pn8wkraivk.fsf@delenn.bartv.net> (raw)
In-Reply-To: <20090520142223.GM20046@lunn.ch> (message from Andrew Lunn on 	Wed, 20 May 2009 16:22:23 +0200)

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> 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. 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 directory.  (any or all of this set)

    Andrew> You could map these into eCos like concepts:

    Andrew> Hard code     -> Hard coded
    Andrew> command line  -> Redboot cfg block parameter?
    Andrew> FIS Directory -> FIS Directory!

    Andrew> I find it interesting that Linux guys consider FIS
    Andrew> directory usable, which is against what Bart was saying.

The approach is usable iff you have NOR flash as well as NAND flash.
    
    Andrew> Putting that point aside, it does show that Linux
    Andrew> considers it necessary to have multiple ways of
    Andrew> configuring the partitions, so maybe eCos also needs
    Andrew> multiple ways of configuring partitions.

To cope with systems which only have NAND flash, I think we must
support hard-coding via configury. Hence that functionality must be
implemented straightaway. It does not preclude adding other ways of
specifying partitions in future, e.g. by storing them in NOR flash, if
we feel that the added flexibility is worth the implementation effort
and the code and data bloat. Obviously typically Linux developers will
be less concerned about the latter than eCos developers.

Bart

  parent reply	other threads:[~2009-05-20 15:34 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19  8:27 Simon Kallweit
2009-05-19 13:47 ` Ross Younger
2009-05-19 14:17   ` Andrew Lunn
2009-05-20 13:24     ` Bart Veer
2009-05-20 13:34       ` Rutger Hofman
2009-05-20 13:53         ` Andrew Lunn
2009-05-20 13:56           ` Gary Thomas
2009-05-20 14:22             ` Andrew Lunn
2009-05-20 15:22               ` Andrew Lunn
2009-05-20 15:34               ` Bart Veer [this message]
2009-05-20 13:58           ` Rutger Hofman
2009-05-20 14:16     ` Ross Younger
2009-05-20 14:21       ` Gary Thomas
2009-05-20 15:25         ` Ross Younger
2009-05-20 15:37           ` Gary Thomas
2009-05-19 16:29 ` Andrew Lunn
2009-06-03  8:51   ` Andrew Lunn
2009-06-03 10:21     ` Ross Younger
2009-06-03 10:48       ` Andrew Lunn
2009-06-03 11:52         ` Simon Kallweit
2009-06-03 12:26         ` Rutger Hofman
2009-06-03 13:33     ` Jürgen Lambrecht
2009-06-10 17:39     ` Nick Garnett
2009-06-11 11:25       ` Rutger Hofman
2009-06-13 16:31       ` Andrew Lunn
2009-06-18 14:10         ` Nick Garnett
2009-06-19  7:47           ` Andrew Lunn
2009-06-19 14:14             ` Ross Younger
2009-06-19 15:02               ` Andrew Lunn
2009-06-19 16:54               ` Jürgen Lambrecht
2009-06-29 11:09             ` Nick Garnett
2009-06-19  8:07           ` Andrew Lunn
2009-06-19 11:37             ` Daniel Morris
2009-06-19 12:06               ` Andrew Lunn
2009-05-20  1:02 ` Jonathan Larmour
2009-05-20  7:11   ` Simon Kallweit
2009-05-20 11:12     ` Rutger Hofman
2009-05-20 11:29       ` Simon Kallweit
2009-05-20 13:37         ` Rutger Hofman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pn8wkraivk.fsf@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=gary@mlbassoc.com \
    --cc=rutger@cs.vu.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).