• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 5903 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Nandwrite with -m option

anthony barrera
Intellectual 430 points


Hello,

We are running the TI SDK Linux kernel 3.14.43 on our custom hardware based on the BeagleBone Black. Firmware is stored in NAND flash. Our application programs the our kernel to NAND (mtd8) with mtdutils v1.5.0 as follows:

flash_erase /dev/mtd8 0 0

nandwrite -b 1 /dev/mtd8 -p /tmp/ramdisk1/image.binary1

The option that I am concerned with is (taken from the nandwrite help):

-m, --markbad           Mark blocks bad if write fails

I can find very little documentation or examples on the -m option. It seems that it should be included so, in the event that blocks go bad, the nandwrite command will mark the bad blocks so they are skipped in the future. Most of the examples I have come across for the nandwrite command do NOT include -m. Is there any reason not to use this option when programming my kernel to NAND?

Thank you in advance for any help! - Anthony

  • 0
    TI__Guru** 116100 points
    Hi Anthony,
    I have also used with both arguments and not see any problem.
    You can use "-p -m" both arguments.
  • 0
    TI__Mastermind 29520 points
    Hello Anthony,

    Please take a look on the fragment:
    lists.denx.de/.../044657.html

    markblockbad:
    + /* Erase to this block failed.
    + * Mark it bad.
    + */
    + ret = mtd->block_markbad(mtd, instr.addr);
    + if (!ret)
    + printf("Marked block as bad\n");
    + else
    + printf("Unable to mark block as bad. Failed\n");
    + ofs -= thiswrite;
    + addr -= thiswrite;
    + len += thiswrite;
    +

    Cleaning using U-Boot
    Run U-boot and then use the following commands to clean the NAND device.

    Run the command nand bad to generate a list of the blocks on the device that the driver believes to be bad. Keep a copy of this list—it will be used later to remark the bad blocks manually.

    For each of the bad blocks on the list, run: nand dump <block-number>

    If the output of the dump command looks like "real" data, then it is safe to assume that it is a good block. If the block is all zeros (both in-band and out-of-band) then it is very likely to be a genuinely bad block. Keep a record of all the blocks that are genuinely bad.

    Run nand scrub to erase ALL of the blocks on the NAND device. This will also set most of the bad blocks to "good".

    Run nand bad again to obtain a revised list of bad blocks. Compare this list with the list of "genuinely bad" blocks (that is, blocks containing all zeros), obtained at step 3.

    For each block on the "genuinely bad" list that is no longer marked as bad by nand bad, run nand markbad &lt;block-number&gt;.

    At the end of this operation, the BBT will have been reconstructed to contain only the blocks that are genuinely bad. The device can now safely be re-initialized.

    Simply running nand scrub without first identifying which blocks are genuinely bad (using nand bad and nand markbad commands, as described above) will silently convert soft bad blocks to false good blocks, which will cause unrecoverable problems with reading and writing data.

    Best regards,
    Yanko
  • 0 in reply to Yanko Todorov-XID
    Intellectual 430 points
    Thank you for the details of this procedure Yanko. I followed the steps and it looks like all of the bad blocks listed are genuinely bad blocks.

    If I use the nandwrite command with the -m option in Linux, in theory, if a block that is currently good goes bad in the future, the -m should ensure that this block gets marked as bad in my BBT, and skipped in all future flash operations, correct?
  • 0 in reply to anthony barrera
    TI__Mastermind 29520 points
    Hello Anthony,

    I think that you are right. In addition to your conclusion:
    The bad block table is mirrored on the chip (device) to allow updates of the bad block table without data loss.

    nand_scan() calls the function nand_default_bbt(). nand_default_bbt() selects appropriate default bad block table desriptors depending on the chip information which was retrieved by nand_scan().

    The standard policy is scanning the device for bad blocks and build a ram based bad block table which allows faster access than always checking the bad block information on the flash chip itself.


    Best regards,
    Yanko