public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Nick Garnett <nickg@ecoscentric.com>
Cc: "ecos-devel@ecos.sourceware.org" <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND review
Date: Sat, 13 Jun 2009 16:31:00 -0000	[thread overview]
Message-ID: <20090613163115.GN5179@lunn.ch> (raw)
In-Reply-To: <m3eitsm1is.fsf@xl5.calivar.com>

> 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. They will put one
filesystem onto the NAND device. For them partitioning is just
bloat. I think that should be a strong argument for having an API
which does not enforce the use of partitions.

http://pokylinux.org/releases/pinky-3.1/readme.hardware

The freescale ADS section talks about using NAND devices and putting
the partition table in the FIS directory. 

I found other freescale extensions for Redboot, but most information
seems to require that you register. However it looks like Freescale
have a redboot which fully integrated NAND devices into FIS and FIS
can be used to partition the flash.

Your argument about the HAL knowing about the boot block sections
makes a lot of sense. However i think we need an architecture where
additional partition information can come from other places. FIS, or a
NandFIS would be one such other place. We also need to think about how
this information is exported, eg into file systems, to Linux, and to
RAM versions of eCos running on top of ROM or ROMRAM Redboot etc.

    Andrew

           

  parent reply	other threads:[~2009-06-13 16:31 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
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 [this message]
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=20090613163115.GN5179@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=nickg@ecoscentric.com \
    /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).