To update the m4 firmware we currently use the ubiupdatevol on linux to write a new firmware to /dev/ubi0_2 and afterwards reboot the linux so that the u-boot handles the m4 rebooting
As we had no time yet to optimize the linux startup time this can take some time. I tried to do some optimizations, but it seemed like it could be quite time consuming. So my question would be is there maybe another easier way we could use during development to reload and reboot the m4 firmware? One thing I heard about that could be useful is remoteproc.
So my question would be:
Is remoteproc feasible to do this?
If remoteproc is feasible, would you have any hints where to start?
Are there other options to reload and reboot the firmware?
For now I use imx m4fwloader app , which does this from user space. ( i’m running non Toradex kernel though, but depending on “things”, you may still be able to use it ).
Remoteproc would be next step.
I need to read on & study remoteproc, for now I just heard the word here & elsewhere before.
Glancing at that code it seems to do exactly what that small app does, not more, just didn’t see how it expects user to pass the blob to it. ( I hope it’s as easy as with that user app ).
Toradex’s kernel and repo and how it updates it are great. I’m thinking to track Toradex’s Git tree for my other iMX7 based SoM, non Toradex. Because Toradex tracks different sources (besides it’s own in depth work that is …)
The user app violates typical user space/kernel space borders: The app writes directly into hardware registers via /dev/mem… Some kernel might not even allow this (e.g. if CONFIG_DEVMEM is disabled, or CONFIG_STRICT_DEVMEM is enabled).
remoteproc is a kernel framework which allows to load the firmware into memory accessible by the remote processor and starts the remote processor. To load the firmware from user space it uses the firmware loading mechanism (hence the M4 core firmware needs to be placed under /lib/firmware). You then can start/stop the firmware using sysfs, see also Documentation/ABI/testing/sysfs-class-remoteproc and Documentation/remoteproc.txt.
Yea I agree on /dev/mem, and that it may not be available or allowed on the system for security reasons may be, was one of my concerns when I found it. I planned to investigate the kernel driver, which wasn’t in bsp provided for my project. All start, stop, reset if it has is great if it has.
For development and debugging, luckily one can always config the kernel how they want and enable that devmem. And hook up firmware file from non specific location, at any time after system booted. All may be handy when you trying out things an debugging.
I understand direct access to hw registers this way from user space is wrong & ugly, but sometimes it’s just easier to try out things (esp. if you never dived deep or new into understanding Linux kernel/driver code). And the small bad app does things straight out of the App note, so easy & quick(er) relatively
I wonder if OP has back-ported that driver yet, otherwise I’ll get to it sometime.
Nope, didn’t have time yet as we had some other more important issues, but I think I will look into this the next days as we have another issue that might be related to starting / stoping the m4 firmware
Update: @dry I got it to work. In the answer is the description how (you have to adapt the dts entry if you use tcm memory).
Would this be correct to use the OCRAM memory (using the default OCRAM linker script)?
I added my firmware to /lib/firmware and updated the name in /sys/class/remoteproc/remoteproc0/firmware.
I tried to start the firmware with echo start > /sys/class/remoteproc/remoteproc0/state and got always a write error until I realized that it tries to start the firmware anyways.
So this is where I got stuck with the following error ( dmesg | grep remote ):
It looks like newer kernel versions simply leave table_ptr unset if no resource table is used. Where does it crash if you do something like this? I’m sure it will crash somewhere:)
Everything you need to get the remoteproc running is in the comments to the answer from stefan. Should you have a problem with overwriting sections in the elf file take a look at this ( Error in M4 ocram linker file - Technical Support - Toradex Community ). Issue is it doesn’t work well together with the rpmsg. Couldn’t get it to run anymore after I used remoteproc