I have some technical questions regarding the SPE (Sensor Processing Engine) firmware loading and execution process based on the attached boot sequence diagram.
In the diagram, it appears that MB2 is responsible for loading and executing the SPE firmware. Regarding this process, I would like to ask the following:
Question 1: Is it possible for developers to modify, build, and reinstall the MB2 source code? I would like to know if the source code for MB2 is provided to developers and if the Jetson Orin platform supports booting with a custom-built MB2.
Question 2: If MB2 cannot be modified, is there an alternative way or a different stage in the boot sequence to load and execute the SPE firmware? If there are any workarounds or alternative methods to trigger the SPE firmware at a different stage (e.g., via PSC or other auxiliary processors), please provide relevant technical documentation or website links.
I look forward to your professional guidance on this matter.
We are evaluating the feasibility of the following scenario: We are investigating whether the process of loading and executing the SPE firmware can be implemented within a developer-modifiable code area. The specific use case involves receiving the SPE firmware at runtime via communication from another execution domain (e.g., CPU Bootloader), uploading it to RAM, and immediately executing the firmware directly from RAM.
This is possible, but the implementation may be quite complicated. Here are some points I can imagine, for your reference. (Some of following suggestions are out of L4T support and not verified. Just for your information.)
You cannot change the SPE init process. Such process is tightly integrated into the whole chip boot flow. Any change may result in unexpected behavior, which may be impossible to debug by end users.
By default, SPE FW (code/data) is loaded to TCM, which is only visible by SPE R5.
from your description, it seems that you want to run very big program in SPE, so TCM (256KB) cannot accommodate all code/data? So you want to extend the memory to DRAM?
SPE can access main memory (DDR) with correction mapping. IVC is based on shared memory. Please note that such IVC channel will only be available after kernel’s up in current design.
With shared memory, it provides a possible solution for your goal.
Still keep current SPE boot process and make a loop to wait for messages from CCPLEX.
In CCPLEX side, leverage the shared memory (between CCPLEX and SPE, refer to IVC implementation for details.). download the code/data to shared memory, and send message to SPE.
When SPE gets the message from CCPLEX, jump DRAM to run something.
Anyway, there are still more issues, like link address, buffer allocation, etc. More important, it may crash/hang the system if device enters SC7. Also, I don’t know whether there’s any other problem. Still, I’m just discussing about the technical possibility as an individual. That request has no official support.
From previous experience, SPE core has very limited perf (200M per my memory) and it’s only doable for some simple real-time tasks. Too complicated tasks may be improper for such a small core.
Feel free to do more technical discussions, but again, no such support in official L4T BSP.