DM365 EVM: Change NAND settings in Linux Kernel

Hi Sean,

Depending on how the NAND chip is interfaced other informations such as mask_chipsel, mask_ale, mask_cle also should be modified. Have you tried modifying them? These are passed from "struct davinci_nand_pdata" of arch/arm/mach-davinci/board-dm365-evm.c file.

Regards, Sudhakar

Hi Sudhakar

I have not changed the mask_chipsel, mask_cle or mask_ale values as I am new to this and have no clue what they would need to be changed to. I know that the existing NAND chip uses 2 chip selects and that the new one uses 1 chip select and I had to make a change to uBoot to get this working.

I have changed the ecc_mode in arch/arm/mach-davinci/board-dm365-evm.c from NAND_ECC_HW to NAND_ECC_HW_OOB_FIRST as that made sense from reading various c file it seemed to be the correct setting.  It is also what I have done for uBoot which is working.

static struct davinci_nand_pdata davinci_nand_data = {
        .mask_chipsel           = BIT(14),
        .parts                  = davinci_nand_partitions,
        .nr_parts               = ARRAY_SIZE(davinci_nand_partitions),
        .ecc_mode               = NAND_ECC_HW_OOB_FIRST,
        .options                = NAND_USE_FLASH_BBT,
        .ecc_bits               = 4,
};

What I do not know is what to change mask_chipsel to to set it to use 1 chip select.  There is no mask_cle or mask_ale defined so it appears to be using the defaults defined in arch/arm/mach-davinci/include/mach/nand.h which are:

#define MASK_ALE                0x08
#define MASK_CLE                0x10

Ultimately I would like to boot using this NAND but I do not know what to lookup in the Micron literature to see what these values should be changed to if required.  As I am able to flash the device with the UBL and a custom compiled uBoot using the standard tools provided in the DVSDK 3.10 and get everything to boot correctly I assume that it is properly supported and working correctly.

How do I figure out what data is being read that is then being referenced by the line BIT(14) and what should I look at to figure out if the ALE & CLE masks need to change.  My gut feel is that the mask_chipsel is wrong as there are only one chip selects used for the new device versus 2 for the old and I did need to change this in uBoot to get it to stop giving an error about the NAND not being found.

Any help or pointers would be greatly appreciated.

Regards
Sean

Sean,

You can try by removing the ".mask_chipsel " initialization line from the davinci_nand_data structure. MASK_ALE and MASK_CLE will be proper because even U-Boot uses the same values.

Regards, Sudhakar

Hi Sudhakar

I have tried removing the ".mask_chipsel" line from the structure definition but it does not seem to make any difference.  I did some digging and added some printk lines to the platform_match function in drivers/base/platform.c and found a difference in the driver probing output.  Using the original NAND I get the following driver matches being performed:
edma
davinci_emac
vpss
dm3xx_ipipeif
dm365_isif
vpfe-capture
davinci_osd
davinci_venc
i2c_davinci
serial8250
musb_hdrc
davinci_mmc
davinci_nand

Using the new NAND I get the following output:
edma
davinci_emac
vpss
dm3xx_ipipeif
dm365_isif
vpfe-capture
davinci_osd
davinci_venc
i2c_davinci
serial8250
musb_hdrc
davinci_mmc
<<< davinci_nand should be here but it is missing, platform_driver_probe returns -19 (device not found) after this list>>>
davinci-asp
rtc_davinci
davinci_keyscan
spi_davinci
watchdog
regulatory
nop_usb_xceiv
davincifb
davinci_previewer
davinci_resizer
serial8250

Based on my limited kernel knowledge it appears that the davinci_nand driver is not linking correctly (excuse the terminology) to the new NAND.  I took a look in arch/arm/mach-davinci/board-dm365-evm.c but I do not see anything in the NAND setup that obviously needs to be changed.  I have however seen the following defined there but I do not know if this needs to be changed or not.

static struct resource davinci_nand_resources[] = {
        {
                .start          = DM365_ASYNC_EMIF_DATA_CE0_BASE,
                .end            = DM365_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
                .flags          = IORESOURCE_MEM,
        }, {
                .start          = DM365_ASYNC_EMIF_CONTROL_BASE,
                .end            = DM365_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
                .flags          = IORESOURCE_MEM,
        },
};

