linux-kernel - Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

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]

Date:   Thu, 3 Dec 2020 10:53:54 +0000
From:   André Przywara <andre.przywara@....com>
To:     Samuel Holland <samuel@...lland.org>,
        Maxime Ripard <mripard@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>
Cc:     devicetree@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com,
        Rob Herring <robh+dt@...nel.org>,
        Icenowy Zheng <icenowy@...c.xyz>,
        Yangtao Li <frank@...winnertech.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

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

Hi,

> On 12/2/20 7:54 AM, Andre Przywara wrote:
> ...
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges = <0x0 0x0 0x0 0x40000000>;
>> +
>> +		syscon: syscon@...0000 {
>> +			compatible = "allwinner,sun50i-h616-system-control",
>> +				     "allwinner,sun50i-a64-system-control";
>> +			reg = <0x03000000 0x1000>;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			ranges;
>> +
>> +			sram_c: sram@...00 {
>> +				compatible = "mmio-sram";
>> +				reg = <0x00028000 0x30000>;
>> +				#address-cells = <1>;
>> +				#size-cells = <1>;
>> +				ranges = <0 0x00028000 0x30000>;
>> +			};
>> +
>> +			sram_c1: sram@...0000 {
>> +				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.

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

Cheers,
Andre