Stuck at Starting Kernel ..." after loading M4 Firmware

Technical Support
, , ,
1

Hello everyone,

I have a Colibri iMX7 1GB eMMC and a Iris Carrier Board. I’m trying to run some code from an old project that contain a Cortex-M4 firmware and some Linux applications.

After following this tutorial I was able to create a linux image, load it on my board and boot successfully. However, after loading the M4 firmware my linux kernel got stuck after the “Starting Kernel …” message.

Because I use UART2 and SPI I created a custom device tree to disable those peripherals:

/dts-v1/;
#include "imx7d-colibri-emmc.dtsi"
#include "imx7-colibri-eval-v3.dtsi"

/ {
	model = "Toradex Colibri iMX7D 1GB on Colibri Evaluation Board V3";
	compatible = "toradex,colibri_imx7d_emmc-eval", "toradex,colibri_imx7d_emmc", \
		     "fsl,imx7d";
};

/delete-node/&bl;

&ecspi3 {
	status = "disabled";
};

&usbotg2 {
	vbus-supply = <&reg_usbh_vbus>;
	status = "okay";
};

&uart2 {
  status = "disabled";
};

Next, to add it to my build, I added the .dts file to the meta-toradex-nxp/recipes-kernel/linux/linux-toradex directory and the file linux-toradex_%.bbappend to meta-toradex-nxp/recipes-kernel/linux.

linux-toradex_%.bbappend file:

SRC_URI += "file://mobitec_iris_imx7.dts;subdir=git/arch/${ARCH}/boot/dts"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
PACKAGE_ARCH = "${MACHINE_ARCH}"

Finally, I edited /meta-toradex-nxp/conf/machine/colibri-imx7-emmc.conf to alter KERNEL_DEVICETREE:

KERNEL_DEVICETREE += "imx7d-colibri-emmc-eval-v3.dtb imx7d-colibri-emmc-aster.dtb mobitec_iris_imx7.dtb"

The Yocto project is something new for me and I know that the right way of doing all this is to create a new layer… however this process isn’t clear for me yet…

Well… After all of this I was able to compile, load and boot the image successfully. I was also able to verify that my device tree was compiled and it’s .dtb file was present at the boot partition.

Unfortunately, after loading the M4 firmware, the kernel still gets stuck in the same place…

Any idea of what could be causing this problem?

Best,
Mauricio

2

Hi @farina!

Are you able to run that same M4 firmware using our default BSP 2.8 image? I’d give that a try. The expected behavior would be for the kernel to start normally and perhaps panic whenever your application tries to use UART2 or SPI. Anyway, it shouldn’t be stuck on Starting Kernel.

Which memory is your M4 firmware using (TCM, OCRAM or DDR)?

3

Hello @gustavo.tx!

Thanks for the fast reply!

I tried to run the M4 firmware on the standard image 2.8 and also recompile my custom image with version 2.8 and. In both cases, I have the same problem.

I looked at the project’s cmake files and I believe that it is using TCM.

# RELEASE/DEBUG LINK FILE
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -T MCIMX7D_M4_tcm.ld -static -L ${BspRootDirPath}/platform/devices/MCIMX7D/linker/gcc/")
4

@farina,

Have you tried running some of the built-in FreeRTOS demos such as the hello_world? If so, did it cause the same issue?

Also, despite the Starting Kernel freezing issue, does the firmware actually run on the M4?

5

Yes I did. I followed this tutorial to compile the hello world firmware and used the exact same process to load it on the board.

When the system boots, I can see the “Hello World!” message and the kernel boots correctly!

About my firmware, yes it runs on the M4… I can see some log messages being printed on my serial port…

6

Another thing…

I just notice that… while I was doing the hello world test, that the /dev/ttymxc1 a.k.a. UART_B was present in my custom image. However, it disappeared after running:

setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/serial@30890000'

So I’m guessing that my .dts file isn’t being applied after all. However, I notice that, while I didn’t have the UART_B disabled and was running the hello world example, the Kernel didn’t hang on the “Starting Kernel …” message, but instead, gave me a kernel panic during the initialization.

Could this be the cause of my problem?

7

An Update…

After my last discovery I tried disabling all SPIs and UART_B manually on u-boot by running:

setenv defargs clk_ignore_unused

setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/serial@30890000'

setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/spi@30820000'
setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/spi@30830000'
setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/spi@30840000'
setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30400000/ecspi@30630000'

setenv m4boot 'fatload mmc 1:1 ${loadaddr} Koala_plotter.elf && bootaux ${loadaddr}'

saveenv

However the Kernel is still hanging on the same place…
So I’m guessing this problem has nothing to do with peripherals…

8

Hi @farina!

I also think this may have nothing to do with the peripherals. When Linux tries to take control over a peripheral that’s being used by the M4, the kernel should panic just like you mentioned happening with UART_B. The kernel should start nonetheless, at least regarding these peripherals.

Since the hello_world demo boots, I’m suspicious there may be something in your firmware code that may be causing such issues.

A good debug starting point would be to disable all peripheral assignments in your firmware. Comment and disable the parts of the code that use the peripherals and check if it works. If it does, then progressively enable the peripherals to try to find the culprit.

9

Hi @gustavo.tx!

I figure out the problem!
It was the PWM_0 that was causing the kernel to hang.

After disabling it on u-boot everything worked as it should! I’m just still don’t understand why the PWM would cause the whole kernel to hang instead of just giving me a panic.

Also, how can I fix my problem of the device tree not being applied after all?

10

Hey @farina!

Glad it worked! I also find it strange it didn’t make the kernel panic.

About your device tree issue, perhaps you have to update your U-Boot environment variables so to load the correct .dtb file.

Check fdt_file environment variable on U-Boot. Its value should be the filename of the device tree to be loaded. Try modifying this variable from within U-Boot ( setenv fdt_file [...] ) and check if the correct .dtb is loaded.

On your Toradex Easy Installer image, check the uEnv.txt file. These are the default environment variables to be loaded by U-Boot. You can modify this file after you generate an image so to have the correct variable referring to your custom .dtb.

11

Thanks for the help @gustavo.tx!

12

You are welcome. Thanks for your feedback.