How to porting Nano-X to RTEMS, graphic drivers support and PC VESA support.
Pavel Pisa
ppisa4lists at pikron.com
Tue Apr 15 09:06:40 UTC 2014
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 at pikron.com
==================================================
>
> 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_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: pisa at cmp.felk.cvut.cz
> > www: http://cmp.felk.cvut.cz/~pisa
> > university: http://dce.fel.cvut.cz/
> > company: http://www.pikron.com/
More information about the users
mailing list