AM6548: tiboot3.bin doesn't boot.

Hi Adish,

Please share the exact code change. So that I can reproduce on my local setup.

Also couple of questions:

1) Which SDK version are you using?
2) What is the silicon version?

Best Regards,
Keerthy

Hi Keerthy,

The changes I made is I added the debug prints.

I cloned the u-boot sources from the following repo : http://git.denx.de/u-boot.git

Below is the patch.

diff --git a/include/common.h b/include/common.h
index f0679ac705..f636ea76f1 100644
--- a/include/common.h
+++ b/include/common.h
@@ -33,4 +33,7 @@
 # include <env_internal.h>
 #endif
 
+#define DEBUG 1
 #endif /* __COMMON_H_ */

This increased my tiboot3 size, more than 160 KB.

I am using AM654x - Revision 1.0 EVM.

Hi Adish,

Can you try the same with the SDK 7.1: https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/index_FDS.html

Typically i am seeing size around 148KB.

Regards,
Keerthy

Hi Keerthy,

I used the same SDK version (ti-processor-sdk-linux-am65xx-evm-07_01_00_17).

With DEBUG enable, size of the tiboot3.bin is 172 KB.

Without DEBUG, size is 148 KB as you mentioned.

When the size goes above 150 KB, tiboot3 doesnt boot.

Attached tiboot3_with_Debug.bin and tiboot3_no_debug.bin inside tiboot3_images.zip for your reference. Also, why does tiboot3 doesnt work when its size goes above 150 KB, any specific reason ?

Thanks and regards,

Adish PV

tiboot3_images.zip

Adish,

Your findings are absolutely valid. I checked with our internal experts.
The available internal memory of R5F which is booted by tiboot3.bin aka R5 SPL is around 512KB.
Some of it is allocated for RoM libraries. Rest is divided between SPL image, BSS, Stack, Heap etc.

So ~160-170 KB is the limit.

Hope you can resolve this issue.

Best Regards,
Keerthy

Hi Keerthy,

Thank you for your response. 

My actual requirement is to load  R5 firmware, to avoid R5 core going to low power state (wfe) after A53 initialization.

To enable the actual load_firmware function,  enabled the configurations CONFIG_FS_LOADER and CONFIG_SPL_ENV_SUPPORT in the am65x_evm_r5_defconfig. file.

Even this changes increasest tiboot3.bin size to around 165 kb and it doesn't work.

So how do i accommodate the load firmware changes, Is there a way to increase the permissible size for R5 SPL image ?

Hi Adish,

TI SDK doesn't support loading of MCU R5 firmware from R5 SPL on AM65x SoCs. AM65x has only one R5F cluster, which is also the boot R5F. It comes up in a pre-configured mode (like ATCM is disabled, in LockStep-mode by default on such eFused devices) with R5 SPL running on it. R5 SPL cannot itself load a complete different firmware and do a reset cycle to run that firmware. The WFE is actually a h/w requirement to be able to shutdown the R5F so that it can then be booted up (and possibly reconfigured) from A53 U-Boot or A53 Linux kernel. 

Is there a reason why you want MCU R5 application firmware to be running from R5 SPL itself? Can you not use A53 U-Boot to load the MCU R5F with your application firmware. And do understand that you will be stuck in LockStep-mode without a means to reconfigure the cluster into Split-mode. It is possible to do a branch-only boot (load some firmware and branch to it, no full reset cycle), but your firmware has to play well with R5 SPL code and vectors and MPU settings, and will be stuck in the same mode that ROM brings out the core in. You would have to copy some code for 7.1 SDK J721E into AM65x to achieve it.  

regards

Suman 

Hi Suman,

Our requirement is to control the A53 core standalone reset by A53 core itself ( not the system wide reboot ) without disturbing the R5 core firmware execution.

So, we want to load R5 firmware ( without R5 core full reset ) by R5 SPL after the A53 core initialisation. Also,  A53 standalone reset by A53 core itself should not disturb the R5 core firmware execution.

