DM385 + IPNC RDK3.5 + kernel 2.6.37 -> nand flash driver support needed?

Hi Ganesh,

You are checking now linux kernel NAND driver, does this mean you can detect/access this NAND from u-boot?

The correct u-boot messages that I expect are:

NAND: HW ECC BCH8 Selected
128 MiB

Or you do not need NAND support in u-boot, but only in linux?

I see that Spansion S34ML01G1 NAND is x8 (2048 + 64 spare) bytes, which is 1024 + 32 spare words. The NAND chip on DM814x TI EVM is Micron MT29F2G16AAD x16 1024 + 32 spare words. Do you know what NAND chip is located at the IPNC board?

See also if the below e2e threads will be in help:

e2e.ti.com/.../372626
e2e.ti.com/.../494786
e2e.ti.com/.../450963
e2e.ti.com/.../470668

Regards,
Pavel

Hi Pavel Botev (1176686) ,

"You are checking now linux kernel NAND driver, does this mean you can detect/access this NAND from u-boot?

The correct u-boot messages that I expect are:

NAND: HW ECC BCH8 Selected
128 MiB"

Yes i'm now looking at linux kernel, No in uboot NAND is not been detected.

Or you do not need NAND support in u-boot, but only in linux?

Yes i do need support for nand in uboot but priority is nand support in linux kernel as of now.

I see that Spansion S34ML01G1 NAND is x8 (2048 + 64 spare) bytes, which is 1024 + 32 spare words. The NAND chip on DM814x TI EVM is Micron MT29F2G16AAD x16 1024 + 32 spare words. Do you know what NAND chip is located at the IPNC board?

yes spansion s34ml01g1 nand we are using, x8 I/O data lines, Device id F1, page size 2048 Bytes , ONFI 1.0  compliant. i need to know what can i do enable support in my kernel. do i need to enable mux in board file or by default it will have the support. as my nand is connected on cs0.

thanks & regards,

ganesh

Ganesh,

If you use the same physical pins in your custom board like in IPNC board, then the pinmux should be fine. But I would suggest you to double check the pinmux registers values with devmem2 tool from user space.

Regards,
Pavel

You can also use omap_mux to check the pinmux settings from user space:

# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/omap_mux/...

BR
Pavel

Hi Pavel Botev , thanks for your response i will see through it one more help, regarding pin muxing and nand configuration setting, as i was checking ./arch/arm/mach-omap2/devices.c file, i was able to see
#ifdef CONFIG_MTD_CFI
ti814x_nor_init();
#endif
but with respect to nand initailization i was not able to find any file except driver part. so can you just point me to a direction where pin mux configuration available for nand and where i can set nand configuration for my nand.

i have followed

# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/omap_mux/..

it was very helpful,  i have checked datasheet with respect to gpmc pins are correct except gpmc_wait0 pin which need to be connected to mode0,

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_wait0
name: gpmc_wait0.gpio1_31 (0x48140a10/0xa10 = 0x60080), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE7
signals: gpmc_wait0 | gpmc_a_26_mux2 | NA | NA | NA | xdma_evt_0_mux0 | NA | gpio1_31

can you elaborate on this. Is wait0 necessary because as i checked nand datasheet, wait0(R/B) pin is connected to +3.3 v.

but even if we don't consider wait0 it should detect right.  while in dmesg i'm getting

No NAND device found.

thanks & regards,

Ganesh 

thanks & regards,
Ganesh

Ganesh,

I think linux kernel do not make NAND pinmux, but keep the NAND pinmux setting from u-boot. You can set the NAND pins in linux kernel using the approach described in the below wiki:
processors.wiki.ti.com/.../TI81XX_PSP_User_Guide

You can also explore your board file (i.e. board-dm385ipnc.c). See "struct mtd_partition ti814x_nand_partitions" and board_nand_init(). It seems that NAND is hard-coded to x16 there : NAND_OMAP_BUS_16. You might also check this.

Regards,
Pavel

Hi Pavel Botev ,

dm385_evm_init -> cpu_is_ti814x -> bw -> 0/*8-bit nand if BTMODE BW pin on board is OFF*/

i have checked total file i believe settings are correct it is x8 only. any other  input.

thanks & regards,
Ganesh

Ganesh,

Please check the values of registers CONTROL_STATUS and GPMC_CONFIG1. Check them with devmem2 tool from user space.

Regards,
Pavel

Check also TRM, chapter GPMC

For 8-bit NAND, you should be aligned to:

Table 11-2. GPMC Pin Multiplexing Options
Figure 11-4. GPMC to 8-Bit NAND Device

BR
Pavel

Hi Pavel Botev , i have checked GPMC_CONFIG1_i in TRM but to read the CONFIG1 register i need address in datasheet i didn't find anything . sorry to ask but could you point me in right direction.
Table 10-2. GPMC Pin Multiplexing Options
Figure 10-4. GPMC to 8-Bit NAND Device
i have checked above table and figure their is no issue with interfacing.

Refer to DM38x datasheet (SPRS821D), section 2.10 Memory Map Summary

GPMC base addr: 0x50000000

DM38x TRM (SPRUHG1B):

GPMC_CONFIG1_i : 60h + (30h × i) (for CS0, offset is 0x60)

BR
Pavel

Hi Pavel Botev (1176686) ,

following are my GPMC_CONFIG and control status register values.

0x5000 0000 + 60 + (30 * 0) = 0x5000 0060 for CS0

