My task for this week is to determine the interface of the remoteproc framework. As shameful as I could be, I still couldn’t figure out the interface and what is needed to make the framework runs. After some discussions with my supervisor, I was told that my work method was all wrong. I’ve been reading too much the Linux source codes and obviously this is going to take forever because Linux is very complicated and it is impossible for a beginner to understand everything just by reading the codes. It takes years (of working in this field) for a person to really understand how everything works in Linux (unless that person is a computer genius which is absolutely not my case). Just like how people always say “Curiosity killed the cat”. We need to have the right strategy to tackle our problematic!

The real way to do the job is by figuring out the life of a remote processor. Right from where the remote processor is plugged in, until it is plugged out. I have to figure out what is going to happen in the kernel so that I know what to implement in the remoteproc platform-specific driver. Because I was lost deep in the source code, my supervisor asked me to clear my mind, get rid of all the codes and start back anew. Study back the simple beagle-6502 project which uses the remoteproc framework and from there, figure out how our processor can be used with the framework.

Although my work method was wrong, I will still write an important point that I found out this week in this blog because I might refer them here if I were to face the same problem in the future.

One of the many questions that puzzled me the most was “Who calls the probe function implemented in the remoteproc platform-specific driver?”. By looking at some of the examples from the source code (ste modem, omap, and 6502 driver), their remote processors were defined as platform-devices. Platform-device is a device which is not discoverable by the kernel (not like a pci or usb device where their corresponding bus will inform the kernel if a new device is plugged in). In this case, the user needs to inform the kernel about the device whether during the module loading or using device tree support (DTS). So, I f we want to implement our own remote processor, we have to keep in mind that we need to inform the kernel about our remote processor.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.