Way to clear nand bad block table

Way to clear nand bad block table

[Marc Reilly]

Hi,

Is there a way to clear the nand bad block table?

I'm not sure what happened, but I was playing around with barebox init and
didn't register the nand device - then when I booted the kernel there were a
stack of UBI errors. 
I assume this also did something to the bbt as subsequent barebox startups
give a heap of bad block messages. Note not all blocks are bad - tested with
nandtest and there's still some R/W going on.
All the code I looked at seemed to indicate that once a block is marked bad
you can't go back.

Any ideas much appreciated.

Cheers,
Marc


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Way to clear nand bad block table

[Juergen Beisert]

HI Marc,

Marc Reilly wrote:
> Is there a way to clear the nand bad block table?
>
> I'm not sure what happened, but I was playing around with barebox init and
> didn't register the nand device - then when I booted the kernel there were
> a stack of UBI errors.
> I assume this also did something to the bbt as subsequent barebox startups
> give a heap of bad block messages. Note not all blocks are bad - tested
> with nandtest and there's still some R/W going on.
> All the code I looked at seemed to indicate that once a block is marked bad
> you can't go back.
>
> Any ideas much appreciated.

The flash blocks which contains the "bad block table" are protected by 
the "bad block table" aware MTD layer.

So, the ugly way: run a bootloader which does not use the in-flash bad block 
table. Then the tables are regular blocks in the flash and can be erased. 
After that run again the bad block table aware bootloader and it will 
re-create the in-flash table. But be careful: In this case the generic 
functions scans all blocks in the NAND to collect the bad block markers in 
each NAND block's OOB. If this information is already destroyed somehow, this 
solution does not help.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Way to clear nand bad block table

[Marc Reilly]

Hi Juergen,

Thanks for your ideas.

I managed to clear the BBT, it was a bit of a hack... the saga is below for 
anyone who runs into similar problem.

On Thursday, July 26, 2012 11:27:48 AM Juergen Beisert wrote:
> The flash blocks which contains the "bad block table" are protected by
> the "bad block table" aware MTD layer.
> 
> So, the ugly way: run a bootloader which does not use the in-flash bad block
> table. Then the tables are regular blocks in the flash and can be erased.
> After that run again the bad block table aware bootloader and it will
> re-create the in-flash table. But be careful: In this case the generic
> functions scans all blocks in the NAND to collect the bad block markers in
> each NAND block's OOB. If this information is already destroyed somehow,
> this solution does not help.

Recompiling barebox with bbt support disabled stopped the all the bad block 
messages, however erasing the nand didn't clear the BBT for subsequent 
reboots...
The issue was that the erase commands and functions skip erasing bad blocks, 
and the blocks that held the actual BBT were being considered bad, so they 
weren't getting erased. After commenting out calls to nand_block_checkbad() in 
nand_write.c and block_isbad() in mtd_erase()/core.c I was able to manually 
erase the blocks. (erasing actual bad blocks results in I/O error)
Next restart of barebox the BBT was regenerated with the two actual bad 
blocks.

After all that, I noticed imx_low_erase() in nand_imx.c. Probably would have 
been easier to make up a command around that.

Cheer,s
Marc

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Way to clear nand bad block table

[Sascha Hauer]

On Fri, Jul 27, 2012 at 11:24:48AM +1000, Marc Reilly wrote:
> Hi Juergen,
> 
> Thanks for your ideas.
> 
> I managed to clear the BBT, it was a bit of a hack... the saga is below for 
> anyone who runs into similar problem.
> 
> On Thursday, July 26, 2012 11:27:48 AM Juergen Beisert wrote:
> > The flash blocks which contains the "bad block table" are protected by
> > the "bad block table" aware MTD layer.
> > 
> > So, the ugly way: run a bootloader which does not use the in-flash bad block
> > table. Then the tables are regular blocks in the flash and can be erased.
> > After that run again the bad block table aware bootloader and it will
> > re-create the in-flash table. But be careful: In this case the generic
> > functions scans all blocks in the NAND to collect the bad block markers in
> > each NAND block's OOB. If this information is already destroyed somehow,
> > this solution does not help.
> 
> Recompiling barebox with bbt support disabled stopped the all the bad block 
> messages, however erasing the nand didn't clear the BBT for subsequent 
> reboots...
> The issue was that the erase commands and functions skip erasing bad blocks, 
> and the blocks that held the actual BBT were being considered bad, so they 
> weren't getting erased. After commenting out calls to nand_block_checkbad() in 
> nand_write.c and block_isbad() in mtd_erase()/core.c I was able to manually 
> erase the blocks. (erasing actual bad blocks results in I/O error)
> Next restart of barebox the BBT was regenerated with the two actual bad 
> blocks.
> 
> After all that, I noticed imx_low_erase() in nand_imx.c. Probably would have 
> been easier to make up a command around that.