# devmem2 0x50000060 //GPMC_CONFIG1_0
/dev/mem opened.
Memory mapped at address 0x40299000.
Read at address 0x50000060 (0x40299060): 0x00001800

root@DM385_IPNC:~# devmem2 0x48140040 //control status
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address 0x48140040 (0x40313040): 0x00000317

thanks & regards,
Ganesh

Ganesh,

Ganesh Biradar said:

root@DM385_IPNC:~# devmem2 0x48140040 //control status
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address 0x48140040 (0x40313040): 0x00000317

The value in CONTROL_STATUS register is correct, you have bit [16] BW = 0 (8-bit data bus), which means BOOT[12] pin is correctly set.

Ganesh Biradar said:

following are my GPMC_CONFIG and control status register values.

0x5000 0000 + 60 + (30 * 0) = 0x5000 0060 for CS0

# devmem2 0x50000060 //GPMC_CONFIG1_0
/dev/mem opened.
Memory mapped at address 0x40299000.
Read at address 0x50000060 (0x40299060): 0x00001800

The value in GPMC_CONFIG1_0 is not correct, you have bits [13:12] DEVICESIZE = 0x1 (16-bit), which means that GPMC_CONFIG1_0 is not properly set in the linux kernel.

I would suggest you to track the NAND init/config, and check where exactly  GPMC_CONFIG1_0 is set for 16-bit, and change for 8-bit.

Regards,
Pavel

Hi Pavel Botev,

thanks for your input, to check myself in every step of nand i have put up log messages from probing to configuring , i checked that in

./drivers/mtd/nand/nand_base.c

/* Get buswidth to select the correct functions */
        busw = chip->options & NAND_BUSWIDTH_16;

follows:

/* Read the flash type */
        type = nand_get_flash_type(mtd, chip, busw,
                                &nand_maf_id, &nand_dev_id, table);

then i get

"No NAND Device found"

any input? i'm trying just requiring some insight.

regards,

Ganesh

Ganesh Biradar said:

any input?

Change from 16-bit to 8-bit

Hi Pavel Botev ,

"any input?"

actually i was referring to i'm in correct path.

#define NAND_BUSWIDTH_16 0x00000002

actually in place of
busw = chip->options & NAND_BUSWIDTH_16; <------> busw = chip->options & 0;

but still i get No NAND Device Found.

thanks & regards,
Ganesh

Ganesh Biradar said:

actually in place of
busw = chip->options & NAND_BUSWIDTH_16; <------> busw = chip->options & 0;

Do you have the correct value in GPMC_CONFIG1_0 register now? (check it with devmem2 from user space)

Regards,
Pavel

Hi Pavel Botev ,

# devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x40299000.
Read at address 0x50000060 (0x40299060): 0x00001800

same as it is. i will get back to you as i'm checking
./drivers/mtd/nand/omap2.c.

regards,
Ganesh

Hi Pavel Botev ,

Observation:

1-> in board file board-dm385ipnc.c :

board_nand_init(ti814x_nand_partitions, ARRAY_SIZE(ti814x_nand_partitions), 0, bw);

it is properly setting bw = 0 for 8-bit and cs = 0, now when it comes to driver side, these what i observed in dmesg after putting some debug logs.
omap2-nand driver initializing
DM385 -> omap_nand_probe -> omap2-nand.0 -> cs -> 0
DM385 -> 1 : busw: 0 chip->options: 131072 NAND_BUSWIDTH_16: 2
DM385 -> nand_get_flash_type: ID read 17,17
DM385 -> nand_get_flash_type: ID 17,17 against 17,17
DM385 -> nand_get_flash_type: ID read type_id -> 00, *dev_id -> 17
DM385 -> check onfi compliant
DM385 -> 2 : busw: 0 chip->options: 131072 NAND_BUSWIDTH_16: 2
No NAND device found.
DM385 -> 1 : busw: 2 chip->options: 131074 NAND_BUSWIDTH_16: 2
DM385 -> nand_get_flash_type: ID read 17,17
DM385 -> nand_get_flash_type: ID 17,17 against 17,17
DM385 -> nand_get_flash_type: ID read type_id -> 00, *dev_id -> 17
DM385 -> check onfi compliant
DM385 -> 2 : busw: 2 chip->options: 131074 NAND_BUSWIDTH_16: 2
No NAND device found.

if you can see first when it is probing buswidth(busw) is zero(x8) but next time buswidth(busw) value is set 2(x16).

which means it is properly configured but it is unable to get the device to work.

conclusion: still nand device is not getting probed.

what could be the issue? any help.

thanks & regards,
Ganesh

Ganesh,

Can you put the below printk() to examine the GPMC_CONFIG1_0 register value:

board-dm385ipnc.c

static void __init dm385_evm_init(void)
{
...
printk GPMC_CONFIG1_0

/* nand initialisation */
board_nand_init(ti814x_nand_partitions,
ARRAY_SIZE(ti814x_nand_partitions), 0, NAND_OMAP_BUS_16);

printk GPMC_CONFIG1_0

}

Then change from NAND_OMAP_BUS_16 to NAND_OMAP_BUS_8 and print:

static void __init dm385_evm_init(void)
{
...
printk GPMC_CONFIG1_0

/* nand initialisation */
board_nand_init(ti814x_nand_partitions,
ARRAY_SIZE(ti814x_nand_partitions), 0, NAND_OMAP_BUS_8);

printk GPMC_CONFIG1_0

}