Thanks and Regards,

Adish P V 

Hi Adish,

Yeah ok, thanks for the background. You are in the right direction with enabling those KConfig options. Additionally, you would need to define the env variables for the firmware load addr and size, 'mcur5f0_0loadaddr' and 'mcur5f0_0fwname' in the AM65x config files. See the reference done on J721E in 

regards

Suman

Hi Suman,

Thank you for your reply.

We are now working with the J721E EVM to understand and explore more on the R5 SPL loading R5 core firmware and boot.

We compiled the ti-processor-sdk-rtos-j721e-evm-07_02_00_06 version SDK U-Boot source code for the J721E EVM R5 SPL binary.

Using tisdk-default-image-j7-evm.tar.xz as a Root file system.

In the file arch/arm/mach-k3/common.c

function: jump_to_image_no_args

 if (!fit_image_info[IMAGE_ID_DM_FW].image_start)
                size = load_firmware("mcur5f0_0fwname", "mcur5f0_0loadaddr",
                                     &loadaddr);

Above if statement is false and not calling the load_frimware function.

fit_image_info[IMAGE_ID_DM_FW].image_start holds value 0xa0000000 ( not of this value is 0 )

In the tisdk-default-image-j7-evm.tar.xz root file system has firmware  /lib/firmware/j7-mcu-r5f0_0-fw -> pdk-ipc/ipc_echo_testb_mcu1_0_release_strip.xer5f and same path set with the mcur5f0_0fwname in R5 SPL.

So, is there anything else we need to enable or take care to load and boot the R5 core firmware/application from R5 SPL?

Is it possible to load and boot the diag application( present In ti-processor-sdk-rtos-j721e-evm-07_02_00_06/pdk_jacinto_07_01_05_14/packages/ti/board/diag/ )  like diag_led or diag_uart by R5 SPL with the above method ?

Means, is it okay to replace the j7-mcu-r5f0_0-fw in the filesystem with diag applications compiled fo R5 MCU 0 core?

Thank you for looking into this.

Thanks and Regards,

Ravikiran J J

Hi Ravikiran,

There is a change between 7.0 SDK and 7.1 SDK for J721E (and J7200). The System Firmware functionality is now split between the M3 core and the MCU R5 core. The MCU R5 firmware is now combined with the U-Boot images and is incorporated as a FIT image. If you are using J721E just to understand the flow, I will recommend you guys to stick with the 7.0 SDK.

PDK is our RTOS-side code primarily, and not all firmwares built there can be dropped in as is to use with Linux. The Linux remoteproc has some firmware requirements like a .resource_table section, with a virtio device entry and a trace entry.

The MCU R5F firmwares also have special restrictions to play well with R5 SPL and the cluster configuration that the ROM brings out the core in. Starting from 7.1, all MCU R5F firmwares on J721E and J7200 also need to include the split-portion of the System Firmware pieces.

regards

Suman

Hi Suman,

We are using the 7.0 SDK now for J721E EVM R5 SPL compilation.

We observed the firmware load successful with the debug prints and R5 core is not going to low power state or WFE.

Currently, R5 SPL is loading the firmware present in the filesystem /lib/firmware/j7-mcu-r5f0_0-fw -> pdk-ipc/ipc_echo_testb_mcu1_0_release_strip.xer5f and same path is set with the mcur5f0_0fwname in the R5 SPL too.

We would like to know is there anyway or any application  which are meant for R5 SPL in the SDK,  with which we can confirm the application boot after the firmware load in the R5 SPL.

We would like understand the AM65X SDK load firmware support and  size constraint issue that we reported earlier in the same thread.

Thanks and Regards,

Ravikiran J J

Hi Ravikiran,

ipc_echo_testb_mcu1_0_release_strip.xer5f is the basic IPC example firmware, but customized to boot with R5 SPL and using BTCM (the b in testb stands for BTCM). You can boot all the way to kernel, and either look through the remoteproc traces or by running an rpmsg kernel sample (once kernel detects the core in IPC-only mode and initializes the IPC).

