On 03/12/2020 16:20, Chen-Yu Tsai wrote:

Hi,

On Thu, Dec 3, 2020 at 11:45 PM André Przywara [off-list ref] wrote:

quoted

On 03/12/2020 15:02, Chen-Yu Tsai wrote:

quoted

On Thu, Dec 3, 2020 at 6:54 PM André Przywara [off-list ref] wrote:

quoted

On 03/12/2020 03:16, Samuel Holland wrote:

Hi,

quoted

On 12/2/20 7:54 AM, Andre Przywara wrote:
...

quoted

+    soc {
+            compatible = "simple-bus";
+            #address-cells = <1>;
+            #size-cells = <1>;
+            ranges = <0x0 0x0 0x0 0x40000000>;
+
+            syscon: syscon@3000000 {
+                    compatible = "allwinner,sun50i-h616-system-control",
+                                 "allwinner,sun50i-a64-system-control";
+                    reg = <0x03000000 0x1000>;
+                    #address-cells = <1>;
+                    #size-cells = <1>;
+                    ranges;
+
+                    sram_c: sram@28000 {
+                            compatible = "mmio-sram";
+                            reg = <0x00028000 0x30000>;
+                            #address-cells = <1>;
+                            #size-cells = <1>;
+                            ranges = <0 0x00028000 0x30000>;
+                    };
+
+                    sram_c1: sram@1a00000 {
+                            compatible = "mmio-sram";
+                            reg = <0x01a00000 0x200000>;
+                            #address-cells = <1>;
+                            #size-cells = <1>;
+                            ranges = <0 0x01a00000 0x200000>;
+
+                            ve_sram: sram-section@0 {
+                                    compatible = "allwinner,sun50i-h616-sram-c1",
+                                                 "allwinner,sun4i-a10-sram-c1";
+                                    reg = <0x000000 0x200000>;
+                            };
+                    };
+            };

You mentioned that you could not find a SRAM A2. How were these SRAM ranges
verified? If you can load eGON.BT0 larger than 32 KiB, then presumably NBROM
uses SRAM C, and it is in the manual, but I see no mention of SRAM C1.

The manual says that SRAM C *can* be used by "the system", at boot time,
as long as it's configured correctly. I couldn't find any details on how
to switch clock sources for SRAM C, and the manual stanza on this is
quite gibberish. I presume it's configured either by BROM or by reset
default this way. I think the idea is that the later users (VE, DE) take
ownership at some point (which means we can't run any firmware in there).
The BSP boot0 is 48KB already, so reaching into SRAM C, and the code
itself heavily uses SRAM C (found by hacking boot0 to drop to FEL and
inspecting the memory afterwards).

For C1: I copied this name from the H6 .dtsi, the manual calls this
"VE-SRAM", in both manuals, and the description looks identical there
for both SoCs. I think this will be later used by the video engine, so I
kept it in. The large size made me suspicious, and from former
experiments it looks like being aliased to (parts of) SRAM C.

I would just call it sram_ve or ve_sram. SRAM C1 would make more sense if
it were part of SRAM C, not the other way around.

But isn't that what we do? "sram_c1" is just the node name alias used
for the parent node. That is actually never referenced anywhere (in any
of the the H6 .dts), so we can actually remove it, I guess.
The actual SRAM section is called ve_sram already.

This is what I had in mind:

syscon: {
        sram_c: sram@28000 {
                compatible = "mmio-sram";
                reg = <0x00028000 0x30000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 0x00028000 0x30000>;

                /* starting address might not be correct */
                sram_c_ve: sram-section@0 {
                        compatible = "allwinner,sun50i-h616-ve-sram-c",
                                     "allwinner,sun4i-a10-sram-c1";
                       /* 64 kiB borrowed from ve_sram */
                        reg = <0x0 0x10000>;
                };
        };

        ve_sram: sram@1a00000 {
                compatible = "mmio-sram";
                reg = <0x01a00000 0x200000>;
                #address-cells = <1>;
                #size-cells = <1>;
        };
};

OK, I am taking this version, but am dropping the sram_c_ve subnode,
until we know where it is, what we actually need and until we can test it.

Another variant, trying to describe the aliasing, though it seems
quite confusing:

I don't know the exact nature of the aliasing, only that there is some.

syscon: {
        ve_sram: sram@1a00000 {
                compatible = "mmio-sram";
                reg = <0x01a00000 0x200000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

                ve_sram_c: sram-section@28000 {
                        compatible = "allwinner,sun50i-h616-ve-sram-c",
                                     "allwinner,sun4i-a10-sram-c1";
                        reg = <0x28000 0x10000>;
                };
        };
};


Just out of curiosity, is the whole SRAM @1a00000 accessible by the CPU?

I have no clue, but I would guess not, since I doubt that it's actually
2MB in size. I just played around a bit with it from U-Boot, and found
strings from the SPL in there.

Does it require the system control SRAM bits to be set, or does that only
affect the portion that SRAM C "borrows"? If it isn't accessible to the
CPU at all, then we might as well not put it in the device tree.

Yeah, that's another option I am thinking about.

quoted

And I can't change the compatible name, for the fallback, at least.

I can make the new compatible string read
"allwinner,sun50i-h616-ve-sram", if that helps, but that would mean
deviating from the H6 and other SoCs.

Matching what the documents say makes more sense to me.

I will just delay this decision by not using that string in the first
place ;-)

Thanks!
Andre

Regards
ChenYu

quoted

Cheers,
Andre

quoted

Also the sram-section node would make more sense if it were in sram_c, as
that is the part that gets switched around, not the full region @ 1a00000.

ChenYu

quoted

Maybe some guys with more VE knowledge can shine some light on this?

Cheers,
Andre

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/3dc67c21-f649-cca5-ec54-c639c54ee56a%40arm.com.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel