linux-kernel - Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

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: <82a1ef7ea170ba50f58f74e26dac6170ac87783f.camel@bootlin.com>
Date:   Fri, 30 Nov 2018 14:26:34 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Linux Media Mailing List <linux-media@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        devel@...verdev.osuosl.org,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-sunxi@...glegroups.com, Hans Verkuil <hverkuil@...all.nl>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control
 node with SRAM C1

Hi,

On Fri, 2018-11-30 at 11:38 +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 16, 2018 at 12:52 AM Chen-Yu Tsai <wens@...e.org> wrote:
> > On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> > <paul.kocialkowski@...tlin.com> wrote:
> > > Add the H5-specific system control node description to its device-tree
> > > with support for the SRAM C1 section, that will be used by the video
> > > codec node later on.
> > > 
> > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 ++++++++++++++++++++
> > >  1 file changed, 22 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > index b41dc1aab67d..c2d14b22b8c1 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > @@ -94,6 +94,28 @@
> > >         };
> > > 
> > >         soc {
> > > +               system-control@...0000 {
> > > +                       compatible = "allwinner,sun50i-h5-system-control";
> > > +                       reg = <0x01c00000 0x1000>;
> > > +                       #address-cells = <1>;
> > > +                       #size-cells = <1>;
> > > +                       ranges;
> > > +
> > > +                       sram_c1: sram@...0000 {
> > > +                               compatible = "mmio-sram";
> > > +                               reg = <0x01d00000 0x80000>;
> > 
> > I'll try to check this one tomorrow.
> > 
> > I did find something interesting on the H3: there also seems to be SRAM at
> > 0x01dc0000 to 0x01dcfeff , again mapped by the same bits as SRAM C1.
> > 
> > And on the A33, the SRAM C1 range is 0x01d00000 to 0x01d478ff.
> > 
> > This was found by mapping the SRAM to the CPU, then using devmem to poke
> > around the register range. If there's SRAM, the first read would typically
> > return random data, and a subsequent write to it would set some value that
> > would be read back correctly. If there's no SRAM, a read either returns 0x0
> > or some random data that can't be overwritten.
> > 
> > You might want to check the other SoCs.
> 
> This range seems to contain stuff other than SRAM, possibly fixed lookup
> tables. Since this is entirely unknown, lets just stick to the known full
> range instead.

Thanks for investigating all this!

I also conducted some tests and found that the H5 has its SRAM C1
(marked as SRAM C in the manual) at 0x18000. However for the A64, SRAM
C1 gets mapped to 0x1D00000. There is also SRAM C at 0x18000 but this
one seems unrelated to the VPU and only used by DE2 (as already
described in the A64 dt).

I share your conclusion that there seems to be more than SRAM in there.
Testing with devmem write/read on the start address was reliable as a
test, but some chunks in the range did not behave like SRAM (not the
same value read).

I agree that we should keep the known full range as there are lots of
unknowns here.

Cheers,

Paul

> ChenYu
> 
> > > +                               #address-cells = <1>;
> > > +                               #size-cells = <1>;
> > > +                               ranges = <0 0x01d00000 0x80000>;
> > > +
> > > +                               ve_sram: sram-section@0 {
> > > +                                       compatible = "allwinner,sun50i-h5-sram-c1",
> > > +                                                    "allwinner,sun4i-a10-sram-c1";
> > > +                                       reg = <0x000000 0x80000>;
> > > +                               };
> > > +                       };
> > > +               };
> > > +
> > >                 mali: gpu@...0000 {
> > >                         compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
> > >                         reg = <0x01e80000 0x30000>;
> > > --
> > > 2.19.1
> > > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)