• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 522 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FLASH OF DM6467

NINGMENG CHEN
Intellectual 895 points

I use nand_flash_writer.out to program NAND FLASH. When I use NAND01GW3B2BN6E, it's OK.

But when I use K9F1G08U0B-PCB0 to replace NAND01GW3B2BN6E, the nand block can't be found.

BUT the flash id of them are same.  Should I change the nand_flash_writer source code?

 

 

  • 0
    TI__Mastermind 37340 points

    I would recommend comparing block and page sizes among these two NAND parts; I believe there was one other customer under another platform that found that despite the device IDs being equal, the parts were actually slightly different.  Modifying the flash writter source code should help in this case.

  • 0 in reply to Juan Gonzales
    Intellectual 895 points

    I use NAND01GW3B2BN6E.

    I config the kernel "NAND Flash device on davinci SOC"

    When the kernel run, the error appear"

    nand_davinci nand_davinci.0: Using 1-bit hardware ECC
    NAND device: Manufacturer ID: 0x20, Chip ID: 0xf1 (ST Micro NAND 128MiB 3,3V 8-bit)
    No oob scheme defined for oobsize 256
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0004000
    [00000000] *pgd=00000000
    Internal error: Oops: 805 [#1]
    Modules linked in:
    CPU: 0
    PC is at nand_scan+0x640/0xa80
    LR is at 0x1
    pc : [<c01b04f0>]    lr : [<00000001>]    Not tainted
    sp : c0457ee8  ip : 60000013  fp : c0457f24
    r10: 00000020  r9 : 000000f1  r8 : c02a4b80
    r7 : c0605000  r6 : c0605180  r5 : 00000001  r4 : 00000000
    r3 : 00000000  r2 : 00000000  r1 : c0456000  r0 : 00000029
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
    Control: 5317F  Table: 80004000  DAC: 00000017
    Process swapper (pid: 1, stack limit = 0xc04561a0)
    Stack: (0xc0457ee8 to 0xc0458000)
    7ee0:                   c026bef0 c0457ef8 0000004e 00000001 c0457f24 c0605180
    7f00: c0680ca0 c028e730 00000001 00000000 00000002 c0680ca0 c0457f74 c0457f28
    7f20: c01b32c4 c01afec0 c00c09ec c02fe028 c028e810 c028e728 c0298674 c029cf44
    7f40: 00000000 c029cf40 c0457f74 c02a4d78 c028e730 c029cf80 c02a4d78 00000000
    7f60: 00000000 00000000 c0457f8c c0457f78 c015f8d8 c01b2e60 c028e738 c02a4d78
    7f80: c0457fac c0457f90 c015f9f4 c015f894 c012e3ec c029cf24 c0456000 c029ced8
    7fa0: c0457fd4 c0457fb0 c015fd00 c015f9ac c002eed8 c0456000 00000000 c002ef28
    7fc0: 00000000 00000000 c0457ff4 c0457fd8 c0032298 c015fc8c 00000000 00000000
    7fe0: 00000000 00000000 00000000 c0457ff8 c004bd58 c0032214 720773f5 c95f3dcc
    Backtrace:
    [<c01afeb0>] (nand_scan+0x0/0xa80) from [<c01b32c4>] (nand_davinci_probe+0x474/0x66c)
    [<c01b2e50>] (nand_davinci_probe+0x0/0x66c) from [<c015f8d8>] (driver_probe_device+0x54/0x74)
    [<c015f884>] (driver_probe_device+0x0/0x74) from [<c015f9f4>] (driver_attach+0x58/0x94)
     r5 = C02A4D78  r4 = C028E738
    [<c015f99c>] (driver_attach+0x0/0x94) from [<c015fd00>] (bus_add_driver+0x84/0x12c)
     r6 = C029CED8  r5 = C0456000  r4 = C029CF24
    [<c015fc7c>] (bus_add_driver+0x0/0x12c) from [<c0032298>] (init+0x94/0x1e0)
    [<c0032204>] (init+0x0/0x1e0) from [<c004bd58>] (do_exit+0x0/0xda0)
     r7 = 00000000  r6 = 00000000  r5 = 00000000  r4 = 00000000
    Code: ea000003 e59f03e4 ebfa67b8 e3a03000 (e5833000)
     <0>Kernel panic - not syncing: Attempted to kill init!

     

     

     

    "NAND device: Manufacturer ID: 0x20, Chip ID: 0xf1 (ST Micro NAND 128MiB 3,3V 8-bit)" seems right.

    but the "No oob scheme defined for oobsize 256" seems wrong? It should be 64?

    What's wrong with it? It can booted with the FLASH. So the hardware should be OK.

  • 0 in reply to NINGMENG CHEN
    TI__Mastermind 37340 points

    when you say 'It can booted with the FLASH', what do you mean?  Have you booted from this flash sucessfully in the past (using u-boot)?

    If you can access the flash memory using nand_flash_writer as implied in your first post, the we can probrably rule out hardware issues (assuming you can still do this); however, you still need to make sure you make the proper changed to u-boot and Linux kernel to support this new NAND device... have you done this yet? 

  • 0 in reply to Juan Gonzales
    TI__Expert 6385 points

    Hello,

    This issue is due to a bug in the core NAND driver on 2.6.10 kernel wherein, while reading the extended id for calculating oob size, it includes a part of 'minimum sequential access time' in the calculation.

    Here is the patch that resolves this issue:

    --- drivers/mtd/nand/nand_base.c@@/main/DaVinci_Linux_Releases_Integration/DM700_Linux_Releases_Integration/6	2007-12-20 17:37:37.000000000 +0530
+++ drivers/mtd/nand/nand_base.c	2009-03-17 17:22:00.000000000 +0530
@@ -2923,7 +2923,7 @@
 			mtd->oobblock = 1024 << (extid & 0x3);
 			extid >>= 2;
 			/* Calc oobsize */
-			mtd->oobsize = (8 << (extid & 0x03)) * (mtd->oobblock / 512);
+			mtd->oobsize = (8 << (extid & 0x01)) * (mtd->oobblock / 512);
 			extid >>= 2;
 			/* Calc blocksize. Blocksize is multiples of 64KiB */
 			mtd->erasesize = (64 * 1024)  << (extid & 0x03);