mmap on /dev/fd0 on pc686 BSP not working at all.

Gedare Bloom gedare at rtems.org
Mon Sep 21 16:17:24 UTC 2020


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.gardas at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/users


More information about the users mailing list