Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges
 in OCRAM
To:     Nishanth Menon <nm@ti.com>
CC:     Rob Herring <robh+dt@kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
        Aswath Govindraju <a-govindraju@ti.com>
References: <20210609140604.9490-1-vigneshr@ti.com>
 <20210611191640.lczsliyzasjie6lm@dismantle>
From:   Vignesh Raghavendra <vigneshr@ti.com>
Message-ID: <84e5865f-e107-f0e1-ca8b-b6bd655e92e6@ti.com>
Date:   Sat, 12 Jun 2021 12:51:42 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <20210611191640.lczsliyzasjie6lm@dismantle>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

+Aswath

On 6/12/21 12:46 AM, Nishanth Menon wrote:
> On 19:36-20210609, Vignesh Raghavendra wrote:
>> Last 256K of OCRAM (256K@0x701c0000) 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@0x701E0000 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@ti.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@70000000 {
>>  		atf-sram@0 {
>>  			reg = <0x0 0x1a000>;
>>  		};
>> +
>> +		dmsc-sram@1c0000 {
>> +			reg = <0x1c0000 0x40000>;
> 
>> +		};
>>  	};
>>  
>>  	gic500: interrupt-controller@1800000 {
>> -- 
>> 2.31.1
>>
>