[Letux-kernel] ECC

H. Nikolaus Schaller hns at goldelico.com
Sun Mar 19 21:54:21 CET 2017


Hi Marek,

> Am 19.03.2017 um 21:42 schrieb Belisko Marek <marek.belisko at gmail.com>:
> 
> Hi Nikolaus,
> 
> On Sun, Mar 19, 2017 at 6:43 PM, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> Hi Marek,
>> 
>>> Am 18.03.2017 um 08:54 schrieb Belisko Marek <marek.belisko at gmail.com>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Sat, Mar 18, 2017 at 8:44 AM, Belisko Marek <marek.belisko at gmail.com> wrote:
>>>> Hi Nikolaus,
>>>>>>> 
>>>>>>> There is only one remaining issue with our latest U-Boot and Kernel: the NAND
>>>>>>> ECC mode does not match between U-Boot and Kernel (OneNAND has no choice for that).
>>>>>> Probably ECC options are different between u-boot and kernel (dts)?
>>>>> 
>>>>> Yes, they disagree.
>>>>> 
>>>>> The question is how to make them agree...
>>>>> 
>>>>> AFAIR, MLO must have some specific ECC enabled while the other partitions are a
>>>>> little more configurable.
>>>>> 
>>>>> The main problem seems to be that the kernel does not have ECC specification for
>>>>> individual partitions but only for the full chip. This means there is no real
>>>>> flexibility if we want to load MLO from NAND.
>>>>> 
>>>>> Maybe we can look into the BeagleBoard setup?
>>>>> 
>>>>> @Marek: if you have a little time, could you help to research the settings?
>>>> Yes I'll look on that and get back with findings.
>>> OK in kernel dts we have bch8 ecc scheme selected and it's sw
>>> detection. AFAIK only am33xx have elm module which is used for
>>> HW ecc. And u-boot is using (in omap3_beagle.h inherited)
>>> OMAP_ECC_HAM1_CODE_HW so we should somehow align them.
>>> I don't have board by hand now so it's not verified but I think this
>>> is a problem. There is an u-boot command to switch ecc schme so I'll
>>> try (probably on Sunday) to test if we can access u-boot env from
>>> linux.
>> 
>> I have now looked up the DT of the BeagleBoard (not XM) which has a very similar
>> NAND chip. They seem to use "ham1" as the ECC mode in the device tree:
>> 
>> http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-beagle.dts#L392
>> 
>> Unfortunately, I can't read the fw_printenv either:
>> 
>> 
>> And the device tree is strange. Here is the source patch:
>> 
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
>> index 907abcf..ad6ac7d 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
>> @@ -636,7 +636,7 @@
>>                interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
>>                             <1 IRQ_TYPE_NONE>; /* termcount */
>>                nand-bus-width = <16>;
>> -               ti,nand-ecc-opt = "bch8";
>> +               ti,nand-ecc-opt = "ham1";
>> 
>>                gpmc,sync-clk-ps = <0>;
>>                gpmc,cs-on-ns = <0>;
>> 
>> And what I get...
>> 
>> root at letux:~# /usr/bin/fdtdump /sys/firmware/fdt |fgrep ecc
>>                ti,nand-ecc-opt = "sw";
>> root at letux:~#
>> 
>> Strange. Does U-Boot or the kernel overwrite this setting?
> Look in dts at line 1116 there is overwritten ecc to sw.. With this
> change I can read fw_printenv content ;)

Ah, great finding!

That comes from that we are still lacking upstreaming of some local
improvements to the DTS files...

Well, in this case it was not possible to upstream something new
since we didn't have a new U-Boot for years. It is just now that
it starts to work.

> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 46babfd..c8c27bb 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -1113,7 +1113,7 @@
> 
> &gpmc {
>        nand at 0,0 {
> -               ti,nand-ecc-opt = "sw"; /* stay compatible with our
> old u-boot (does not support bch8) */
> +               ti,nand-ecc-opt = "ham1"; /* stay compatible with our
> old u-boot (does not support bch8) */
> 
>                kernel at 280000 {
>                        reg = <0x280000 0x600000>;

BR and thanks for finding this!
Nikolaus



More information about the Letux-kernel mailing list