Is there any framebuffer testcases?

Peng Fan van.freenix at
Tue Apr 19 09:19:13 UTC 2016

Hi Pavel,

2016-04-17 6:23 GMT+08:00 Pavel Pisa <ppisa4lists at>:

> Hello Peng and Chris,
> I have been looking to find some more time to upgrade to
> actual RTEMS-4.12 compiler GCC-6.1 toolchain and investigate
> actual state of rtems-source-builder Microwindows configuration.
> I have build demos only from Microwindows completely
> out of RTEMS build in the past. Then original do_it
> script has been adapted and made functional during
> Alexandru-Sever Horin work and Qiao Yang has then
> worked with Chris and others help on RSB build.
> But goal has been libraries build and installation.
> I have tested libraries to compile with our SuiTk
> and OMK based project at that time. I have to dig
> under the RSB hood to find how it is implemented
> and how to run parts of the process to debug and
> modify it. There are some results of this day.
> I have sent patch with proposal to switch to official
> Microwindows repository so following analysis takes
> that into account and does not attempt to build separate
> NXlib package because NXlib is included in the main
> Microwindows repository now. I am testing with i386 BSP
> under QEMU now but I have had no problems with switching
> between that and RPi and i.MX1 in the past.
> The build of complete graphic build set runs smoothly
> after libtiff update to 4.0.6 version.
> cd rtems-source-builder/rtems
> ../source-builder/sb-set-builder \
>     --log=graphic-build-log.txt \
>     --prefix=/opt/rtems4.12 \
>     --rtems-bsp=i386/pc686 \
>     --with-rtems-bsp=pc686 \
>     --pkg-tar-files \
>     graphics/graphics-all.bset
> and my sample application builds, starts and shows initial screen
> correctly.
> But not much more can be tested without modifications because default
> RSB build disables/patches out keyboard for now (RPi keyboard has not
> been implemented and keyboard driver block testing during last GSoC).
> When dependencies are build, I started with looking for Microwindows
> samples build. I have used minimal build set for that with build tree
> clean disabled
> cd rtems-source-builder/rtems
> ../source-builder/sb-set-builder \
>     --log=graphic-microwindows-build-log.txt \
>     --prefix=/opt/rtems4.12 \
>     --rtems-bsp=i386/pc686 \
>     --with-rtems-bsp=pc686 \
>     --pkg-tar-files \
>     --no-clean \
>     graphics/microwindows.bset

I did not try pc686. I directly build for mx6ulevk board.
../source-builder/sb-set-builder --log=l-g.txt
--prefix=/home/Freenix/development/rtems/4.12 --rtems-bsp=arm/mx6ulevk
--with-rtems-bsp=mx6ulevk --pkg-tar-files graphics/graphics-all.bset

But i met errors:
Test programs compile skipped for RTEMS

Building NXext library

NXext.c:6:25: fatal error: X11/Xlibint.h: No such file or directory

 #include <X11/Xlibint.h>


compilation terminated.

Makefile:260: recipe for target 'nxext' failed

make[2]: Leaving directory
make[2]: *** [nxext] Error 1

make[2]: Target 'all' not remade because of errors.

make[1]: ***
Error 2
make[1]: Target 'all' not remade because of errors.

make: *** [all] Error 2

