TDA4AH-Q1: WKUP ROM Code execution on custom board

Hi Arthur,

Arthur Odin said:

we are currently trying to boot from a NOR Flash through the OSPI (In simple-SPI) interface.

Is there a reason you are using only SPI bootmode rather than the OSPI bootmode or the xSPI bootmode? What NOR Flash part are you using?

Arthur Odin said:

The custom .tiimage loaded in Flash is a combined TI-compatible image (i.e. a bootable blob+TIFS+data).

Can you clarify if you are using Linux SPL or RTOS SBL for your bootloader? Also, please confirm the SDK version you are using?

Arthur Odin said:

[On J784s4 EVM] This same .tiimage works ONLY if MCU_Only pin = 0 and TIFS loads fine, however it doesn't work when MCU_ONLY is Up (with this binary or any other for that matter).

Are you seeing the same behavior as your custom board on J784S4 EVM as well?

The TI SDKs do not use or support MCU-only boot-mode. The MAIN domain is needed invariably for DDR and Secure Proxy setups that the TIFS needs to communicate with the cores in the MAIN domain. So, please try with MCU-only boot-mode set to 0 on your custom board. Is there a reason you are only trying MCU-only bootmode? 

Arthur Odin said:

Are there any HW integration constraints to take into account concerning the pinout (which is the only possible thing that changes for RBL or TIFS between a custom board and the EVM) or clocking for a custom board ? This is never mentioned in any documentation that I'm aware of.

The ROM is agnostic of the board, so the pin configurations are expected to the same between TI EVM or any other customer board. ROM also uses specific pinmux configuration/pins for each BootMode, so while the peripheral may have multiple pins, your board design will have to adhere to the pins used by ROM to support boot using that peripheral. The specific pin usage in bootmode is detailed in the TRM in the 4.3 Boot Mode Pins chapter.

Arthur Odin said:

Why is the TIFS behavior different when using MCU_Only = 1 (concerning the Secure Proxy writing) compared to MCU_Only = 0 ?

There are not enough Secure Proxies to establish communication between TIFS and all the other cores. Please see the section J784S4 Secure Proxy Descriptions from the TI-SCI documentation that provides the list of secure proxies used.

Arthur Odin said:

[EDIT] Could you please provide documentation or references relating to the MCU_BOOTMODE[7] OVRD pin that apparently has to be taken into account when dealing with HS devices ?

Please also have this pin as 0 on HS-devices. The note in the TRM is meant to say that this pin is not applicable for GP devices, and requires the pin to be 0.

Please also see this related thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1304422/am69-mcu_bootmode-pin-settings

regards

Suman

Hello Suman,

Thanks for your point-by-point answers, however I'd like to rebound on some of them :

Suman Anna said:

Is there a reason you are using only SPI bootmode rather than the OSPI bootmode or the xSPI bootmode? What NOR Flash part are you using?

Because our custom board is still is development and the xSPI is not functional yet, however SPI is. The NOR Flash is not the same as the EVM, that's all I can say I apologize.

Suman Anna said:

Can you clarify if you are using Linux SPL or RTOS SBL for your bootloader? Also, please confirm the SDK version you are using?

We are using a heavily revised and modified RTOS SBL. It re-uses the "SBL_CombinedBootInit()" routine that works on the EVM (from SDK RTOS 9.2) but not on our custom board.

Suman Anna said:

Are you seeing the same behavior as your custom board on J784S4 EVM as well?

As stated, it displays the same behavior when MCU_ONLY=1, for both our custom board and the EVM. However when MCU_ONLY=0, the TIFS executes (i.e. sends the BOOT_NOTIFICATION message to the MCU_SA3 Thread 5), allowing the rest of the SBL_CombinedBootInit() to continue on the EVM, but NOT on our custom board.

Suman Anna said:

The TI SDKs do not use or support MCU-only boot-mode. The MAIN domain is needed invariably for DDR and Secure Proxy setups that the TIFS needs to communicate with the cores in the MAIN domain. So, please try with MCU-only boot-mode set to 0 on your custom board. Is there a reason you are only trying MCU-only bootmode? 

