Is there any framebuffer testcases?

Pavel Pisa ppisa4lists at
Sat Apr 16 22:23:36 UTC 2016

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 \

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 \

Build log shows steps of build and sources locations


Generally, if you go to the directory


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 MICROWINDEMO=Y

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 MICROWINDEMO=Y

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 BSP
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 interrupt driven GPIO driver for i.MX1/i.MXS which I can share.
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.

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.

Best wishes,


More information about the users mailing list