RPi Graphic testing

[Pavel Pisa]

Hello Qiao Yang,

On Wednesday 22 of July 2015 11:19:35 QIAO YANG wrote:
> Hi,
>
> When I updated to the latest firmware start.elf , the graphic doesn’t show
> anymore. I haven’t yet found out what has been changed in the latest
> firmware. I’ve uploaded my firmware. I’ve retested my latest commit, it
> worked with hello, ticker and rbi samples.
>
> https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0
> <https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0>

I have been able to run your binary of ticker and its console is displayed
on the RPi correctly. Whwn I have used your binary and start.elf on my card
then it runs OK as well. I have tried even your binary when loaded
by u-boot from TFTP server. I have hard time to find right version
of U-boot with working network support.

Only older version works correctly and I am not sure
if that one was compiled by me or even loaded from some
site

U-Boot 2014.10-rc2-g600877e-dirty (Sep 25 2014 - 09:57:12)

But with right U-boot version the binary works as well.
I have build successfully ticker binary myself as well.

Then I have tested my complete graphic application example.
I have to disable keyboard and mouse config and then have
obstacle with framebuffer driver setup

#if (BSP_HAS_FRAME_BUFFER == 1)
  #define CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
#endif

#define CONFIGURE_INIT
#include <rtems/confdefs.h>

Because raspberrypi BSP does not set define BSP_HAS_FRAME_BUFFER yet.
When I forced graphics inclusion then application starts.

But there seems to be some problem with some parameters obtained
from graphic driver probably or some other similar problem
because image is screwed on the couple of the first lines.
But start of the display seems to be right.

Parameters

[#]fb_var_screeninfo: xres : 1280
[#]fb_var_screeninfo: yres : 1024
[#]fb_var_screeninfo: bpp : 32

matches monitor info and values in the driver structures looks
reasonable either

fb_fix_info = {smem_start = 0xe6fa000 "\377", smem_len = 5242880,
               type = 0, visual = 2, line_length = 160}

But there is a mistake with computed line_length. It is number
of bytes for one image line. So next change is required

--- a/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
@@ -126,7 +126,8 @@ fb_init(void)
   fb_var_info.bits_per_pixel = init_frame_buffer_entries.depth;
   fb_fix_info.smem_start = init_frame_buffer_entries.base;
   fb_fix_info.smem_len = init_frame_buffer_entries.size;
-  fb_fix_info.line_length = fb_var_info.xres/VIDEO_FONT_WIDTH;
+  fb_fix_info.line_length = fb_var_info.xres *
+                            ((fb_var_info.bits_per_pixel + 7) / 8);

   printk("[#]fb_var_screeninfo: xres : %lu\n", fb_var_info.xres);
   printk("[#]fb_var_screeninfo: yres : %lu\n", fb_var_info.yres);

As for the

fb_var_info = {xres = 1280, yres = 1024, bits_per_pixel = 32,
               red = {offset = 0, length = 0, msb_right = 0},
               green = {offset = 0, length = 0, msb_right = 0},
               blue = {offset = 0, length = 0, msb_right = 0},
               transp = {offset = 0, length = 0, msb_right = 0}}

the colors fields locations are missing but that information
is ignored by actual Microwindows so it is not problem for now.

As for the memory map setup, the RTEMS does use only
single level pagetable/MMU regions setup for CP15 (MMU)
equipped arms. That means that maping works with 1 MB
blocks granularity.

Look at arm_cp15_start_setup_translation_table() and 
arm_cp15_start_set_translation_table_entries() functions in
in

  c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h

and other related functions in in
  c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
  c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c

The 1 MB granularity/page size is reflected by

  #define ARM_MMU_SECT_BASE_SHIFT 20

in

  c/src/lib/libcpu/arm/shared/include/arm-cp15.h

So if you detect size of the memory window for VideoCore,
you should align it/extend it down and up to 1 MB boundary
or at least consider that behavior of the mapping functions.

The actual limit of the memory usable for RTEMS application
below VideoCore region should be used to setup limit
for RTEMS workspace and application memory size later.

Best wishes,

             Pavel