2009-03-09 06:18:45     HW_ECC in Linux on BF526 functional?

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

2009-03-09 06:18:45     HW_ECC in Linux on BF526 functional?

Marco Reppenhagen (GERMANY)

Message: 70600   

 

Hi!

 

I would like to use HW_ECC on BF526 (0.0)  and wondered about the output to OOB;

No bootrom_ecc is used, because jffs2.

 

Under U-Boot I see no problems - HW_ECC works fine: Correct values and correct OOB-Bytes.

 

If I write something threw MTD-Char-Device into NAND  under Linux,  BB is ok, but  the 6 Bytes for ECC are 0x00 or containing trash! (Look at it using nand dump under u-boot)

 

Then I gave out the return of ecc-register-read: 0x00. Ooops... that not what I would like to see!  These 0x00 are the base for syndrom calculation and -no wonder- the result is 3 times 0x00 written to OOB.

 

After that, I took a look into page-size setup: A hack changed 512 Page sizes to 256...( At the moment a 512page sized NAND will set "0" into NFC_CTL-register. The manual tell me: This should be a "1"...)

 

Now I'm confused: Do somebody use HW-ECC and take a look to what realy happen in the mtd-drivers?

 

Using SW-ECC on u-boot and in linux works fine, but cause a lot CPU-load during use of  MTD....

TranslateQuoteReplyEditDelete

 

 

2009-03-09 06:22:12     Re: HW_ECC in Linux on BF526 functional?

Mike Frysinger (UNITED STATES)

Message: 70601   

 

make sure you're using the latest svn version and not the last release

QuoteReplyEditDelete

 

 

2009-03-10 03:48:41     Re: HW_ECC in Linux on BF526 functional?

Marco Reppenhagen (GERMANY)

Message: 70655   

 

Hi!

 

A took a look about the changes made between our Revision and the latest trunk but I don't think that anything will affect the problem at all. But to be shure I have to take a much closer look, what will take lot more time. The HW-ECC is not compatible with SW-ECC so first I switch U-Boot and Linux to SW-ECC even if it would eat some performance (I have to go on with our project).

 

 

 

To be shure what I'm talking about (Anyone can check it quite fast:)

 

THIS is what Linux writes to OOB using HW-ECC:

 

Page 00040000 dump:

        27 05 19 56 af 06 f6 35  49 af dc 33 00 13 6d 06

        00 00 00 00 00 00 00 00  eb f5 e0 23 05 10 04 00

        62 6f 6f 74 70 61 72 74  79 00 00 00 00 00 00 00

        00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

        00 00 00 80 00 13 6c 7a  00 00 00 00 27 05 19 56

        81 2f 9e 5a 49 af dc 32  00 00 00 40 00 00 00 00

        00 00 00 00 7e e4 05 0b  05 10 06 00 62 6f 6f 74

        73 63 72 69 70 74 00 00  00 00 00 00 00 00 00 00

        00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 38

        00 00 00 00 65 63 68 6f  20 62 6f 6f 74 20 66 72

        6f 6d 20 6e 61 6e 64 2e  2e 2e 0a 69 6d 78 74 72

        61 63 74 20 31 32 30 30  30 30 30 20 31 20 31 30

        30 30 30 30 30 0a 62 6f  6f 74 6d 0a 27 05 19 56

        2e 1f 62 47 49 af d9 01  00 13 6c 3a 00 00 10 00

        00 23 aa 88 58 2f 3c 33  05 10 02 01 4c 69 6e 75

        78 2d 32 2e 36 2e 32 36  2e 35 2d 41 44 49 2d 32

        30 30 39 52 31 2d 70 72  65 2d 67 64 1f 8b 08 00

        00 d9 af 49 02 03 ac bd  0b 5c 54 d5 f6 38 be 67

        60 66 ce 0c 07 38 83 a3  73 50 94 01 5f 03 28 e7

        70 b4 44 eb 16 0f c9 89  54 06 04 54 32 3b 08 0a

        19 86 75 bb 37 eb d6 0d  b1 d4 bc 2f c6 c9 b4 37

        60 99 95 8f 19 b0 5b dd  ac ec 65 56 5e b5 d7 ed

        dd 75 3c 80 5a 59 f8 4a  7c ce 7f ad 7d ce 30 a3

        62 b7 be bf 3f 9f cf 61  ce 59 6b ef bd d6 7e ad

        bd d6 7e ac 5d 18 48 21  96 40 e9 9f f2 e0 b7 50

        d4 07 76 dc c5 79 77 ef  3b 76 fa 9d e8 1a dd bc

        7a 56 49 9b c8 2a f9 b3  0a 03 0e 08 25 8f 60 64

        ce 4b e4 6e 9f e8 cf 0d  24 91 1c 78 f2 e0 d1 05

        36 e4 e9 03 5b f2 48 a0  39 4f af ac 7c 06 e1 29

        81 86 94 d4 80 ce 40 02  5b 01 f6 63 1e c2 f0 dd

        2a eb 65 9d f2 d2 a1 06  b6 88 27 b2 5e 39 7b 2d

        fe 3f 75 ed 35 62 ed 94  da 22 46 9a 02 94 62 03

OOB:

        00 00 00 ff ff ff ff ff

        ff ff ff ff ff ff ff ff

 

You see: First Bytes are 0x00 (upper three ECC-Bytes) and the lower would contain trash,

so I filled them with 0xff

(don't care about it; It's a trick that I can use data without correction an detection

by using neutral elements like 0x0 or 0xff).

 

This is the correct page, written by U-Boot:

 

Page 00040000 dump:

        27 05 19 56 af 06 f6 35  49 af dc 33 00 13 6d 06

        00 00 00 00 00 00 00 00  eb f5 e0 23 05 10 04 00

        62 6f 6f 74 70 61 72 74  79 00 00 00 00 00 00 00

        00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

        00 00 00 80 00 13 6c 7a  00 00 00 00 27 05 19 56

        81 2f 9e 5a 49 af dc 32  00 00 00 40 00 00 00 00

        00 00 00 00 7e e4 05 0b  05 10 06 00 62 6f 6f 74

        73 63 72 69 70 74 00 00  00 00 00 00 00 00 00 00

        00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 38

        00 00 00 00 65 63 68 6f  20 62 6f 6f 74 20 66 72

        6f 6d 20 6e 61 6e 64 2e  2e 2e 0a 69 6d 78 74 72

        61 63 74 20 31 32 30 30  30 30 30 20 31 20 31 30

        30 30 30 30 30 0a 62 6f  6f 74 6d 0a 27 05 19 56

        2e 1f 62 47 49 af d9 01  00 13 6c 3a 00 00 10 00

        00 23 aa 88 58 2f 3c 33  05 10 02 01 4c 69 6e 75

        78 2d 32 2e 36 2e 32 36  2e 35 2d 41 44 49 2d 32

        30 30 39 52 31 2d 70 72  65 2d 67 64 1f 8b 08 00

        00 d9 af 49 02 03 ac bd  0b 5c 54 d5 f6 38 be 67

        60 66 ce 0c 07 38 83 a3  73 50 94 01 5f 03 28 e7

        70 b4 44 eb 16 0f c9 89  54 06 04 54 32 3b 08 0a

        19 86 75 bb 37 eb d6 0d  b1 d4 bc 2f c6 c9 b4 37

        60 99 95 8f 19 b0 5b dd  ac ec 65 56 5e b5 d7 ed

        dd 75 3c 80 5a 59 f8 4a  7c ce 7f ad 7d ce 30 a3

        62 b7 be bf 3f 9f cf 61  ce 59 6b ef bd d6 7e ad

        bd d6 7e ac 5d 18 48 21  96 40 e9 9f f2 e0 b7 50

        d4 07 76 dc c5 79 77 ef  3b 76 fa 9d e8 1a dd bc

        7a 56 49 9b c8 2a f9 b3  0a 03 0e 08 25 8f 60 64

        ce 4b e4 6e 9f e8 cf 0d  24 91 1c 78 f2 e0 d1 05

        36 e4 e9 03 5b f2 48 a0  39 4f af ac 7c 06 e1 29

        81 86 94 d4 80 ce 40 02  5b 01 f6 63 1e c2 f0 dd

        2a eb 65 9d f2 d2 a1 06  b6 88 27 b2 5e 39 7b 2d

        fe 3f 75 ed 35 62 ed 94  da 22 46 9a 02 94 62 03

OOB:

        a5 d5 12 f1 ff ff 8a 17

        ff ff ff ff ff ff ff ff

 

All 6 Bytes make sens and an error correction an detection is possible.

 

I use the char-device of the mtd and write whole filesystems under linux to NAND. Even a "dd" give the faulty result.

 

The pitty: I gave out the result of the ecc register read and saw 0x00! So I'm a little bit scared, that error correction and detection don't work any way... but: I have to take a very close look to the trunk to be shure.... until that: Any suggestions?

TranslateQuoteReplyEditDelete

 

 

2009-03-10 04:49:33     Re: HW_ECC in Linux on BF526 functional?

Mike Frysinger (UNITED STATES)

Message: 70674   

 

just to make sure we're on the same page ...

 

in u-boot, you have *not* defined CFG_BFIN_NFC_BOOTROM_ECC and CONFIG_BFIN_NFC_NO_HW_ECC.  that means u-boot uses HW ECC when operating.

 

in Linux, you defined CONFIG_MTD_NAND_BF5XX_HWECC, but not CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC.

 

the hw-ecc algorithm is not the same as sw-ecc, so whenever you change things, you need to erase the pages completely.

 

the bootrom ecc layout does not prevent you from using jffs2.  you do however have to do a *scrub* operation when switching between those modes because the bad block marker location changes.

 

what version of software exactly are you using (u-boot and linux) ?  the only nand devices we've tested are the ones on the bf548-ezkit and the bf527-ezkit, and afaik those are both 512bytes.  the hw-ecc setup has been working fine for us on those boards.

QuoteReplyEditDelete

 

 

2009-03-10 06:08:13     Re: HW_ECC in Linux on BF526 functional?

Marco Reppenhagen (GERMANY)

