Booting linux 2.8 halts freeRTOS running on M4 core

I initially had a kernel panic when booting Linux while a freeRTOS on M4 was running. I fixed that. Now have opposite problem.

A little less than 1 second into booting Linux 2.8, the M4 core stops running. Linux is running fine. Here is what I do:

tftp ${loadaddr} hello_world.elf
bootaux ${loadaddr}  which starts the M4, which is running
boot

Less than 1 second later while Linux is booting, the M4 stops working.

What should I look for?

Thanks,
Robert

I can tell my M4 core stopped by a logic analyzer looking at SPI transfers and a hardware timer. If the timer stops, then there is not SPI transfers. It is a retriggerable timer, so if SPI stops within the timer interrupt, then no more timer.

Does the M4 have complete control of incoming clocks, or can the A7 corrupt the multiplexing?

Can the A7 kill M4 interrupts?

In the Linux dtb, I’ve disabled most of the SPI references, such as

MX7D_PAD_ECSPI2_MOSI__GP104_IO21
&ecspi3 {

}

There are a large number of PAD entries with the SPI label, do I have to eliminate these?

After a process of elimination I found the GPT timer is being corrupted. I tracked another post from Stefan.tx that stated GPTB has an interaction problem with SysPllPfd0.

I believe GPTA also has the same issue.

Question: Is this the correct timer init?

CCM_UpdateRoot(CCM, BOARD_GPTA_CCM_ROOT, ccmRootmuxGptOsc24m, 0, 0)

Question: Are the GPT’s peripherals that can be accessed from the A7 and M4. If so, any way to modify the Linux DTB to eliminate access to GPT?
Thanks

I found the problem. Will create followup thread on the more specific GPT issue