Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 2743 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

omap2 NAND Driver: BCH page read

Andrea Scian
Intellectual 1000 points
Other Parts Discussed in Thread: AM3352

Dear All,

I'm working with different TI cortex-A8 platform (DM8148, AM335x, AM35xx) and all of the uses the driver/mtd/nand/omap2.c driver for the integrated NAND controller.

I've found some issue with some Spansion NANDs that should be compatible with other Samsung parts (we also use Micron too) that the already use without problems on the same products.

Getting deeper into the code to find the bug, I've found an issue withing the hardware ecc page read, found in variuos kernel.

For example in 2.6.37 (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary) and 3.1/3.2 (http://arago-project.org/git/projects/?p=linux-am33x.git) official kernel (for dm8148 and am33x plarform) there's an error (correct me if I'm wrong) in omap_read_page_bch().

In particular the command NAND_CMD_RNDOUT is used in the wrong way: by reading the datasheet of nearly every nand, first we must send the command to read the whole page and later send the "random access read" command withing this page. In the code of the two kernels above the page read command is never send, while into the "random access" command is send the page address too.

We look at the bus (but the source code confirm this) with a logical analizer and see that this give a transaction that's wrong, compared to the one described into the datasheet

The function can be fixed pretty easily, but I'm looking for an "official" solution.

By looking at some other kernel repositories I've found that:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/omap2.c?id=62116e5171e00f85a8d53f76e45b84423c89ff34

  • into the git.ti.com 3.8 tree, it seems that we have a completely different implementation (at the moment of writing, I'm still trying to understand if this driver is correct or not)

http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master/drivers/mtd/nand/omap2.c

Is there any other place to look for a "official" kernel tree?

Has anybody have an experience like this on some "omap2" nand driver based platform?

Has someone, hopefully in TI itself, has a fix (or want to write a fix, I can help in this, in writing and/or testing) for this issue?

Thanks in advance for any feedback and Best Regards,

Andrea

  • 0
    Prodigy 20 points

    Hi Andrea,

    I don't know exactly what is your problem but we have trouble with a Spansion NAND (S34ML04G1) as well. We have some boards with am3352 + Samsung NAND + 3.2 kernel from Angstrom ND it works fine. On the boards with the Spansion NAND, UBIFS is not happy (see below) and mtd tests torture and subpagetest are printing some error messages.

    <snip for UBIFS problem>

    [   26.047902] UBI: run torture test for PEB 3964
    [   26.171187] UBI error: torture_peb: read problems on freshly erased PEB 3964, must be bad
    [   26.179786] UBI error: erase_worker: failed to erase PEB 3964, error -5
    [   26.186724] UBI: mark PEB 3964 as bad
    [   26.191174] UBI: 37 PEBs left in the reserve 

    <snip>

    Like you I would welcome a fix for this issue as looking at omap2.c from 3.10 does not give any clue.

    Kind regards,

    Christophe

  • 0 in reply to Christophe Levantis
    Prodigy 65 points

    Hello All,

    Spansion has recently released both Linux and u-boot patches that will help permanently fixing the issue you are facing here. These patches are posted to Spansion's webpage.

    Just FYI,  here is a short description of the issue:

    The issue is mainly due to a NAND protocol violation in the omap driver since the Random Data Output command (05h-E0h) expects to see only the column address that should be addressed within the already loaded read page into the read buffer. Only 2 address cycles with ALE active should be provided between the 05h and E0h commands. The Page read command expects the full address footprint (2bytes for column address + 3bytes for row address), but once the page is loaded into the read buffer, Random Data Output should be used with only 2bytes for column address.

    These patches can be found here: http://www.spansion.com/Support/Pages/DriversSoftware.aspx

    - u-boot patch: http://www.spansion.com/Support/Software/u-boot-psp-04.04.00.01-NAND.zip

    - Linux Patch: http://www.spansion.com/Support/Software/linux-psp-04.04.00.01-NAND.zip

    Thanks!

    Best regards,

    Bacem Daassi

    Spansion Inc. - Application Engineering

  • 0 in reply to Bacem Daassi
    Intellectual 1000 points

    Dear Bacem,

    thanks for publish those patch officially in your site.

    I've integrated them in my source code and it work perfecty.

    Please only note that I also need to apply the following patch (which is already integrated into the newest kernels) to solve a problem in the Nand manuf/id printout


    diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
    index a796dd7..6caf219 100644
    --- a/drivers/mtd/nand/nand_base.c
    +++ b/drivers/mtd/nand/nand_base.c
    @@ -3162,7 +3162,7 @@ ident_done:
    printk(KERN_INFO "NAND device: Manufacturer ID:"
    " 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, *dev_id,
    nand_manuf_ids[maf_idx].name,
    - chip->onfi_version ? type->name : chip->onfi_params.model);
    + chip->onfi_version ? chip->onfi_params.model : type->name);

    return type;
    }

    Best Regards,

    Andrea