How to porting Nano-X to RTEMS, graphic drivers support and PC VESA support.

[黄喜]

Hi  Pavel,


          I have a question to trouble you.
          What's difference  between  scr_mx1sl.c and rtems-4.11\c\src\lib\libbsp\arm\gumstix\fb\fb.c ?


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 .


 So I think I need two files if I porting Microwindows into RTEMS, they all should be exist. Is right?








At 2014-04-14 20:48:33,"Pavel Pisa" <pisa at 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 at cmp.felk.cvut.cz
>    www:        http://cmp.felk.cvut.cz/~pisa
>    university: http://dce.fel.cvut.cz/
>    company:    http://www.pikron.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140415/d72e3da3/attachment-0001.html>