linux-kernel - Re: [PATCH] arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges in OCRAM

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: <84e5865f-e107-f0e1-ca8b-b6bd655e92e6@ti.com>
Date:   Sat, 12 Jun 2021 12:51:42 +0530
From:   Vignesh Raghavendra <vigneshr@...com>
To:     Nishanth Menon <nm@...com>
CC:     Rob Herring <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Aswath Govindraju <a-govindraju@...com>
Subject: Re: [PATCH] arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges
 in OCRAM

+Aswath

On 6/12/21 12:46 AM, Nishanth Menon wrote:
> On 19:36-20210609, Vignesh Raghavendra wrote:
>> Last 256K of OCRAM (256K@...01c0000) is reserved for SYSFW usage. Hence
>> add an entry in DT so that its not used for generic pool memory
>> allocation.
> 
> Are you really sure?? I know that I had set a budget for 16K in sysfw
> when I did the memory split up for sysfw of which 16k is actually used.
> 
> Not sure where this 256K bucket started off from.. am I missing
> something here?
> 

Per: http://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/firewalls.html

24	dmsc	0x44060000	0x4407BFFF	dmsc,rwcd	 	 // alias for 0x701E0000
24	dmsc	0x701FC000	0x701FFFFF	sproxy_private,rwcd	 	 
24	dmsc	0x4407C000	0x4407FFFF	sproxy_private,rwcd	 	 
24	dmsc	0x701C0000	0x701DFFFF	everyone,rwcd	 	 

So it looks like only 128K@...01E0000 is firewalled off. 
Will update the patch.

This makes me wonder why ATF is being moved to 0x701a0000-0x701c0000
leaving a hole at 0x701C0000-0x701DFFFF? 


> 
>>
>> Without this certain drivers using SRAM as generic shared memory pool
>> may end up being allocated memory from this range and will lead to boot
>> time crash when the reserved range is accessed (due to firewall
>> violation).
>>
>> Signed-off-by: Vignesh Raghavendra <vigneshr@...com>
>> ---
>>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> index f1c42ef05e52..77b88e536534 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> @@ -16,6 +16,10 @@ oc_sram: sram@...00000 {
>>  		atf-sram@0 {
>>  			reg = <0x0 0x1a000>;
>>  		};
>> +
>> +		dmsc-sram@...000 {
>> +			reg = <0x1c0000 0x40000>;
> 
>> +		};
>>  	};
>>  
>>  	gic500: interrupt-controller@...0000 {
>> -- 
>> 2.31.1
>>
>