Saturday, July 3, 2010

Linux and the built-in flash

I don't know if this is generally known, but I've been digging into the original firmware, and it appears that the flash translation layer used for the internal memory is NFTL. At least some left-over debug strings strongly point in that direction. NFTL is readily supported by the Linux kernel, but there's a problem: When I enable the jz4740 NAND flash support in the opendingux kernel, it freezes at some point during bootup, so I cannot test my assumption.

(Also tried the legacy kernel, but it wouldn't even compile with NFTL enabled.)

15 comments:

  1. Are you sure it is permanently frozen? The bad block scan causes a delay of a few seconds, but I can boot an OpenDingux kernel with NAND support.

    ReplyDelete
  2. I got it to this stage now:

    Could not find valid boot record
    NFTL: could not mount device

    To get it there, in nftl_add_mtd() I had to change the size check to accept a 4GB MTD device and disable the MTD name check.

    I have to leave now. If anyone can make it mount, please post about it.

    ReplyDelete
  3. I tried again, but for me the kernel always freezes permanently when enabling JZ4740 NAND flash. Maybe my kernel config is wrong. Could you post yours somewhere?

    ReplyDelete
  4. I just pushed my latest NAND changes to my opendingux-kernel repository. The ECC computation works now. I think I have made a reasonable guess about partition boundaries. The bad block table seems to work, but since there seem to be no bad blocks on my Dingoo I don't know for sure how many bits per block it uses.

    The NFTL driver couldn't find any "ANAND" signature though. I also couldn't find any other block that looks like it could contain an NFTL header with a different signature. So I think either NFTL support is compiled in but not used or there are two FTL designs both named NFTL.

    I think the last 6 bytes of the oob area are likely to be used by the FTL. The header of the IHFS partition and the boot sector of the VFAT partition both have 00 00 00 00 as their last 4 bytes in the oob. The other 2 bytes might be used for wear leveling.

    ReplyDelete
  5. I wrote a long entry explaining the latest progress but it seems blogspot ate it. I don't have time to type it again; the short version is: git pull from opendingux-kernel.

    ReplyDelete
  6. Tried this kernel image, but it still hangs after "loopback: module loaded", just like my own kernel. Are there any flash-related hardware differences between models?

    ReplyDelete
  7. Strange blogspot glitch, it seems. After I posted my previous comment, yours showed up, too.

    ReplyDelete
  8. OK, a kernel built from the latest sources works for me. (Meaning it doesn't freeze.)

    ReplyDelete
  9. In the latest sources I disabled logging to the serial console, since I noticed that was slowing down the boot a lot. Maybe this was responsible for the hang as well.

    ReplyDelete
  10. I just pushed an FTL driver to opendingux-kernel. On my A320, it can mount the NAND FAT partition (read-only). The block device is /dev/ccnand1. Please test.

    ReplyDelete
  11. Yesterday I made several bug fixes to the FTL driver and now it seems to work. However, it does not support Dingoos with two NAND chips instead of one. Does anyone know how the second chip can be addressed?

    ReplyDelete
  12. Woohoo, great job! Don't have time to test it right now, but I know someone who will be very happy about it. :)

    ReplyDelete
  13. Tested and working. Merged it into my kernel tree.

    ReplyDelete