* Way to clear nand bad block table @ 2012-07-26 8:25 Marc Reilly 2012-07-26 9:27 ` Juergen Beisert 0 siblings, 1 reply; 5+ messages in thread From: Marc Reilly @ 2012-07-26 8:25 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Way to clear nand bad block table 2012-07-26 8:25 Way to clear nand bad block table Marc Reilly @ 2012-07-26 9:27 ` Juergen Beisert 2012-07-27 1:24 ` Marc Reilly 0 siblings, 1 reply; 5+ messages in thread From: Juergen Beisert @ 2012-07-26 9:27 UTC (permalink / raw) To: barebox, marc 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Way to clear nand bad block table 2012-07-26 9:27 ` Juergen Beisert @ 2012-07-27 1:24 ` Marc Reilly 2012-07-27 7:53 ` Sascha Hauer 0 siblings, 1 reply; 5+ messages in thread From: Marc Reilly @ 2012-07-27 1:24 UTC (permalink / raw) To: Juergen Beisert; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Way to clear nand bad block table 2012-07-27 1:24 ` Marc Reilly @ 2012-07-27 7:53 ` Sascha Hauer 2012-07-27 8:31 ` RFC: How to setup and handle NAND flashes in Barebox Juergen Beisert 0 siblings, 1 reply; 5+ messages in thread From: Sascha Hauer @ 2012-07-27 7:53 UTC (permalink / raw) To: Marc Reilly; +Cc: barebox, Juergen Beisert, Wolfram Sang 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RFC: How to setup and handle NAND flashes in Barebox 2012-07-27 7:53 ` Sascha Hauer @ 2012-07-27 8:31 ` Juergen Beisert 0 siblings, 0 replies; 5+ messages in thread From: Juergen Beisert @ 2012-07-27 8:31 UTC (permalink / raw) To: barebox; +Cc: Wolfram Sang 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-07-27 8:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-07-26 8:25 Way to clear nand bad block table Marc Reilly 2012-07-26 9:27 ` Juergen Beisert 2012-07-27 1:24 ` Marc Reilly 2012-07-27 7:53 ` Sascha Hauer 2012-07-27 8:31 ` RFC: How to setup and handle NAND flashes in Barebox Juergen Beisert
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.