09-14-2020 02:36 PM
The openamp examples set shared memory in the device tree using a compatibility string of "shm_uio".
When I look for a Linux device driver that publishes the memory to the UIO subsystem, I can't find one. Which driver handles the publishing of the shm_uio block?
09-16-2020 02:37 PM
Hmmm. Crickets. Oh well. Sleep well moderators.
After digging through the libmetal source code, it appears that there is no device driver that handles the UIO device tree mapping into userspace. In fact, if a driver attaches to the device tree entry, libmetal open calls fail.
In Linux what appears to occur is libmetal traverses through /sys/bus/<bus name>/devices looking for the entry passed passed in the metal_device_open call. When it finds the entry, it searches the of_node information posted for the device and from that pulls the physical address mapping. It then makes mmap calls on the physical address value to map the physical memory into userspace.
Bottom Line: The device tree entries for libmetal access are not used by Linux device drivers. The device tree information published in the sysfs file system is used by the libmetal source to extract physical address and interrupt information.
09-17-2020 09:29 AM - edited 09-17-2020 09:31 AM
It appears that I was wrong. The block does get bound as a UIO device when metal_device_open is called. I'm not sure how it gets bound to a driver. This is done somewhere in the deep bowels of libmetal. Looks like the next step is to bring libmetal into the SDK so I can follow the source code flow.