Pavel

Hi Pavel Botev (1176686) ,

As you mentioned i was trying to print config_gpmc1 register value,

in earlier board file,

static void __init dm385_evm_init(void)

{

...

u32 *control_status = TI81XX_CTRL_REGADDR(0x40);

/*TI81XX_CTRL_BASE + TI81XX_L4_SLOW_IO_OFFSET + 0x40 = 0x48140000 + 0xB2000000 + 0x40 = 0xFA140040*/

if (*control_status & (1<<16))

                       bw = 2; /*16-bit nand if BTMODE BW pin on board is ON*/

               else

                       bw = 0; /*8-bit nand if BTMODE BW pin on board is OFF*/

}

based on it i got bw = 0,

now to print gpmc config register i have to add support for offset of l3 interconnect. because to directly access gpmc register is not possible. following changes i made,

/*./arch/arm/mach-omap2/control.h*/

#define TI81XX_GPMC_REGADDR(reg)                                        \

               OMAP2_L3_IO_ADDRESS(TI81XX_GPMC_BASE + (reg))//added myself as their is no support to read gpmc register 

/*./arch/arm/plat-omap/include/plat/ti81xx.h*/

#define TI81XX_GPMC_BASE        0x50000000

/*./arch/arm/plat-omap/include/plat/io.h*/

#define OMAP2_L3_IO_OFFSET      0x90000000

#define OMAP2_L3_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_L3_IO_OFFSET) /* L3 */

/*0x50000000 + 0x90000000 + 0x60 = 0xE0000060 */

/*board-dm385ipnc.c*/

u32 *control_status = TI81XX_CTRL_REGADDR(0x40);

u32 *gpmc_config = TI81XX_GPMC_REGADDR(0x60); //in board file

printk(KERN_INFO"DM385 -> %s -> control_status -> 0x%x\n",__func__,*control_status);

printk(KERN_INFO"DM385 -> 1 -> %s -> gpmc_config -> 0x%x\n",__func__,*gpmc_config);

as i started booting the sd card,

DM385 -> dm385_evm_init -> control_status -> 0x317

Unable to handle kernel paging request at virtual address e0000060

pgd = c0004000

[e0000060] *pgd=00000000

