[#3825] BF54x NFC Driver calculating ECC for 512 bytes pagesize has a bug

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#3825] BF54x NFC Driver calculating ECC for 512 bytes pagesize has a bug

Submitted By: Bryan Wu

Open Date

2008-01-13 06:26:58     Close Date

2008-02-01 04:01:50

Priority:

Medium     Assignee:

Bryan Wu

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

Category:

N/A     Board:

N/A

Processor:

N/A     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

App binary format:

N/A     

Summary: BF54x NFC Driver calculating ECC for 512 bytes pagesize has a bug

Details:

 

Hello Volodymyr,

 

I have made the NAND programming, now I want to implement the HW ECC considering the linux driver, however it seem buggy to me - do I miss something or it is really not correct. Please tell me your comments if you have already used the NFC HW ECC calculation in you project.

 

This is the very function:

 

static int bf5xx_nand_calculate_ecc(struct mtd_info *mtd,

        const u_char *dat, u_char *ecc_code)

{

    struct bf5xx_nand_info *info = mtd_to_nand_info(mtd);

    struct bf5xx_nand_platform *plat = info->platform;

    u16 page_size = (plat->page_size ? 512 : 256);

    u16 ecc0, ecc1;

    u32 code[2];

    u8 *p;

    int bytes = 3, i;

 

    /* first 4 bytes ECC code for 256 page size */

    ecc0 = bfin_read_NFC_ECC0();

    ecc1 = bfin_read_NFC_ECC1();

 

    code[0] = (ecc0 & 0x3FF) | ((ecc1 & 0x3FF) << 11);            // <------------ look this

 

    dev_dbg(info->device, "returning ecc 0x%08x\n", code[0]);

 

    /* second 4 bytes ECC code for 512 page size */

    if (page_size == 512) {

        ecc0 = bfin_read_NFC_ECC2();

        ecc1 = bfin_read_NFC_ECC3();

        code[1] = (ecc0 & 0x3FF) | ((ecc1 & 0x3FF) << 11);    // <------------ look this

        bytes = 6;

        dev_dbg(info->device, "returning ecc 0x%08x\n", code[1]);

    }

 

    p = (u8 *)code;                            // <------------ look this

    for (i = 0; i < bytes; i++)

        ecc_code[i] = p[i];

 

    return 0;

}

 

I think that the function written in this way, stores the ecc in the lowest 3 bites of the code[] 0 and 1 elements, but latter the first 6 bytes of the byte-converted array are copied, this makes that the last meaningful ecc byte is lost, instead an always-zero byte is got - the highest byte of code[0].

 

Regards,

Tito.

 

 

Follow-ups

 

--- Bryan Wu                                                 2008-01-14 04:10:46

It should be fixed in svn trunk head.

 

-Bryan

 

--- Bryan Wu                                                 2008-02-01 06:07:14

fixed, so close it.

 

-Bryan

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes