linux-kernel - Re: [PATCH] ARM: mach-qcom: fix support for ipq806x

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]

Message-ID: <6357240c.170a0220.999b2.23d6@mx.google.com>
Date:   Mon, 24 Oct 2022 21:57:27 +0200
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Russell King <linux@...linux.org.uk>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Arnd Bergmann <arnd@...db.de>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Nick Hawkins <nick.hawkins@....com>,
        John Crispin <john@...ozen.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] ARM: mach-qcom: fix support for ipq806x

On Sat, Oct 22, 2022 at 04:21:28PM +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2022 at 11:55 PM Christian Marangi <ansuelsmth@...il.com> 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 :)
> 

Hi,
bad news... yesterday I tested this binding and it's problematic. It
does work and the router correctly boot... problem is that SMEM is
broken with such configuration... I assume with this binding, by the
system view ram starts from 0x42000000 instead of 0x40000000 and this
cause SMEM to fail probe with the error "SBL didn't init SMEM".

This is the location of SMEM entry in ram

		smem: smem@...00000 {
			compatible = "qcom,smem";
			reg = <0x41000000 0x200000>;
			no-map;

			hwlocks = <&sfpb_mutex 3>;
		};

On openwrt (kernel 5.10 and 5.15) we currently use a mix of the old Makefile.boot
infra and a patch to ignore atags. With the current configuration we can
correctly bootup the system by passing the load addr to the decompressor
to 0x42000000 (+TEXT_OFFEST) and also use SMEM as it gets correctly init
in the not mapped ram addr.

We are now working on adding 6.1 kernel support and since Makefile.boot
infra got dropped, I'm searching a better solution that can also be
upstreamed, for now PHY_OFFSET seems the only solution.

Wonder if you have other ideas about this.

-- 
	Ansuel