cat /sys/kernel/debug/remoteproc/remoteprocX/trace0, where X is the dynamically created remoteproc number.

modprobe rpmsg_client_sample count=10 (should exchange 10 messages with all the booted cores including MCU R5F)

Alternatively, you can look up the trace address from the resource table, and use a md at U-Boot prompt to see the traces. This ofcourse relies on the firmware image using traces in memory. To get the trace buffer address from a booted core, you can look up the trace entry from its resource table from sysfs.

cat /sys/class/remoteproc/remoteprocX/resource_table.

regards

Suman

Hi Suman,

Thank you for your response.

On trying to enable firmware load, in R5 SPL for AM65xx, size goes up to 165 KB and it doesn't boot.

We enabled CONFIG_FS_LOADER and CONFIG_SPL_ENV_SUPPORT in the defconfig.

Please suggest a solution for the above issue.

Regards,

Adish PV

Hi Adish,

Could you please share the sizes of booting Vs non-booting tiboot3.bin?

We can try disabling configs that are not critical for boot. What is the delta in size that
you are getting to with enabling CONFIG_FS_LOADER and CONFIG_SPL_ENV_SUPPORT in the defconfig.

Best Regards,
Keerthy

Hi Adish,

I managed to enable FS_LOADER and the configs that were causing a size increase.
I disabled the non-critical CONFIGS from the defconfig and reduced the size to a boot friendly size.

Here is the patch: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_configs_2D00_am65x_5F00_evm_5F00_r5_5F00_defconfig_2D00_Delete_2D00_non_2D00_critical_2D00_c.patch

Hope this unblocks you.

Best Regards,
Keerthy

Hi Adish,

I managed to enable FS_LOADER and the configs that were causing a size increase.
I disabled the non-critical CONFIGS from the defconfig and reduced the size to a boot friendly size.

Here is the patch: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0412.0001_2D00_configs_2D00_am65x_5F00_evm_5F00_r5_5F00_defconfig_2D00_Delete_2D00_non_2D00_critical_2D00_c.patch

Hope this unblocks you.

Best Regards,
Keerthy

Hi Keerthy,

We tried using the above patch in which non-critical configs are removed.

It works fine now and we are able to load the firmware with AM65xx EVM. Appreciate your efforts put into it.

Currently it is using IPC echo test firmware in the PDK. Do we have any other example like LED toggle or UART prints which can be loaded to R5 using SPL to confirm execution is fine ?

Thanks for looking into this matter.

Regards, 

Adish PV

Hi Keerthy,

Currently after enabling R5 firmware load from R5 SPL, firmware is loaded to R5 twice.

Once by R5 SPL and then by remoteproc on linux kernel boot. How can we disable firmware load again by linux remoteproc ?

Also, the above mentioned sysfs entry to check remoteproc trace will not be created if linux remoteproc is disabled. Correct me if I am wrong.

In this case if we disable linux remoteproc, how can we verify firmware load by R5 SPL ?

Thanks and Regards,

Adish PV

Hi Keerthy and Suman,

With the patch provided to reduce the size of tiboot3.bin and additional changes with reference in J721E SDK version 07_00_01 I was able to load the R5 firmware with SPL.

I used ipc_echo_testb_mcu1_0_release_strip.xer5f  from AM65xx PDK as the R5 firmware.

To test the sameI used the debugfs command from linux:

cat /sys/kernel/debug/remoteproc/remoteproc0/trace0

But this did not yield the expected result. It just executed without any error but did not give out any output.

Any thoughts on this ?

Thanks and Regards,

Adish PV

Hi Adish,

Please try attaching CCS to the MCR R5F and check whether it has crashed. Now that you
are able to load firmware from SPL successfully you can use CCS to check
on its execution.

Best Regards,
Keerthy