<div dir="ltr">Hi Pavel,<div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-17 6:23 GMT+08:00 Pavel Pisa <span dir="ltr"><<a href="mailto:ppisa4lists@pikron.com" target="_blank">ppisa4lists@pikron.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello Peng and Chris,<br>
<br>
I have been looking to find some more time to upgrade to<br>
actual RTEMS-4.12 compiler GCC-6.1 toolchain and investigate<br>
actual state of rtems-source-builder Microwindows configuration.<br>
<br>
I have build demos only from Microwindows completely<br>
out of RTEMS build in the past. Then original do_it<br>
script has been adapted and made functional during<br>
Alexandru-Sever Horin work and Qiao Yang has then<br>
worked with Chris and others help on RSB build.<br>
But goal has been libraries build and installation.<br>
I have tested libraries to compile with our SuiTk<br>
and OMK based project at that time. I have to dig<br>
under the RSB hood to find how it is implemented<br>
and how to run parts of the process to debug and<br>
modify it. There are some results of this day.<br>
<br>
I have sent patch with proposal to switch to official<br>
Microwindows repository so following analysis takes<br>
that into account and does not attempt to build separate<br>
NXlib package because NXlib is included in the main<br>
Microwindows repository now. I am testing with i386 BSP<br>
under QEMU now but I have had no problems with switching<br>
between that and RPi and i.MX1 in the past.<br>
<br>
The build of complete graphic build set runs smoothly<br>
after libtiff update to 4.0.6 version.<br>
<br>
cd rtems-source-builder/rtems<br>
<br>
../source-builder/sb-set-builder \<br>
--log=graphic-build-log.txt \<br>
--prefix=/opt/rtems4.12 \<br>
--rtems-bsp=i386/pc686 \<br>
--with-rtems-bsp=pc686 \<br>
--pkg-tar-files \<br>
graphics/graphics-all.bset<br>
<br>
and my sample application builds, starts and shows initial screen correctly.<br>
But not much more can be tested without modifications because default<br>
RSB build disables/patches out keyboard for now (RPi keyboard has not<br>
been implemented and keyboard driver block testing during last GSoC).<br>
<br>
When dependencies are build, I started with looking for Microwindows<br>
samples build. I have used minimal build set for that with build tree<br>
clean disabled<br>
<br>
cd rtems-source-builder/rtems<br>
<br>
../source-builder/sb-set-builder \<br>
--log=graphic-microwindows-build-log.txt \<br>
--prefix=/opt/rtems4.12 \<br>
--rtems-bsp=i386/pc686 \<br>
--with-rtems-bsp=pc686 \<br>
--pkg-tar-files \<br>
--no-clean \<br>
graphics/microwindows.bset<br></blockquote><div><br></div><div>I did not try pc686. I directly build for mx6ulevk board.</div><div>../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<br></div><div><br></div><div>But i met errors:</div><div>"</div><div><div>Test programs compile skipped for RTEMS </div><div>Building NXext library </div><div>NXext.c:6:25: fatal error: X11/Xlibint.h: No such file or directory </div><div> #include <X11/Xlibint.h> </div><div> ^ </div><div>compilation terminated. </div><div>Makefile:260: recipe for target 'nxext' failed </div><div>make[2]: Leaving directory '/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/microwindows-v0.93-dev-arm-rtems4.12-1/build-xc/src/nxlib'</div><div>make[2]: *** [nxext] Error 1 </div><div>make[2]: Target 'all' not remade because of errors. </div><div>make[1]: *** [subdir-/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/microwindows-v0.93-dev-arm-rtems4.12-1/build-xc/src/nxlib] Error 2</div><div>make[1]: Target 'all' not remade because of errors. </div><div>make: *** [all] Error 2</div></div><div>"</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Build log shows steps of build and sources locations<br>
<br>
rtems-source-builder/rtems/~ms/rsb/microwindows-v0.93-dev-i386-rtems4.12-1.txt<br>
<br>
Generally, if you go to the directory<br>
<br>
rtems-source-builder/rtems/build/microwindows-v0.93-dev-i386-rtems4.12-1<br>
<br>
then there is RSB generated doit script which can be invoked manually<br>
as well. The core of Microwindows the build is<br>
<br>
export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686<br>
make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all<br>
<br>
In the fact, for fully installed RTEMS for given target with dependencies<br>
(libtiff, freetype etc.) these two lines are all what you need to do<br>
in clean, unpathes Microwindows sources to build for RTEMS and it<br>
has been mechanism I used for many years before more integration<br>
and which I know the best and can be run directly in Microwindows<br>
GIT tree and it can be easily edited and corrected with full GIT support<br>
<br>
The Microwindows demos build has been disabled in default Microwindows<br>
RTEMS config mainline GIT. The config file or make argument MICROWINDEMO=Y<br>
has to be added<br>
<br>
export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686<br>
make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all MICROWINDEMO=Y<br>
<br>
But demos are not build due disable KBD (kbd_rtems replaced by kbd_null)<br>
and mouse (mou_rtems replaced by mou_null) and RTEMS specific message queues<br>
are missing there in the MwSelect<br>
<br>
struct MW_UID_MESSAGE m_kbd<br>
struct MW_UID_MESSAGE m_mou<br>
<br>
So at the end, if simple mainline Microwindows build is the most sucesfull for now<br>
<br>
git clone git://<a href="http://github.com/ghaerr/microwindows.git" rel="noreferrer" target="_blank">github.com/ghaerr/microwindows.git</a><br>
cd microwindows/src<br>
export RTEMS_MAKEFILE_PATH=/opt/rtems4.12/i386-rtems4.12/pc686<br>
make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all MICROWINDEMO=Y<br>
<br>
Some applications which require to register events to main system select() /<br>
Windows WaitForMultipleObjects fails because MwRegisterFdOutput and corresponding<br>
functions are not available in RTEMS port. But you find quite a lot of<br>
demos binaries in microwindows/src/bin and initial IMFS filesystems<br>
is filled by fonts and demo images. malpha demo can be run for i386/pc686 BSP<br>
under QEMU by next command<br>
<br>
qemu-system-x86_64 -gdb tcp::1234 -enable-kvm -kernel microwindows/src/bin/malpha \<br>
-vga cirrus \<br>
-net nic,vlan=0,model=e1000 -net user,vlan=0 \<br>
-serial stdio \<br>
-append "--console=com1 --video=auto"<br>
<br>
You need to define simple graphic driver for RTEMS - generally its responsibility<br>
is to pass framebuffer base address to Microwindows and you need some mouse<br>
and keyboard UID (micro input driver) driver on RTEMS side.<br></blockquote><div><br></div><div>I have a simple lcdif driver ready, without interrupt support. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I have interrupt driven GPIO driver for i.MX1/i.MXS which I can share.<br></blockquote><div>There is no keyboard on my board. Anyway If you could share, I may can reuse it</div><div>for other boards in my side. Thanks. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It is used for ten years in production devices already and it is well<br>
portable. We use the same core and push repeat brush cancelation FSM<br>
in many other systems oven on bare metal without OS.<br>
<br>
Your situation on MX6ULT is much simpler at the end because hardware<br>
solves most of these tasks for you in integrated Keypad Port (KPP) peripheral.<br>
But complete software example can help to understand what needs to be<br>
bound together.<br>
<br>
And generally, I consider MX6ULT as interesting target so I can<br>
look at it as well but I have many priority tasks which push me<br>
to other directions now.<br></blockquote><div><br></div><div>Actually this is just my first target to support RTEMS on i.MX6UL. When most</div><div>drivers ready and upstreamed, I also plan to add other i.MX6/7 support. If you</div><div>are interested, that would be great.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As for RSB, we need to add option to select if demos should be included<br>
in the Microwindows build (MICROWINDEMO=Y) and if no mouse patch<br>
should be applied. In the fact I have plan to modify Microwindows<br>
to allow select default KBD, mouse and screen drivers independently<br>
on the target and I believe that it would be accepted by mainline<br>
so patches should not be applied and mechanism to propagate these<br>
options to the build should be added. I can help or prepare<br>
changes with Chris's help when I have some time ...<br>
<br>
I support adaptation of mainline Microwindows to better match<br>
actual and future RTEMS builds but it has to be done such way<br>
that easy build from Microwindows GIT is possible and there is<br>
no option to introduce RTEMS specific branch with another set<br>
of the subdirectories Makefiles. The top level RTEMS specific one<br>
can be changed as we want but at least for some years compatibility<br>
with RTEMS-4.11 and RTEMS-4.10 has to be taken into account.<br>
I have newer considered Microwindows makefiles as the most elegant<br>
solution but they are used for many configurations (Linux, Android,<br>
RTEMS, etc) and I am surprised now that compatibility<br>
with RTEMS build survived addition of SDL1.2, SDL2.0 builds<br>
and NXlib in embedded and server options which all happened<br>
on mainline from my last test Microwindows test after last GSoC<br>
changes merging to mainline. At least I have no resources<br>
and even environment to help, propose and test switch of mainline<br>
Microwindows to another make system (automake, Scons, WAF etc.)<br>
for all ports. So we need to limit changes to some top level files<br>
and think how to not break other users ports.<br></blockquote><div><br></div><div>Thanks for all the info and kindly help. I am new to graphics, and met many issues(:</div><div><br></div><div>Thanks,</div><div>Peng.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Best wishes,<br>
<br>
Pavel<br>
</blockquote></div><br></div></div></div>