| Message ID | 20210528144718.25132-5-s-anna@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add R5F nodes on TI K3 AM64x SoCs | expand |
Hi Suman, On 5/28/21 8:17 PM, Suman Anna wrote: > +&oc_sram { > + main_r5fss0_core0_sram: r5f-sram@40000 { > + reg = <0x40000 0x40000>; > + }; > + > + main_r5fss0_core1_sram: r5f-sram@80000 { > + reg = <0x80000 0x40000>; > + }; > + > + main_r5fss1_core0_sram: r5f-sram@c0000 { > + reg = <0xc0000 0x40000>; > + }; > + > + main_r5fss1_core1_sram: r5f-sram@100000 { > + reg = <0x100000 0x40000>; > + }; > +}; > + Now that ATF is being moved to end of SRAM[1], is it possible to move these allocations closer to that ATF reserved location? This will provide one large contiguouos memory at the beginning of SRAM which can be used as generic pool. Right now there are two dis-contiguous pool (256K@0 and ~384K@140000) which is not very efficient use of SRAM. [1] http://kahuna.dhcp.ti.com:8000/project/arm64-ti-dts/patch/20210607133806.18158-1-a-govindraju@ti.com/
On 09:47-20210528, Suman Anna wrote: > Reserve some portions of the MAIN domain on-chip SRAM for use by various > R5F cores on AM642 EVM and SK boards. A bank (256 KB) each is reserved > from the on-chip SRAM for each R5F core. This is done through specific > child SRAM nodes in the board dts file. > > The memory regions are also assigned to each R5F remoteproc node using > the sram property. The reserved SRAM banks are as follows for each core: > Main R5FSS0 Core0 : OCSRAM1 > Main R5FSS0 Core1 : OCSRAM2 > Main R5FSS1 Core0 : OCSRAM3 > Main R5FSS1 Core1 : OCSRAM4 > > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Ming Wei <mwei@ti.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > Link: https://lore.kernel.org/r/20210528144718.25132-5-s-anna@ti.com > --- > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++++++++++++++++++++++ > arch/arm64/boot/dts/ti/k3-am642-sk.dts | 22 ++++++++++++++++++++++ > 2 files changed, 44 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts > index 4d0b3f86525e..083df636d7ff 100644 > --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts > +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts > @@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 { > }; > }; > > +&oc_sram { > + main_r5fss0_core0_sram: r5f-sram@40000 { > + reg = <0x40000 0x40000>; > + }; > + > + main_r5fss0_core1_sram: r5f-sram@80000 { > + reg = <0x80000 0x40000>; > + }; > + > + main_r5fss1_core0_sram: r5f-sram@c0000 { > + reg = <0xc0000 0x40000>; > + }; > + > + main_r5fss1_core1_sram: r5f-sram@100000 { > + reg = <0x100000 0x40000>; > + }; > +}; We need to relook at these addresses -> please see the series from Vignesh[1] and Ashwath[2]. 0x0 <-> 0x1a0000 is free 0x1a0000 <-> 0x1bc000 -> TF-A 0x1bc000 <-> 0x1c0000 -> Free 0x1c0000 <-> 0x200000 -> Seems to be sysfw? [1] https://lore.kernel.org/linux-devicetree/20210609140604.9490-1-vigneshr@ti.com/ [2] https://lore.kernel.org/linux-devicetree/162343800075.7434.10921347563461214925.b4-ty@ti.com/
Hi Vignesh, Nishanth, On 6/11/21 2:13 PM, Nishanth Menon wrote: > On 09:47-20210528, Suman Anna wrote: >> Reserve some portions of the MAIN domain on-chip SRAM for use by various >> R5F cores on AM642 EVM and SK boards. A bank (256 KB) each is reserved >> from the on-chip SRAM for each R5F core. This is done through specific >> child SRAM nodes in the board dts file. >> >> The memory regions are also assigned to each R5F remoteproc node using >> the sram property. The reserved SRAM banks are as follows for each core: >> Main R5FSS0 Core0 : OCSRAM1 >> Main R5FSS0 Core1 : OCSRAM2 >> Main R5FSS1 Core0 : OCSRAM3 >> Main R5FSS1 Core1 : OCSRAM4 >> >> Signed-off-by: Suman Anna <s-anna@ti.com> >> Signed-off-by: Ming Wei <mwei@ti.com> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> Link: https://lore.kernel.org/r/20210528144718.25132-5-s-anna@ti.com >> --- >> arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++++++++++++++++++++++ >> arch/arm64/boot/dts/ti/k3-am642-sk.dts | 22 ++++++++++++++++++++++ >> 2 files changed, 44 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts >> index 4d0b3f86525e..083df636d7ff 100644 >> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts >> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts >> @@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 { >> }; >> }; >> >> +&oc_sram { >> + main_r5fss0_core0_sram: r5f-sram@40000 { >> + reg = <0x40000 0x40000>; >> + }; >> + >> + main_r5fss0_core1_sram: r5f-sram@80000 { >> + reg = <0x80000 0x40000>; >> + }; >> + >> + main_r5fss1_core0_sram: r5f-sram@c0000 { >> + reg = <0xc0000 0x40000>; >> + }; >> + >> + main_r5fss1_core1_sram: r5f-sram@100000 { >> + reg = <0x100000 0x40000>; >> + }; >> +}; > These addresses are currently in sync with the corresponding firmware linker map files. Any changes needed here should also be aligned and updated with all the firmwares then. Nishanth, How about dropping this patch until we conclude the discussion and picking up the rest? > We need to relook at these addresses -> please see the series from > Vignesh[1] and Ashwath[2]. > > 0x0 <-> 0x1a0000 is free > 0x1a0000 <-> 0x1bc000 -> TF-A > 0x1bc000 <-> 0x1c0000 -> Free > 0x1c0000 <-> 0x200000 -> Seems to be sysfw? Looking at the dicussion on v1, I am confused. Is the default reservation size for SYSFW 0x40000 (256K) or 0x20000 (128K)? The v2 of the SYSFW SRAM reservations is still using 256K at 0x1c0000 offset. > > > [1] https://lore.kernel.org/linux-devicetree/20210609140604.9490-1-vigneshr@ti.com/ > [2] https://lore.kernel.org/linux-devicetree/162343800075.7434.10921347563461214925.b4-ty@ti.com/ >
On 13:05-20210614, Suman Anna wrote: > >> +&oc_sram { > >> + main_r5fss0_core0_sram: r5f-sram@40000 { > >> + reg = <0x40000 0x40000>; > >> + }; > >> + > >> + main_r5fss0_core1_sram: r5f-sram@80000 { > >> + reg = <0x80000 0x40000>; > >> + }; > >> + > >> + main_r5fss1_core0_sram: r5f-sram@c0000 { > >> + reg = <0xc0000 0x40000>; > >> + }; > >> + > >> + main_r5fss1_core1_sram: r5f-sram@100000 { > >> + reg = <0x100000 0x40000>; > >> + }; > >> +}; > > > > These addresses are currently in sync with the corresponding firmware linker map > files. Any changes needed here should also be aligned and updated with all the > firmwares then. > > Nishanth, > How about dropping this patch until we conclude the discussion and picking up > the rest? Lets skip this patch for this merge cycle - aka stay compatible with the previous reference binaries that do not use OCSRAM (aka not pick up 4x latency improvement), till we figure out a future looking and relatively stable memory map that considers: a) R5s IPC RAM + future usage: b) M4F IPC RAM c) ICSSG buffer RAMs
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts index 4d0b3f86525e..083df636d7ff 100644 --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts @@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 { }; }; +&oc_sram { + main_r5fss0_core0_sram: r5f-sram@40000 { + reg = <0x40000 0x40000>; + }; + + main_r5fss0_core1_sram: r5f-sram@80000 { + reg = <0x80000 0x40000>; + }; + + main_r5fss1_core0_sram: r5f-sram@c0000 { + reg = <0xc0000 0x40000>; + }; + + main_r5fss1_core1_sram: r5f-sram@100000 { + reg = <0x100000 0x40000>; + }; +}; + &main_r5fss0_core0 { mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>; memory-region = <&main_r5fss0_core0_dma_memory_region>, <&main_r5fss0_core0_memory_region>; + sram = <&main_r5fss0_core0_sram>; }; &main_r5fss0_core1 { mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>; memory-region = <&main_r5fss0_core1_dma_memory_region>, <&main_r5fss0_core1_memory_region>; + sram = <&main_r5fss0_core1_sram>; }; &main_r5fss1_core0 { mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>; memory-region = <&main_r5fss1_core0_dma_memory_region>, <&main_r5fss1_core0_memory_region>; + sram = <&main_r5fss1_core0_sram>; }; &main_r5fss1_core1 { mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>; memory-region = <&main_r5fss1_core1_dma_memory_region>, <&main_r5fss1_core1_memory_region>; + sram = <&main_r5fss1_core1_sram>; }; &main_pmx0 { diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts index 5891e6a05ddf..b388b3ca210a 100644 --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts @@ -387,26 +387,48 @@ &mailbox0_cluster7 { status = "disabled"; }; +&oc_sram { + main_r5fss0_core0_sram: r5f-sram@40000 { + reg = <0x40000 0x40000>; + }; + + main_r5fss0_core1_sram: r5f-sram@80000 { + reg = <0x80000 0x40000>; + }; + + main_r5fss1_core0_sram: r5f-sram@c0000 { + reg = <0xc0000 0x40000>; + }; + + main_r5fss1_core1_sram: r5f-sram@100000 { + reg = <0x100000 0x40000>; + }; +}; + &main_r5fss0_core0 { mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>; memory-region = <&main_r5fss0_core0_dma_memory_region>, <&main_r5fss0_core0_memory_region>; + sram = <&main_r5fss0_core0_sram>; }; &main_r5fss0_core1 { mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>; memory-region = <&main_r5fss0_core1_dma_memory_region>, <&main_r5fss0_core1_memory_region>; + sram = <&main_r5fss0_core1_sram>; }; &main_r5fss1_core0 { mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>; memory-region = <&main_r5fss1_core0_dma_memory_region>, <&main_r5fss1_core0_memory_region>; + sram = <&main_r5fss1_core0_sram>; }; &main_r5fss1_core1 { mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>; memory-region = <&main_r5fss1_core1_dma_memory_region>, <&main_r5fss1_core1_memory_region>; + sram = <&main_r5fss1_core1_sram>; };