static struct platform_device davinci_nand_device = {
        .name                   = "davinci_nand",
        .id                     = 0,
        .num_resources          = ARRAY_SIZE(davinci_nand_resources),
        .resource               = davinci_nand_resources,
        .dev                    = {
                .platform_data  = &davinci_nand_data,
        },
};

From my current understanding it appears that because this step fails the actual changes being made to the davinci_nand.c and related files is not being executed as the system does not believe there is a NAND chip on the board.

Thanks for the help so far, I really appreciate it.

Regards
Sean

After a bit more digging it appears that something is not being detected correctly by platform_probe.  This function is executed first, then platform_driver_register and then the platform_match is done.

Any ideas what I should be looking at to determine why the probe is failing.

Hi，Sean Preston

   We have also meet this problem, Because of the Nand flash  MT29F16G08FAA of DM365 EVM have been stop production, so we want to using MT29F16G08ABABA to replace it.  Including your modify in U-boot, we can found Nand and down kernel and filesystem.

  And the nand flash also cannot  be detected in kernel.

 We have not modify UBL source of nand, can you give me some advices of it.

 In the following, we plan to modify kernel dirvers to support nand of MT29F16G08ABABA, we can communicate the progress each other.

I'm also advice  that TI can modify the dirvers to support other nands to replace MT29F16G08FAA, because it's stop production.

Thanks a lot.

Hi Gomo

As far as I am aware there is no need to edit the UBL source as you are able to write the UBL and uBoot and when the device boots it successfully loads the UBL, uBoot and Kernel.

The issue now is to get it working with the Kernel.  From my playing around and some info provided by others I understand that the hardware is defined as a part of the board-dm365.evm.c file but there is no output from that section of code if you add printk lines which I assume is because the serial output is not working at that point.  So now I am looking into how to debug the kernel startup process.  What I do know is that when the kernel starts and drivers are loaded, something is causing an error so the davinci_nand driver is not loaded.  Then when the platform_match is done later the driver can not be found and thus never executes the davinci_nand driver stuff so the MTD device is never created.

I would love any help you may be able to provide, otherwise lets just keep posting the info we do have until we are able to get it working.

Regards
Sean

Hi Sean：

             I use flash is MT29F16G08ABABA, and can boot from SD card and download kernel and filesystem, and the kernel also can detect the nand and show the nand partition table, but we can not boot from nand flash, and UBL can not copy uboot and have  display  nothing.

            And I search forum and fond a issue http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/42223/168910.aspx#168910, it said MT29F16G08ABABA is rather new and supports ONFI2.1, But DM365 ROM bootloader (RBL) doesn't support ONFI detection. So we will buy  new MT29F8G08ABABA  chips to try it.

           We can communicate each other through E-mail, My address is guoyj@daheng-image.com.

          Thanks you very much.

Hi Sean,

Sean Preston said:

What I do know is that when the kernel starts and drivers are loaded, something is causing an error so the davinci_nand driver is not loaded.

The first place to start looking is to make sure the probe function of davinci_nand driver - nand_davinci_probe() in drivers/mtd/nand/davinci_nand.c is getting called during the boot sequence. You can insert a print statement at the very begining of this function to ascertain this.

Thanks,

Sekhar

Hi Sekhar：

    Sean use nand flash is MT29F8G08ABABA and our project  use MT29F16G08ABABA, and he can boot from nand flash but I'm not.

Features of MT29F16G08ABABA
• Open NAND Flash Interface (ONFI) 2.1-compliant1
• Single-level cell (SLC) technology
• Organization
– Page size x8: 4320 bytes (4096 + 224 bytes)
– Block size: 128 pages (512K +28K bytes)
– Plane size: 2 planes x 2048 blocks per plane
– Device size: 16Gb: 4096 blocks;
32Gb: 8192 blocks;
64Gb: 16,384 blocks;
128Gb: 32,768 blocks 

and READ ID Parameter Tables
Table 6: Read ID Parameters for Address 00h
Device                       Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
MT29F16G08ABABA 2Ch    48h    00h     26h      89h     00h    00h     00

Features of MT29F8G08ABABA
• Open NAND Flash Interface (ONFI) 2.1-compliant
• Single-level cell (SLC) technology
• Organization
– Page size x8: 4320 bytes (4096 + 224 bytes)
– Block size: 128 pages (512K +28 K bytes)
– Plane size: 2 planes x 1024 blocks per plane
– Device size: 8Gb: 2048 blocks

