I’m getting this Linux message when mqxboot’ing my M4 firmware blob:
Loading into SRAM area, which might be used by suspend/resume!
After checking this Toradex’s page :
I added parameter at U-boot time: initcall_blacklist=sram_init. It seemed it should solve the problem, but instead I got mcc module crash at load time / kernel whooiping , with message
mcc_get_smem_pool: ocram pool unavailable!
[ 23.655217] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Any help with this? Blacklist was a bad idea seems, but how else do you release SRAM from suspend/resume? Disable that subsystem entirely in kernel configuration?
Our FreeRTOS BSP is only supported with the V2.6.1 Beta 1 release, not with older releases. This newer releases do not provide mqxboot hence it is not possible to load FreeRTOS with mqxboot.
The V2.5 Beta 3 release does not make use of Remoteproc. The MCC/mqxboot loading mechanism does not explicitly requests the SRAM area, it is able to load the firmware despite the area being used by the Suspend/Resume mechanism. The message you are seeing is only a warning: You won’t be able to use suspend/resume after the firmware has been loaded into SRAM.
I think i need to clarify my previous message: I’m loading an MQX application with mqxboot, I’m not using FreeRTOS. The reference to the Toradex link on FreeRTOS I made because I thought the same boot parameter initcall_blacklist=sram_init should be applicable here too (I don’t know what it does but looks like just removes all SRAM from Linux, by that Ooops message i got).
Are you saying that Linux will not try to suspend/resume after I have loaded something into SRAM? Or do I need to pass some special boot parameter to disable suspend / resume . Or disable this in kernel config & rebuild.
Our Linux BSP does not enter suspend/resume automatically, you would need to instruct the kernel to do that manually (typically using echo mem > /sys/power/state). WIth v2.5 Beta 3, if you explicitly instruct it to enter suspend, it will actually try to enter suspend but it will fail… However, as long as you don’t explicitly ask the kernel to enter suspend, you should be fine.
I’m having the same issue trying to mqxboot my firmware on the M4 core, when I use the same U-boot parameter 'initcall_blacklist=sram_init'.
When I try to execute it without any extra parameters i get the warning “Loading into SRAM area, which might be used by suspend/resume!” mentioned above and the blob seems to be loaded properly and it goes to the entry point. But in the console connected to the M4 core UART I can’t see any message. So MQX seems to be not creating any task.
I also tried to set setenv defargs 'clk_ignore_unused' variable in order to be sure that no clocks are disabled by linux kernel, but it doesn’t make a difference.
I tried to debug M4 firmware in DS-5 environment, but the only thing I can get to see is that MQX is active but it doesn’t create any task (just the idle_task) and it gets looping inside the idletask.
This firmware was previously working properly in Toradex’s BSP v2.3b1 (kernel 3.0.15).
Could someone tell me why MQX 4.1.1 is not able to execute anything? Anyone with similar problems?
