Hello Alexander,
you have to put correct nand configuration in devicetree in arch/arm/boot/dts/sun5i-a13-olinuxino.dts of your board. For comparision you may check sun7i-a20-cubieboard2.dts which has appropriate definitions. sunxi-nand-wip branch works on a20.
Good luck! Daniel
Alexander Kaplan writes:
Hi,
I tried both the kernel from https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
and u-boot from https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip
I can successfully compile and boot them on my A13-OLinuXino but there is no NAND available. Neither in kernel log nor in the u-boot output there is anything mentioned about NAND. I tried to enable all the NAND options, especially the "Support for NAND on Allwinner SoCs" in nconfig but I'm afraid I still have not found the right configuration.
Would it be possible to share the build configuration files?
Thanks in advance Alex
On Tue, May 26, 2015 at 7:52 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 05/26/2015 09:34 AM, Roy Spliet wrote:
Hello Hans,
Re-sent to everybody instead of just you. Reply inline.
Op 25-05-15 om 22:39 schreef Hans de Goede:
Hi,
On 25-05-15 20:35, Hans de Goede wrote:
Hi,
On 22-05-15 09:04, Roy Spliet wrote:
Hello,
For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip partitioning, ECC and randomisation. Docs for the DT specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable configuration options for the boot and boot_rescue partitions, make sure to pick one of these (which should be no problem for MLC-type nand). The ECC mode for these boot partitions is called hw_syndrome.
Assuming you now have a Linux set-up kernel based on this tree with NAND support on an MMC, for U-boot what you should currently do is:
- in include/configs/sunxi-common.h, adjust the parameters
<CONFIG_NAND_SUNXI_>PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip and DT configuration. 2) Build 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND: # flash_erase /dev/mtd0 # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin 4) Reboot without the MMC card and see U-boot load
Ok, it took me way longer then I wanted (see below) but I've this working now. It is cool to see u-boot load from nand :)
That should be all.
@Alex: To answer your question specifically: It's likely that the parameters in sunxi-common.h mentioned above might not match your NAND-chip configuration in the Linux kernel. I can't tell you precisely how to fetch these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise equal parameters, but perhaps he can help you with this better than I can.
Alex, could it be that you are writing the nand using a (rebased) version of bbrezillon's sunxi-nand-next branch ?
I started with that too because it is much newer and contains various bug fixes, but it seems that it also contains a new bug causing it to write the NAND in such a way that the BROM and u-boot SPL code will not read it.
I've just pushed a rebased version of the sunxi-nand branch of Boris here:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
And that works for me, where as before I got the exact same errors trying to fel load a nand enabled spl.
I'm working on merging over all the changes from the sunxi-nand-next branch onto my working sunxi-nand-experiment branch 1 by 1 until I find the one which causes the breakage...
Ok, so quick update the breakage was caused by this commit:
https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb4...
When it was rebased someone (Boris I guess) forgot to remove the "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the patch) and likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" line at line 1161. With these 2 lines removed the sunxi-nand-next branch from Boris, rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can load the spl / resp. u-boot.bin from there (on a cubieboard2).
You're right... I did spot this, but assumed this was my own mistake in merging these patches with our 4.0RC7 tree. Sorry, could have saved you some trouble if I were sharper.
I've also tried to get this code running on a cubieboard (non 2 so A10 rather then A20), the SPL loads fine there (indicating that the kernel bits work), but then I get:
U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19) DRAM: 1024 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 Nand initialised NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data ...
Thanks for testing this. I don't own an A10 myself, so I haven't observed this behaviour. First thing I would verify personally is whether all the clocks are properly configured. Could you make U-boot print &ccm->ahb_gate0 and &ccm->nand0_clk_cfg? For the first, bits 6 (DMA) and 13 (NAND) must be set, the second must have bit 31 set, bits 24 and 25 cleared (and otherwise, the accompanying PLL must be configured too... probably easier to use the OSC24M), and the divide ratios set to 0 (although a small divider, like 1, shouldn't be a problem either). I am assuming these values should be correct, but only because BROM initialised part of it. I am aware of the fact that the SPL driver doesn't control the DMA gating reg and the NAND post-dividers. It might be a good idea to do so for as long as we don't have a full DMA driver, so I'll patch that up today.
I've just tried the prelimary v4 of your patch-set from: https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip
And the changes you've made fix these errors on the A10, good job.
Regards,
Hans