DRA829J: Set module clock parent via direct registers access

Hi Antonio,

Antonio Pinto said:

However, we want to avoid the usage of Sciclient_pmSetModuleClkParent function to select the value of the multiplexer. We would rather write it directly to the MMR register (CLK_SEL bitfield).

Why do you want to do this, what are your reasons?

Also, what core are you trying to set this from, and for what peripheral?

Antonio Pinto said:

If you have a procedure (including additional steps) to change clock parent with detailed description would be perfect.

No, there is no ready-made procedure available for this in the SDK, 

The TDA4 devices are heterogenous devices with multiple processors, and all Clock and Device Management is centralized under the SciServer managed by the MCU1_0 core.  Some of the mux clocks do drive multiple peripherals, and if you are trying to modify registers directly, then the SoC could hang-up due to incorrect configurations, and mismatched state machine logic. 

regards

Suman

Hi Suman
Thanks for your quick response.

Suman Anna said:

Why do you want to do this, what are your reasons?

Also, what core are you trying to set this from, and for what peripheral?

We are working on a very specific project that requires avoiding the use of Sciclient functions. The goal is to minimize dependencies on the M3 core as much as possible. As a result, we are rewriting all functions related to board configuration.

This configuration is performed by SBL (our costum bootloader) running on the MCU Core and affects all peripherals that we plan to use.

Suman Anna said:

The TDA4 devices are heterogenous devices with multiple processors, and all Clock and Device Management is centralized under the SciServer managed by the MCU1_0 core.  Some of the mux clocks do drive multiple peripherals, and if you are trying to modify registers directly, then the SoC could hang-up due to incorrect configurations, and mismatched state machine logic.

We are aware of it. Nevertheless, we would like to confirm whether SciServer performs any additional actions or verifications when setting the new mux value (besides confirming that frequency is correct).

Here is an overview of the sequence we have implemented:
1. Configure PLLs and set desired frequencies
2. Configure source clocks by setting mux values via direct register access (CLK_SEL bitfield)
3. Power configuration (setting PDs and LPSCs)

Knowing this, do we need to take into consideration any additional steps to select the source clock? (e.g. trigger RST)

Thank you.
António

Hi Antonio,

Antonio Pinto said:

We are working on a very specific project that requires avoiding the use of Sciclient functions.

What end-equipment market is your project/product geared towards?

I still do not see the reasons other than your preference to avoid this. Are you planning not to use the Sciclient library at all? If so, is your usage going to be different between SBL and when the MCU1_0 application is running.

Antonio Pinto said:

The goal is to minimize dependencies on the M3 core as much as possible. As a result, we are rewriting all functions related to board configuration.

The TIFS (DMSC M3) core is very fundamental to the overall Device Boot, and this core needs to be booted before you can proceed further on the overall boot. The TIFS firmware handles all the Security related configuration - including processor boot and firewall configuration. So, you cannot even boot other cores without the TIFS M3 core.

The Board Configuration is used by both the TIFS cores (TIFS firmware becomes ready only after processing these requests), and the MCU1_0 SciServer/Device Management code for the SciClient interface.

Please note that TIFS firmware sets up some initial firewalls as well during its boot covering some of the relevant register regions. Please see J721E Firewall Descriptions for a list of registers covered.

Antonio Pinto said:

This configuration is performed by SBL (our costum bootloader) running on the MCU Core and affects all peripherals that we plan to use.

The overall Clock and PSC configuration is actually owned by the MCU1_0 firmware, and both SBL and MCU1_0 firmwares do use the Sciclient_direct library, which are native library calls on MCU1_0. The Sciclient library is a wrapper here over the lower-level functions implemented within the rm_pm_hal library code.

Antonio Pinto said:

Here is an overview of the sequence we have implemented:
1. Configure PLLs and set desired frequencies
2. Configure source clocks by setting mux values via direct register access (CLK_SEL bitfield)
3. Power configuration (setting PDs and LPSCs)

Knowing this, do we need to take into consideration any additional steps to select the source clock? (e.g. trigger RST)

PLLs are already configured with default frequencies during Sciclient_init within SBL code. Please note that both ROM and TIFS does configure some PLLs as well during their boot, and rest of the PLLs are initialized during the Sciclient initialization within SBL code.

Anyway, these are the same steps that would have been done by SBL within Sciclient_init and any specific source selection. The Power Configuration is the only piece that is handled within each driver as part of init (they all use the Sciclient API).

What all layers are you rewriting overall?

regards

Suman

Hi Suman

Please find my answers below. Note that we have developed our own SBL where board configuration is done.

Suman Anna said:

What end-equipment market is your project/product geared towards?

It is for Aerospace market.

Suman Anna said:

Are you planning not to use the Sciclient library at all?

Yes, we want to avoid that dependence.

Suman Anna said:

What all layers are you rewriting overall?

Besides TIFS (mandatory to boot), we are planning to rewrite everything else.
Therefore, the goal is to minimize dependencies on the M3 core as much as possible.
For this reason we need to confirm correctness of the clock changing procedure to implement on our custom SBL.

