RPi Graphic testing

Pavel Pisa pisa at cmp.felk.cvut.cz
Mon Jul 20 18:38:46 UTC 2015


Hello Qiao Yang and other,

On Monday 20 of July 2015 15:06:23 Pavel Pisa wrote:
> Hello Qiao Yang,
>
> I have spent more time with attempt to test
> your RPi code but I am not sucesfull.
> I have tried direct boot to application binary
> as well as U-boot based start.
>
> I expect that problem source can be version
> of my primary bootloader

I have tested the build and it seems that real problem
is really mismatch between VideoCore area sent
to the monitor and RTEMS view because application
seems to run OK, detects monitor

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

DRAM:  448 MiB
....
....

[+] framebuffer initialize
[+] framebuffer use display resolution 1280*1024
[#]fb_var_screeninfo: xres : 1280
[#]fb_var_screeninfo: yres : 1024
[#]fb_var_screeninfo: bpp : 32
[#]fb_fix_screeninfo: smem_start : 1C006000
[#]fb_fix_screeninfo: smem_len : 500000
[#]fb_fix_screeninfo: line_length : 160
[#]_RPI_initVideo: maxCol : 160
[#]_RPI_initVideo: maxRow : 64
[#]_RPI_initVideo: fb_mem : 1C006000

and correctly advances to the Init() and test application,
even character output is called right way to the RPi graphic
console support. Stack trace for curiosity

#0  _RPI_outch (c=48 '0') at ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/outch.c:347
#1  0x0000a320 in fbcons_write_polled (c=48 '0', minor=<optimized out>) 
at ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:79
#2  fbcons_write_support_polled (minor=<optimized out>, buf=0x10a6df "0\001", len=1) 
at ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:102
#3  0x0000f8c0 in oproc (c=<optimized out>, tty=tty at entry=0x10eb50) 
at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/termios.c:1192
#4  0x0000feb4 in rtems_termios_write (arg=0x10a700) 
at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/termios.c:1214
#5  0x000177ec in rtems_deviceio_write (iop=0x103d70 <rtems_libio_iops+112>, buf=<optimized out>, nbyte=<optimized out>, major=<optimized 
out>, minor=1) at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109
#6  0x0001704c in device_write (iop=<optimized out>, buffer=<optimized out>, count=<optimized out>) 
at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libfs/src/imfs/deviceio.c:82
#7  0x0001a274 in __swrite (ptr=0x105a08, cookie=0x105c40, buf=0x10a897 "0", n=1) 
at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/stdio.c:97
#8  0x0001b95c in __sfvwrite_r (ptr=0x105a08, fp=0x105c40, uio=0x10a7e8) at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/fvwrite.c:99
#9  0x0001a408 in __sprint_r (ptr=<optimized out>, fp=0x105c40, uio=0x10a7e8) 
at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/vfprintf.c:437
#10 0x0001b204 in _vfiprintf_r (data=0x105a08, fp=fp at entry=0x105c40, fmt0=fmt0 at entry=0x41 "", ap=...) 
at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/vfprintf.c:1774
#11 0x00019f00 in fiprintf (fp=0x105c40, fmt=0x100398 "%s%02lu:%02lu:%02lu   %02lu/%02lu/%04lu%s") 
at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/fiprintf.c:50
#12 0x00008ba4 in Test_task (unused=<optimized out>) 
at ../../../../../../../../../git/rtems-yangqiao/c/src/../../testsuites/samples/ticker/tasks.c:44
#13 0x00019810 in _Thread_Handler () at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/score/src/threadhandler.c:95
#14 0x000197a0 in TOD_TICKS_PER_SECOND_method () 
at ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/score/src/coretodtickspersec.c:28
#15 0x00002008 in ?? ()
#16 0x00002008 in ?? ()

As for ATAGS, on my system it seems that argument passed by U-boot is consistent. Memory content

0x100:	0x00000005 0x54410001
0x108:  0x00000000 0x00000000 0x00000000
  ATAG_CORE block, 5 words complete, all zeros

0x114:  0x00000004 0x54410002 0x1c000000 0x00000000
  ATAG_MEM block, 4 words
  __u32   size = 0x1c000000 ... 448 MiB
  __u32   start = 0x00000000

0x124:  0x00000067 0x54410009
  ATAG_CMDLINE block, 0x67 words ... 412 - 8 bytes
  next ATAG at 0x124 + 0x067 * 4 => 0x2c0

0x12c:	"dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708.boardrev=0xf bcm2708.serial=0x53a65607 
smsc95xx.macaddr=B8:27:EB:A6:56:07 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.me"...
0x1f4:	"m_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 
rootfstype=ext4 elevator=deadline rootwait ro init=/sbin/init-overla"...
0x2bc:	"y"

0x2bd:	0x00	0x00	0x00
0x2c0:  0x00	0x00	0x00	0x00	0x00	0x00	0x00
    ATAG_NONE, end of the list, all OK

0x2c8:	0x00	0x00	0x00	0x00	0x00	0x00
0x2cd:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2d5:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2dd:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2e5:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2ed:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2f5:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x2fd:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x305:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x30d:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x315:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x31d:	0x00	0x00	0x00	0x00

No garbage after command line end. The parameters are reorganized by U-boot,
More of these added i.e. dma.dmachans, FB parameters etc. My original parameters
start at dwc_otg.lpm_enable=0 and U-boot modified ones are removed.

Do the added VideoCore parameters match your expectation?
It seems to be VideoCore internal data/code area from the first glimpse?

vc_mem.mem_base=0x1ec00000
vc_mem.mem_size=0x20000000

The values are used in Linux kernel and for older kernels ( < 4.0 ) seems to be
only source of the value. See

https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/vc_mem.c

Other mechanism is used for never kernels. There has been information that
dynamic allocation would be used for this memory on newer kernels.

Do these values match what you expect?

Genrally, RTEMS should tune its memory map according
to the boot loader provided parameters.

Best wishes,

              Pavel



More information about the devel mailing list