During my 10th week at Aeste, I continued my unfinished business from the 9th week: bit banging the gpio to implement a custom 8 bits wide bus. I spent most of my time this week debugging the gpio driver for the custom bus. My code was ready at the beginning of the week, but it was buggy, and didn’t quite work. One of the most crucial problem is to set the right timing as when to set or read the RW or EN signal and etc.
There are two type of drivers that I developed: Host side GPIO and remoteproc side GPIO. The host GPIO was developed using the traditional kernel module method because it will be later integrated with the platform-specific remoteproc driver. As for the remoteproc side, I just created a simple program that access the GPIO to do bus read and write repeatedly. In real world application, the remoteproc gpio program should be a physical processor or a firmware that interface the processor’s data/address bus with the GPIO.
As for now, I only tested the bus with a clock speed of 1Hz because I focused on having a functioning bus. I can later change the bus speed fairly easily by tweaking the timer used in the host side gpio driver, should I need to determine the maximum speed of the bus. The host side driver’s code is also not too robust and lacks some data integrity features, because for now the focus is to make it work. One of the known bug of this bus is that I consider that once the bus is switched to Read (or write), it will continue to stay in that state until the read (or write) cycle is finished. This means that if the remoteproc side decided to cancel the read cycle, the host side will not acknowledge it and continue the read cycle until it finishes. If we consider a system where the host nor the remoteproc never cancel their read or write cycle, my current custom bus will definitely work.
After I finished the GPIO driver, I switched to the platform-specific driver that I developed and used with an x86 virtual machine. To my surprise, the driver was having a little problem when used on the raspberry pi. The driver can load and detect a remote processor normally, but whenever it tries to boot up the processor, an error occured: “kobject_add_internal failed for remoteproc0” with an error code of ‘-EEXIST’. Apparently it was saying that a remoteproc0 object was already present, and when the remoteproc driver tries to register the processor, a conflict happens.
My next task should be fixing this small problem of platform-specific remoteproc driver and then, everything should be ready to be combined into a more complete driver (remoteproc + gpio drivers).
0 Comments