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.)
Mh. Thats no good news.
ReplyDeleteAre 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.
ReplyDeleteI got it to this stage now:
ReplyDeleteCould 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.
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?
ReplyDeletekernel image and source diff
ReplyDeleteI 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.
ReplyDeleteThe 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.
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.
ReplyDeleteTried 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?
ReplyDeleteStrange blogspot glitch, it seems. After I posted my previous comment, yours showed up, too.
ReplyDeleteOK, a kernel built from the latest sources works for me. (Meaning it doesn't freeze.)
ReplyDeleteIn 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.
ReplyDeleteI 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.
ReplyDeleteYesterday 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?
ReplyDeleteWoohoo, great job! Don't have time to test it right now, but I know someone who will be very happy about it. :)
ReplyDeleteTested and working. Merged it into my kernel tree.
ReplyDelete