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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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
+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 <[email protected]>
>> ---
>> 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
>>
>
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 <[email protected]>
>>> ---
>>> 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
>>>
>>
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