Internal error: Oops: 5 [#1]

last sysfs file:

Modules linked in:

CPU: 0    Not tainted  (2.6.37_DM385_CARDVR_3.50.00 #26)

PC is at dm385_evm_init+0xc8/0x2e0

LR is at release_console_sem+0x180/0x194

pc : [<c00128e8>]    lr : [<c007054c>]    psr: 60000013

sp : c4025f80  ip : c4025ec0  fp : c4025f94

r10: 00000000  r9 : 00000000  r8 : 00000000

r7 : c000b6f4  r6 : c00724c8  r5 : fa140000  r4 : e0000000

r3 : 60000013  r2 : c047fa6c  r1 : 000012e5  r0 : 00000039

Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel

Control: 10c5387f  Table: 80004019  DAC: 00000017

Process swapper (pid: 1, stack limit = 0xc40242e8)

Stack: (0xc4025f80 to 0xc4026000)

5f80: c002cb50 c002cf44 c4025fa4 c4025f98 c000b714 c001282c c4025fdc c4025fa8

5fa0: c003d4f8 c000b700 c4025fc4 00000176 c0489494 c00724c8 c4025fdc c002cb50

5fc0: c002cf44 c00724c8 00000013 00000000 c4025ff4 c4025fe0 c0008cfc c003d448

5fe0: 00000000 c0008c5c 00000000 c4025ff8 c00724c8 c0008c68 fffef7f7 ffffffff

Backtrace:

[<c0012820>] (dm385_evm_init+0x0/0x2e0) from [<c000b714>] (customize_machine+0x20/0x2c)

r5:c002cf44 r4:c002cb50

[<c000b6f4>] (customize_machine+0x0/0x2c) from [<c003d4f8>] (do_one_initcall+0xbc/0x190)

[<c003d43c>] (do_one_initcall+0x0/0x190) from [<c0008cfc>] (kernel_init+0xa0/0x154)

r8:00000000 r7:00000013 r6:c00724c8 r5:c002cf44 r4:c002cb50

[<c0008c5c>] (kernel_init+0x0/0x154) from [<c00724c8>] (do_exit+0x0/0x5d0)

r5:c0008c5c r4:00000000

Code: e59f11bc e59f01bc e5952040 eb0cd3c7 (e5942060)

---[ end trace 1b75b31a2719ed1c ]---

Kernel panic - not syncing: Attempted to kill init!

Backtrace:

[<c004af70>] (dump_backtrace+0x0/0x110) from [<c034768c>] (dump_stack+0x18/0x1c)

r6:c4022000 r5:0000000b r4:c04a6998 r3:60000113

[<c0347674>] (dump_stack+0x0/0x1c) from [<c03476ec>] (panic+0x5c/0x178)

[<c0347690>] (panic+0x0/0x178) from [<c0072530>] (do_exit+0x68/0x5d0)

r3:c0481084 r2:c4025d60 r1:00000001 r0:c040535b

r7:00000000

[<c00724c8>] (do_exit+0x0/0x5d0) from [<c004b3e4>] (die+0x2b0/0x2ec)

r7:00000000

[<c004b134>] (die+0x0/0x2ec) from [<c004daa8>] (__do_kernel_fault+0x6c/0x8c)

[<c004da3c>] (__do_kernel_fault+0x0/0x8c) from [<c004db30>] (do_bad_area+0x68/0x74)

r8:c4025f38 r7:00000000 r6:00003800 r5:c0004000 r4:00000005

r3:c4025f38

[<c004dac8>] (do_bad_area+0x0/0x74) from [<c034b5f0>] (do_translation_fault+0x9c/0xa8)

[<c034b554>] (do_translation_fault+0x0/0xa8) from [<c003d1f4>] (do_DataAbort+0x38/0xa0)

r7:c0468378 r6:e0000060 r5:00000005 r4:00000005

[<c003d1bc>] (do_DataAbort+0x0/0xa0) from [<c034962c>] (__dabt_svc+0x4c/0x60)

Exception stack(0xc4025f38 to 0xc4025f80)

5f20:                                                       00000039 000012e5

5f40: c047fa6c 60000013 e0000000 fa140000 c00724c8 c000b6f4 00000000 00000000

5f60: 00000000 c4025f94 c4025ec0 c4025f80 c007054c c00128e8 60000013 ffffffff

r8:00000000 r7:c000b6f4 r6:c00724c8 r5:c4025f6c r4:ffffffff

[<c0012820>] (dm385_evm_init+0x0/0x2e0) from [<c000b714>] (customize_machine+0x20/0x2c)

r5:c002cf44 r4:c002cb50

[<c000b6f4>] (customize_machine+0x0/0x2c) from [<c003d4f8>] (do_one_initcall+0xbc/0x190)

[<c003d43c>] (do_one_initcall+0x0/0x190) from [<c0008cfc>] (kernel_init+0xa0/0x154)

r8:00000000 r7:00000013 r6:c00724c8 r5:c002cf44 r4:c002cb50

[<c0008c5c>] (kernel_init+0x0/0x154) from [<c00724c8>] (do_exit+0x0/0x5d0)

r5:c0008c5c r4:00000000

i got crashed, if i remove newly added code it boots fine.

thanks & regards,

Ganesh

Ganesh Biradar said:

u32 *control_status = TI81XX_CTRL_REGADDR(0x40);

/*TI81XX_CTRL_BASE + TI81XX_L4_SLOW_IO_OFFSET + 0x40 = 0x48140000 + 0xB2000000 + 0x40 = 0xFA140040*/

if (*control_status & (1<<16))

                       bw = 2; /*16-bit nand if BTMODE BW pin on board is ON*/

               else

                       bw = 0; /*8-bit nand if BTMODE BW pin on board is OFF*/

}

based on it i got bw = 0,

Why you investigate CONTROL_STATUS [16] BW bit / BOOT[12] pin ? We already found that it is fine.

Ganesh Biradar said:

now to print gpmc config register i have to add support for offset of l3 interconnect. because to directly access gpmc register is not possible.

You’ll need to map the physically memory to virtual memory using linux kernal ioremap system call.

static void __init dm385_evm_init(void)
{

static void __iomem *base;

base = ioremap(0x50000000, SZ_4K);
printk("before NAND init GPMC_CONFIG1_0 = %x", __raw_readl(base + 0x60));

    /* nand initialisation */
    board_nand_init(ti814x_nand_partitions,
        ARRAY_SIZE(ti814x_nand_partitions), 0, NAND_OMAP_BUS_8);

    printk("after NAND init GPMC_CONFIG1_0 = %x", __raw_readl(base + 0x60));
}

Regards,
Pavel

Ganesh,

I made some test on the DM814x TI EVM. This EVM comes with 16-bit NAND chip, and BOOT[12] pin is controlled from switch. When we have 16-bit NAND, the switch on the EVM (CS0BW) (BTMODE12) is ON/1. When we have 8-bit NAND chip, the switch on the EVM should be OFF/0.

I put this code:

static void __init ti8148_evm_init(void)
{

static void __iomem *base;
static void __iomem *base1;
....
base = ioremap(0x50000000, SZ_4K);
base1 = ioremap(0x48140000, SZ_4K);

printk("before NAND init GPMC_CONFIG1_0 = %x\n", __raw_readl(base + 0x60));
printk("before NAND init CONTROL_STATUS = %x\n", __raw_readl(base1 + 0x40));

/* nand initialisation */
board_nand_init(ti814x_nand_partitions,
ARRAY_SIZE(ti814x_nand_partitions), 0, NAND_OMAP_BUS_16);

printk("after NAND init GPMC_CONFIG1_0 = %x\n", __raw_readl(base + 0x60));
printk("after NAND init CONTROL_STATUS = %x\n", __raw_readl(base1 + 0x40));
...
}

With NAND_OMAP_BUS_16 and BOOT[12] pin 1, I have the below values:

before NAND init GPMC_CONFIG1_0 = 1810
before NAND init CONTROL_STATUS = 10317
after NAND init GPMC_CONFIG1_0 = 1810
after NAND init CONTROL_STATUS = 10317

root@dm814x-evm:~# devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x40338000.
Read at address 0x50000060 (0x40338060): 0x00001810
root@dm814x-evm:~# devmem2 0x48140040
/dev/mem opened.
Memory mapped at address 0x401b1000.
Read at address 0x48140040 (0x401b1040): 0x00010317


With NAND_OMAP_BUS_8 and BOOT[12] pin 0, I have the below values:

before NAND init GPMC_CONFIG1_0 = 810
before NAND init CONTROL_STATUS = 317
after NAND init GPMC_CONFIG1_0 = 810
after NAND init CONTROL_STATUS = 317

root@dm814x-evm:~# devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x40338000.
Read at address 0x50000060 (0x40338060): 0x00000810
root@dm814x-evm:~# devmem2 0x48140040
/dev/mem opened.
Memory mapped at address 0x401b1000.
Read at address 0x48140040 (0x401b1040): 0x00000317

Can you make the same test at your side?

Regards,
Pavel

Hi @Pavel Botev,

1 -> Why you investigate CONTROL_STATUS [16] BW bit / BOOT[12] pin ? We already found that it is fine.?

Actually, when i got the sdk for my project, in board file, it is already investigating and then setting the buswidth.  i'm not investigating. i was just trying to show you. how buswidth is being set here in my nand initialization.

2 ->

I have followed the test you ask for this is what i got,

>>>>>>>>>>>>>> NAND_BUSWIDTH_16: <<<<<<<<<<<<<<<<<<

before NAND init GPMC_CONFIG1_0 = 1800
before NAND init CONTROL_STATUS = 317

board_nand_init(ti814x_nand_partitions, ARRAY_SIZE(ti814x_nand_partitions), 0, 2);

after NAND init GPMC_CONFIG1_0 = 1800
after NAND init CONTROL_STATUS = 317

devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x40051000.
Read at address  0x50000060 (0x40051060): 0x00001800

devmem2 0x48140040
/dev/mem opened.
Memory mapped at address 0x4012b000.
Read at address  0x48140040 (0x4012b040): 0x00000317


>>>>>>>>>>>>>>>> NAND_BUSWIDTH_8: <<<<<<<<<<<<<<<<

before NAND init GPMC_CONFIG1_0 = 1800
before NAND init CONTROL_STATUS = 317

board_nand_init(ti814x_nand_partitions, ARRAY_SIZE(ti814x_nand_partitions), 0, 0);

after NAND init GPMC_CONFIG1_0 = 1800
after NAND init CONTROL_STATUS = 317

devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x4031e000.
Read at address  0x50000060 (0x4031e060): 0x00001800

devmem2 0x48140040
/dev/mem opened.
Memory mapped at address 0x400ec000.
Read at address  0x48140040 (0x400ec040): 0x00000317

no change at all.

 

thanks & regards,

Ganesh

 

Ganesh Biradar said:

board_nand_init(ti814x_nand_partitions, ARRAY_SIZE(ti814x_nand_partitions), 0, 2);

Can you try with NAND_OMAP_BUS_16 instead of 2?

Ganesh Biradar said:

board_nand_init(ti814x_nand_partitions, ARRAY_SIZE(ti814x_nand_partitions), 0, 0);

Can you try with NAND_OMAP_BUS_8 instead of 0?

Can you also try with the latest linux kernel version for the IPNC RDK, you can take it from the below location:

Regards,
Pavel

Hi Pavel Botev (1176686) ,

case 1:

The MACROS you ask to use is not available in IPNC RDK3.5, they where added in IPNC RDK3.8. even for testing purpose, i have added support in my present header file as mentioned dm81xx, like below used in board init file but no effect.

arch/arm/plat-omap/include/plat/nand.h

enum nand_bussize {

          NAND_OMAP_BUS_8,

          NAND_OMAP_BUS_16

  };

case 2:

As we have already started our work on ipnc rdk3.5 around 3 months, we made lot of customization and our application around ipnc rdk 3.5, we can't change and their no time for us to go for ipnc rdk 3.8(the link you provided)

case 3:

If you look at below log, i'm using spansion nand which has device id 0x1F, manufacturer id 0x01. here when it is uanble to read proper id itself.

omap2-nand driver initializing

DM385 -> omap_nand_probe -> omap2-nand.0 -> cs -> 0

DM385 -> 1 : busw: 0

DM385 -> nand_get_flash_type: ID read maf_id -> 17, dev_id -> 17/* Read manufacturer and device IDs */

DM385 -> nand_get_flash_type: ID maf_id -> 17,dev_id -> 17 against id_data[0] -> 17,id_data[1]->17/*Read manufacture & device id once again and compare with old ids*/

DM385 -> nand_get_flash_type: ID read type_id -> 00, *dev_id -> 17

DM385 -> check onfi compliant

DM385 -> onfi 1 -> nand_get_flash_type : omap2-nand.0

No NAND device found.

DM385 -> 1 : busw: 2

DM385 -> nand_get_flash_type: ID read maf_id -> 17, dev_id -> 17

DM385 -> nand_get_flash_type: ID maf_id -> 17,dev_id -> 17 against id_data[0] -> 17,id_data[1]->17

DM385 -> nand_get_flash_type: ID read type_id -> 00, *dev_id -> 17

DM385 -> check onfi compliant

DM385 -> onfi 1 -> nand_get_flash_type : omap2-nand.0

thanks & regards,

Ganesh

Ganesh,

Then I would suggest to apply all the GPMC/NAND related patches available in the below tree and that are not present in your linux kernel code base.

arago-project.org/.../

Example patch is:
arago-project.org/.../

Regards,
Pavel

Hi Pavel Botev ,

I took the ipnc rdk 3.8 kernel from git and builded without any change, except debug log for before and after nand initialization, with NAND_OMAP_BUS_8 & NAND_OMAP_BUS_16.

same values as i got while trying ipnc rdk 3.5.

GPMC_CONFIG1_0 = 1800 & CONTROL_STATUS = 317 for both x8 & x16. i even check with devmem2 tool same values.

thanks & regards,
Ganesh

Ganesh,

I suspect GPMC_CONFIG1_0 is configured in u-boot for 16-bit NAND, and then the linux kernel does not change it to 8-bit.

When booting the board, stop at the u-boot prompt and check/write the register like below:

TI8148_EVM#md 0x50000060 1
50000060: 00001810 ....
TI8148_EVM#mw 0x50000060 0x00000810 1
TI8148_EVM#md 0x50000060 1
50000060: 00000810

Then proceed with booting the board and check if you have the correct value in GPMC_CONFIG1_0 in user space (with devmem2 tool).

Regards,
Pavel

Hi Pavel Botev,

In u-boot:

DM385_IPNC#md 0x50000060 1
50000060: 00001800    ....
DM385_IPNC#mw 0x50000060 0x00000810 1
DM385_IPNC#md 0x50000060 1
50000060: 00000810    ....

In kernel:

before NAND init GPMC_CONFIG1_0 = 810
before NAND init CONTROL_STATUS = 317
after NAND init GPMC_CONFIG1_0 = 810
after NAND init CONTROL_STATUS = 317

#  devmem2 0x50000060
/dev/mem opened.
Memory mapped at address 0x40202000.
Read at address  0x50000060 (0x40202060): 0x00000810
#  devmem2 0x48140040
/dev/mem opened.
Memory mapped at address 0x4012d000.
Read at address  0x48140040 (0x4012d040): 0x00000317

the values changed, but nand flash is not yet detected.

One more thing, as i put some log where nand probe is failing.

in drivers/mtd/nand/nand_base.c -> nand_get_flash_type() -> where we read manufacture id and device id,

        /* Read entire ID string */

        for (i = 0; i < 8; i++)
        {
                id_data[i] = chip->read_byte(mtd);
                printk(KERN_INFO"DM385 -> id_data[%d] -> %02x\n",i,id_data[i]);
        }
i got these values, i should get maf,dev ids.

DM385 -> id_data[0] -> 17
DM385 -> id_data[1] -> 17
DM385 -> id_data[2] -> 17
DM385 -> id_data[3] -> 17
DM385 -> id_data[4] -> 17
DM385 -> id_data[5] -> 17
DM385 -> id_data[6] -> 17
DM385 -> id_data[7] -> 17

it is failing

 if (!type->name) // i checked type->name is null
                return ERR_PTR(-ENODEV);

thanks & regards,

Ganesh

Ganesh Biradar said:

One more thing, as i put some log where nand probe is failing.

in drivers/mtd/nand/nand_base.c -> nand_get_flash_type() -> where we read manufacture id and device id,

Do you mean the below NAND probe function is failing?

linux-kernel/drivers/mtd/nand/omap2.c

 omap_nand_probe(struct platform_device *pdev)

What is the kernel log you have there? On DM814x TI EVM I have:

omap2-nand driver initializing
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron NAND 256MiB 3,3V 16-bit)
omap2-nand: detected x16 NAND flash
Creating 6 MTD partitions on "omap2-nand.0":