and READ ID Parameter Tables
Table 5: Read ID Parameters for Address 00h
Device                    Byte 0  Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
MT29F8G08ABABA 2Ch   38h      00h      26h    85h      00h      00h   00h

I compared the two datesheet of nand flash. The only difference is the value of Byte1, one is 0x48, the other is 0x38. Is it the reason that it cannot boot from the nand MT29F16G08ABABA? Are you sure that it cannot boot from this type of nand?  We want to know the exactly answer and modify our scheme in time.

Wish your reply!  Thanks a lot.

Hi

gomo said:

I compared the two datesheet of nand flash. The only difference is the value of Byte1, one is 0x48, the other is 0x38. Is it the reason that it cannot boot from the nand MT29F16G08ABABA? Are you sure that it cannot boot from this type of nand?  We want to know the exactly answer and modify our scheme in time.

Byte 0 is the manufacturer ID which is Micron (0x2c) in this case and byte 1 is the chip ID. The original part has ID 0xd3 which you will find in drivers/mtd/nand/nand_ids.c so you will need to add the relevant entry to this table for this chip to be recognised.  In my info for uBoot this was one of the changes that I listed which you will need to change.

The other important thing is that my part is a 1GB NAND and has 1 chip enable and 1 die whereas the old part has 2 chip enables and 4 dies.  The chip enables was the other change I needed to make.  You will need to check what the details are of your chip to see if you need these changes or not.

Hope that helps.

Regards
Sean

Hi Sean：

          Thanks a lot for your reply at first.

            using nand flash of MT29F16G08ABABA, we can boot from SD card and download kernel and filesystem, and the kernel also can detect the nand and show the nand partition table, but we can not boot from nand flash, and UBL have  display  nothing.

            Tha nand of MT29F16G08ABABA also has 1 chip enable and 1 die, the same with yours. The old part have 2 chip enables and 4 dies and Our hardware engineer told me that it only using 1 chip enables and 2 dies.

Sean Preston said:

  The chip enables was the other change I needed to make.  You will need to check what the details are of your chip to see if you need these changes or not.

         I have not idea to modify to change chip enables. Can you tell me where and how to modify? UBL or U-boot source?

Hi Sean：

          Thanks a lot for your reply at first.

            using nand flash of MT29F16G08ABABA, we can boot from SD card and download kernel and filesystem, and the kernel also can detect the nand and show the nand partition table, but we can not boot from nand flash, and UBL have  display  nothing.

            Tha nand of MT29F16G08ABABA also has 1 chip enable and 1 die, the same with yours. The old part have 2 chip enables and 4 dies and Our hardware engineer told me that it only using 1 chip enables and 2 dies.

Sean Preston said:

  The chip enables was the other change I needed to make.  You will need to check what the details are of your chip to see if you need these changes or not.

         I have not idea to modify to change chip enables. Can you tell me where and how to modify? UBL or U-boot source?

FYI,

We are using a 512MB Micron part ID = 0xDC.  The linux kernel kept telling me I had two nand chips and my last partition extended to 1024MB.  After changing .mask_chipsel to equal zero the kernel no longer says I have two nands and shows the last partition ending at 512MB.

John A          

Sean,

I'm able to get the same micron part working with U-Boot and the recognized by Linux kernel.  However, I'm having issues with the Bad Block Table (BBT).  Did you ever get this NAND chip working?

Thanks.

Hi

We got the NAND working in Linux with the BBT butnot in uBoot but I think that was to do with the version of uBoot in the DVSDK.  In the end we dropped the NAND as it was too unreliable and even with the BBT working we had lots of corruption taking place which resulted in us losing everything on the NAND chip.  We had this problem with the EVM NAND chip as well.  In the end we used an SD card and are currently getting serial flash working which we are planning to use for the uBoot etc.

Sorry this is not the answer you are looking for.

Regards
Sean

Sean,

Thanks so much for the reply.  Would you be able to post the details (or source) for davinci_nand.c (any mods?) and how you erased the flash?  I've had to modify mtd-utils to allow for the OOB size of this Micron Chip (128 bytes).

I can erase the chip successfully (at least, I think so) but I'm unable to write anything to it successfully.  nandtest utility fails, as well as JFFS2 file system.

Thanks,

JTT