[RPI BSP] Framebuffer test

[QIAO YANG]

Hi Pavel Pisa,

On Apr 07, 2015, at 06:50 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:

> Hello Yang Qiao,
>
> On Tuesday 07 of April 2015 00:00:33 QIAO YANG wrote:
>> I've implemented a simple framebuffer, but I've got no idea how to test it.
>>
>> I've got Alan's rki and I made a sample to test the mailbox, the
>> framebuffer information seems to be successfully set and get (width,
>> height, pitch, buffer pointer, buffersize etc). In linux we open the
>> interface and map the pointer to set the pixels. If I try to access the
>> pointer and set the memory directly in the driver to draw something, the
>> program will stay still when I try to assign value to a certain address of
>> memory, or maybe it's only allowed to use memset/ memcpy to set the memory?
>>
>> I've also tried to load the driver and open it ( /dev/fb0 ) with "open",
>> but it failed, while I can see the interface with "ls /dev ".
>>
>> In order to test the framebuffer, how can I use the fb interface to print
>> something, or maybe access the memory directly? Is there any existing
>> sample for fb testing? If not, is it necessary to create a common sample
>> for all to print something?
>
> I have not studied how it works on RPi. As I know from
> other reading, some part of physical memory is reserved for
> GPU/framebuffer by one of boot stages and configuration
> can be changed by "gpu_mem" in "config.txt"
>
> http://elinux.org/RPiconfig
>
> It is great if you can setup display output mode.
> How is setup framebuffer start address? In the fact
> if you use same mode setup as is used in Linux then
> you should have same framebuffer starting physical address.
> RTEMS uses 1:1 CPU (virtual) to physical mapping.
> It is necessary to check that framebuffer physical address
> range is covered by 1:1 mapping initialization. This is in the
> fact equivalent to mmap() address space/VMA and page table manipulation
> on Linux. Check page table initialization at
>
> rtems/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
>
> I am almost sure that you have to define additional rage
> to cover framebuffer address range. You should use uncached
> configuration
>
> ARMV7_MMU_DATA_READ_WRITE
>
> at least for start. Some performance can be gained if read caching
> and write through + write combine is enabled for framebuffer area,
> but I am not sure if there is defined matching CP15 combination
> in 
 
I have got it work after setting the MMU. Thanks!
>
>
> rtems/c/src/lib/libcpu/arm/shared/include/arm-cp15.h
>
> If this matches then you should be able to access framebuffer directly.
> I.e. from some BSP/framebuffer driver initialization code or some application
> linked to RTEMS system libraries some or you can modify some RTEMS
> test example to access given address directly.
>
> Which pixel format are you using - 16 bit RGB565, 24 bit RGB888
> or 32 bit RGBA8888? I would suggest to use 32 bit format RGB + 8 bit
> padding when there is enough memory for simplicity. It allows simple
> XY to address conversion and accesses to pixel are aligned.
 
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)?
>
>
> Then you should test something like
>
> memset((char *)startaddress, 0, size_x * size_y * 4);
> for (i = 0; i < 500; i++) {
> ((uint32_t *)startaddress)[i] = 0xffffff;
> ((uint32_t *)startaddress+1280)[i] = 0x0000ff;
> ((uint32_t *)startaddress+1280*2)[i] = 0x00ff00;
> ((uint32_t *)startaddress+1280*3)[i] = 0xff0000;
> }
>
> and you should see white, red, green and blue strips an the to of the display.
> If this goes well then you can check that physical address is passed right
> by /dev/fb0 appropriate IOCTL to the graphic libraries.
 
I've got a screen shot for a rainbow square. I'm now moving to check the interface.
fb_test.png
>
> You can access and modify physical addresses even from terminal by
> RTEMS shell medit command
>
> rtems/cpukit/libmisc/shell/main_medit.c
>
> You need to have shell compiled and started in your application or you
> can compile and use RTEMS shell example for this testing.
> Remember, the mapping is 1:1 and you are in "kernel space"
> so you can access all peripherals and registers accessible to the CPU.
>
> Then I suggest to test Microwindows to paint some more interesting
> image on the screen.
 
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. 
>
>
> Best wishes,
>
> Pavel
 

regards,

YANG QIAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150407/278ed0b6/attachment-0002.html>