How to use lvgl on pc386 BSP.

[Pavel Pisa]

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:     ppisa at pikron.com

    Czech Technical University in Prague
    e-mail:     pisa at 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/