All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot]  BCH8 support when we do not have ELM h/w engine.
@ 2013-12-04 17:43 Enric Balletbo Serra
  2013-12-10  8:25 ` Enric Balletbo Serra
  0 siblings, 1 reply; 7+ messages in thread
From: Enric Balletbo Serra @ 2013-12-04 17:43 UTC (permalink / raw)
  To: u-boot

Dear Pekon,

I'm trying to enable the support for BCH8 for platforms that do not
have ELM hardware engine. Maybe I'm missing something but my first and
quick attempt was applying the following patch:

  http://pastebin.com/VUjuGChR

With this patch I'm able to switch to
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW with the nandecc hw bch8 command.

Then I tried to flash a ubi rootfs into the nand, but the kernel can't
mount the filesystem, I see messages like that:

[    3.703582] ecc unrecoverable error
[    3.707244] UBI warning: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 2:0, read only 64 bytes, retry

OTOH, if I flash the rootfs from the kernel (my board sets the ecc to
bch8) I don't have any problem, I can mount without problems.

I saw that the OOB layout is not the same when I flash the rootfs from
the u-boot or from the kernel. For example:

If the rootfs is flashed from the kernel the OOB data is like that:

U-Boot # nand dump.oob 0x680000
Page 00680000 dump:
OOB:
    ff ff 79 43 68 64 3b 80
    b2 46 49 4d 58 2a 6d ff
    52 3f 7d 2a 7f a2 98 70
    57 32 30 35 c7 ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff

If the rootfs is flashed for the u-boot the OOB data is like data:

Page 00680000 dump:
OOB:
    ff ff 79 43 68 64 3b 80
    b2 46 49 4d 58 2a 6d 52
    3f 7d 2a 7f a2 98 70 57
    32 30 35 c7 ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff

Note that look the same except after byte number 16. In the first case is
    ff 52 3f 7d 2a 7f a2 98 70
and in the second case is
    52 3f 7d 2a 7f a2 98 70

It's possible that something is wrong writting the OOB data ? Any clue
? I'm in the right direction or completely wrong ?

Thanks in advance,
   Enric

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2013-12-04 17:43 [U-Boot] BCH8 support when we do not have ELM h/w engine Enric Balletbo Serra
@ 2013-12-10  8:25 ` Enric Balletbo Serra
  2013-12-10  8:40   ` Gupta, Pekon
  0 siblings, 1 reply; 7+ messages in thread
From: Enric Balletbo Serra @ 2013-12-10  8:25 UTC (permalink / raw)
  To: u-boot

2013/12/4 Enric Balletbo Serra <eballetbo@gmail.com>:
> Dear Pekon,
>
> I'm trying to enable the support for BCH8 for platforms that do not
> have ELM hardware engine. Maybe I'm missing something but my first and
> quick attempt was applying the following patch:
>
>   http://pastebin.com/VUjuGChR
>
> With this patch I'm able to switch to
> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW with the nandecc hw bch8 command.
>
> Then I tried to flash a ubi rootfs into the nand, but the kernel can't
> mount the filesystem, I see messages like that:
>
> [    3.703582] ecc unrecoverable error
> [    3.707244] UBI warning: ubi_io_read: error -74 (ECC error) while
> reading 64 bytes from PEB 2:0, read only 64 bytes, retry
>
> OTOH, if I flash the rootfs from the kernel (my board sets the ecc to
> bch8) I don't have any problem, I can mount without problems.
>
> I saw that the OOB layout is not the same when I flash the rootfs from
> the u-boot or from the kernel. For example:
>
> If the rootfs is flashed from the kernel the OOB data is like that:
>
> U-Boot # nand dump.oob 0x680000
> Page 00680000 dump:
> OOB:
>     ff ff 79 43 68 64 3b 80
>     b2 46 49 4d 58 2a 6d ff
>     52 3f 7d 2a 7f a2 98 70
>     57 32 30 35 c7 ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>
> If the rootfs is flashed for the u-boot the OOB data is like data:
>
> Page 00680000 dump:
> OOB:
>     ff ff 79 43 68 64 3b 80
>     b2 46 49 4d 58 2a 6d 52
>     3f 7d 2a 7f a2 98 70 57
>     32 30 35 c7 ff ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>     ff ff ff ff ff ff ff ff
>
> Note that look the same except after byte number 16. In the first case is
>     ff 52 3f 7d 2a 7f a2 98 70
> and in the second case is
>     52 3f 7d 2a 7f a2 98 70
>
> It's possible that something is wrong writting the OOB data ? Any clue
> ? I'm in the right direction or completely wrong ?
>
> Thanks in advance,
>    Enric

Any clue about this ?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2013-12-10  8:25 ` Enric Balletbo Serra
@ 2013-12-10  8:40   ` Gupta, Pekon
  2013-12-10  8:46     ` Enric Balletbo Serra
  0 siblings, 1 reply; 7+ messages in thread
From: Gupta, Pekon @ 2013-12-10  8:40 UTC (permalink / raw)
  To: u-boot

Hi Enric,

Sorry I missed your earlier mail, so din't check this..

>From: Enric Balletbo Serra [mailto:eballetbo at gmail.com]
>>
>> I saw that the OOB layout is not the same when I flash the rootfs from
>> the u-boot or from the kernel. For example:
>>
>> If the rootfs is flashed from the kernel the OOB data is like that:
>>
>> U-Boot # nand dump.oob 0x680000
>> Page 00680000 dump:
>> OOB:
>>     ff ff 79 43 68 64 3b 80
>>     b2 46 49 4d 58 2a 6d ff
>>     52 3f 7d 2a 7f a2 98 70
>>     57 32 30 35 c7 ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>
>> If the rootfs is flashed for the u-boot the OOB data is like data:
>>
>> Page 00680000 dump:
>> OOB:
>>     ff ff 79 43 68 64 3b 80
>>     b2 46 49 4d 58 2a 6d 52
>>     3f 7d 2a 7f a2 98 70 57
>>     32 30 35 c7 ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>     ff ff ff ff ff ff ff ff
>>
>> Note that look the same except after byte number 16. In the first case is
>>     ff 52 3f 7d 2a 7f a2 98 70
>> and in the second case is
>>     52 3f 7d 2a 7f a2 98 70
>>
>> It's possible that something is wrong writting the OOB data ? Any clue
>> ? I'm in the right direction or completely wrong ?
>>
Yes, there seems to be an mis-match between u-boot and kernel
ecc-layout. Give me a day's time, and I'll try to root cause this.
However, don't have OMAP3 boards, so I can test this only on other boards.

with regards, pekon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2013-12-10  8:40   ` Gupta, Pekon
@ 2013-12-10  8:46     ` Enric Balletbo Serra
  2013-12-12 18:12       ` Gupta, Pekon
  2014-01-13  9:47       ` Gupta, Pekon
  0 siblings, 2 replies; 7+ messages in thread
From: Enric Balletbo Serra @ 2013-12-10  8:46 UTC (permalink / raw)
  To: u-boot

Hi Pekon,

2013/12/10 Gupta, Pekon <pekon@ti.com>:
> Hi Enric,
>
> Sorry I missed your earlier mail, so din't check this..
>
>>From: Enric Balletbo Serra [mailto:eballetbo at gmail.com]
>>>
>>> I saw that the OOB layout is not the same when I flash the rootfs from
>>> the u-boot or from the kernel. For example:
>>>
>>> If the rootfs is flashed from the kernel the OOB data is like that:
>>>
>>> U-Boot # nand dump.oob 0x680000
>>> Page 00680000 dump:
>>> OOB:
>>>     ff ff 79 43 68 64 3b 80
>>>     b2 46 49 4d 58 2a 6d ff
>>>     52 3f 7d 2a 7f a2 98 70
>>>     57 32 30 35 c7 ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>
>>> If the rootfs is flashed for the u-boot the OOB data is like data:
>>>
>>> Page 00680000 dump:
>>> OOB:
>>>     ff ff 79 43 68 64 3b 80
>>>     b2 46 49 4d 58 2a 6d 52
>>>     3f 7d 2a 7f a2 98 70 57
>>>     32 30 35 c7 ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>     ff ff ff ff ff ff ff ff
>>>
>>> Note that look the same except after byte number 16. In the first case is
>>>     ff 52 3f 7d 2a 7f a2 98 70
>>> and in the second case is
>>>     52 3f 7d 2a 7f a2 98 70
>>>
>>> It's possible that something is wrong writting the OOB data ? Any clue
>>> ? I'm in the right direction or completely wrong ?
>>>
> Yes, there seems to be an mis-match between u-boot and kernel
> ecc-layout. Give me a day's time, and I'll try to root cause this.
> However, don't have OMAP3 boards, so I can test this only on other boards.
>
> with regards, pekon

