am243x_evm/am2434: initial support

[natto1784]

This patchset aims to:

• make ti_k3 pinctrl multi-instance
• add soc support for am2434 r5 and m4 cores
• introduce am243x evaluation module as a board

[m-braunschweig]

Thanks for adding the initial Cortex-R5F support. I looked at the changes for it and the main domain and found a few possible improvements that are in the single comments.

Also the NUM_IRQS and SYS_CLOCK_HW_CYCLES_PER_SEC Kconfig options need to be adjusted for this SoC. But to keep the scope of this PR limited I would suggest changing this later by splitting up the Kconfig into multiple files in a different PR.

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

[natto1784]

Hello @m-braunschweig

Also the NUM_IRQS and SYS_CLOCK_HW_CYCLES_PER_SEC Kconfig options need to be adjusted for this SoC. But to keep the scope of this PR limited I would suggest changing this later by splitting up the Kconfig into multiple files in a different PR.

noted

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

I actually saw your documentation from the patchset here a few days ago: TexasInstruments#1 and I must say I am not doing it much differently. We are primarily using sbl_null and sbl_ospi to test out the zephyr ELFs. Additionally I also enable clocks for some modules from the SBL itself - for instance this allows me to use the mcu_uart0 for both m4 and r5

         status = SOC_moduleClockEnable(TISCI_DEV_MCU_UART0, 1);
         status = SOC_moduleSetClockFrequency(
                     TISCI_DEV_MCU_UART0,
                     TISCI_DEV_MCU_UART0_FCLK_CLK,
                     48000000
                     );

For now there is also the need to set the timer clock source manually if I am using a timer different from the SBL.

I appreciate your review and suggestions and will get to working on them tomorrow, might also edit this comment as I remember things.

[m-braunschweig]

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

I actually saw your documentation from the patchset here a few days ago: TexasInstruments#1 and I must say I am not doing it much differently. We are primarily using sbl_null and sbl_ospi to test out the zephyr ELFs.

Ok. Did you do any modifications for using sbl_ospi? Because you have the exception vector on the start of the SRAM partition of the core while I put it to 0x0 and I needed to change the bootloader for it to boot (which I don't really like).

[natto1784]

Ok. Did you do any modifications for using sbl_ospi? Because you have the exception vector on the start of the SRAM partition of the core while I put it to 0x0 and I needed to change the bootloader for it to boot (which I don't really like).

For R5, did nothing, the vector table at the start of SRAM (0x70000000) gets relocated to 0x0 via z_arm_relocate_vector_table

For M4, you need to set the CONFIG_KERNEL_ENTRY="__start" since that is how it's configured in SBL

edit: actually just realised i had set ROMSTART_RELOCATION_ROM earlier in the local board defconfig, forgot about it. for future readers, what @m-braunschweig says above is correct.

[m-braunschweig]

The relocation itself wasn't the problem in my case. It was either parsing or setting the entryPoint via the DMSC-L which is why I hardcoded it. I will look at this again later to see, if it is really necessary or whether there was something else going on

[glneo]

This looks correct, but it is a fix unrelated to this refactor. Should this go in its own commit?

[natto1784]

I think it's fine if it does not affect other boards negatively

[m-braunschweig]

Seems good except the small typo in the model property (I will already approve it anyway, since it's only a minor thing).
With the compatible property I'm also with how it currently is

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarQube Cloud