On Sat, Jan 11, 2020 at 1:47 AM Tim Sander <tim@xxxxxxxxxxxxxxx> wrote: > > Hi Masahiro Yamada > > Sorry for the large delay. I have seen the patches at > https://lists.infradead.org/pipermail/linux-mtd/2019-December/092852.html > Seem to resolve the question about the spare_area_skip_bytes register. > > I have now set the register to 2 which seems to be the right choice on an Intel > SocFPGA. But still i am out of luck trying to boot 5.4.5-rt3 or 5.5-rc5. I get the > following messages during bootup booting: > [ 1.825590] denali-nand-dt ff900000.nand: timeout while waiting for irq 0x1000 > [ 1.832936] denali-nand-dt: probe of ff900000.nand failed with error -5 > > But the commit c19e31d0a32dd 2017-06-13 22:45:38 predates the 4.19 kernel > release (Mon Oct 22 07:37:37 2018). So it seems there is not an obvious commit > which is causing the problem. Looking at the changes it might be that the timing > calculations in the driver changed which might also lead to a similar error. > > I am booting via NFS the bootloader is placed in NOR flash. The corresponding > nand dts entry is updated to the new format and looks like this: > nand@ff900000 { > #address-cells = <0x1>; > #size-cells = <0x0>; > compatible = "altr,socfpga-denali-nand"; > reg = <0xff900000 0x100000 0xffb80000 0x10000>; > reg-names = "nand_data", "denali_reg"; > interrupts = <0x0 0x90 0x4>; > clocks = <0x2d 0x1e 0x2e>; > clock-names = "nand", "nand_x", "ecc"; > resets = <0x6 0x24>; > status = "okay"; > nand@0 { > reg = <0x0>; > #address-cells = <0x1>; > #size-cells = <0x1>; > partition@0 { > label = "work"; > reg = <0x0 0x10000000>; > }; > }; > }; > > The last kernel i am able to boot is 4.19.10. I have tried booting: > 5.1.21, 5.2.9, 5.3-rc8, 5.4.5-rt3 and 5.5-rc5. They all failed. Unfortunately the > range is quite large for bisecting the problem. It also occurred to me that > all the platforms with Intel Cyclone V in mainline are development boards > which boot from SD-card not exhibiting this problem on their default boot path. What will happen if you apply all of these: http://patchwork.ozlabs.org/project/linux-mtd/list/?series=149821 on top of the mainline kernel, and then, hack denali->clk_rate and denali->clk_x_rate as follows? - denali->clk_rate = clk_get_rate(dt->clk); - denali->clk_x_rate = clk_get_rate(dt->clk_x); + denali->clk_rate = 50000000; + denali->clk_x_rate = 200000000; If it still fails, what about this? denali->clk_rate = 0; denali->clk_x_rate = 0; > PS: Here is some snippet from an older mail i didn't sent to the list yet which > might be superseded by now: > To get into this matter i started reading the "Intel Cyclone V HPS TRM" > Section 13-20 Preserving Bad Block Markers: > "You can configure the NAND flash controller to skip over a specified number of > bytes when it writes the last sector in a page to the spare area. This option > write the desired offset to the spare_area_skip_bytes register in the config > group. For example, if the device page size is 2 KB, and the device > area, set the spare_area_skip_bytes register to 2. When the flash controller > writes the last sector of the page that overlaps with the spare area, it > spare_area_skip_bytes must be an even number. For example, if the bad block > marker is a single byte, set spare_area_skip_bytes to 2." I did not know this documentation. It says "For example" (twice), it sounds uncertain to me, though. Anyway, an intel engineer checked the boot ROM code. SPARE_AREA_SKIP_BYTES=2 is correct, he said. -- Best Regards Masahiro Yamada ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/