Hi Karel, I don't know if I can provide any answers, but I can provide some guidance maybe. I implemented mmap() in rtems to provide portability and compliance for mmap applications that use MAP_SHARED with fixed addresses. We don't do any real mapping or translating of memory since there is no virtual memory support in rtems. Kevin Kirsepl extended/fixed the file handler part of that implementation
There is an mmap helper implemented in libbsd: rtems-libbsd.git: /rtemsbsd/sys/fs/devfs/devfs_devs.c:391 devfs_imfs_mmap() Vijay implemented that as part of the BBB framebuffer work. I haven't studied it closely enough to give any advice on how to replicate/use that in another FB. Hopefully he may be able to chime in, as he also did a lot of the work with lvgl porting. The pc386 FB was written by one of Pavel Pisa's students, Jan Dolezal. I had hopes we could generalize the code to other targets because it is relatively simple compared to other framebuffers. I think someone tried with raspberry pi. But that effort hasn't really moved in a few years. My guess is that the pc386 fb needs to have something like devfs_imfs_mmap(). Gedare On Sun, Sep 20, 2020 at 2:43 PM Karel Gardas <karel.gar...@centrum.cz> wrote: > > > Hello, > > I'm attempting to get rtems-example/lvgl/hello working on pc686 BSP. I'm > using VESA framebuffer which is default on pc686, although I needed to > do few fixes here and there to ensure littlevgl library compiles well. > All patches here > https://lists.rtems.org/pipermail/devel/2020-September/062186.html > > Now, everthing is compiled and VESA fb is well initialized -- or seems > so. Now, vgl library tries to use that fb (/dev/fb0) and basically tries > to mmap it for its own use. The code looks: > > void fbdev_init(void) > { > // Open the file for reading and writing > fbfd = open(FBDEV_PATH, O_RDWR); > if(fbfd == -1) { > perror("Error: cannot open framebuffer device"); > return; > } > printf("The framebuffer device was opened successfully.\n"); > [...] > // Map the device to memory > fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, > MAP_SHARED, fbfd, 0); > if((intptr_t)fbp == -1) { > perror("Error: failed to map framebuffer device to memory"); > return; > } > memset(fbp, 0, screensize); > > printf("The framebuffer device was mapped to memory successfully.\n"); > > > The mmap above fails. Screensize is realistic and good looking number. > > While debugging this mmap I see it fails on the call to function on line > 280: > > err = (*iop->pathinfo.handlers->mmap_h)( > iop, &mapping->addr, len, prot, off ); > > it returns -1 and hence mmap failure since code below looks: > > if ( err != 0 ) { > mmap_mappings_lock_release( ); > free( mapping ); > return MAP_FAILED; > } > > when I try to step into the problematic function above, I end up in > default_mmap.c:31 on: > > rtems_set_errno_and_return_minus_one( ENOTSUP ); > > and as the function claims it really returns -1 to me. > > Now, my obvious question is: how to make VESA fb mmappable? It looks > like the same library is working fine on BBB while using FreeBSD BBB > framebuffer driver, so there is probably some way how to convince RTEMS > mmap to work with fb0. > > Any idea how to proceed with this is highly appreciated. > > Thanks, > Karel > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users