PROCESSOR-SDK-AM64X: Triggering a system reset on AM64X

Hi Felix,

The DMSC-M3 is working like a resource manager. It runs the system firmware and provide system services to all R5F cores. When the System reset happens, the ROM bootloader loads and runs the system firmware on DMSC-M3, then initializes DDR, enables all other cores like R5Fs, A53s, M4 etc. After that the R5F0_0 will load the SBL (secondary bootloader) will be load and run. The SBL will then load and run application image for each core and run the application for each core.

What I usually do is flash the SBL NULL into OSPI flash or SD card and the set boot mode for OSPI or SD card boot. To reset, either power cycle the EVM or use the "System Reset" from CCS.

Best regards,

Ming 

Ming Wei said:

then initializes DDR,

Just a minor issue, but are you sure about that? The way I see it DDR memory needs to be initialized by the SBL/U-Boot, i.e. the first "customer" code running on R5F0_0.

Also, I'm not sure if you've answered Felix' question. The way I read it he's got the initial booting sorted out, and now needs a means to explicitly reset the system at runtime.

We've been using the Sciclient_pmDeviceReset() API on AM65x hardware in the past. On the AM64x we're currently directly writing to SW_MAIN_WARMRST in CTRLMMR_RST_CTRL. I believe we ran into issues with Sciclient_pmDeviceReset on the AM64x, but that could have been due to an early SYSFW for example.

