• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 2899 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.

NAND Flash bad block table sharing between U-Boot and Linux

Louis Dupont
Intellectual 480 points

Seems like I’m having an issue with U-Boot and Linux sharing a bad block table. As I perform a “nand read” within U-boot, I get a message saying that there’s no bad block tables followed by a bunch of  “Skipping bad block”. I shut down my board and then perform another “nand read” within U-boot I get a message saying a bad block table was found. So U-boot builds the bad block tables.

However, as Linux (kernel 2.6.35.7) boots it will also display a message stating that no bad block table was found and will proceed to rewriting the bad block table which U-boot won’t be able to read and so on.

I tried versions 1.3.3 as well as 2009.11 of U-boot. Regardless of the version of U-boot it appears to process the bad block table differently that Linux. Am I supposed to enable something on one side or the other to make both compatible? Should I try version 2010.12 of U-Boot?

Thanks 

  • 0
    Prodigy 140 points

    Louis

     

    We have been battling a u-boot\Linux bad block issue as well.  We have a situation where most of the time everything is ok.  Some of our boards can get programmed, first with u-boot, then a Linux load using a ram based linux to write the linux image.   After this u-boot says the linux image has a bad crc.  If we load a linux image into sdram and then check the flash image, everything looks good.

     

    This sounds like something similar to you problem (different bad clock perspectives or handling between u-boot and linux).  I have just started a deep dive with a jtag debugger, but not made much progress yet.  Have you found anything out about this?

     

    Cheers

     

    Christopher Leidigh

  • 0 in reply to cleidigh
    Intellectual 480 points

    Not sure if this is the same issue. In my case the issue was systematic. I intended to use the NAND Flash solely for the file system (The kernel image is on another SPI Flash) so I ended up using the SPI Flash for everything including the file system. The bad block table issue wouldn't corrupt the data (although I never did any extensive testing to verify). It was simply not recognized by either Linux or U-Boot and was build twice (by U-boot and Linux) during the boot process every time. In my case it was a performance issue. The memory was a MT29F4G08AACHC-ET:C. I used several Linux/U-Boot versions always with the same result so I always assumed that this was a misconfiguration (block size or something like that) on one of my ports but I never went ahead and tried to see what was changed on the bad block table through JTAG on any mean to dump the content of the BBT after a U-Boot only boot and a complete boot. Sorry I can't be more helpful.