• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 2152 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

NAND Flash pre-programming

Matthew Schuckmann1
Intellectual 975 points
Other Parts Discussed in Thread: AM3352

I've been tasked with creating a golden image for pre-programming production NAND flash parts that will be soldered onto our AM3352 based board running Linux. We are using a Macronix MX30LF2G28AB 2Gbit part. 

In my research I've come up with a lot of questions and I'm hoping that someone with some experience can help me out.

1. My first question is: Is this actually typically done with NAND flash for mass production? Everything I've seen on the web talks about programming the NAND flash through u-boot or JTAG so that bad blocks and ECC is handled correctly. This makes me think that I might be on a fools errand here. 

2. I have found a little information and it seems to suggest that the process is highly dependent on the Flash programmer that is used and that in general it is a good idea to included the OOB data with the calculated ECC values in the image(s). So I've gone looking for a tool to add the OOB and ECC data to the MLO, u-boot.img, zImage, and rootfs.ubi files. I haven't really found this tool, I did get a  bin2nand tool from a TI rep. but it only supports BCH8 for ECC and I've selected BCH16. I can probably get by with BCH8 but if BCH16 fits why not use it? I find it really odd that there is no tool to do this, am I missing something? 

3. I did come up with a novel way to create the files with the correct OOB/ECC data, but I'd like some confirmation that the method is sound. 

1. Use the u-boot command 'nand write' to write the data to the nand, skipping bad blocks and writing the ECC data.

2. Boot to Linux and use the MTD utils command nanddump to read the data out with the OOB data, and skipping any bad blocks, something like this: 

$ nanddump --bb='skipbad' -o -l <size> -f zImage.oob.bin /dev/mtd4

This should give me a copy of the data from NAND with the correct ECC for BCH16. I even tested this by writing it back to NAND with the u-boot command 'nand write.raw' and it worked. Btw I first checked that there were no bad blocks on the device because nand write.raw doesn't skip bad blocks. 

However, I read something here that makes me question if my approach is correct. Basically I think the logic goes if there were a bit error in the source NAND and if nanddump didn't correct it during read it would get transferred to the image and therefore transferred to any NAND programmed from the image, of course the ECC checksum should be able to correct it.  I'm not sure if nanddump does the correction, I think it does but I'm not sure (I suppose that I can test this by inducing a bit error, doing the nanddump, removing the OOB data and comparing the image to the original. 

If anybody can share any experiences you have with this I'd very much appreciate it. 

Thanks,
Matt S. 

  • 0
    TI__Guru**** 393215 points

    Hi Matthew,

    I will forward this to the factory team.

  • 0
    Prodigy 120 points
    Hi Matthew,

    You might also consider the Macronix MX30LF2G18AC 2Gbit part. It is recommended for new designs and only requires 4-bit ECC.
    The OOB size is only 64 bytes so you could only use BCH8, but it should still give you the same level of extra protection BCH16
    does for devices requiring 8-bit ECC (e.g. MX30LF2G28AB).

    Some programmers can calculate ECC on-the-fly, but they typically use a default ECC scheme (not BCH8 or BCH16).
    If you are willing to work closely with a programmer manufacturer, they might be able to add the BCH8 or BCH16
    algorithm, but it will take time and there may be development costs involved. Including the BCH8 or BCH16 data in your
    golden code seems like the simplest approach.

    In addition to the ECC data for the OOB, the programmer will also need a partition table with enough spare blocks
    in each partition to handle bad blocks.

    In regards to your novel way to create files with OOB/ECC data: As far as I know, the 'nanddump' utility is set to read the raw NAND data and is not processed through the host ECC engine to correct errors. Hopefully, you will receive comments from other users that are more knowledgeable.

    Best regards,

    -Rick Culver
  • 0 in reply to Rick Culver
    Intellectual 975 points

    Thanks for the info Rick. 

    After I posted I looked back through my notes and remembered that the MX30LF2G28AB part only requires BCH8 but the AM335x bootloader has a quirk that if the OOB can fit BCH16 it assumes that that's what will be used and basically forces you to use it. The MX30LF2G28AB has 112 bytes of OOB which is just big enough for BCH16. 

    So your suggestion of MX30LF2G18AC is a good one if I can convenience our board manufacture to switch parts this late in the game. 

    I don't think I'll be able to work closely enough with the programmer to add any ECC algorithms. At this point our board vendor is still trying to wrap their head around the fact that NAND flash is different from NOR flash. 

    The point about partitions is noted, I've already got extra space in each partition. 

    I've still got to look at how nanddump works and test things out. I know that you can choose to skip ECC or not (-n option)  I'm just not sure if that applies when dumping the OOB data. It's easy enough to look at the code and or test it as I suggested, I just haven't had time to do it yet. 

    Thanks again,
    Matt S.