I guess what Felix would like to hear (and what I'm interested in as well) is what the recommended way of resetting a running system is. The answer probably depends on what code you're running (I'm assuming MCU+ SDK on R5f cores only, or at least no Linux on A53) and what kind of reset you want (POR/Warm, possibly reset isolation).

The TRM explains the reset features in quite some detail, but the connection to the software offerings is missing, and these are often crucial, since for example our current way of resetting via CTRLMMR_RST_CTRL could break with any new MCU+ release, if that release decides to limit access to these registers to the DMSC.

Regards,

Dominic

EDIT: I believe the reason why we're writing to CTRLMMR_RST_CTRL is that we specifically wanted a warm reset, that kept our isolated MCU (M4) domain running. The TISCI documentation at https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/sysreset.html doesn't support that assumption though, since it says this would trigger a warm reset. But then it says it is SoC dependent, but I couldn't find the SoC specifics for the AM64x, so maybe some insight from your SysFW guys might help.

Hi Dominic,

Thanks a lot for your comments. You are correct. Loading and running the system firmware is done in SBL. 

As of the warm reset for a specific core (such as R5F0_0 or R5F0_1), you can do the following: 

sciclientCpuProcIdCore0 = Bootloader_socGetSciclientCpuProcId(CSL_CORE_ID_R5FSS0_0);
sciclientCpuDevIdCore0 = Bootloader_socGetSciclientCpuDevId(CSL_CORE_ID_R5FSS0_0);
sciclientCpuProcIdCore1 = Bootloader_socGetSciclientCpuProcId(CSL_CORE_ID_R5FSS0_1);
sciclientCpuDevIdCore1 = Bootloader_socGetSciclientCpuDevId(CSL_CORE_ID_R5FSS0_1);
/* hold core0 and core 1 in reset */
status = Sciclient_pmSetModuleRst_flags(sciclientCpuDevIdCore1, 1, 0, SystemP_WAIT_FOREVER);
status = Sciclient_pmSetModuleRst_flags(sciclientCpuDevIdCore0, 1, 0, SystemP_WAIT_FOREVER);
/* release the CPUs */
status = Sciclient_procBootReleaseProcessor(sciclientCpuProcIdCore0, 0, SystemP_WAIT_FOREVER);
status = Sciclient_procBootReleaseProcessor(sciclientCpuProcIdCore1, 0, SystemP_WAIT_FOREVER);
/* release the reset for the CPUs */
status = Sciclient_pmSetModuleRst_flags(sciclientCpuDevIdCore0, 0, 0, SystemP_WAIT_FOREVER);
status = Sciclient_pmSetModuleRst_flags(sciclientCpuDevIdCore1, 0, 0, SystemP_WAIT_FOREVER);

Sciclient_pmDeviceReset() will issue a message TISCI_MSG_SYS_RESET via Sciclient_service(). I have no visibility of how the TISCI_MSG_SYS_RESET is processed b the system firmware. My guess is it will do a main domain warm reset. I need to confirm it with our system firmware developer.

Directly writing to SW_MAIN_WARMRST in CTRLMMR_RST_CTRL seems another good way to do the main domain warm reset.

Best regards,

Ming

Thank you both for answering.
Yes the first answer wasn't exactly an answer to my questions. But the second one is way closer.
So it is good to have the warm-reset feature which just resets the cores but does not explicitly rerun the SBL. At least I understand it like that.
It would be good to know if the other mentioned option Sciclient_pmDeviceReset does a reset which runs the SBL again.
This is somehow important for our Firmware update concept which shall trigger an automatic reset and the nw fw must be loaded by the SBL. And at least if even wanted by user it must be possible to reset the device via firmware without releasing the power connection and have a new boot-up.
And thanks for the hint with the TRM. I guess it will be the Power-On-Reset which will do the job here. The question is if there is already an SCI-function which triggers this option.

Best regards,

Felix

Hi Ming,

but running the RBL which will in fact start the SBL is what I want so this is the function I need. thanks!

Another question here which is linked to the SPINLOCK-Implementation: I once had an issue with not reset SPINLOCKs where Dominik was also involved (hey friend!): https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1008815/processor-sdk-am64x-ccs-cpu-reset-does-not-reset-spinlocks/3728731?tisearch=e2e-sitesearch&keymatch=%25252525252520user%2525252525253A453845#3728731

So the solution is: "I believe your issue can be resolved by sending a software reset to the spinlock module before you use it. Whichever core is the first to run in your multicore application can be responsible for the reset. Or it can be implemented in the bootloader before any of your applications are started."

So a warm reset of a single CPU would in fact lead to a situation where in the worst case the SPINLOCKs can't be used anymore. This makes the warm reset of any CPU unusable if you need the Spinlocks. will there be a solution for that? maybe I need to open another question for this topic.

Best regards,

Felix

Hi Felix,

Yes. It will be better for you to start new thread regarding to the "spinlock and warm reset" issue. Thanks!

I will close this one.

Best regards,

Ming

Hi Ming,

it would be great if you could get us an answer to this:

Ming Wei said:

Sciclient_pmDeviceReset() will issue a message TISCI_MSG_SYS_RESET via Sciclient_service(). I have no visibility of how the TISCI_MSG_SYS_RESET is processed b the system firmware. My guess is it will do a main domain warm reset. I need to confirm it with our system firmware developer.

Everyone who stumbles about this thread in the future should probably wonder what kind of reset this triggers.

Regards,

Dominic

Hi Dominic,

I did answer the behavior of the Sciclient_pmDeviceReset() in previous post: 

Sciclient_pmDeviceReset() issued a system reset which cause the RBL to work.

Best regars,

Ming 

Hello Ming,

Ming Wei said:

Sciclient_pmDeviceReset() issued a system reset which cause the RBL to work.

that is true for both a warm and a POR reset of the main domain. Previously you were a lot more specific, but wanted to confirm that with a system firmware developer:

Ming Wei said:

My guess is it will do a main domain warm reset. I need to confirm it with our system firmware developer.

The details of the different resets are very subtle, see chapter 5.3.5 in the TRM (Rev. C) and its various sub-chapters. It would be great if you could get an answer with a reference to the TRM. The RBL is running in several (most?) of these resets.

Regards,

Dominic

Hi Dominic,

I just checked with the system firmware team. The Sciclient_pmDeviceReset() for AM64x/AM243x is actually doing the warm reset by setting the SW_MAIN_WARMRST (bit 0 -3) of CTRLMMR_RST_CTRL Register (0x18170) to 0x6.

Best regards,

Ming