costel.vasiliu Posted May 13, 2016 Posted May 13, 2016 Hi ! Ref : Olinuxino LIME2 4G with new 3.4.112 kernel When installing to NAND, on the console I see a lot of : PHY_PageRead : too much ecc err,bank 0 block 276,page 4 PHY_PageRead : too much ecc err,bank 0 block 276,page 18 and so on ... Sometimes the installation succeeded, sometimes not, but the system is often instable, and finally, fully unusable. I tried all the precompiled images, then I compiled myself, but the same problem ... Until now, I used 3.4.106 without problems Thanks for support ! Greetings ,
phelum Posted May 13, 2016 Posted May 13, 2016 Hi, If you re-install 3.4.106 does it work properly (just like it used to) ? If so I'd go looking for a change in the NAND driver. Cheers, Steven
costel.vasiliu Posted May 14, 2016 Author Posted May 14, 2016 Hi ! I found something related to this error message : https://github.com/cubieplayer/Cubian/issues/427 Is a little bit old and it is for another platform, but this comment : "solstag commented on Feb 12, 2015" may help. Of course, I reinstalled 3.4.106 and it works fine. I suspected the unit, but the same error appeared on other 3 units tested, bought at different times (I have a lot of Lime2 4G in production and all of them are working fine with 3.4.106) I need 3.4.112 for native overlayfs (in 3.6.106 I patched with AUFS) and for MALI driver. Otherwise, 3.4.106 should be enough for my purpose. Another remark : the error appears randomly. Yesterday, I compiled the whole image (jessie desktop) from scratch (according to Igor's instructions). Until now, after 12 hours, I have no problem, so, still testing ... Thanks, Greetings !
phelum Posted May 14, 2016 Posted May 14, 2016 Hi, I found a bug in my 3.4.103 kernel recently which caused the NAND clock calcs to fail on my Olimex Lime board. But it doesn't affect any other A20 boards that I've checked. After reporting it here I found Hans deGrode found it about a year ago. So, my report was old news. Since you have the kernel source maybe check /drivers/block/sunxi_nand/nfd/nand_block.c and find get_cmu_clock. Here is my patched version with my patch then the proper one. __u32 get_cmu_clk(void) { #if 0 // orig code and my patch __u32 reg_val; __u32 div_p, factor_n; __u32 factor_k, factor_m; __u32 clock; reg_val = *(volatile unsigned int *)(0xf1c20000 + 0x20); div_p = (reg_val >> 16) & 0x3; factor_n = (reg_val >> 8) & 0x1f; factor_k = ((reg_val >> 4) & 0x3) + 1; factor_m = ((reg_val >> 0) & 0x3) + 1; // div_p load above seems wrong because the source is an // exponent rather than a simple value. So we do it // properly here. div_p = 1 << ((reg_val >> 16) & 0x3); // SJS 2016-04-30 // But, NAND access works only when div_p is 1. So we just // set it to 1 unconditionally. div_p = 1; // SJS 2016-04-30 clock = 24 * factor_n * factor_k/div_p/factor_m; #else // code from https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/block/sunxi_nand/nfd/nand_blk.c __u32 reg_val; __u32 div_p, factor_n; __u32 factor_k; __u32 clock; reg_val = *(volatile unsigned int *)(0xf1c20000 + 0x20); div_p = (reg_val >> 16) & 0x3; factor_n = (reg_val >> 8) & 0x1f; factor_k = ((reg_val >> 4) & 0x3) + 1; clock = (24 * factor_n * factor_k) >> div_p; #endif return clock; } The original code used div_p as a divisor rather than a shift which caused a divide by zero crash on my Lime board. My patch fixed this but caused problems on my CB1. The proper patch works fine. Maybe your kernel has a faulty patch. Cheers, Steven
Recommended Posts