So, do you know whether we need to consider extra steps when selecting source clock (besides selecting mux value)?

Thank you.
António

Hi Antonio,

The engineer responsible is currently out of office. Please expect 4 business day delay in response.

Regards,

Takuma

Hi Antonio,

Antonio Pinto said:

It is for Aerospace market.

Ok, thanks for the clarifications. I understand the reasons/needs for this given that this is for Aerospace market.

Antonio Pinto said:

Yes, we want to avoid that dependence.

Are there any parts of the Sciclient layers that you would re-use? Sciclient_direct is a wrapper library over the low-level rm_pm_hal drivers.

Antonio Pinto said:

Besides TIFS (mandatory to boot), we are planning to rewrite everything else.

OK, the SoC has lot of clocks and device information. So, will you be rewriting even the device and clock data as well?

The PLL initialization sequence for example needs to be written very carefully if you are going to rewrite the PLL driver code yourself as well.

TI can only provide generic guidance, and won't be able to provide any debug support for issues that that may be introduced in your code.

Antonio Pinto said:

Therefore, the goal is to minimize dependencies on the M3 core as much as possible.

The TIFS boot still requires that the board configuration data be passed to it, without which it is not in a functionally ready-state. You would need this at the minimum, for supporting

I don't know what your s/w dependencies are for configuring firewalls, or using UDMA between multiple cores. Any firewall setup and processor boot sequences will require the M3 core for sure. Will you be using a GP device or a HS device, and if latter, is this going to be a HS-Prime device (that may allow you to customize TIFS firmware)?

Antonio Pinto said:

So, do you know whether we need to consider extra steps when selecting source clock (besides selecting mux value)?

The Mux selection registers in CTRL_MMR registers may require you to unlock the partition to allow-writing in general. A dedicated peripheral clock selection probably is a simpler change, but you need to be careful with changing PLLs or the PLL Divider Clocks, since they can supply more than one peripheral with different clocking requirements. 

regards

Suman

Hi Suman

Suman Anna said:

Are there any parts of the Sciclient layers that you would re-use? Sciclient_direct is a wrapper library over the low-level rm_pm_hal drivers.

Due to DO-178 certification we need to avoid their usage.

Suman Anna said:

OK, the SoC has lot of clocks and device information. So, will you be rewriting even the device and clock data as well?

The PLL initialization sequence for example needs to be written very carefully if you are going to rewrite the PLL driver code yourself as well.

TI can only provide generic guidance, and won't be able to provide any debug support for issues that that may be introduced in your code.

We are aware of that. We have already re-written most of the code.
PLL initialization is implemented and working.

Suman Anna said:

The TIFS boot still requires that the board configuration data be passed to it, without which it is not in a functionally ready-state. You would need this at the minimum, for supporting

This is under analysis. We are passing the current TI configuration. But in the near future we need to understand which is the minimal configuration needed/passed by/to TIFS.

Suman Anna said:

I don't know what your s/w dependencies are for configuring firewalls, or using UDMA between multiple cores. Any firewall setup and processor boot sequences will require the M3 core for sure. Will you be using a GP device or a HS device, and if latter, is this going to be a HS-Prime device (that may allow you to customize TIFS firmware)?

It will be used as GP device.

Suman Anna said:

A dedicated peripheral clock selection probably is a simpler change

Does it mean we don't need any additional step to select a dedicated clock source? Setting mux value is enough and safe?

Suman Anna said:

but you need to be careful with changing PLLs or the PLL Divider Clocks, since they can supply more than one peripheral with different clocking requirements. 

Yes correct. We take into consideration this limitation while performing PLL initialization.

So, can you confirm the question regarding clock selection please?

Thank you.
António

Hi Antonio,

Antonio Pinto said:

Due to DO-178 certification we need to avoid their usage.

Ok. I understand that this is the Safety certification standard in Aerospace industry at high-level, but am not what it entails in general or what extra details it requires when compared to the Automotive ISO-26262 standard (which is what our RTOS s/w is written for in general).

Antonio Pinto said:

This is under analysis. We are passing the current TI configuration. But in the near future we need to understand which is the minimal configuration needed/passed by/to TIFS.

The main variability is around the RM Board Configuration data, again it would mostly be around how you need to deal with DMA channel separation between different processing cores.

Antonio Pinto said:

It will be used as GP device.

Ok. TIFS will still setup the initial firewalls as per J721E Firewall Descriptions even on a GP device.

Antonio Pinto said:

Does it mean we don't need any additional step to select a dedicated clock source? Setting mux value is enough and safe?

Yes, as long as that mux clock is not driving mutiple peripherals, it would be as simple as that. Hopefully, you would have configured the desired clock rates on the parent clocks as all needed.

Again, given that this is all your implementation and zero re-use from TI clock data, it all depends on how you are dealing with all the leaf clocks.

regards

Suman