Re: Creating NAND flash image outside embedded target

[Frank Haverkamp <haver@vnet.ibm.com>]

Hi Kevin,

we had a similar problem with our embedded powerpc system where we
needed pre-build binary images to be flashed via a JTAG programming
utility into our NAND flashes. We also wanted to boot using NAND
flash only and have NAND flash scrubbing and the possiblity to
handle those bad blocks gracefully. 

For those and other reasons we developed UBI which we recently
published. It implements an interresting volume management approach,
helping to overcome some limitations which a traditional fixed
address/size partitioning scheme had. If you like, you can have a look
at our design paper and the associated utilities in my mtd-utils.git.

Here you can find our UBI design paper and a brief overview:
http://www.linux-mtd.infradead.org/doc/ubi.html

Maybe you find other aspects which are interessting for your
application too.

On Thu, 2006-06-22 at 17:28 -0700, Kevin Starinieri wrote:
> I have looked through the mail archives and did not see any subject
> threads regarding this.  I am trying to create a NAND flash image
> without having to do it on my embedded target.  

> I then wanted to partition the fake mtd device and write to it using a
> nandwrite utility that I compiled for x86 that is used for samsung arm
> s3c2410 nand flash.  But the utility expects the device to be
> partitioned and erase regions to be defined.  But, I don't know of
> anyway to do this outside of my target.

For generation of UBI/NAND images on your developemt (x86) systems we
are using the ubi-utils toolchain:

 o mkpfi is processing a configuration file and binary input data e.g.
   JFFS2 images, boot-code, kernel images. It creates a partial flash
   image (pfi) file which can be used by other tools e.g.
 o pfi2bin which converts the pfi file into plain binary output.
   For NOR flashes that would be an image you could directly burn
   into your NOR which you solder afterwards onto your board,
   for NAND you can run:
 o bin2nand which adds the OOB whith ECC information (currently only
   our layout, but one could consider enhancing it).

The output of this we can flash via JTAG to our systems. If this works
we use on our embedded systems:
 o overwriting files in JFFS2 ;-) and
 o pfiflash to flash pfi files to the system e.g. boot-code, 
   kernel which are stored in UBI static volumes. We are 
   using this to update our systems. To create UBI volumes 
   manually and update them, we use:
 o ubimkvol, ubirmvol, ubiupdatevol

We even started (and have not finished yet) the inverse toolchain which
can convert the data you read via JTAG from broken systems back into
binary data which previously was written to the UBI volumes. This is
intended to be used for field returns which do not boot/operate
correctly anymore.

Frank