If I can help somehow just let me know.

Thanks,
   Enric

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2013-12-10  8:46     ` Enric Balletbo Serra
@ 2013-12-12 18:12       ` Gupta, Pekon
  2014-01-13  9:47       ` Gupta, Pekon
  1 sibling, 0 replies; 7+ messages in thread
From: Gupta, Pekon @ 2013-12-12 18:12 UTC (permalink / raw)
  To: u-boot

Hi Enric, 

>From: Enric Balletbo Serra [mailto:eballetbo at gmail.com]
>>>> Note that look the same except after byte number 16. In the first case is
>>>>     ff 52 3f 7d 2a 7f a2 98 70
>>>> and in the second case is
>>>>     52 3f 7d 2a 7f a2 98 70
>>>>
>>>> It's possible that something is wrong writting the OOB data ? Any clue
>>>> ? I'm in the right direction or completely wrong ?
>>>>
>> Yes, there seems to be an mis-match between u-boot and kernel
>> ecc-layout. Give me a day's time, and I'll try to root cause this.
>> However, don't have OMAP3 boards, so I can test this only on other boards.
>>
I have done some fix here.
But I hv still not completely tested this for all boot modes.
So plz consider this as RFC. And once I'm done, I'll post a formal patch.
(attaching the patches here for reference)..

with regards, pekon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mtd-nand-omap-fix-ecclayout-oobfree-offset.patch
Type: application/octet-stream
Size: 3398 bytes
Desc: 0001-mtd-nand-omap-fix-ecclayout-oobfree-offset.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131212/ea4f43d5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-mtd-nand-omap-fix-ecclayout-for-BCH4_SW-and-BCH8_SW-.patch
Type: application/octet-stream
Size: 4575 bytes
Desc: 0002-mtd-nand-omap-fix-ecclayout-for-BCH4_SW-and-BCH8_SW-.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131212/ea4f43d5/attachment-0001.obj>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2013-12-10  8:46     ` Enric Balletbo Serra
  2013-12-12 18:12       ` Gupta, Pekon
@ 2014-01-13  9:47       ` Gupta, Pekon
  2014-01-14 14:25         ` Enric Balletbo Serra
  1 sibling, 1 reply; 7+ messages in thread
From: Gupta, Pekon @ 2014-01-13  9:47 UTC (permalink / raw)
  To: u-boot

Hi Enric,

>
>Hi Pekon,
>
>2013/12/10 Gupta, Pekon <pekon@ti.com>:
>> Hi Enric,
>>
>> Sorry I missed your earlier mail, so din't check this..
>>
>>>From: Enric Balletbo Serra [mailto:eballetbo at gmail.com]
>>>>
>>>> I saw that the OOB layout is not the same when I flash the rootfs from
>>>> the u-boot or from the kernel. For example:
>>>>
>>>> If the rootfs is flashed from the kernel the OOB data is like that:
>>>>
>>>> U-Boot # nand dump.oob 0x680000
>>>> Page 00680000 dump:
>>>> OOB:
>>>>     ff ff 79 43 68 64 3b 80
>>>>     b2 46 49 4d 58 2a 6d ff
>>>>     52 3f 7d 2a 7f a2 98 70
>>>>     57 32 30 35 c7 ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>
>>>> If the rootfs is flashed for the u-boot the OOB data is like data:
>>>>
>>>> Page 00680000 dump:
>>>> OOB:
>>>>     ff ff 79 43 68 64 3b 80
>>>>     b2 46 49 4d 58 2a 6d 52
>>>>     3f 7d 2a 7f a2 98 70 57
>>>>     32 30 35 c7 ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>     ff ff ff ff ff ff ff ff
>>>>
>>>> Note that look the same except after byte number 16. In the first case is
>>>>     ff 52 3f 7d 2a 7f a2 98 70
>>>> and in the second case is
>>>>     52 3f 7d 2a 7f a2 98 70
>>>>
>>>> It's possible that something is wrong writting the OOB data ? Any clue
>>>> ? I'm in the right direction or completely wrong ?
>>>>
>> Yes, there seems to be an mis-match between u-boot and kernel
>> ecc-layout. Give me a day's time, and I'll try to root cause this.
>> However, don't have OMAP3 boards, so I can test this only on other boards.
>>
>> with regards, pekon
>
>If I can help somehow just let me know.
>
I have posted the patches to fix this regression between u-boot and kernel.
And was expecting if you could test it confirm if this solves regression on your
OMAP3 board.
http://lists.infradead.org/pipermail/linux-mtd/2014-January/051384.html

You can download the patch from [1]
[1] http://lists.infradead.org/pipermail/linux-mtd/2013-December/050944.html


with regards, pekon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] BCH8 support when we do not have ELM h/w engine.
  2014-01-13  9:47       ` Gupta, Pekon
