<html><body><div>Hi Pavel Pisa,<br><br>On Apr 07, 2015, at 06:50 AM, Pavel Pisa <ppisa4lists@pikron.com> wrote:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content">Hello Yang Qiao,<br><br>On Tuesday 07 of April 2015 00:00:33 QIAO YANG wrote:<br></span></span><blockquote class="quoted-plain-text" type="cite">I've implemented a simple framebuffer, but I've got no idea how to test it.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">I've got Alan's rki and I made a sample to test the mailbox, the</blockquote><blockquote class="quoted-plain-text" type="cite">framebuffer information seems to be successfully set and get (width,</blockquote><blockquote class="quoted-plain-text" type="cite">height, pitch, buffer pointer, buffersize etc). In linux we open the</blockquote><blockquote class="quoted-plain-text" type="cite">interface and map the pointer to set the pixels. If I try to access the</blockquote><blockquote class="quoted-plain-text" type="cite">pointer and set the memory directly in the driver to draw something, the</blockquote><blockquote class="quoted-plain-text" type="cite">program will stay still when I try to assign value to a certain address of</blockquote><blockquote class="quoted-plain-text" type="cite">memory, or maybe it's only allowed to use memset/ memcpy to set the memory?</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">I've also tried to load the driver and open it ( /dev/fb0 ) with "open",</blockquote><blockquote class="quoted-plain-text" type="cite">but it failed, while I can see the interface with "ls /dev ".</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">In order to test the framebuffer, how can I use the fb interface to print</blockquote><blockquote class="quoted-plain-text" type="cite">something, or maybe access the memory directly? Is there any existing</blockquote><blockquote class="quoted-plain-text" type="cite">sample for fb testing? If not, is it necessary to create a common sample</blockquote><blockquote class="quoted-plain-text" type="cite">for all to print something?</blockquote><span class="body-text-content"><br>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" data-mce-href="http://elinux.org/RPiconfig">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 </span></div></div></blockquote><span> </span><br>I have got it work after setting the MMU. Thanks!<br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><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.</span></div></div></blockquote><span> </span><br>In fact, for the moment, I'm using 16bit RGBA for display. As for the memory, rpi A has 256MB, rpi B has 512MB, and rpi2 has 1GB. I'm not as experience to tell which format would be better but I'll consider that. Is there any kernel configuration that would let user to determine the memory for GPU(it's like the memory split on wheezy)? <br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><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></span></div></div></blockquote><span> </span><br>I've got a screen shot for a rainbow square. I'm now moving to check the interface.<br><img class="_mime-inline " style="margin:10px;" title="fb_test.png" src="blob:https://www.icloud.com/92b2506a-88fb-4d06-8293-639466c47eb6" alt="fb_test.png" data-mce-src="blob:https://www.icloud.com/92b2506a-88fb-4d06-8293-639466c47eb6" data-mce-style="margin: 10px;"><br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><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.</span></div></div></blockquote><span> </span><br>I guess you've got my reply on the email, gtk building. It's weird that all libraries are installed successfully, but the compiler still complain about library missing. Do you have any idea what might be the problem? I'll try to compile some samples without the build scripts later. <br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>Best wishes,<br><br> Pavel<br></span></div></div></blockquote><span> </span><br><br>regards,<br><br>YANG QIAO<br></div></div></body></html>