It’s been a while !
Our developpements went well until now. Everything (Linux app on A7, FreeRTOS on M4 side) was running perfectly on our platform.
( We use Toradex MCIMX7D_M4_ddr.ld linker script for M4 since our M4 FW is larger than TCM and OCRAM. )
We started using HAB u-boot.
From that point, M4 did not start again. It seems no code is executed (maybe a reset or starting PC issue) for we cannot see any of its GPIOs initialize. On the other hand, linux kernel is running fine and our app starts properly, saying it cannot start dialog with m4.
HAB security checks are all ok (otherwise kernel wouldn’t start), we made several tests :
- Using m4 signed firmware on a colibri
with no HAB → M4 is running
- Disabling signature check for m4 firmware and using
non-signed m4 FW on colibri with HAB → M4 not running
- Disabling signature checks for all partitions except u-boot so that we use all our non-signed (and proved to be working) firmwares on colibri with HAB → M4 not running
- Patching M4 linker script to have “m_interrupts” placed in OCRAM_S (0x20180000) or TCM (0x1FFF8000) on colibri with HAB → M4 not running
- Running only m4 (with bootaux command in uboot) on colibri with HAB → M4 not running
From what we see, M4 doesn’t execute a single instruction when HAB activated, in our setup.
Is there anything we’re missing here ?
Why did M4 suddenly stopped working upon activating HAB uboot ?
I admit I’m not too familiar with how the M4 is handled during the HAB process. From what I can understand from the information you provided, you signed the M4 firmware/binary with HAB I assume.
However referencing this HAB documentation from our partners at Foundries.io (https://app.foundries.io/docs/latest/reference/secure-boot.html#). It appears that fuses relating to the M4 core need to be set as well. Do note that they use the i.MX7ULP for reference in their documentation meaning the fuse values listed may not be valid for the i.MX7 SoC.
Be aware this is only a theory as I’m not completely sure if this will solve your issue. What might be best would be to obtain the security reference manual for the i.MX7 from NXP. This document should in better detail describe what happens to the M4 core during the HAB process, as well as give proper fuse locations in the case you do need to set fuses for the M4.
Fuses are only used to verify uboot and then uboot checks all partitions signatures, M4 included.
We tested a small code for m4 that could fit in TCM and it successfully ran with HAB uboot.
It seems everything is working fine as long as we execute m4 code in TCM, but our code is too large to fit in TCM.
Do you know if there are any limitations regarding M4 code location with HAB uboot ?
If there are no solutions to enable M4 code in DDR could we at least have a M4 code section in TCM that then “jumps” into DDR ?
I haven’t been able to find any documentation that suggests HAB limits M4 code location.
May I ask what your process for implementing HAB in your environment is? Especially how you signed your M4 firmware. Also what version of our BSP/U-Boot are you working on?
I’ll continue to look on my end to see if I can find anything about the M4’s interaction with HAB but I’m afraid this might be outside my area of expertise. It might be beneficial to also ask this question to NXP on their community platform if possible.
We’ve got news.
I’m not the one in charge of the linux part but we use buildroot and use :
git clone -b 2016.11-toradex git://git.toradex.com/u-boot-toradex.git/
git clone -b toradex_4.9-1.0.x-imx git://git.toradex.com/linux-toradex.git
git clone -b colibri-imx7-m4-freertos-v8 git://git.toradex.com/freertos-toradex.git
Last update of these on our side was in september 2018.
Regarding the M4 matter :
Apparently, you HAVE to put your data section in TCM_U when running in HAB with m4. (All our other tests failed)
Thus we ended up using MCIMX7D_M4_ddr.ld patched to have an additional custom data section allocated in TCM_U.
m_custom (RW) : ORIGIN = 0x20000000, LENGTH = 0x00008000
We then patched the higher level linker (MCIMX7D_M4.ld) to have all the data that’s not heap, stack and bss (only the .data section, in fact) put in the custom section in TCM.
And now it works fine !
In the end, we use less than 1kB of TCM_U.
We’ll also post this question + answer on NXP community to ensure this solution is the right way to go !
Hope this helps ! Best Regards !
Glad you were able to find a solution. Also thank you for sharing the details as I’m sure this will be of use to someone here in the future.