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@csie.org> wrote:
> > On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.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@bootlin.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@1c00000 {
> > > +                       compatible = "allwinner,sun50i-h5-system-control";
> > > +                       reg = <0x01c00000 0x1000>;
> > > +                       #address-cells = <1>;
> > > +                       #size-cells = <1>;
> > > +                       ranges;
> > > +
> > > +                       sram_c1: sram@1d00000 {
> > > +                               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@1e80000 {
> > >                         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