NAND device unrecognized with an Update Error 0xffffffea(-22)

[RohanSingh]

Hi,

I am trying to use MfgTool to flash Linux image to the NAND and boot from NAND on IMX28 EVK board. But the process halts and does not respond after throwing an error Updater Error 0xffffffea (-22) - , attached is a log of events. Which shows that NAND device is not recognized and the process could not proceed further. I am using Micron’s 29F2G08ABAEA WP chip as NAND device, attached is the data sheet for the same.

My question is, how can I update the Mfgtool / Updater.sb files to be able to detect my NAND device and flash it. What are the changes I need to make and how can I build it. Any resources/guidance would greatly help me.

Say that if somehow I was able to flash the Linux image to the NAND device, then what are the chances that my NAND device would be detected by the Imx28 on chip ROM boot code and would be able to boot from the NAND device (provided the boot settings are set to boot from NAND). Is there any way to tell the on chip ROM boot code to detect my NAND device. Is the boot code in internal ROM capable of reading from any NAND device or only specific NAND devices.

Request you to please provide your inputs on the above queries.

[AugustoLanari]

Hi,

I've a 29F2G08ABAEA as well on an mx53 board.

I've already added the flash definition in nand_device_info both in kernel and u-boot, and generated the MFG bootloader/kernel/initramfs for Freescale MFG Tool.

The problem is that programming the nand by Freescale MFG Tool, only the bootloader is correctly written, for the kernel I have CRC error.

At the moment I workarounded this by rewriting kernel and rootfs via u-boot and tftp.

After this I have no CRC error and the board is able to boot and the nand (on which rootfs is written) does not show any problem.

Any idea?

It seems an issue related on how the MFG Tool sends the binaries to the MFG kernel (probably a corruption during transfer?)

Regards,

Augusto

[dingram1z]

Hi Rohan:

I am able to successfully flash and boot using a Micron MT29F4G08ABADA NAND WP Flash chip, which seems to have the same specs and technology as your target chip.  I am able to program the device installed in the i.MX28 EVK NAND flash socket over the micro USB connector link from a Windows PC running the Freescale Manufacturing Tool.  I am then able to boot the EVK from NAND flash to load a custom Linux kernel and UBIFS root filesystem.

Getting the NAND chip to be recognized during the kernel boot scan and programming the chip via the Mfg Tool are independent operations, and both must be successful.  Since the output you sent is generated from running the Mfg Tool, perhaps you should start there and continue until the programming is successful.  Then, you can move on to getting the EVK to boot from NAND.

I have compared a capture file of output from the debug terminal during a successful Mfg Tool programing run with yours  I have not looked exhaustively, but our outputs track very closely except for the NAND chip-related items.  The critical difference begins at line 106 in my file:  "Scanning for NAND Flash chips...".  Interestingly, during your run, the next line ("NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit") shows that your NAND chip was detected and the ID's were read correctly.

I believe the Mfg Tool "updater_ivt.sb" kernel uses the same technique to recognize NAND flash types as works in the "normal" kernel.  The first step is to locate the device in the following array of structures:

    struct nand_flash_dev nand_flash_ids[ ],

which is initialized in the following kernel source file:

    [ drivers/mtd/nand/nand_ids.c ]

Your chip ID (0xDA) matches the following entry:

    /* 2 Gigabit */

    {"NAND 256MiB 3,3V 8-bit", 0xDA, 0, 256, 0, LP_OPTIONS},

whereas my chip ID (0xDC) matches the entry in the next size block:

    /* 4 Gigabit */

    {"NAND 512MiB 3,3V 8-bit", 0xDC, 0, 512, 0, LP_OPTIONS},

This matching is how you received single "NAND device:..." output line in your file.

The second step is to locate the device in one of the arrays of structures of the following type:

    struct nand_device_info[ ],

which are initialized in the following kernel source file:

    [ drivers/mtd/nand/nand_device_info.c ]

There are a number of these arrays of structures, corresponding to different "Types", as shown in the following "directory" from the same file:

