| Message ID | 20210609140604.9490-1-vigneshr@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: ti: k3-am64-main: Add SYSFW reserved ranges in OCRAM | expand |
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> Thanks and regards, Lokesh
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
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.
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 >
+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 >> >
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 >>> >>
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
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 {
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(+)