Regards,
Pavel

Hi Pavel Botev ,

following is my kernel log.

omap2-nand driver initializing
No NAND Device found
No NAND Device found

yes it is failing in nand probe, >>>>>>>> line +1261 nand_scan_ident <<<<<<<<<<<<<

thanks & regards,
Ganesh

Ganesh Biradar said:

in drivers/mtd/nand/nand_base.c -> nand_get_flash_type() -> where we read manufacture id and device id,

        /* Read entire ID string */

        for (i = 0; i < 8; i++)
        {
                id_data[i] = chip->read_byte(mtd);
                printk(KERN_INFO"DM385 -> id_data[%d] -> %02x\n",i,id_data[i]);
        }
i got these values, i should get maf,dev ids.

DM385 -> id_data[0] -> 17
DM385 -> id_data[1] -> 17
DM385 -> id_data[2] -> 17
DM385 -> id_data[3] -> 17
DM385 -> id_data[4] -> 17
DM385 -> id_data[5] -> 17
DM385 -> id_data[6] -> 17
DM385 -> id_data[7] -> 17

it is failing

On my side, the flow does not execute "Read entire ID string" code. Before that, it check for ONFI NAND (nand_flash_detect_onfi), which return 1 and then goto ident_done.

What value you have in ret after the below code (I have 1)?