Message: 70682   

 

just to make sure we're on the same page ...

 

OK...

 

in u-boot, you have *not* defined CFG_BFIN_NFC_BOOTROM_ECC and CONFIG_BFIN_NFC_NO_HW_ECC.  that means u-boot uses HW ECC when operating.

 

U-Boot uses HW-ECC, no Bootrom_ECC, correct. (Verified by debug outputs)

 

in Linux, you defined CONFIG_MTD_NAND_BF5XX_HWECC, but not CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC.

 

The same mode in linux, too: I use HW-ECC and no BOOTROM-ECC....

 

the hw-ecc algorithm is not the same as sw-ecc, so whenever you change things, you need to erase the pages completely.

 

Yes, of course. If I use SW-ECC I erase everything, u-boot AND linux is compiled with sw-ecc turned on, and so on...

 

the bootrom ecc layout does not prevent you from using jffs2.  you do however have to do a *scrub* operation when switching between those modes because the bad block marker location changes.

 

You're right: It's no generally problem. We got trouble using Bootrom-ECC with our Small-paged NANDs.... We solved this problem a few weeks ago. (Thank you ;-)

 

what version of software exactly are you using (u-boot and linux) ?  the only nand devices we've tested are the ones on the bf548-ezkit and the bf527-ezkit, and afaik those are both 512bytes.  the hw-ecc setup has been working fine for us on those boards.

 

Well, that's not the question at all.

 

If you put in a printk where ecc0 and ecc1 greps the ecc- registers in bf5xx_nand.c, this result would be more interesting: If you see a 0x00 everytime, we've got a problem. If I see Upper ECC-Bytes in every single page written by linux, it's shure fishy.

 

Currently I work on Linux version 2.6.26.5-ADI-2009R1.

 

There are some patches of mine, which won't be easy to merge with the trunk. (I put in  trunk-mtd-stuff in our revision and this don't effect the ecc-problem: Still 0x0 is read from ecc-registers. )

 

U-Boot is SVN288. I checked the ECC-Bytes of the u-boot by calcuating them "manually": They are OK an matches with my results.

 

Again: I'm afraid of the zero-Bytes my linux is writing into the oob area.

 

My question is why the ecc-register-read returns this 0x00? They should return the calculated values based on the data which are then XORed to the read-oob-stuff. (The result is usually 0 if no error occured). Hmmm.... I think I have to spend a little more time....

 

BTW: We switch to next release.. (waiting for ;-) - Do you have latest news about the date of next release?

 

---

 

 

TranslateQuoteReplyEditDelete

 

 

2009-03-10 06:23:42     Re: HW_ECC in Linux on BF526 functional?

Mike Frysinger (UNITED STATES)

Message: 70683   

 

sorry, i also meant to ask exactly what NAND chip you're using ...

 

random thought ... u-boot operates in PIO mode while the kernel uses DMA/PIO ...

 

what if you modify bf5xx_nand_probe() and set the read_buf/write_buf funcs to the non-dma versions ?  (just remove "_dma" from the func names in the assignment i think)

 

as for kernel versions, i wanted to make sure you had the BF52x-specific fix that was added somewhat recently (look at the nand_dma_rw func).

QuoteReplyEditDelete

 

 

2009-03-10 09:40:43     Re: HW_ECC in Linux on BF526 functional?

Marco Reppenhagen (GERMANY)

Message: 70696   

 

We use a 8-bit/ 512/ 16384 from ST.

 

I just tried the PIO-Mode (good idea!) but no effect to my ecc-problem.

 

After that I tried to put in the hole mtd (before I only implemented mtd/nand) from trunk into my revision, but there are too much changes of any kind (api, structures, etc.) so I can't do it in fair time... ;-(

 

(Shure: There are some interesting changes, f.e. usage of subpages, etc. )

 

But now I have to wait until we switch to the new (release) Kernel or a late trunk-version, which become our "release".

 

If you would liek to spend some time, please insert a simple output in function "bf5xx_nand_calculate_ecc":

 

 

 

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

    ecc0 = bfin_read_NFC_ECC0();

    ecc1 = bfin_read_NFC_ECC1();

 

    if (( ecc0 == 0x0) && (ecc1 == 0x0)){     dev_err(info->device,

        "ecc registers returned 0x0!\n");

    }

 

    code[0] = (ecc0 & 0x7ff) | ((ecc1 & 0x7ff) ...........

 

 

While jffs2 scans the nand, every single page will cause my output.

 

If the same is up to you, we've got a "little" problem...

 

Even clean pages (simple: Everything if 0xFF and ECC should be FF) of a fresh scrubed nand cause a output... Maybe I misunderstand something, but in this simple case the 22-bit of ecc should be 1, too? If there are 256 Bytes contaiing "0x0" the ECC is 0x0, and so on....

 

OK I think I switch to sw-ECC to get up with our project.

Later We put in the new release Kernel (or the candidate) and when I see some stupid ECC-Bytes in OOB I will post again. (A lot changed betwenn 2009R and trunk... possibly  there is no problem in the trunk.)

 

So thank you for fast response and good ideas!

Attachments

    Outcomes