Dear Joel,
I compile the GUI packet reference to http://rtems.org/wiki/index.php/RTEMSGraphicsToolkit#Experimental_GSoC_2012_Version_of_the_RTEMS_Graphics_Toolkit but have many errors .Has any detail guide or good packet ?
Thanks!
At 2014-04-15 05:06:40, "Pavel Pisa" <***@pikron.com> wrote:
>Helo Hans,
>
>On Tuesday 15 of April 2014 03:01:54 »Æϲ wrote:
>> Hi Pavel,
>>
>>
>> I'm very happy to get your mail. May be Nano-x can't support the
>> VGA device from your mail. But has a method can realize it. I know the
>> SM502 graphic MCU support LVDS and VGA graphic port. So we can through
>> write the framebuffer,and the SM502 can convert the pixel to VGA format.
>
>you have to be more specific about your hardware to get some
>more relevant answer.
>
>The first, are you speaking about x86 based hardware or embedded
>ARM/MIPS/Sparc based system? Is the SM502 SiliconMotion multimedia
>companion chip?
>
>When I speak about VGA, I have not in mind VGA connector/RGB analog
>signals. The original PC style VGA is standard for I/O registers
>and framebuffer mapping and function on old PCs. It support 640x480
>pixels max and only in 4 BPP format. But due to compatibility
>requirements with all that DOS and other direct hardware accessing
>software the exact registers mapping is support even by allmost
>all today GPU offers which can be used with PC (Intel, Nvidia, ATI/AMD).
>But recent Microwindows/Nano-X versions do not support plane based
>pixels access which is the only way to achieve 640x480 on bare VGA
>hardware so RTEMS included VGA driver is of no use with recent hardware
>and Nano-X.
>
>But the PC based cards are equipped by BIOS which can be called
>and allows to setup required graphic mode. It is called VESA BIOS
>and there exists more of its EXTENSIONS where one (VBE3) allows to
>be called from protected mode. That is what we want to implement for RTEMS.
>
>The other option (for PC and PCI/PCIe/AGP cards) is to write own graphic
>driver which locates card on PCI bus and does whole initialization
>itself. The example is our Cirrus driver
>
>http://git.rtems.org/rtems/tree/c/src/lib/libbsp/i386/pc386/console/fb_cirrus.c
>
>This driver does not use any part of PC BIOS and is not x86 specific in fact
>so it can be adapted/included in other RTEMS platforms/architectures builds
>and in the fact it should be moved to some shared location one day.
>Ideally with support for runtime (at RTEMS startup) selection of graphic
>hardware support.
>
>> Through your attaching file. Maybe I can porting the Nano-X with
>> RTEMS to ARM MCU with a LCD.
>
>In the case of embedded, you need to use/implement target system specific
>driver.
>
> On Tuesday 15 of April 2014 03:40:32 »Æϲ wrote:
>> What's difference between scr_mx1sl.c and
>> rtems-4.11\c\src\lib\libbsp\arm\gumstix\fb\fb.c ?
>
>The RTEMS Gumstick graphics driver is a real/integrated RTEMS driver
>which provides IOCTL based control over hardware
>
>http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/gumstix/fb/fb.c
>
>When Nano-X is configured for RTEMS then it selects scr_rtems.c
>
>https://github.com/alex-sever-h/microwin/blob/master/src/drivers/scr_rtems.c
>
>its graphics driver/configuration. In the fact that driver
>does not setup mode directly in HW but opens console device
>previously registered by target specific RTEMS fb.c and uses
>architecture independent IOCTLs to ask HW setup from RTEMS.
>RTEMS fb.c provides information about selected mode and
>pixels organization and setups Nano-X PSD/drawing rutines
>for that mode, BPP etc.
>
>> 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 .
>
>Our scr_mx1sl.c bypasses RTEMS framebuffer driver (we do not have one for
>CSB336). But because we know that our bootblock setups graphics and
>shows logo on display, we know that we do not need to take care about
>initialization. The framebuffer start address and other parameters
>are delivered to RTEMS application through our system specific
>BootBlock Config structures and at the end we directly provide
>information to the Nano-X through scr_mx1sl.c where is framebuffer
>RAM located etc. We than do some more tricks to achieve full screen
>double buffering etc. But for you, scr_mx1sl.c, is an example
>how to do all graphics setup under application control without
>need to modify RTEMS BSP support.
>
>> So I think I need two files if I porting Microwindows into RTEMS, they all
>> should be exist. Is right?
>
>I hope, my description should be enough. It could worth to somehow clean
>it up and put somewhere into RTEMS wiki.
>
>I guess that you are speaking about ARM based system with PCI and
>SiliconMotion multimedia SM502 companion chip.
>
>In such case, you should start from Cyrrus PCI driver if RTEMS support
>PCI configuration space access functions on your target.
>You need to find how SM502 should be configured for you panel
>and write code to provide setup over card memory mapped regions
>(start addresses needs to be setup/can be found from PCI device
>BAR registers).
>
>If you achieve mode setup then you need to find/map actual framebuffer
>to the ARM CPU address pace and provide start address and mode to
>the calling scr_rtems.c driver. Then Nano-X should use your HW
>and can draw GUI.
>
>But be prepared that it can be quite slow for higher resolutions.
>The chip gains speed through acceleration.
>Nano-X provides good infrastructure for 2D acceleration but
>if you want to use SM502 hardware implementation of blits etc.,
>then you need to write your own scr_xxx driver which provides
>own implementation of these function which can send commands
>directly to the chip. You can route calls through target specific
>fb.c included in RTEMS through IOCTLs or you can access HW directly
>form your Nano-X driver. Because there would be quite huge amount
>of code required and it would be quite specific to your setup
>it can be easier in such case to move all, even HW initialization
>to target specific Nano-X driver and bypass RTEMS fb.c.
>Other option is to negotiate RTEMS wide set of IOCTLs for graphic
>acceleration, but I think that it is simper and more flexible
>to write code in one place first and start more universal infrastructure
>implementation when there knowledge/experience
>gained.
>
>Best wishes,
>
> Pavel Pisa
>
>==================================================
> PiKRON s.r.o. Phone/Fax: +420 2 84684676
> Kankovskeho 1235 Phone: +420 2 84684676
> 182 00 Praha 8 WWW: http://www.pikron.com/
> Czech Republic e-mail: ***@pikron.com
>==================================================
>
>
>>
>> At 2014-04-14 20:48:33,"Pavel 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_GS
>> >>oC_ 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_Gra
>> >phics_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: ***@cmp.felk.cvut.cz
>> > www: http://cmp.felk.cvut.cz/~pisa
>> > university: http://dce.fel.cvut.cz/
>> > company: http://www.pikron.com/
>