@ 2014-01-14 14:25         ` Enric Balletbo Serra
  0 siblings, 0 replies; 7+ messages in thread
From: Enric Balletbo Serra @ 2014-01-14 14:25 UTC (permalink / raw)
  To: u-boot

Hi Pekon,

2014/1/13 Gupta, Pekon <pekon@ti.com>:
> Hi Enric,
>
>>
>>Hi Pekon,
>>
>>2013/12/10 Gupta, Pekon <pekon@ti.com>:
>>> Hi Enric,
>>>
>>> Sorry I missed your earlier mail, so din't check this..
>>>
>>>>From: Enric Balletbo Serra [mailto:eballetbo at gmail.com]
>>>>>
>>>>> I saw that the OOB layout is not the same when I flash the rootfs from
>>>>> the u-boot or from the kernel. For example:
>>>>>
>>>>> If the rootfs is flashed from the kernel the OOB data is like that:
>>>>>
>>>>> U-Boot # nand dump.oob 0x680000
>>>>> Page 00680000 dump:
>>>>> OOB:
>>>>>     ff ff 79 43 68 64 3b 80
>>>>>     b2 46 49 4d 58 2a 6d ff
>>>>>     52 3f 7d 2a 7f a2 98 70
>>>>>     57 32 30 35 c7 ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>
>>>>> If the rootfs is flashed for the u-boot the OOB data is like data:
>>>>>
>>>>> Page 00680000 dump:
>>>>> OOB:
>>>>>     ff ff 79 43 68 64 3b 80
>>>>>     b2 46 49 4d 58 2a 6d 52
>>>>>     3f 7d 2a 7f a2 98 70 57
>>>>>     32 30 35 c7 ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>     ff ff ff ff ff ff ff ff
>>>>>
>>>>> Note that look the same except after byte number 16. In the first case is
>>>>>     ff 52 3f 7d 2a 7f a2 98 70
>>>>> and in the second case is
>>>>>     52 3f 7d 2a 7f a2 98 70
>>>>>
>>>>> It's possible that something is wrong writting the OOB data ? Any clue
>>>>> ? I'm in the right direction or completely wrong ?
>>>>>
>>> Yes, there seems to be an mis-match between u-boot and kernel
>>> ecc-layout. Give me a day's time, and I'll try to root cause this.
>>> However, don't have OMAP3 boards, so I can test this only on other boards.
>>>
>>> with regards, pekon
>>
>>If I can help somehow just let me know.
>>
> I have posted the patches to fix this regression between u-boot and kernel.
> And was expecting if you could test it confirm if this solves regression on your
> OMAP3 board.
> http://lists.infradead.org/pipermail/linux-mtd/2014-January/051384.html
>
> You can download the patch from [1]
> [1] http://lists.infradead.org/pipermail/linux-mtd/2013-December/050944.html
>
>
> with regards, pekon

Thanks for the patches, I tested and worked for me on our OMAP3 based
boards, I'll answer the mail that you sent to the linux-omap ML.

Sorry for the delay, cheers,

   Enric

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-01-14 14:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-04 17:43 [U-Boot] BCH8 support when we do not have ELM h/w engine Enric Balletbo Serra
2013-12-10  8:25 ` Enric Balletbo Serra
2013-12-10  8:40   ` Gupta, Pekon
2013-12-10  8:46     ` Enric Balletbo Serra
2013-12-12 18:12       ` Gupta, Pekon
2014-01-13  9:47       ` Gupta, Pekon
2014-01-14 14:25         ` Enric Balletbo Serra

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.