Writing a ubinize'd image to fresh NANDFlash with a burner

Writing a ubinize'd image to fresh NANDFlash with a burner

[Pontus Hedman]

So I have used ubinize to create a UBIFS image.  I would now
like to burn it to fresh-from-the factory blank nandflash

Do I just tell the burner to skip bad blocks on write, like nandwrite
does?

This will happen only once; after that Linux will mount the
filesystem and take of it itself.
-- 
Pontus Hedman
Navcast

Re: Writing a ubinize'd image to fresh NANDFlash with a burner

[Artem Bityutskiy]

On Thu, 2009-01-08 at 11:55 -0500, Pontus Hedman wrote:
> Do I just tell the burner to skip bad blocks on write, like nandwrite
> does?

Yes, this is right.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Writing a ubinize'd image to fresh NANDFlash with a burner

[Artem Bityutskiy]

On Thu, 2009-01-08 at 11:55 -0500, Pontus Hedman wrote:
> So I have used ubinize to create a UBIFS image.  I would now
> like to burn it to fresh-from-the factory blank nandflash
> 
> Do I just tell the burner to skip bad blocks on write, like nandwrite
> does?
> 
> This will happen only once; after that Linux will mount the
> filesystem and take of it itself.

I've updated UBI documentation and reflected what you asked there
as well. Please, beware about the "skip 0xFF'ed pages" part. See here:

http://www.linux-mtd.infradead.org/doc/ubi.html#L_format_det

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Writing a ubinize'd image to fresh NANDFlash with a burner

[Pontus Hedman]

On Tue, 2009-01-13 at 16:45 +0200, Artem Bityutskiy wrote:
> On Thu, 2009-01-08 at 11:55 -0500, Pontus Hedman wrote:
> > So I have used ubinize to create a UBIFS image.  I would now
> > like to burn it to fresh-from-the factory blank nandflash
> > 
> > Do I just tell the burner to skip bad blocks on write, like nandwrite
> > does?
> > 
> > This will happen only once; after that Linux will mount the
> > filesystem and take of it itself.
> 
> I've updated UBI documentation and reflected what you asked there
> as well. Please, beware about the "skip 0xFF'ed pages" part. See here:
> 
> http://www.linux-mtd.infradead.org/doc/ubi.html#L_format_det

Thanks... let me see if I got this right (it's a bit complicated for
me):

I have a Xeltek SP5000 flasher.  It turns out that it wants its binary
image to have eraseblocks that *include* the OOB.  That is, it wants the
binary file I give it to contain 128KiB+2KiB byte blocks (consisting of
64 pages of 2048+64 bytes each) in the case of this nandflash.

The flasher *will* skip bad blocks while writing though, so I don't have
to worry about that. Recall, I'm writing to fresh-from-the factory flash
with whatever bad block markings they already put there.

Now, ubinize created an image for me with 128KiB block / 2048B pages.

I think all I have to do is insert 64 bytes of OOB data every 2048 bytes
in that image to make it compliant.  So I guess I would make that OOB
data be all 0xFFs so that the flash OOB parts are left alone?
-- 
Pontus Hedman
Navcast

Re: Writing a ubinize'd image to fresh NANDFlash with a burner

[Artem Bityutskiy]

On Tue, 2009-01-13 at 13:53 -0500, Pontus Hedman wrote:
> I think all I have to do is insert 64 bytes of OOB data every 2048 bytes
> in that image to make it compliant.  So I guess I would make that OOB
> data be all 0xFFs so that the flash OOB parts are left alone?

Probably. You may easily add one more ubinize command line option which
would make it put OOB data to the output image, just like you
described. 

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Writing a ubinize'd image to fresh NANDFlash with a burner

[Pontus Hedman]

On Wed, 2009-01-14 at 14:37 +0200, Artem Bityutskiy wrote:
> On Tue, 2009-01-13 at 13:53 -0500, Pontus Hedman wrote:
> > I think all I have to do is insert 64 bytes of OOB data every 2048 bytes
> > in that image to make it compliant.  So I guess I would make that OOB
> > data be all 0xFFs so that the flash OOB parts are left alone?
> 
> Probably. You may easily add one more ubinize command line option which
> would make it put OOB data to the output image, just like you
> described. 

Ok, thanks for the reassurance.  Since we have other (non-ubifs) binary
hunks that also need to have this done, it's easier for me to just write
a single program that stuffs the 64 byte OOBs into all of them.

Just by the way, we were using jffs2 before.  UBIFS is quite an
improvement!

Thanks again for your help,
-- 
Pontus Hedman
Navcast