This is the mail archive of the
mailing list for the eCos project.
Re: NAND review
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Nick Garnett <nickg at ecoscentric dot com>
- Cc: "ecos-devel at ecos dot sourceware dot org" <ecos-devel at ecos dot sourceware dot org>
- Date: Sat, 13 Jun 2009 18:31:15 +0200
- Subject: Re: NAND review
- References: <4A126D59.email@example.com> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <firstname.lastname@example.org>
> 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.
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.