[RPI BSP] Framebuffer test

[Pavel Pisa]

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 

  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.

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.

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.

Best wishes,

            Pavel