linux-kernel - Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

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] [day] [month] [year] [list]

Date:   Mon, 16 Jan 2017 15:02:26 +0100
From:   Andreas Färber <afaerber@...e.de>
To:     Neil Armstrong <narmstrong@...libre.com>, carlo@...one.org
Cc:     Heinrich Schuchardt <xypron.glpk@....de>, khilman@...libre.com,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org
Subject: Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and
 usable memory range

Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas Färber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>>  	memory@0 {
>>>  		device_type = "memory";
>>>  		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>>  	};
>>>
>>> or
>>>
>>>  	memory@0 {
>>>  		device_type = "memory";
>>>  		reg = <0x0 0x1000000 0x0 0x7f000000>;
>>>  	};
>>>
>>> The second version leads to failure of the Odroid C2.
>>>
>>> When I looked at /sys/firmware/fdt I saw this difference:
>>>
>>> --- fails
>>> +++ works
>>>
>>>         memory@0 {
>>> -               device_type = "memory";
>>>                 reg = <0x0 0x0 0x0 0x78000000>;
>>> +               device_type = "memory";
>>> +               linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>>         };
>>>
>>> I found the following sentence in the NXP forum:
>>> In case you want to overwrite the memory usage passed from u-boot, you
>>> can use "linux,usable-memory".
>>> https://community.nxp.com/thread/382284
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x1000000, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
> 
> Hi Andreas,
> 
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
> 
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.

That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).

And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.

A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)