RPi Graphic testing

[QIAO YANG]

On Jul 22, 2015, at 05:50 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:

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)
 
here is a working u-boot for rpi, contributed by swarren.
git://github.com/swarren/u-boot.git
you can checkout his branches  rpi_dev*



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);
I misunderstood the comment " /* number of chars per line */ "  I thought it was the number of characters.
Does this fix the mess of first few lines?  Or there may be some other problems?



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.

In fact I didn't quite understand the use of color palette. In some other bsp's implementation, they just define the structure but I didn't see any hardware related code, and some just return zero. I've seen that we can setup the color palettes with videocore interface by mailbox. I can complete that later if necessary. Since it's ignored, I would place it with lower priority.



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.
Excuse me, I'm not sure if I've got it right.
Do you mean that when I setup the memory area in mmu table, I should make the area aligne to 1MB?

I've understood your ideas on setting up the mmu table. I'll give that a try.



Best wishes,

Pavel
 
Thank you very much for all helps.

Best wishes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150723/e83da4f0/attachment-0002.html>