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

Question

Accepted Answer

[#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