Week 7: First stage of remoteproc driver done

Alright, I’m now on my 7th week at Aeste. Things been going pretty fast ey? Yeah it sure  does! This week I managed to finish my dummy remoteproc driver. It was a big relieve for me because my stress level was going up rapidly when the driver didn’t work after numerous debugs! Like always, I’ll write here one of my most stupid mistakes that I did so that me, you, and everyone else on this planet won’t do the same mistakes again!

One of my most stupid mistakes was that I passed the wrong object to a function. I was pretty sure the object that I passed was the one needed by the function but unfortunately no! Only after reading my codes several times that I realized this mistake of mine. After fixing this problem, another problem appeared.

Here’s my way of creating a dummy remoteproc:

I created a module that registers a platform device named “rproc” for example.

and then I insert the remoteproc module that I wrote. This module will specifically search for a platform device named “rproc”. As it was already inserted earlier, it will get probed by the kernel automatically. In this probe function, I allocate a portion of memory that will act as the remote processor’s RAM, and this is where the firmware will be uploaded during the boot up process.

To make the whole process simpler, I call the remoteproc boot up function during the device probe. This means that once the remote processor gets probed, the boot up function will be called and the remoteproc framework will look for the firmware to upload at the processor’s RAM. I had a little problem with this firmware loading mechanism because I didn’t have a real and proper firmware to be used (a firmware with a proper header and resource table). So, I modified the “find resource table” function of my remoteproc module and make this function create a fake resource table. Now that I have a resource table, the remoteproc framework won’t have any problem verifying the firmware resource, and then upload it to the RAM of my remote processor!

The first step of the remoteproc implementation is now done. My next task is to develop a small module that gives users the ability to peek into the remoteprocessor’s RAM. I tried to implement a virtual remoteproc UART so that I can access the remote processor’s resource through a serial console. But there was a slight problem, and I still couldn’t debug it even after spending a lot of time on it. Because there were too much time wasted on the problematic virtual UART, my supervisor asked me to start developing something simple first, such as a device file that do R/W on local memory. After this has been achieved I should start expanding its features till I get a complete module that will serves the functionality of a virtual UART.