回复: Re: How to porting Nano-X to RTEMS, graphic drivers support and PC VESA support.

huangxi_hans huangxi_hans at 163.com
Wed Apr 16 14:22:53 UTC 2014


Hi  Gedare,

          I will supply the detailed porting steps if I porting the Nano-X  and RTEMS to AT91SAM9G45 MCU successful.





huangxi_hans

发件人: Gedare Bloom
发送时间: 2014-04-16 22:19
收件人: huangxi_hans
抄送: Pavel Pisa; rtems-users
主题: Re: Re: How to porting Nano-X to RTEMS, graphic drivers support and PC VESA support.
Thank you both for keeping this on the list. -Gedare

On Wed, Apr 16, 2014 at 9:44 AM, huangxi_hans <huangxi_hans at 163.com> wrote:
> 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
> ==================================================
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140416/166ceda9/attachment.html>


More information about the users mailing list