ret = nand_flash_detect_onfi(mtd, chip, &busw);

What value you have in *maf_id and id_data[0]? I have 0x2C, which is the correct value when check in the Micron NAND datashet.

What value you have in *dev_id and id_data[1]? I have 0xCA, which is the correct value when check in the Micron NAND datashet.

/* Send the command for reading device ID */
    chip->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);

    /* Read manufacturer and device IDs */
    *maf_id = chip->read_byte(mtd);
    *dev_id = chip->read_byte(mtd);

chip->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);

    for (i = 0; i < 2; i++)
        id_data[i] = chip->read_byte(mtd);

Hi Pavel Botev ,


DM385 -> nand_get_flash_type: ID read maf_id -> 17,dev_id-> 17 //these what i got my side

i have already mention that it is not able to read proper maf & dev id. check 3/4 reply post back. following is the link.

e2e.ti.com/.../1946385

Ganesh,

And what are the Manufacture ID and Device ID in your NAND chip datasheet? Are they both 17?

Regards,
Pavel

Do you check if NAND pimux is correct? Not being able to read correct info from the NAND chip through the GPMC/NAND pins might be caused by wrong pinmux.

Regards,
Pavel

Hi Pavel Botev ,

please check below information:

maf_id is 0x01, dev_id is 0xF1.

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_cs0
name: gpmc_cs0.gpmc_cs0 (0x481409e4/0x9e4 = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_cs0 | NA | NA | NA | NA | NA | NA | gpio1_23

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad0
name: gpmc_ad0.gpmc_ad0 (0x48140960/0x960 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad0 | NA | NA | NA | NA | NA | NA | boot0

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad1
name: gpmc_ad1.gpmc_ad1 (0x48140964/0x964 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad1 | NA | NA | NA | NA | NA | NA | boot1

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad2
name: gpmc_ad2.gpmc_ad2 (0x48140968/0x968 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad2 | NA | NA | NA | NA | NA | NA | boot2

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad3
name: gpmc_ad3.gpmc_ad3 (0x4814096c/0x96c = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad3 | NA | NA | NA | NA | NA | NA | boot3

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad4
name: gpmc_ad4.gpmc_ad4 (0x48140970/0x970 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad4 | NA | NA | NA | NA | NA | NA | boot4

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad5
name: gpmc_ad5.gpmc_ad5 (0x48140974/0x974 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad5 | NA | NA | NA | NA | NA | NA | boot5

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad6
name: gpmc_ad6.gpmc_ad6 (0x48140978/0x978 = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad6 | NA | NA | NA | NA | NA | NA | boot6

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ad7
name: gpmc_ad7.gpmc_ad7 (0x4814097c/0x97c = 0x50001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DIS | TI81XX_MUX_MODE0
signals: gpmc_ad7 | NA | NA | NA | NA | NA | NA | boot7

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_wait0
name: gpmc_wait0.gpio1_31 (0x48140a10/0xa10 = 0x60080), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE7
signals: gpmc_wait0 | gpmc_a_26_mux2 | NA | NA | NA | xdma_evt_0_mux0 | NA | gpio1_31

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_wen
name: gpmc_wen.gpmc_wen (0x48140a04/0xa04 = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_wen | NA | NA | NA | NA | NA | NA | NA

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_oen_ren
name: gpmc_oen_ren.gpmc_oen_ren (0x48140a00/0xa00 = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_oen_ren | NA | NA | NA | NA | NA | NA | NA

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_ben0
name: gpmc_ben0.gpmc_ben0 (0x48140a08/0xa08 = 0x40001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_DOWN | TI81XX_MUX_MODE0
signals: gpmc_ben0 | gpmc_a_25_mux2 | NA | NA | NA | xdma_evt_2_mux0 | timer6_mux3 | gpio1_29

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_advn_ale
name: gpmc_advn_ale.gpmc_advn_ale (0x481409fc/0x9fc = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_advn_ale | gpmc_cs6 | NA | NA | NA | NA | timer5_mux3 | gpio1_28

Regards
Ganesh

Ganesh Biradar said:

maf_id is 0x01, dev_id is 0xF1.

You mean that these are the values in the NAND chip datasheet, but you have 0x17 in linux kernel?

Ganesh Biradar said:

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux

I will check the pinmux. Meanwhile I would suggest you to attach oscilloscope on the DM385 GPMC pins and to check there is the expected activity when you send/receive commands/info from the external NAND chip.

Note that there is HW diagnostic NAND test for DM814x TI EVM, you might adjust it for your custom board to check if the NAND hardware is fine.

SOFTWARE -> Diagnostic software -> BaseBoard -> RevD -> src -> CCS_Test_code -> Base_Board -> NAND

PG2.1_readme.txt

This CCS test application validates the NAND-Flash for its ability to perform write access; read access and data storing ability. The test application writes
a known pattern into the desired number of pages and then reads back the same. The known  pattern written into the memory is the incremental hexadecimal numbers. After writing to the entire memory area, this application reads them back and validates  the data read. If the data read does not match the expected pattern, this test  is declared failed. It is declared pass otherwise.

Hi Pavel Botev ,

This excerpt i got from spansion datasheet,

For the S34ML01G1 device, four read cycles sequentially output the manufacturer code (01h), device id (F1h), 3rd cycle (00h), and 4th cycle ID of 1Dh respectively.

i will see through the link you have sended me.

One more thing,

I have started adding nand support in uboot also, as you said by default uboot is using x16 bit, while checking

./arch/arm/include/asm/arch-ti81xx/cpu.h

/* This gives the buswidth of the booting device */

#define SYSBOOT_BW_POS          (16) --> I came across what happen if i change 16 to 8, will it will take default x8 bit or not.

NOTE: in uboot also we have not got NAND support.

regards,
Ganesh

Ganesh Biradar said:

root@DM385_IPNC:~# cat /sys/kernel/debug/omap_mux/gpmc_wait0
name: gpmc_wait0.gpio1_31 (0x48140a10/0xa10 = 0x60080), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE7
signals: gpmc_wait0 | gpmc_a_26_mux2 | NA | NA | NA | xdma_evt_0_mux0 | NA | gpio1_31

On the DM814x TI EVM, this gpmc_wait0 signal is used (not gpio1_31). What about the IPNC ref design, can you check there? Can you try with this gpmc_wait0 signal used on your custom board?

Regards,
Pavel

Ganesh,

Ganesh Biradar said:

#define SYSBOOT_BW_POS          (16) --> I came across what happen if i change 16 to 8, will it will take default x8 bit or not.

No, I do not think this will switch from 16-bit data bus to 8-bit data bus.

This is the bit position in the CONTROL_STATUS register ([16] BW), not 16-bit/8-bit data bus configuration.

#define SYSBOOT_BW_POS        (16)
#define SYSBOOT_BW_MASK        (BIT(SYSBOOT_BW_POS))

bw = __raw_readl(CONTROL_STATUS) & (SYSBOOT_BW_MASK);
bw >>= SYSBOOT_BW_POS;

Regards,
Pavel

Hi Pavel Botev ,

cat /sys/kernel/debug/omap_mux/gpmc_wait0
name: gpmc_wait0.gpmc_wait0 (0x48140a10/0xa10 = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_wait0 | gpmc_a_26_mux2 | NA | NA | NA | xdma_evt_0_mux0 | NA | gpio1_31

even after making changes, No NAND device found.

NAND in u-boot: how do i set x8 support in uboot.

regards,
Ganesh

Ganesh Biradar said:

cat /sys/kernel/debug/omap_mux/gpmc_wait0
name: gpmc_wait0.gpmc_wait0 (0x48140a10/0xa10 = 0x60001), b NA, t NA
mode: TI814X_PIN_INPUT_PULL_UP | TI81XX_MUX_MODE0
signals: gpmc_wait0 | gpmc_a_26_mux2 | NA | NA | NA | xdma_evt_0_mux0 | NA | gpio1_31

even after making changes, No NAND device found.

The proper pinmux of the DM385 GPMC pins is not enough, you should also have physical connection between DM385 GPMC pins and external NAND chip pins.

Regards,
Pavel

Hi Pavel Botev ,

"The proper pinmux of the DM385 GPMC pins is not enough, you should also have physical connection between DM385 GPMC pins and external NAND chip pins."

yes i have checked schematics and based on that only i made change to gpmc_wait to r/b.

regards,
Ganesh

Ganesh Biradar said:

NAND in u-boot: how do i set x8 support in uboot.

You can explore the gpmc_set_cs_buswidth() function from the below u-boot files:

u-boot/arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c ->  get_sysboot_ipnc_bw()

u-boot/board/ti/dm385_ipnc/evm.c -> board_init()

u-boot/arch/arm/cpu/arm_cortexa8/ti81xx/mem.c -> gpmc_set_cs_buswidth()

See also the below file/function:

u-boot/drivers/mtd/nand/ti81xx_nand.c -> board_nand_init()

Hi Pavel Botev,

Well the problem which i faced in kernel same problem i'm facing in u-boot also.

NAND:  HW ECC BCH8 Selected
DM385 -> 1 : busw: 0
DM385 -> nand_get_flash_type: ID read 17,17 ------------------------------------->[maf_id & dev_id]
DM385 -> nand_get_flash_type: ID 17,17 against 17,17
0 MiB

1 -> In arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c

u32 get_sysboot_ipnc_bw(void) -> making sure only x8 mode is supported

bw = __raw_readl(CONTROL_STATUS) & (SYSBOOT_IPNC_BW_MASK);
        bw >>= SYSBOOT_IPNC_BW_POS;
        if (bw == 0)    /* 16-bit nand if BTMODE BW pin on board is ON */
        {
                 return 0;/* x8 bit NAND mode*/
        }
        else if (bw == 1)/* 8-bit nand if BTMODE BW pin on board is OFF */
        {
                return 0;
        }

2-> cs = 0;

But still i'm unable to get x8 support nor it is able to read properly perform READ ID.

Ganesh,

Regarding maf_id/dev_id issue, the same debug suggestions like for linux kernel are valid here also in u-boot.

Regarding x8 NAND issue, can you provide me the exact steps you are doing to switch from 16-bit NAND to 8-bit NAND?

Regards,
Pavel

Hi Pavel Botev,

only change i made is

In arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c

u32 get_sysboot_ipnc_bw(void) -> making sure only x8 mode is supported

bw = __raw_readl(CONTROL_STATUS) & (SYSBOOT_IPNC_BW_MASK);
        bw >>= SYSBOOT_IPNC_BW_POS;
        if (bw == 0)    /* 16-bit nand if BTMODE BW pin on board is ON */
        {
                 return 0;/* x8 bit NAND mode*/      ----------------------------------> earlier it was return 1;
        }
        else if (bw == 1)/* 8-bit nand if BTMODE BW pin on board is OFF */
        {
                return 0;
        }

that's it.

regards,

ganesh

Ganesh,

This code is based on the CONTROL_STATUS[16] BW bit value, which depends on the BTMODE[12]/R3 pin value. And I do not think your hack is proper. You should double check the BTMODE[12] pin settings.

At reset, BTMODE[12] is sampled to determine the GPMC CS0 bus width:
0 = 8-bit data bus
1 = 16-bit data bus



Regards,
Pavel

Also in linux kernel, you stated that CONTROL_STATUS[16] BW = 0, but now in u-boot you have CONTROL_STATUS[16] BW = 1?