This problem comes up regularly. I remember Wolfram implemented a nand
'scrub' command. He was working on i.MX28. I don't know wether his
command was i.MX28 specific, but it would be nice to have such a command
around.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

RFC: How to setup and handle NAND flashes in Barebox

[Juergen Beisert]

Sascha Hauer wrote:
> On Fri, Jul 27, 2012 at 11:24:48AM +1000, Marc Reilly wrote:
> > Thanks for your ideas.
> >
> > I managed to clear the BBT, it was a bit of a hack... the saga is below
> > for anyone who runs into similar problem.
> >
> > On Thursday, July 26, 2012 11:27:48 AM Juergen Beisert wrote:
> > > The flash blocks which contains the "bad block table" are protected by
> > > the "bad block table" aware MTD layer.
> > >
> > > So, the ugly way: run a bootloader which does not use the in-flash bad
> > > block table. Then the tables are regular blocks in the flash and can be
> > > erased. After that run again the bad block table aware bootloader and
> > > it will re-create the in-flash table. But be careful: In this case the
> > > generic functions scans all blocks in the NAND to collect the bad block
> > > markers in each NAND block's OOB. If this information is already
> > > destroyed somehow, this solution does not help.
> >
> > Recompiling barebox with bbt support disabled stopped the all the bad
> > block messages, however erasing the nand didn't clear the BBT for
> > subsequent reboots...
> > The issue was that the erase commands and functions skip erasing bad
> > blocks, and the blocks that held the actual BBT were being considered
> > bad, so they weren't getting erased. After commenting out calls to
> > nand_block_checkbad() in nand_write.c and block_isbad() in
> > mtd_erase()/core.c I was able to manually erase the blocks. (erasing
> > actual bad blocks results in I/O error) Next restart of barebox the BBT
> > was regenerated with the two actual bad blocks.
> >
> > After all that, I noticed imx_low_erase() in nand_imx.c. Probably would
> > have been easier to make up a command around that.
>
> This problem comes up regularly. I remember Wolfram implemented a nand
> 'scrub' command. He was working on i.MX28. I don't know wether his
> command was i.MX28 specific, but it would be nice to have such a command
> around.

Just an idea:

I think we need something like a "NAND handling environment". For example the 
MTD generates a in-flash bad block table without any interaction. That might 
be a nice feature, but only when:

 - the factory bad block markers are still intact
 - the regular NAND driver can read the factory bad block markers (the i.MX
   driver for example cannot)
 - the flash is more or less untouched yet

Whenever one of these dependencies are not valid (anymore), we are in trouble 
with automatically generation of the in-flash bad block table.
Use cases are for example: general development on NAND drivers, a Linux driver 
that crashes the NAND somehow or a different bootloader/operation system that 
uses its own ways to handle and mark bad blocks.
For these use-cases we need a different approach: something we can do 
manually.

 - a 'test' command that checks if the factory bad block markers seems still
   intact (or not). This command should have some parameters where you can
   describe the expected OOB layout to be able to check for various ways to
   mark bad blocks
 - a 'list' command which lists all the currently known bad blocks (from
   whatever source, in-flash or in-ram BBT or freshly read from the OOB area)
   This list could be stored somewhere (like the "bad sector table" in the
   early days of hard disks). At least this would help later on to still use a
   NAND memory where all the OOB based bad block markers are lost. For example
   with my S3C6410 CPU the internal ROM routines force me to write the
   checksums into a position in the OOB where most of the manufacturers 
   stores the factory bad block info. So, there is no simple way later
   on to distinguish checksums from bad block markers.
 - a 'create' command for the in-flash BBT. This command can use the the
   result of the 'list' command or should accept a list of *known' bad blocks
   manually entered

With these tools we could instruct Barebox to use an in-flash BBT only if it 
already exists. If not, it should fall back to OOB scan, and should not write 
an in-flash BBT with the collected information.
A user then can run the various tools to get an idea if the NAND is intact (or 
not) and the 'create' command would then write a correct in-flash BBT (with 
the help of the other collecting commands) to be used by Barebox itself and 
Linux. 

jbe

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox