<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi  Pavel,<div><br></div><div>          I have a question to trouble you.</div><div>          What's difference  between  scr_mx1sl.c and rtems-4.11\c\src\lib\libbsp\arm\gumstix\fb\fb.c ?</div><div><br></div><div>The  scr_mx1sl.c  from microwin\src\drivers, and the fb.c in BSP of RTEMS. I think scr_mx1sl.c tell Microwindows how to format the pixel data, and the fb.c tell RTEMS how to initialize the hardware .</div><div><br></div><div> So I think I need two files if I porting Microwindows into RTEMS, they all should be exist. Is right?<br><br><br><br><br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2014-04-14 20:48:33,"Pavel Pisa" <pisa@cmp.felk.cvut.cz> wrote:
>Hello all,
>
>On Sunday 13 of April 2014 06:13:59 Aaron J. Grier wrote:
>> there was some work done on the toolkit in 2012:
>> http://www.rtems.org/wiki/index.php/RTEMSGraphicsToolkit#Experimental_GSoC_
>>2012_Version_of_the_RTEMS_Graphics_Toolkit you should be able to leverage
>> this for your ARM project.
>>
>> I'm a bit out of touch with the current activities involving RTEMS and
>> Nano-X.  The last project I worked on with RTEMS and Nano-X was
>> discontinued at the end of 2010.
>
>we are using Microwindows/Nano-X codebase together
>with our SuiTk GUI on RTEMS at company on ARM CSB336
>board.
>
>We have tested actual RTEMS git build for i386
>with Nano-X under QEMU with CIRRUS GD5446 driver
>developed during mentioned GSoC. The RTEMS configuration
>for that setup is described there
>
>http://www.rtems.org/wiki/index.php/RTEMSGraphicsToolkit#Running_RTEMS_Graphics_Toolkit_under_QEMU
>
>The use of Nano-X with RTEMS on embedded targets where
>framebuffer is simply mapped from fixed someaddress
>in fixed format is quite straightforward. I can provide
>some info and code which we use. I am attaching microwin-080121
>version of our adapted driver as example.
>
>When it is put into src/drivers directory and Nano-X are modified
>to build an use that "driver"/configuration then it can be
>used from application. I.e. calling GdOpenScreen() low level init.
>
>But such solution is not usable for PC and even on other targets
>it is bypassing RTEMS drivers framework.
>
>One of our students - Jan Dolezal - is working now on VESA BIOS
>Extension (VBE3) based solution for standard PC hardware.
>It should be integrated same as CIRRUS GD5446 driver into RTEMS
>mainline if he succeed. Unfortuantelly QEMU VESA BIOS does not
>provide VBE3 support but our initial check shows that most f real cards
>support it. So we hope to provide that solution and then next step
>is add layer to switch between three i386 (VGA, Cirrus and VBE3)
>graphic divers during startup phase. Problem is, that VGA is unusable
>with actual Nano-X because actual Nano-X deprecated/removes old
>planes based driver for ancient VGA hardware.
>
>The support for VBE3 requires application/driver configurable GDT
>entries. Jan Dolezal has already setup GIT repository with his work
>
>  https://github.com/dolezaljan/rtems
>
>As for Nano-X build with use of do_it script, we have found some problem
>with actual version in 
>
>  git://git.rtems.org/rtems-graphics-toolkit.git
>
>The repo points to incorrect Nano-X GIT revision.
>We have used last Alexandru-Sever Horin's version.
>
>  git://github.com/alex-sever-h/microwin.git
>
>and have some minor patch for config. Jan Jan Dolezal should prepare
>it during his bachelor thesis. All is work in progress and we
>planned to announce our actual steps when we have more finished,
>but I am sending as much info now when there is and interrest
>to coordinate possible effort of others and do not repeat
>fails and looking for same corrections.
>
>Best wishes
>
>                Pavel Pisa
>    e-mail:     pisa@cmp.felk.cvut.cz
>    www:        http://cmp.felk.cvut.cz/~pisa
>    university: http://dce.fel.cvut.cz/
>    company:    http://www.pikron.com/
>
>
</pre></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>