Hello,I'm running sunxi-linux 3.4.90 (current commit ge37d760) on a Cubietruck (A20) and an OlinuXino A10 Lime.
The Cubietruck has an 8GB NAND (H27UCG8T2ATR) which works fine. I added an 8GB NAND (H27UCG8T2BTR) to the OlinuXino A10 Lime and I encountered problems after loading nand.ko: nandd used all available CPU, commands accessing the NAND would hang, there were timeout messages and tracebacks in the log ("INFO: task modprobe:3690 blocked for more than 120 seconds.") and reboot the system would hang on nand driver termination.
The difference between both 8GB NAND chips is their internal organization, the working H27UCG8T2ATR has an 8kB page size (ie. 16 sectors / page) while the non working H27UCG8T2BTR has a 16kB page size (ie. 32 sectors / page). Both have 2 planes in 1 die.
After some scrutinization of the sunxi_nand code, the root cause of my problem is the definition of fields like "SectBitmap" as __u32 (unsigned 32 bit), which is not sufficient for this device.
FULL_BITMAP_OF_SUPER_PAGE (in src/include/nand_physic.h) also returns __u32 but the calculation for H27UCG8T2BTR yields a 64 bit result, due to "(NandStorageInfo.SectorCntPerPage * NandStorageInfo.PlaneCntPerDie)" -> (32*2).
I bypassed this problem by disabling "CFG_SUPPORT_MULTI_PLANE_PROGRAM" in src/include/nand_drv_cfg.h.
The real fix would be to change some fields and definitions to __u64, or alternative to change OpOpts for NAND chips with 32 sectors per page to disable multi plane program.
Question: Does it make sense to fix sunxi_nand for sunxi-linux 3.4? How is this code implemented in the current mainline linux?
If there is interest to fix sunxi_nand, I may have a look at the required changes...
-- Arnd Gronenberg, [email protected], DJ9PZ / AB2QP
smime.p7s
Description: S/MIME Cryptographic Signature
