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

[huangxi_hans]

Hello Pavel,

          Thanks!! And your answer is so detailed.

          I will enable the D-cache and I-cache. If  I  disable the I-cache, the code is running so slowly.

          The framebuffer address is managed by SM502 if I use the SM502 with AT91SAM9G45, but the AT91SAM9G45 directly write this address. Because the SM502 connect a SDRAM for framebuffer RAM,this SDRAM only for framebuffer, not use for other task. My step is below:

         1.   Config the SM502 chip in bootloader, and show logo. That's verify the HW design is or not right.

         2.   Porting the RTEMS 4.11 to AT91SAM9G45 ,and running some tasks ,verify the RTEMS is or not OK.

         3.   Show circle and line to LCD through the RTEMS . Verify LCD handle is or not OK in RTEMS.

         4.    Porting the Nano-X to RTEMS  and  refer to your  scr_mx1sl.c. This course may be need some times.


          Later, may be have some questions need to trouble you. You're a wonderful teacher.


          







huangxi_hans

From: Pavel Pisa
Date: 2014-04-16 16:26
To: 黄喜
CC: rtems-users
Subject: Re: How to porting Nano-X to RTEMS, graphic drivers support and PC VESA support.
Helo Hans,


On Wednesday 16 of April 2014 03:35:19 黄喜 wrote:
>                My project  is based on ARM with SM502 Silicon Motion
> multimedia chip. But the at91sam9g45 connect SM502 through the address bus
> ,data bus and chip select signal.It is not through the PCI interface. But
> the SM502 support the PCI interface connect to other MCU.For example.
> Xscale, MIPS, Hitach etc.
>
>         According to above your answer, The CSB336 has not a fb.c file  in
> RTEMS, the LCD Hardware initialization steps finish in bootloader or
> bootblock.So the LCD controller is initialized before run RTEMS, only do
> scr_mx1sl.c  steps tell Nano-X how to do. The RTEMS doesn't  need know any
> information about the framebuffer. So has not a framebuffer driver
> architecture in CSB336 port. Is right?

Yes, that is a option. RTEMS usually maps virtual and physical addrespace 1:1
so direct access is possible. You need to consider cache. The area 
representing framebuffer control registers has to be uncached and framebuffer
area should be write through (ideally + combine) cached or uncached (slower).

Look at CSB336 memory mapping as an example.

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/csb336/startup/memmap.c

We use framebuffer in main memory for some boards variants (MXS based)
and we need to declare it as MMU_CACHE_WTHROUGH.

>        I don't through the PCI interface connect to SM502 chip. I through
> the data bus and address bus connect to SM502 chip. And I have some
> experience to achieve it about Hardware. And have some demo code to tell me
> how to initialize the SM502 chip through the address bus and data bus, so I
> want to put these initialization code in bootloader, bypass RTEMS
> framebuffer architecture,Because I need show logo of company, and copy the
> application from norflash to DDR. And then base your scr_mx1sl.c to give
> the fixed framebuffer address and LCD configure information to Nano-X.  Is
> a viable method?

Yes than my approach is most simple and you can even use allmost directly
bare metal support code from RTEMS. Writing simple RTEMS based driver
should not be problem as well but you do not gain too much there
and if your framebuffer mapping is specific for your HW (i.e. GPU
is not part of standard supported board or SoC) then there is not
significant reason to try to push it into RTEMS mainline.

I do CC to mainlinglist because information can be interresting
to others as well.

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
==================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140416/4ef986d6/attachment-0001.html>