Resource manager with mmap handler

Hi everyone

I try to write simple resource manager with mmap handler. In mmap handler I use mmap_device_memory() to get access to memory I need. However I have no idea how to return pointer to this memory. Address space of resource manager and address space of process which mmap name registered by resrouce manager are different. I also haven’t found single example in QNX documentation how to write mmap handler.

In case my explanations of the problem was not clear enough, below are two codes which should help to understand what I am trying to do.

// ResourceManager.c

...
int io_mmap(resmgr_context_t *ctp, io_mmap_t *msg, RESMGR_OCB_T *ocb);

int main(int argc, char **argv)
{
    ...

    iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,
                     _RESMGR_IO_NFUNCS, &io_funcs);
    io_funcs.mmap = io_mmap;

    ...

    resmgr_attach(dpp, &resmgr_attr, "/dev/uio", _FTYPE_ANY, 0,
                 &connect_funcs, &io_funcs, &attr)
    ...

    return EXIT_SUCCESS;
}


int io_mmap(resmgr_context_t *ctp, io_mmap_t *msg, RESMGR_OCB_T *ocb)
{
    ...

    void* my_memory = mmap_device_memory(NULL, SIZE , PROT_READ|PROT_WRITE, 0, BASE);
    
   /* 
      mmap function which is invoked in MyProgram.c should return 
      pointer to memory which is mapped here as my_memory
      How can I do that? Should I use:
      - iofunc_mmap, iofunc_mmap_default
      - IOV
      - some kind of macro
      - ???
   */

    return ...;
}
// MyProgram.c

...

int main(void)
{
    ...
    
    fd = open("/dev/uio", O_RDWR);

    ...    
    
    // mem should point to the memory which is mapped in ResourceManager.c
    void* mem = mmap(0, SIZE, PROT_READ | PROT_WRITE,
             MAP_SHARED, fd, OFFSET);
    
    ...

    return EXIT_SUCCESS;
}

I would be very grateful for any directions.

Thanks in advance

Why do you want to access memory mmaped in the resource manager from the client app ?
This is bad design.

Thanks for reply

I am trying to write resource manager similar to uio_pruss on Linux (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/uio/uio_pruss.c). Mapping this linux driver gives access to some memory I need. I also believe that this is more general solution. Many processes would be able to map my name registered by resource manager.

I don’t know wheter using mmap_device_memory() in mmap handler is needed. All I want is to get pointer to memory I want by mapping name registered by RM.

If I understand well the PRUSS driver gives hardware access to client applications.
You can reproduce this behaviour but you don’t have to with QNX.
You can access hardware resources directly in your application.
You have the choice.

How does the linux application communicate with the PRUSS driver ? Is there a specific API ?

I am aware that writing resource manager is not necessary and it would be much easier to map hardware memory directly in client code. I just want my solution to be more elegant. Moreover, there is library called prussdrv (https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c) which makes it easier to work with uio_pruss driver. It helps to write to PRUSS memories and make it easier to use interrupts. I am going to use this library and If my resource manager would behave like uio_pruss then probably it would be no need to modify this library.

uio_pruss driver and prussdrv library is an old, deprecated solution. Currently, remoteproc driver is used when working with PRUSS-ICSS. It is much more generall and powerfull than uio_pruss. However it is also much more complicated and I am not experienced enough to write similar driver in QNX.

I had a quick look at prussdrv.c
What I understand here : Many files (PRUSS_UIO_DRV_PRUSS_BASE, PRUSS_UIO_DRV_PRUSS_SIZE…) are used to get information from the driver. One of the files (prussdrv.mmap_fd → “/dev/uio%d”) is memory mapped and used to get access to peripheral memory (I/Os).
So, your resource manager must manage these files. The file at “/dev/uio%d” must redirect read and writes to the mmaped memory.

That is right. However, I am not sure wheter the information from files PRUSS_UIO_DRV_PRUSS_BASE and
PRUSS_UIO_DRV_PRUSS_SIZE are really essential. Physical base from file PRUSS_UIO_DRV_PRUSS_BASE isn’t used anywhere in this file. Size of the PRUSS memory from file PRUSS_UIO_DRV_PRUSS_SIZE (as far as I understand) is known because it comes from global memory map of my SoC - Sitara AM3358 (https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf page 185).

I don’t think so. prussdrv.c has function like prussdrv_pru_write_memory which writes directly to the PRUSS memory based on pointer from mmap on /dev/uio%. I don’t think that my resource manager should have read/write handler. I belive it would be difficult to write to specified memory in PRUSS using write function.

You are right.
By read/write, I was thinking about resource manager functions managing memory mapped file read/write. I never done this. I don’t know how to do this.
I’ll check if I find something about this in my docs.

Since prussdrv.c mmap “/dev/uio%d” file in memory, I believe you have to manage io_mmap in the resource manager.
See here for more information : http://www.qnx.com/developers/docs/6.6.0.update/#com.qnx.doc.neutrino.getting_started/topic/s1_resmgr_io_mmap.html

You’re right. This is what I am trying to do - take a look at my ResourceManager.c file in my first post. However I have no idea how to do that. There is no any example in documentation which shows how to write mmap handler. As mentioned on the website you linked, this is not very common and not recommended thing to do.

This is much clearer now.
At first, io_mmap() looks like the way to go but… See here :

However, most posts are outdated.
Have you tried QNX support ?

I have free academic license. I suppose it does not involve QNX support.

Anyway, I find your links very helpful. Now I know that it can’t be done as easy as I thought. I will probably try to use shared memory object like it is suggested in http://community.qnx.com/sf/go/topc5910.

Thanks for the help