Reason is to characterise the electrical consumption between the two modes. Again, we were trying both, which led to my questions.

Suman Anna said:

The ROM is agnostic of the board, so the pin configurations are expected to the same between TI EVM or any other customer board. ROM also uses specific pinmux configuration/pins for each BootMode, so while the peripheral may have multiple pins, your board design will have to adhere to the pins used by ROM to support boot using that peripheral. The specific pin usage in bootmode is detailed in the TRM in the 4.3 Boot Mode Pins chapter.

Are all constraints listed in the TRM concerning the booting of the chip, or are there any other documentation we need to be aware of that contain additional infos you can direct me towards ?

Suman Anna said:

There are not enough Secure Proxies to establish communication between TIFS and all the other cores. Please see the section J784S4 Secure Proxy Descriptions from the TI-SCI documentation that provides the list of secure proxies used.

Does that mean that essentially the TIFS contained in the SDK 9.2, which HAS to be loaded onto the chip regardless of the SW Apps and underlying custom hardware with specific constraints cannot work in MCU_ONLY mode eventhough it is a boot option ?

Does that mean we have to power-up the Main Domain in our code in order to get TIFS to effectively configure the additional Secure Proxies ?

Thanks in advance for your additional answers and your help.

Kind regards

Hi Arthur,

Arthur Odin said:

Because our custom board is still is development and the xSPI is not functional yet, however SPI is. The NOR Flash is not the same as the EVM, that's all I can say I apologize.

Understood, SPI is the most basic bootmode with NOR Flashes, but this is practically unused on products. SDKs typically use only OSPI or xSPI modes depending on the Flash part capabillity. Can you try in OSPI BootMode 1s-1s-8s, or even xSPI in the basic 1s-1s-1s boot-mode. Should be faster than the basic SPI mode.

Do you have capabitlity to adjust the bootmode pins like the TI EVM on your board?

Arthur Odin said:

We are using a heavily revised and modified RTOS SBL. It re-uses the "SBL_CombinedBootInit()" routine that works on the EVM (from SDK RTOS 9.2) but not on our custom board.

Thanks for the details. The SBL CombinedBootInit support is SDK is only limited to SDCard and OSPI boot medias, the support is not provided for other bootmodes.

Also, please note that the Combined ROM init mode is not a suitable mode if you were to run PBIST for Safety, as that is destructive, and overrides the setups done by TIFS.

Arthur Odin said:

However when MCU_ONLY=0, the TIFS executes (i.e. sends the BOOT_NOTIFICATION message to the MCU_SA3 Thread 5), allowing the rest of the SBL_CombinedBootInit() to continue on the EVM, but NOT on our custom board.

I am not surprised on the TI EVM behavior with MCU_ONLY=0. This is planned for a future SDK, so until then cannot really test using this configuration.

Arthur Odin said:

Reason is to characterise the electrical consumption between the two modes. Again, we were trying both, which led to my questions.

Understood, thanks for the background.

Arthur Odin said:

Are all constraints listed in the TRM concerning the booting of the chip, or are there any other documentation we need to be aware of that contain additional infos you can direct me towards ?

The BootMode pins and the constraints against each BootMode are all explained in the Initialization chapter of the TRM. There is also a Board EVM Checklist Jacinto7 AM6x/TDA4x/DRA8x Schematic Checklist (Rev. B) that provides some checklist items against bootmode pins.

Arthur Odin said:

Does that mean that essentially the TIFS contained in the SDK 9.2, which HAS to be loaded onto the chip regardless of the SW Apps and underlying custom hardware with specific constraints cannot work in MCU_ONLY mode eventhough it is a boot option ?

Yes, this is a limitation at present until MCU_Only mode is truly supported in our SDK. 

TIFS firmware has to be booted always within the SoC, there is a Watchdog that will get triggered if TIFS is not booted within 180 seconds of SBL being up.

Arthur Odin said:

Does that mean we have to power-up the Main Domain in our code in order to get TIFS to effectively configure the additional Secure Proxies ?

Yes, please follow the sequences used by our SBL code on the EVM.

regards

Suman

Hi Suman,

It was just a HW problem on our end, so nothing really worth sharing. Thanks a lot though.

Cheers