Cortex-M Firmware Loading Issue Analysis
Based on your description, the issue appears to be related to how the Cortex-M firmware is being loaded and managed between different boot scenarios. Let me analyze the potential causes:
Memory Configuration Considerations
When migrating from Yocto to Torizon, one critical aspect is ensuring proper memory area configuration for Heterogeneous Multi-core Processing (HMP)(1). The memory map allocation for firmware, data, and shared buffers needs to be correctly configured between the Cortex-A and Cortex-M cores(1).
Known Issue with EXT4LOAD in Torizon OS 7
There’s a documented issue specifically related to Torizon OS 7 and firmware loading methods(2). The EXT4LOAD method that was functional in Torizon OS 6 has been reported as non-functional in specific versions of Torizon OS 7, including version 7.0.0+build.1(2). This could explain why your firmware loading behavior is inconsistent.
Potential Root Causes
1. Memory Area Conflicts
Your firmware might be using memory regions that conflict with Torizon’s memory layout. When you load the echo example first, it may be setting up the memory areas correctly, but your custom firmware might have different memory requirements(1).
2. Resource Sharing Configuration
The pin configuration and resource sharing between Cortex-M and Cortex-A cores might differ between your Yocto and Torizon setups(1). This includes:
- Pin function and settings sharing across cores
- Memory map allocation differences
- Boot sequence variations
3. RemoteProc Framework Differences
Torizon uses the RemoteProc Linux kernel framework to boot and control remote processors(1). The way your firmware interacts with this framework might differ from the Yocto implementation.
Troubleshooting Steps
1. Verify Memory Areas Configuration
Check if your firmware’s memory configuration matches Torizon’s expected layout. Review the memory map on your Toradex SoM to ensure proper allocation for firmware, data, and shared buffers(1).
2. Compare Firmware Loading Methods
Since there are known issues with EXT4LOAD in Torizon OS 7(2), consider alternative loading methods:
- Using RemoteProc framework for firmware loading(1)
- Checking if your loading method is compatible with Torizon OS 7
3. Resource Sharing Validation
Ensure your pin configuration and hardware resource sharing is properly configured for Torizon(1). This includes:
- Pin function specifications
- Memory area allocations
- Inter-processor communication setup
4. Boot Sequence Analysis
The fact that it works after loading the echo example suggests a boot sequence or initialization order issue. The echo example might be performing some initialization that your firmware relies on but doesn’t perform itself.
Recommendations
- Test with Different Loading Methods: Try using RemoteProc instead of direct U-Boot loading if you’re currently using EXT4LOAD(1)
- Memory Layout Verification: Compare the memory layouts between your working Yocto setup and Torizon
- Incremental Migration: Start with the echo example and gradually modify it toward your firmware functionality
- Boot Sequence Documentation: Document exactly what the echo example does during initialization that might be missing from your firmware
The issue likely stems from differences in how Torizon OS 7 handles Cortex-M firmware loading compared to your previous Yocto setup, particularly given the known regressions in certain loading methods(2).
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.