/*

* A table that maps manufacturer IDs to device information tables.

*/

    static structnand_device_type_info nand_device_type_directory[] __initdata = {

        {nand_device_info_table_type_2, "Type 2"},

        {nand_device_info_table_large_mlc, "Large MLC"},

        {nand_device_info_table_type_7, "Type 7"},

        {nand_device_info_table_type_8, "Type 8"},

        {nand_device_info_table_type_9, "Type 9"},

        {nand_device_info_table_type_10, "Type 10"},

        {nand_device_info_table_type_11, "Type 11"},

        {nand_device_info_table_type_15, "Type 15"},

        {nand_device_info_table_type_16, "Type 16"},

        {nand_device_info_table_bch_ecc12, "BCH ECC12"},

        {nand_device_info_table_bch_ecc24, "BCH ECC24"},

        {0, 0},

    };

In the same file there are functions and logic that locate a particular entry for a specific NAND flash chip.  In my case, my chip is matched to the following entry:

/*

* Type 7

*/

static structnand_device_info nand_device_info_table_type_7[] __initdata = {

< snip >

    {

        .end_of_table = false,

        .manufacturer_code = 0x2c,

        .device_code = 0xdc,

        .cell_technology = NAND_DEVICE_CELL_TECH_SLC,

        .chip_size_in_bytes = 512LL*SZ_1M,

        .block_size_in_pages = 64,

        .page_total_size_in_bytes = 2*SZ_1K + 64,

        .ecc_strength_in_bits = 4,

        .ecc_size_in_bytes = 512,

        .data_setup_in_ns = 20,

        .data_hold_in_ns = 10,

        .address_setup_in_ns = 10,

        .gpmi_sample_delay_in_ns = 6,

        .tREA_in_ns = -1,

        .tRLOH_in_ns = -1,

        .tRHOH_in_ns = -1,

        "MT29F4G08AAA",

    },

< snip >

};

This table is the source of critical information regarding the NAND geometry, timing, etc. that appears in the debug terminal listing when the chip is successfully recognized during the kernel scan.

The matching function for Micron devices in the same file begins with the following:

static struct nand_device_info * __init nand_device_info_fn_micron(constuint8_t id[])

{

    structnand_device_info *table;

    /* Check for an SLC device. */

    if(ID_GET_CELL_TYPE_CODE(id) == ID_CELL_TYPE_CODE_SLC) {

        /* Check number of simultaneously programmed pages. */

        if(ID_GET_MICRON_SIMUL_PROG(id)) {

            /* Type 7 */

            table = nand_device_info_table_type_7;

        }

        else{

            /* Zero simultaneously programmed pages means Type 2. */

            table = nand_device_info_table_type_2;

        }

        returnnand_device_info_search(table, ID_GET_MFR_CODE(id),

        ID_GET_DEVICE_CODE(id));

    }

< snip >

 For my chip, there is an entry in both the "Type 2" and "Type 7" arrays that would seem to match, but the matching function returns the "Type 7" entry.  Your chip seems to appear in the "Type 2" array, but is missing from the "Type 7" array.  Since our chips are very similar and seem to use the same technology, I would expect that the would be of the same "Type".

So, your chip appears to fail to match a "nand_device_info" structure.  I believe that the table used in the "updater" code that runs as part of the Mfg Tool uses the same tables, which would explain the failure to recognize your chip.  It appears that your next step must be to add support for your chip within the context of the Mfg Tool.

Once your chip is recognized, the other major issue you will face is deciding what type of flash filesystem to use.  I am successfully using UBIFS, but JFFS2 is also a widely-used choice.  You will have to make that decision following your own requirements and criteria.

Good Luck,

Darrell

[VladanJovanovic]

You don't have a problem with internal ROM, problem is with the Linux kernel that you need to update to recognize the NAND you are using. Then you would re-use this kernel to also build your own version of updater.sb that you can use to program the board.

So, as you can see from log:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit )
Unrecognized NAND Flash device.

gpmi-nfc gpmi-nfc.0: Chip scan failed

gpmi-nfc: probe of gpmi-nfc.0 failed with error 1

You need to add support for this NAND to linux kernel. This will be needed so you can run it on your board with this NAND device.

Then make a fresh install of LTIB to new folder, select "Manufacturing firmware" profile during first install, apply the NAND patch created above and build updater.sb. Then you'd use this updater instead of the original one that comes with MfgTool to program your NAND.

[RohanSingh]

NAND Datasheet