linux-kernel - Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 25 Jul 2018 11:08:38 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Ladislav Michl <ladis@...ux-mips.org>
Cc:     Marek Belisko <marek@...delico.com>,
        Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, letux-kernel@...nphoenux.org
Subject: Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup


> Am 25.07.2018 um 10:28 schrieb Ladislav Michl <ladis@...ux-mips.org>:
> 
> On Wed, Jul 25, 2018 at 10:16:28AM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> 
>>> Am 25.07.2018 um 10:10 schrieb Ladislav Michl <ladis@...ux-mips.org>:
>>> 
>>> On Wed, Jul 25, 2018 at 08:58:42AM +0200, H. Nikolaus Schaller wrote:
>>>> to better match omap3-beagle.dts (which was the basis
>>>> of designing the GTA04).
>>>> 
>>>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
>>>> ---
>>>> arch/arm/boot/dts/omap3-gta04.dtsi | 14 +++++++-------
>>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> index 03fe404cbf56..9568e0c4d4bf 100644
>>>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> @@ -616,27 +616,27 @@
>>>> 		interrupt-parent = <&gpmc>;
>>>> 		interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
>>>> 			     <1 IRQ_TYPE_NONE>;	/* termcount */
>>>> +		ti,nand-ecc-opt = "ham1";
>>>> +		rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
>>>> 		nand-bus-width = <16>;
>>>> -		ti,nand-ecc-opt = "bch8";
>>> 
>>> You are using weeker ECC scheme just to be compatible with another machine?
>> 
>> No not another machine. The GTA04 uses the same SoC and NAND chip as the BeagleBoard,
>> so you can imagine GTA04 being a BeagleBoard + a lot of other things.
>> 
>> The key reason is to change the ecc scheme is to be compatible with the U-Boot used.
>> 
>> BootROM can only handle ham1 for the MLO. And there is no nand-ecc-opt
>> for each partition. So we either can't mix ECC schemes if we want to be able
>> to read/write MLO as the first partition from kernel.
>> 
>>> So now you cannot boot already deployed filesystem...
>> 
>> No. We always used ham1 and bch8 wasn't working at all here. Therefore nobody
>> did use upstream kernel for NAND yet...
>> 
>>> Also is it enough for
>>> NAND chip used?
>> 
>> Well, the chip is recommended to use bch8 but BootROM imposes above mentioned limits.
> 
> Then common way to handle such a situation is to use 1bit hamming for MLO and BCH8 for
> the rest. You will end with corrupted filesystem with ham1 which I'd consider very
> unfortunate.
> 
> (I know there were endless discussions how to handle this situation. It is already
> solved in U-Boot and for updating MLO from Linux I'm using writeloader tool)

Never heard of this tool, but we haven't followed this discussion for years since
we never had problems with "ham1-everywhere". What I am not completely sure is if
ubifs is using its own ECC scheme or not. If it is (like I assume), the user-space
partition is independent of this setting and we just have discussion for MLO/U-Boot
and kernel partitions.

So I think it boils down to the question if
a) upstream should do a suboptimal thing, but be compatible to the current vendor kernel and u-boot
b) upstream should do the right thing, but stay incompatible

Result of b) would e.g. a stock Debian kernel will not be able to read or write the partitions of a device
created with vendor kernel.

And even worse, it is not clear if users will want to erase and reflash the NAND to match what kernel.org defines if they have a running system.

This makes me believe that a) is still better for practical reasons, even if technically worse.

BR,
Nikolaus

> 
> 	ladis
> 
>> BR,
>> Nikolaus
>> 
>>> 
>>> 	ladis
>>> 
>>>> +		#address-cells = <1>;
>>>> +		#size-cells = <1>;
>>>> 
>>>> -		gpmc,sync-clk-ps = <0>;
>>>> +		gpmc,device-width = <2>;
>>>> 		gpmc,cs-on-ns = <0>;
>>>> 		gpmc,cs-rd-off-ns = <44>;
>>>> 		gpmc,cs-wr-off-ns = <44>;
>>>> 		gpmc,adv-on-ns = <6>;
>>>> 		gpmc,adv-rd-off-ns = <34>;
>>>> 		gpmc,adv-wr-off-ns = <44>;
>>>> -		gpmc,we-off-ns = <40>;
>>>> 		gpmc,oe-off-ns = <54>;
>>>> +		gpmc,we-off-ns = <40>;
>>>> 		gpmc,access-ns = <64>;
>>>> 		gpmc,rd-cycle-ns = <82>;
>>>> 		gpmc,wr-cycle-ns = <82>;
>>>> 		gpmc,wr-access-ns = <40>;
>>>> 		gpmc,wr-data-mux-bus-ns = <0>;
>>>> -		gpmc,device-width = <2>;
>>>> -
>>>> -		#address-cells = <1>;
>>>> -		#size-cells = <1>;
>>>> +		gpmc,sync-clk-ps = <0>;
>>>> 
>>>> 		x-loader@0 {
>>>> 			label = "X-Loader";
>>>> -- 
>>>> 2.12.2
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html