Tool/software:
Hi, Dear Expert
This is concept question, need your double check
We have an sample code (Reset Isolation - MCU Domain), I think it's FFI (freedom from interference) demo, isn't?
When MCU enter Reset Isolation (FFI?!),
(1) Main and MCU domain peripheral can not access each other, isn't
(2) Any IPC service (ex:RPMSG) will be disable, isn't?
Thank You.
Gibbs
We have an sample code (Reset Isolation - MCU Domain), I think it's FFI (freedom from interference) demo, isn't?
Hello Gibbs,
Yes, you are correct.
The above example can be used to showcase that the MCU domain can still be isolated from the MAIN domain after the Reset.
(1) Main and MCU domain peripheral can not access each other, isn't
Yes, by default, in the Reset Isolation MCU+SDK example , the cross domain peripherals usage is restricted.
So, that IPC does not work out in between the cores.
But if the customer wants the Reset isolation along with the IPC and Cross domain peripherals, then we can configure the MCU domain as Partially Isolated.
In this mode , the MCU core will still be isolated when the MAIN domain gets the Reset and cross domain peripherals usage is allowed.
If you control these flags below, then the cross domain peripherals usage will work and the MCU core gets isolated from the MAIN domain after the Reset.
pscMain2MCUDisable = 0;
/* Disabling MCU2Main PSC. This would restrict the MCU domain from accessing
Main domain peripherals/registers. Care must be taken no MCU domain cores access
Main domain registers after this */
pscMCU2MainDisable = 0;
Regards,
Anil.
Hi, Anil
Thanks your suggestion
Follow your comment,
>> copy M4F DRAM data to the DDR for the IPC resource table memory.
Ref this link,
I assume we do not have SW API for "IPC resource table" backup or restore, so we need to implement this function by ourselves, isn't?
I think IPC resource table is located in address 0x9cb00000 + 1MB length, isn't?
I think the story should be like as below with "FFI + MCU reset A Core"
(1) Set these parameter in MCU SW. this can let MCU M4 core warn reset A Core
pscMain2MCUDisable = 0; pscMCU2MainDisable = 0
(2) If A core know system go to FFI, A Core (Linux) should be backup "IPC resource table" in any storage in any time. (ex, eMMC)
(3) Once A core reset happen by M core trigger, U-BOOT or SBL(TIBOOT3) should be restore "IPC resource table" to DDR first
(4) Basically, M core does not need to reload firmware and keep RPMsg communication in this case
If some thing wrong, please correct me.
Thank You again
Gibbs
Hello Anil,
1.The first image is the example code,the second is my code.
I set the values of pscMCU2MainDisable and psMCU2DMDisable to 0, because a value of 1 for these parameters will cause me to not see subsequent logs.
share the M4F core example with only the Reset Isolation code to look at your code changes
.
2.We start the M4 core in the Uboot phase.
which is the boot mode you are using
3.The version is 10.00.00.14.
which version of MCU+SDK you are using
Regards,
Devin.
Hello Anil,
1.In the second image above, there is the backup of the resource table using memcopy and the recovery of the resource table after reset SOC.
where you are doing the memcopy operation for the Linux table and how they are recovering once the Reset is happened
I'm really sorry. Due to consulting security and company regulations, I can't share the whole project with you, but I can share with you the test code I used. I combined RPMSG routine with warm reset routine to test whether the communication can be restored after reset.
2.The boot mode is emmc.
I am asking for which boot mode is it OSPI or emmc. or SD boot mode ?
Regards,
Devin.
Hello Anil,
1.I didn't make any changes to the resetRealsr function.
Please share the snippet of the resetReqIsr function as well.
2.After the code : localAddr = AddrTranslateP_getLocalAddr(table_addr);
Log printing:Table Addr:0x9CC00000 => Local Address:0x9CC00000,Is this address translation correct?
the local address has the DDR content at the 0x9CC00000 location.
3.I share you all the RAT and MPU configurations.
checking your RAT and MPU region settings
RAT:
MPU:
4.I would like to ask how to do it in detail. Should it be configured in linker.cmd or should it allocate a 4K space in the code,or some other way?
allocate a 4KB dedicated memory location for storing DDR Linux tables in to the M4F RAM
Regards,
Devin.
Hello Devin,
The current code above changes do not work because data is being copied to the M4F RAM from DDR .
However, we do not know whether this reset has been fully propagated or not .
If the SoC goes through a reset, it starts from the RBL → SBL → Application sequence.
During this process, we must wait for DDR initialization.
Once DDR initialization is complete, we need to move the local M4F memory to DDR.
This step should be performed at SBL Stage 2, before the A53 core runs.
Step 1: Define a 4KB Memory for Storing the Linux Table
Modify the linker command file to define a dedicated memory region:
M4F_DRAM_LINUX_BAKUP_TABLE : ORIGIN = 0x00030000 , LENGTH = 0x1000
M4F_DRAM : ORIGIN = 0x00031000 , LENGTH = 0xF000
.bss.ipc_backup_linux_table (NOLOAD) : {} > M4F_DRAM_LINUX_BAKUP_TABLE
Step 2: Convert DDR Address Space to Local Memory View
Use RAT (Region Address Translation) and the Address Translate Function to convert DDR address space to local memory.
• The existing above RAT configuration seems correct.
• You can verify it by checking if the local memory address correctly reflects DDR content or not .
Step 3: Access MAIN Domain Peripherals from the MCU Domain
• The MAIN2MCU and MCU2MAIN bridge flags are correctly set, and no changes are required.
• All MAIN2MCU and MCU2MAIN bridge flags remain unchanged.
Step 4: Move DDR Content to the M4F Core
• After initializing the M4F core, copy the DDR content to the M4F core.
• This needs to be done only once and does not require repeated execution.
Step 5: Move M4F DRAM Memory to DDR
• This step should be executed just before the Linux core runs (SBL Stage 2).
The M4F DRAM memory is located at 0x30000 in M4F memory view .
When DM R5F needs to use this memory, it should reference at 0x05040000.
Modify the code as follows:
#define IPC_LINUX_TABLe_BACKUP
if (Bootloader_socIsMCUResetIsoEnabled())
{
#ifdef IPC_LINUX_TABLe_BACKUP
memcpy(0x05040000,0x9CC00000,0x1000);
#endif
}
Step 6: Compile and Flash the Software
• Compile SBL and Applications.
• Flash SBL and Applications
Please let me know if you need any further clarifications.
Please share the Test Results .
Regards,
Anil
HI Anil:
Should I change the device tree to match the linker mapfiles` change?
Hello Gibbs/Dev,
I looked at the bootflow of AM62X. Please look at the link below.
Here, the DM firmware is running before the b-boot and A53 Linux starts.
So, instead of doing the 5th step in the SBL or u-boot, we can move this step to the DM Firmware application.
This also works for you.
Now, you should follow the same steps below except step 5 and step 6.
Step 5 :
Take the DM R5F example, which is already you are using in your application.
In that application, do the MEMCPY call after all the driver init.
Customer need to integrate #include changes as well in the DM R5F Application to fix the compiler erros.
Compile the DM R5F application
Step 6 :
After completing the DM R5F application,
Flash the updated DM application.
Please follow all these steps. If still do not work out in customer Hw , I can connect to online debug.
Step 1: Define a 4KB Memory for Storing the Linux Table
Modify the linker command file to define a dedicated memory region:
Fullscreen123M4F_DRAM_LINUX_BAKUP_TABLE : ORIGIN = 0x00030000 , LENGTH = 0x1000M4F_DRAM : ORIGIN = 0x00031000 , LENGTH = 0xF000.bss.ipc_backup_linux_table (NOLOAD) : {} > M4F_DRAM_LINUX_BAKUP_TABLEStep 2: Convert DDR Address Space to Local Memory View
Use RAT (Region Address Translation) and the Address Translate Function to convert DDR address space to local memory.
• The existing above RAT configuration seems correct.
• You can verify it by checking if the local memory address correctly reflects DDR content or not .Step 3: Access MAIN Domain Peripherals from the MCU Domain
• The MAIN2MCU and MCU2MAIN bridge flags are correctly set, and no changes are required.
• All MAIN2MCU and MCU2MAIN bridge flags remain unchanged.Step 4: Move DDR Content to the M4F Core
• After initializing the M4F core, copy the DDR content to the M4F core.
• This needs to be done only once and does not require repeated execution.
Regards,
Anil.
Hi, Devin
I think you need to reference these two link first, because I think you may have concept problem for SBL/SPL boots.
I think Anil is right,
Once main domain (SoC) reset, it will reload DM R5 FW & SYSFW, and then start SPL (u-boot) later.
So the best way (timing) is try to do recover IPC resource table is in DM R5.
Because in this step, DDR is already finish init.
by the way, I do not receive you slides (PPT)
I can arrange another personal meeting with you when I get your slides.
Gibbs
Hello Devin,
The added patch does not create any problems with your low-power mode of operation and this is just moving data from DDR memory to M4F RAM during the DM FW initiations and not in runtime.
Typically, if you use the MCU+SDK 10 version in your application, then take the DM example from the path below.
C:\ti\mcu_plus_sdk_am62x_10_00_00_14\examples\drivers\ipc\ipc_rpmsg_echo\am62x-sk
Step 5 :
Take the DM R5F example, which is already you are using in your application.
In that application, do the MEMCPY call after all the driver init.
Customer need to integrate #include changes as well in the DM R5F Application to fix the compiler erros.
Compile the DM R5F application
Later, add the above my patch into the DM R5F application.
Compile the DM R5F application
Finally, load the DM R5F update bin file from the Linux core.
https://dev.ti.com/tirex/explore/node?node=A__AXsPVjrUN0EAU1ezb.8iuQ__AM62-ACADEMY__uiYMDcq__LATEST
Regards,
Anil.
Hello Anil / Gibbs，
Typically, if you use the MCU+SDK 10 version in your application, then take the DM example from the path below.
C:\ti\mcu_plus_sdk_am62x_10_00_00_14\examples\drivers\ipc\ipc_rpmsg_echo\am62x-sk
The example we used has a different path than yours,
C:\ti\mcu_plus_sdk_am62x_10_00_00_14\examples\drivers\ipc\ipc_rpmsg_echo_linux\am62x-sk-lp\r5fss0-0_freertos
May I ask if this path is also OK？
Finally, load the DM R5F update bin file from the Linux core.
To which directory should we push the .out file generated after compilation？
@Gibbs,I would like to reply to your question in the PPT here：
[Gibbs]:Why not use uint64_t?? Is it wrong?
As you can see from the LOG, if you use uint64_t, the translated address output is 0.
But if I use uint32_t, its translated address is 0x9CC00000.
[Gibbs]:Why not use Rpmessage_ResourceTable memcopy?
How about erase Rpmessage_ResourceTable in DDR, and check IPC works or not? If IPC works failed, it means you copy the right memory region.
I printed the address of Rpmessage_ResourceTable, which is actually 0x9CC00000.
And I used your test method.When I erase localAddr, RPMessage failed to initialize.
As you can see from the log, the address is correct.
Regards,
Devin.
Hello Gibbs,
The above steps are correct.
@Devin, please follow the steps below. Here, the steps belong to CDD_IPC integration and the same procedure is valid for your use case as well.
First, you need to compile the above IPC example in the release build, and you will get the .out file.
Later, from the link below, you can follow the steps from 5 to 12.
Please let me know if you stuck anywhere .
Regards,
Anil.