On Fri, Oct 21, 2022 at 11:55 PM Christian Marangi <ansuelsmth@xxxxxxxxx> wrote:
> On Fri, Oct 21, 2022 at 11:44:56PM +0200, Linus Walleij wrote:
> > Is it not possible to use Geert's linux,usable-memory-range in
> > the chosen node to make the kernel stay off the memory?
> > (See examples by grep usable-memory in the kernel.)
> >
>
> Hi,
> just to confirm this is one of the example you are suggesting?
>
> chosen {
> bootargs = "console=ttyS0,115200 earlycon";
> stdout-path = "serial0:115200n8";
> linux,usable-memory-range = <0x80200000 0x1fe00000>;
> };
Yep that thing!
> Main problem here is that uboot in some case doesn't support dt and pass
> wrong ATAGS (with the memory not reserved) and AUTO_ZRELADDR calculate
> the wrong addr I assume?
You do have a DTB right, just that it is attached, and then the kernel
uses the ATAGs to augment the memory?
In that case what about disabling ARM_ATAG_DTB_COMPAT
and adding the actual valid memory to the top-level DTS
file? Just like that:
memory {
device_type = "memory";
reg = <0x42000000 0xnnnnnnnn>;
};
> I will test the usable-memory-range but isn't the same of declaring
> reserved space in the dts? Or the zimage decompressor checks
> linux,usable-memory-range bypassing atags?
As long as it just pass "too much" memory it should do the job,
I *think*.
Since I wrote this article:
https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses
Geert introduced some very elaborate low-level OF code and I
do think it kicks in and makes sure to reserve this memory even
before the decompressor goes to work (in difference from e.g.
"reserved memory nodes" that are not inspected until later).
See:
commit 48342ae751c797ac73ac9c894b3f312df18ffd21
"ARM: 9124/1: uncompress: Parse "linux,usable-memory-range" DT property"
Then if the memory node is in the DTB originally or patched in
by U-Boot shouldn't really matter, usable-memory-range should
kick in in either case.
It is described as used for kexec (which I never use) but I think it can
solve your problem too.
The DT property is (by agreement) an undocumented Linux extension,
so Geert knows the intended usecases better :)
Yours,
Linus Walleij
