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:   Sun, 15 Jan 2017 16:44:20 +0100
From:   Andreas Färber <afaerber@...e.de>
To:     Heinrich Schuchardt <xypron.glpk@....de>
Cc:     Neil Armstrong <narmstrong@...libre.com>, khilman@...libre.com,
        carlo@...one.org, 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 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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