I have a user guide update in a draft form with instructions on how to use the NAND. Basically, the NAND is locked and the GPMC bus re-initializes it without unlocking it, so I have a a work around.

Step 1: Build the kernel with GPMC debugging enabled (and disable the re-initialization)

1. make menuconfig ARCH=arm
2. Device Drivers ---> Memory Controller Drivers
3. Check "enable GPMC debug output and skip reset of GPMC during init"

Step 2. Unlock the NAND in U-Boot before you load kernel on startup.


I will send you a draft in your e-mail. It hasn't been internally reviewed yet, but if you find errors or questions, feel free to post comments/feedback and I'll work on updating / correcting any errors.

adam

thanks for the quick response, and for the user guide.
after those steps i was able to wirte only to the FS parttion in the nand chip, is there a way to unlock the whole chip?

The u-boot command 'nand unlock' should unlock the whole chip. The instructions for writing to the kernel partition and MLO partition are there a well, but special caution must be followed when writing to the MLO partition due to the ECC settings for that partition.


adam

I should also add that the write instructions will fail if you try to write an object larger than the partition sizes.

adam

If you want to post logs of what you're seeing, I might be able to help you troubleshoot what's going wrong.

adam

Is there some additional setup that needs to be done to get the MTD partitions to show up in Linux? On my 4.8.6 kernel I can see that mtdparts is being passed to the kernel and appears correct. However, there aren't any /dev/mtdX devices and /proc/mtd shows no devices.

Not that I am aware. I haven't tested the 4.8 tree, but I did some testing on the 4.4 and the 4.8 and the kernel setup the partitions correctly. ARe you able to post a log of your system booting?

(or dump the output of demsg)

that might shed some light on what's going on.

Here's everything from dmesg that looks relevant:

# dmesg | grep -i mtd -C 3
[ 0.000000] pcpu-alloc: s31080 r8192 d22168 u61440 alloc=15*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129408
[ 0.000000] Kernel command line: console=ttyO0,115200n8 ignore_loglevel early_printk no_console_suspend root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait display=15 ignore_loglevel early_printk no_console_suspend mtdparts=omap2-nand.0:512k(MLO),1920k(u-boot),128k(u-boot-env),4m(kernel),-(fs)
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
--
[ 2.825653] gpiochip_find_base: found new base at 488
[ 2.831146] gpio gpiochip7: (twl4030): added GPIO chardev (254:7)
[ 2.838989] gpiochip_setup_dev: registered GPIOs 488 to 507 on device: gpiochip7 (twl4030)
[ 2.927124] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.951660] libphy: Fixed MDIO Bus: probed
[ 2.967926] mousedev: PS/2 mouse device common for all mice
[ 2.974487] i2c /dev entries driver

It looks like mtdoops wants something like "mtdoops.mtddev=omap2.nand" in the bootargs. Perhaps that's the problem?

Your output of dmesg was piped through grep, so I didn't get everything.

Can you see if something similar to the following is shown:

2.122955] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.129791] nand: Micron MT29F4G16ABBDA3W
[ 2.134063] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB siz
e: 64
[ 2.142059] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.150482] 6 cmdlinepart partitions found on MTD device omap2-nand.0
[ 2.157379] Creating 6 MTD partitions on "omap2-nand.0":
[ 2.162994] 0x000000000000-0x000000080000 : "MLO"
[ 2.177124] 0x000000080000-0x000000240000 : "u-boot"
[ 2.189575] 0x000000240000-0x000000260000 : "spl-os"
[ 2.200347] 0x000000260000-0x000000280000 : "u-boot-env"
[ 2.211273] 0x000000280000-0x000000880000 : "kernel"
[ 2.227111] 0x000000880000-0x000020000000 : "fs"

mtdoops is a way to store kernel panic information to flash for later evaluation. I would not expect it to cause an issue with the mtd driver.



adam

Sorry, just trying to avoid polluting the forum. :-)

I definitely don't have those messages which is what I had been expecting to see. I did find this though:

# dmesg|grep nand -C 3
[ 0.000000] pcpu-alloc: s31080 r8192 d22168 u61440 alloc=15*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129408
[ 0.000000] Kernel command line: console=ttyO0,115200n8 ignore_loglevel early_printk no_console_suspend root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait display=15 ignore_loglevel early_printk no_console_suspend mtdparts=omap2-nand.0:512k(MLO),1920k(u-boot),128k(u-boot-env),4m(kernel),-(fs)
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
--
[ 0.565979] gpiochip_find_base: found new base at 508
[ 0.566070] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6)
[ 0.567504] gpiochip_setup_dev: registered GPIOs 508 to 511 on device: gpiochip6 (omap-gpmc)
[ 0.567657] omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has malformed 'reg' property
[ 0.567687] omap-gpmc 6e000000.gpmc: failed to probe DT child 'nand': -19
[ 0.567932] gpmc cs1 before gpmc_cs_program_settings:
[ 0.567962] cs1 GPMC_CS_CONFIG1: 0x00001000
[ 0.567962] cs1 GPMC_CS_CONFIG2: 0x00080801

Looks like an issue with the device tree setup.

Solved it! I'm using a custom DTS file. Whichever logicpd-torpedo-37xx-devkit.dts file I based it off of didn't seem to have the NAND chip select configured for the GPMC node. I added it as shown here and now everything is working.

&gpmc {
ranges = <0 0 0x30000000 0x1000000 /* CS0: 16MB for NAND */
1 0 0x08000000 0x1000000>; /* CS1: 16MB for LAN9221 */

ethernet@gpmc {
pinctrl-names = "default";
pinctrl-0 = <&lan9221_pins>;
interrupt-parent = <&gpio5>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>; /* gpio129 */
reg = <1 0 0xff>;
};
};

I would tend to agree. There were some device tree changes between 4.4, 4.6 and 4.8.

I would suggest rebuilding the device tree to see if that helps make it go away.

adam

That's great news.

adam