diff mbox series

arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges in OCRAM

Message ID 20210609140604.9490-1-vigneshr@ti.com
State New
Headers show
Series arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges in OCRAM | expand

Commit Message

Vignesh Raghavendra June 9, 2021, 2:06 p.m. UTC 
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.

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(+)

Comments

Vignesh Raghavendra June 11, 2021, 6:29 p.m. UTC | #1 
On 6/9/21 8:56 PM, Lokesh Vutla wrote:
> 

> 

> On 09/06/21 7:36 pm, 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.

>>

>> 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>

> 

> You might want to re-base on top of Aswath's patch updating ATF address. Otherwise:

> 

> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

> 


Actually, this patch should go in before Aswath's patch as moving ATF
location around exposed issue of drivers getting memory allocations
overlapping SYSFW reserved ranges

Regards
Vignesh
Nishanth Menon June 11, 2021, 7:03 p.m. UTC | #2 
On 23:59-20210611, Vignesh Raghavendra wrote:
> 

> 

> On 6/9/21 8:56 PM, Lokesh Vutla wrote:

> > 

> > 

> > On 09/06/21 7:36 pm, 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.

> >>

> >> 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>

> > 

> > You might want to re-base on top of Aswath's patch updating ATF address. Otherwise:

> > 

> > Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

> > 

> 

> Actually, this patch should go in before Aswath's patch as moving ATF

> location around exposed issue of drivers getting memory allocations

> overlapping SYSFW reserved ranges



I have applied Aswath's patch, please rebase. understood this is a bug,
but either way, it really was'nt a regression of stuff that was present.

please fix and send asap so that I can pick it up.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
Nishanth Menon June 11, 2021, 7:16 p.m. UTC | #3 
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?


> 

> 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

> 


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
Vignesh Raghavendra June 12, 2021, 7:21 a.m. UTC | #4 
+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

>>

>
Aswath Govindraju June 14, 2021, 4:48 a.m. UTC | #5 
Hi Vignesh,

On 12/06/21 12:51 pm, Vignesh Raghavendra wrote:
> +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? 

> 

> 


The reason for leaving the hole at 0x701C0000-0x701DFFFF was because
initially there was a bug in SYSFW which lead to the usage of the above
region too by it. However, this bug was recently fixed and the the above
region can be used for ATF.

Thanks,
Aswath

>>

>>>

>>> 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

>>>

>>
Nishanth Menon June 14, 2021, 2:28 p.m. UTC | #6 
On 10:18-20210614, Aswath Govindraju wrote:
> Hi Vignesh,

> 

> On 12/06/21 12:51 pm, Vignesh Raghavendra wrote:

> > +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? 

> > 

> > 

> 

> The reason for leaving the hole at 0x701C0000-0x701DFFFF was because

> initially there was a bug in SYSFW which lead to the usage of the above

> region too by it. However, this bug was recently fixed and the the above

> region can be used for ATF.



OK. I am going to drop the TF-A update patch from my queue.

NOTE:
a) Default device configuration (if no specific API call[1]) is done
   assumes last 128K is reserved.
b) if bootloader does invoke optionally a call[1] then only 16K is
   reserved for communication and remainder of 128K is released for usage
   with the constraint that TF-A/OPTEE takes control of security resources.
c) This is only a feature in AM64x devices so, handling is device
   specific.

Hence, on AM64x: (a) should be our default configuration and (b) can
be board specific configuration OR overlay depending on bootloader
capability.

[1] http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handover
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
diff mbox series

Patch

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 {