Thanks for the response,
So, to incorporate the M4 code into the boot container of my iMX8QM I originally followed the instructions on creating a boot container here:
https://developer.toradex.com/linux-bsp/in-depth/build-u-boot-and-linux-kernel-from-source-code/#additional-mandatory-steps-for-specific-socs
these instructions don’t specifically indicate how to incorporate the M4 binary, however, looking at the following page:
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-Boot-process-and-creating-a-bootable-image/ta-p/1101253
I could see that I could command mkimage with the following:
mkimage_imx8 -soc QM -rev B0 -append mx8qmb0-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 ~/build/m40_image.bin 0 0x34FE0000 -out flash.bin
Where ~/build/m40_image.bin is the path to the M4 binary for core 0.
! This all requires that the board.c file of the system controller firmware (SCFW) has been updated to correctly partition the board resources and that a new scfw_tcm.bin is generated and passed to mkimage. My particular M4 binary requires CAN and SPI so my partitioning in board.c looks like this:
/* Create M4 0 partition */
if (rm_is_resource_avail(SC_R_M4_0_PID0) != SC_FALSE)
{
sc_rm_mr_t mr;
/* List of resources */
static const sc_rsrc_t rsrc_list[9U] =
{
SC_R_SYSTEM,
SC_R_IRQSTR_M4_0,
SC_R_MU_5B,
SC_R_MU_7A,
SC_R_MU_8B,
SC_R_GPT_4,
SC_R_SECO_MU_4,
SC_R_SPI_0,
SC_R_CAN_0
};
/* List of pads */
static const sc_pad_t pad_list[6U] =
{
RM_RANGE(SC_P_M40_I2C0_SCL, SC_P_M40_GPIO0_01),
RM_RANGE(SC_P_FLEXCAN0_RX, SC_P_FLEXCAN0_TX),
RM_RANGE(SC_P_SPI0_SCK, SC_P_SPI0_SDI)
};
Now, this will create the boot container as flash.bin this should then be renamed as imx-boot and can replace the same file in the TEZI archive or what I prefer to do is use the UUU utility and just flash the container directly onto my system.
Now, without modifying the u-boot enviroment variables this will fail on boot. The reason can be seen by looking at the file apalis-imx8.h in the u-boot-toradex source (Current version here) and looking at how the memory is mapped, up until and including 5.3.0 it looked like this (taken from apalis-imx8.h):
/**
* SYS_SDRAM_BASE 0x80000000 0.125MiB
* SYS_TEXT_BASE 0x80020000 2.375MiB
* kernel_addr_r 0x80280000 45.5MiB
* fdt_addr_r 0x83000000 1MiB
* scriptaddr 0x83100000 15MiB
* __RESERVED__ 0x84000000 48MiB
* loadaddr 0x870000000 48MiB
* ramdisk_addr_r 0x8A000000 288MiB (to hdp_addr)
* SYS_MEMTEST_START 0x90000000
* hdp_addr 0x9c000000
* SYS_MEMTEST_END 0xC0000000
*/
Now the M4’s (i.e. the SCFW) is assigned memory between 0x8800000 to 0x9000000 and then RPMSG and a few other devices use up to 0x96000000. So there is a conflict with loadaddr and the ramdisk.
So the solution I found here: https://community.toradex.com/t/i-mx8qm-u-boot-is-conflicting-with-m4-0-m4-1-ddr-aliasing-memory-region/14087, that is to shift the load address to 0xa000000 and the ramdisk to 0xa3000000. On 5.4.0 onwards therre is an update to apalis-imx8.h and the memory map looks like:
/**
* SYS_TEXT_BASE 0x80020000 47.9MiB
* fdt_addr_r 0x83000000 1MiB
* scriptaddr 0x83100000 15MiB
* decoder_boot 0x84000000 4MiB
* encoder_boot 0x86000000 4MiB
* loadaddr 0x87000000 48MiB
* Tezi DTB 0x87000000 48MiB
* Tezi overlays 0x870F0000 48MiB
* M4 (FreeRTOS) 0x88000000 128MiB
* ramdisk_addr_r 0x8a000000 96MiB
* SYS_MEMTEST_START 0x90000000
* RPMSG/IPU/DSP 0x90000000 96MiB
* kernel_addr_r 0x96000000 64MiB
* hdp_addr 0x9c000000 64MiB
* SYS_MEMTEST_END 0xC0000000
*/
Which still has clashing memory regions so again I shift the loadaddr and ramdisk to 0xa0000000 and 0xa30000000 respectivly.
So by doing this I can get the kernel to boot fine on all versions of torizoncore and yoctolinux if I don’t add a M4 partition to the boot container. If I do add M4 code and partition the boot container for the M4 code It will boot fine on all versions of the tdx-reference-minimal image up to the current 5.7.0 and on torizoncore up to the 5.3.0 release.
However, on the first 5.4.0 development release of torizoncore the kernel doesn’t start, It gives Starting kernel … and sits there.
I think this points to some change in the torizoncore layer between 5.3.0 to 5.4.0-devel-202108 that prevents the kernel from loading correctly.
I would really love to get this solved so I can update to 5.7.0 and get the benifits of a LTS release.
Thanks for your time.