> Build log shows steps of build and sources locations
> rtems-source-builder/rtems/~ms/rsb/microwindows-v0.93-dev-i386-rtems4.12-1.txt
> Generally, if you go to the directory
> rtems-source-builder/rtems/build/microwindows-v0.93-dev-i386-rtems4.12-1
> then there is RSB generated doit script which can be invoked manually
> as well. The core of Microwindows the build is
>   export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686
>   make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all
> In the fact, for fully installed RTEMS for given target with dependencies
> (libtiff, freetype etc.) these two lines are all what you need to do
> in clean, unpathes Microwindows sources to build for RTEMS and it
> has been mechanism I used for many years before more integration
> and which I know the best and can be run directly in Microwindows
> GIT tree and it can be easily edited and corrected with full GIT support
> The Microwindows demos build has been disabled in default Microwindows
> RTEMS config mainline GIT. The config file or make argument MICROWINDEMO=Y
> has to be added
>   export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686
>   make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all
> But demos are not build due disable KBD (kbd_rtems replaced by kbd_null)
> and mouse (mou_rtems replaced by mou_null) and RTEMS specific message
> queues
> are missing there in the MwSelect
>   struct MW_UID_MESSAGE m_kbd
>   struct MW_UID_MESSAGE m_mou
> So at the end, if simple mainline Microwindows build is the most sucesfull
> for now
>   git clone git://
>   cd microwindows/src
>   export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686
>   make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all
> Some applications which require to register events to main system select()
> /
> Windows WaitForMultipleObjects fails because MwRegisterFdOutput and
> corresponding
> functions are not available in RTEMS port. But you find quite a lot of
> demos binaries in microwindows/src/bin and initial IMFS filesystems
> is filled by fonts and demo images. malpha demo can be run for i386/pc686
> under QEMU by next command
>   qemu-system-x86_64 -gdb tcp::1234 -enable-kvm -kernel
> microwindows/src/bin/malpha \
>       -vga cirrus \
>       -net nic,vlan=0,model=e1000 -net user,vlan=0 \
>       -serial stdio \
>       -append "--console=com1 --video=auto"
> You need to define simple graphic driver for RTEMS - generally its
> responsibility
> is to pass framebuffer base address to Microwindows and you need some mouse
> and keyboard UID (micro input driver) driver on RTEMS side.

I have a simple lcdif driver ready, without interrupt support.

> I have interrupt driven GPIO driver for i.MX1/i.MXS which I can share.
There is no keyboard on my board. Anyway If you could share, I may can
reuse it
for other boards in my side. Thanks.

> It is used for ten years in production devices already and it is well
> portable. We use the same core and push repeat brush cancelation FSM
> in many other systems oven on bare metal without OS.
> Your situation on MX6ULT is much simpler at the end because hardware
> solves most of these tasks for you in integrated Keypad Port (KPP)
> peripheral.
> But complete software example can help to understand what needs to be
> bound together.
> And generally, I consider MX6ULT as interesting target so I can
> look at it as well but I have many priority tasks which push me
> to other directions now.

Actually this is just my first target to support RTEMS on i.MX6UL. When most
drivers ready and upstreamed, I also plan to add other i.MX6/7 support. If
are interested, that would be great.

> As for RSB, we need to add option to select if demos should be included
> in the Microwindows build (MICROWINDEMO=Y) and if no mouse patch
> should be applied. In the fact I have plan to modify Microwindows
> to allow select default KBD, mouse and screen drivers independently
> on the target and I believe that it would be accepted by mainline
> so patches should not be applied and mechanism to propagate these
> options to the build should be added. I can help or prepare
> changes with Chris's help when I have some time ...
> I support adaptation of mainline Microwindows to better match
> actual and future RTEMS builds but it has to be done such way
> that easy build from Microwindows GIT is possible and there is
> no option to introduce RTEMS specific branch with another set
> of the subdirectories Makefiles. The top level RTEMS specific one
> can be changed as we want but at least for some years compatibility
> with RTEMS-4.11 and RTEMS-4.10 has to be taken into account.
> I have newer considered Microwindows makefiles as the most elegant
> solution but they are used for many configurations (Linux, Android,
> RTEMS, etc) and I am surprised now that compatibility
> with RTEMS build survived addition of SDL1.2, SDL2.0 builds
> and NXlib in embedded and server options which all happened
> on mainline from my last test Microwindows test after last GSoC
> changes merging to mainline. At least I have no resources
> and even environment to help, propose and test switch of mainline
> Microwindows to another make system (automake, Scons, WAF etc.)
> for all ports. So we need to limit changes to some top level files
> and think how to not break other users ports.

Thanks for all the info and kindly help. I am new to graphics, and met many


> Best wishes,
>               Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list