<div dir="ltr">Hi everyone,<div>A while back, I experimented with different graphics demos on the Pi. I integrated some of this code into the RKI image and was able to draw simple graphics under RTEMS:</div><div><a href="https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/screen01.html">https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/screen01.html</a><br></div><div><br></div><div>There are some other neat demos available too. This person ported the ugfx library to the Pi using FreeRTOS:</div><div><a href="http://macload1.frogcp.com/">http://macload1.frogcp.com/</a><br></div><div>I was able to run several of the ugfx graphics demos using this port ( under FreeRTOS, not RTEMS ) </div><div><br></div><div>This person has some really nice demos using bare metal. He has support for NEON and SMP on the Raspberry Pi 2 as well.</div><div><a href="https://github.com/PeterLemon/RaspberryPi">https://github.com/PeterLemon/RaspberryPi</a><br></div><div><br></div><div>Another bare metal Multi-core mandelbrot demo:</div><div><a href="https://github.com/mrvn/test">https://github.com/mrvn/test</a><br></div><div><a href="http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904&start=50">http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904&start=50</a><br></div><div><br></div><div>Of course, all of the usual License caveats apply.. This is all good for fun and education, but the code cannot be copied into RTEMS because the licenses are not compatible with the RTEMS license. But they all serve as good references and examples of what can be done with graphics on the Pi. ( and some SMP Pi 2 hints in there ! ) </div><div><br></div><div><br></div><div>Alan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 6:50 PM, Pavel Pisa <span dir="ltr"><<a href="mailto:ppisa4lists@pikron.com" target="_blank">ppisa4lists@pikron.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Yang Qiao,<br>
<div><div class="h5"><br>
On Tuesday 07 of April 2015 00:00:33 QIAO YANG wrote:<br>
> I've implemented a simple framebuffer, but I've got no idea how to test it.<br>
><br>
> I've got Alan's rki and I made a sample to test the mailbox, the<br>
> framebuffer information seems to be successfully set and get (width,<br>
> height, pitch, buffer pointer, buffersize etc). In linux we open the<br>
> interface and map the pointer to set the pixels. If I try to access the<br>
> pointer and set the memory directly in the driver to draw something, the<br>
> program will stay still when I try to assign value to a certain address of<br>
> memory, or maybe it's only allowed to use memset/ memcpy to set the memory?<br>
><br>
> I've also tried to load the driver and open it ( /dev/fb0 ) with "open",<br>
> but it failed, while I can see the interface with "ls /dev ".<br>
><br>
> In order to test the framebuffer, how can I use the fb interface to print<br>
> something, or maybe access the memory directly? Is there any existing<br>
> sample for fb testing? If not, is it necessary to create a common sample<br>
> for all to print something?<br>
<br>
</div></div>I have not studied how it works on RPi. As I know from<br>
other reading, some part of physical memory is reserved for<br>
GPU/framebuffer by one of boot stages and configuration<br>
can be changed by "gpu_mem" in "config.txt"<br>
<br>
<a href="http://elinux.org/RPiconfig" target="_blank">http://elinux.org/RPiconfig</a><br>
<br>
It is great if you can setup display output mode.<br>
How is setup framebuffer start address? In the fact<br>
if you use same mode setup as is used in Linux then<br>
you should have same framebuffer starting physical address.<br>
RTEMS uses 1:1 CPU (virtual) to physical mapping.<br>
It is necessary to check that framebuffer physical address<br>
range is covered by 1:1 mapping initialization. This is in the<br>
fact equivalent to mmap() address space/VMA and page table manipulation<br>
on Linux. Check page table initialization at<br>
<br>
rtems/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c<br>
<br>
I am almost sure that you have to define additional rage<br>
to cover framebuffer address range. You should use uncached<br>
configuration<br>
<br>
ARMV7_MMU_DATA_READ_WRITE<br>
<br>
at least for start. Some performance can be gained if read caching<br>
and write through + write combine is enabled for framebuffer area,<br>
but I am not sure if there is defined matching CP15 combination<br>
in<br>
<br>
rtems/c/src/lib/libcpu/arm/shared/include/arm-cp15.h<br>
<br>
If this matches then you should be able to access framebuffer directly.<br>
I.e. from some BSP/framebuffer driver initialization code or some application<br>
linked to RTEMS system libraries some or you can modify some RTEMS<br>
test example to access given address directly.<br>
<br>
Which pixel format are you using - 16 bit RGB565, 24 bit RGB888<br>
or 32 bit RGBA8888? I would suggest to use 32 bit format RGB + 8 bit<br>
padding when there is enough memory for simplicity. It allows simple<br>
XY to address conversion and accesses to pixel are aligned.<br>
<br>
Then you should test something like<br>
<br>
memset((char *)startaddress, 0, size_x * size_y * 4);<br>
for (i = 0; i < 500; i++) {<br>
((uint32_t *)startaddress)[i] = 0xffffff;<br>
((uint32_t *)startaddress+1280)[i] = 0x0000ff;<br>
((uint32_t *)startaddress+1280*2)[i] = 0x00ff00;<br>
((uint32_t *)startaddress+1280*3)[i] = 0xff0000;<br>
}<br>
<br>
and you should see white, red, green and blue strips an the to of the display.<br>
If this goes well then you can check that physical address is passed right<br>
by /dev/fb0 appropriate IOCTL to the graphic libraries.<br>
<br>
You can access and modify physical addresses even from terminal by<br>
RTEMS shell medit command<br>
<br>
rtems/cpukit/libmisc/shell/main_medit.c<br>
<br>
You need to have shell compiled and started in your application or you<br>
can compile and use RTEMS shell example for this testing.<br>
Remember, the mapping is 1:1 and you are in "kernel space"<br>
so you can access all peripherals and registers accessible to the CPU.<br>
<br>
Then I suggest to test Microwindows to paint some more interesting<br>
image on the screen.<br>
<br>
Best wishes,<br>
<br>
Pavel<br>
<br>
</blockquote></div><br></div>