So it has got the right pointer for frame buffer. Please set the macros
BCM2835_FBMEM_BASE to 0x1C006000 and BCM2835_FBMEM_SIZE to 0x500000 according to your log. in file c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h It’s not possible to setup memory map dynamically and the area is not fixed. I don’t have a better way to deal with it other than set a huge range to cover all possibilities. waiting for your further report > On Jul 20, 2015, at 8:38 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote: > > 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@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@entry=0x105c40, > fmt0=fmt0@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel