Hello Karel and all others, the GPU PC grade graphics card are really complex systems which require firmware etc. Due to legacy nature of 1982 PC design and keeping compatibility forever there is no simple PCI hardware class which would allow to list supported modes and set one of them and map continuous framebuffer memory portabe way. Only register model which allows direct access to videoram is old VGA hardware registers set and mapping which is completely insufficient to send image to today displays. It allows only map 64kB (may be 128kB) starting from 0xA0000 which is enough for text mode but unusable without page switching for anything more.
The real solution is t use full featured driver but today GPUs are mainly 3D accelerators and plain flat RGB framebuffer is setup and image processed by part of 3D engine. When complete setup is required it pulls in complete 3D DRM driver. Some graphics cards have no documentation how to setup mode from driver (Nvidia,...) but reverseengineered open source drivers exists. Some GPUs (Intel, AMD) are documented. But port subset of the drivers to cover most of the graphics cards found on PCs is a problem. You have to take whole graphics stack from some system with really wider developers community (Linux, BSD) which is really huge. Or try to separate setup subset but when new card model appears, you are in a trouble, amount of work is huge. When we wanted to use RTEMS i386 BSP to test Microwindows/Nano-X RTEMS application in QEMU, we have tried to provide at least something that works (Our main target has been infusion system running on RTEMS on ARM https://devel.rtems.org/wiki/TBR/UserApp/AMV_Technic_I ). On Saturday 19 of September 2020 23:41:58 Karel Gardas wrote: > On 9/19/20 10:32 AM, Christian Mauderer wrote: > Yes, in fact there are three FB drivers in pc386 BSP family: > > - for VGA card > - for Cirrus Logic GD5446 card > - for VESA BIOS Extension capable graphics card One feasible option was to implement real hardware driver for simple target hardware available in QEMU. GD544 is old graphics card but with know registers set and that is why it is used by QEMU. The driver has been implemented during GSoC 2012 by Alexandru-Sever Horin. I have not tested it for years. If I remember well it is not capable to read EDID from the display so fixed parameters has to be specified. The other solution which has higher chance to work on broader hardware range is to use some firmware with know common API which is provided by board manufacturer and knows its internal structure and registers. Because even old PC BIOS, DOS code and operating systems loaders need to manage cards, VESA BIOS has been introduced as ROM module which is called by main BIOS, setups basic mode to shouw at least something on the monitor and allows to switch boot menus to graphic mode as well. In a theore, VBE extension entry point should allows to call this code from the protected mode environment but as we have experienced with Jan Dolezal in 2014, the most of the cards have not implemented this entry or its functionality has been broken. So only option was to use old "DOS" real mode entry from x86 CPU 16-bit real-mode. The graphics card setup is called before RTEMS takes full control over CPU and before switch to protected mode is proceed. Call to the VESA BIOS setups the graphics mode and maps complete framebuffer into memory address range available for IO/PCI boarads. Then the framebuffer start address is passed into RTEMS, it switches to the protexted linear address mode and framebuffer start address is returned to the application when it requests information from the driver. The is probably source of your problem. On the Linux and BSD, the framebuffer is mapped into virtual address range and page table has to be setup for graphics process to translate user-space address into physical address. So you need mmap of physical address range into virtual one or the framebuffer driver has to provide mmap operation which allows to map part of the "/dev/fb" "file" into process space. But RTEMS is single linear address space system, so the start of the framebuffer address returned by IOCTL is already address where the RGB color bytes are present. See the Nano-X RTEMS driver https://github.com/ghaerr/microwindows/blob/c1c3595674a1e64d5e26ff4ef25a557c7452d546/src/drivers/scr_rtems.c#L78 The IOCTL returns framebuffer parameters and returned start address is used directly as the address o the start of the plane to draw images onto https://github.com/ghaerr/microwindows/blob/c1c3595674a1e64d5e26ff4ef25a557c7452d546/src/drivers/scr_rtems.c#L140 So it is highly probable that if you skip mmap or other equivalent fragment of the code in LVGL and copy start address without modification, you have your graphics image on the screen. I have interrest for LVGL, we have tried it on NuttX. Which sources are you using and what is your configuration? > The latest one is enabled by default and that's what I'm trying to use. > > > Maybe > > an alternative to using the BSP framebuffer driver could be to just port > > the FreeBSD framebuffer driver for PC and use that one? That might could > > be less work than fixing the PC BSPs driver. > > Hmm. Just a brief check reveals that FB also supports several FB drivers: > > - for EFI frame buffer > - for KMS enabled graphics card with vt_fb backend If there is safe EFI service which can be called from RTEMS protected mode safely or before full RTEMS core is started it could be interesting option. But generally I do consider to call anything outside of RTEMS code as extremely unsafe for any RT application. There is no guarantee how badly proprietary code is written. The other option which would be great even for x86_64 BSP is to sandbox VESA BIOS code execution (real one, because protected seem to be broken on the most cards anyway). It requires small interpreter of x86 ISA subset. Because it is interpretted it cannot lad to the lost of the CPU control, tasks switching etc. And it allows to allows access only to the address ranges which are belonging and reserved for video BIOS and HW use and protect rest of the RT executive from this buggy code. It can corrupt memory anyway because it can setup DMA or command GPU processing cores which has full access to the main memory, but it is much better separated. Generally, I would like to participate on such work, but my time is really limited. We experienced adventure of distance only teaching in the last semester and next one has been switched to the distat one on the last Friday as well. Best wishes, Pavel Pisa company: https://www.pikron.com/ e-mail: pp...@pikron.com Czech Technical University in Prague e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://dce.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel