Testing of the Raspberry Pi graphic support

QIAO YANG yangqiao0505 at me.com
Wed Jul 1 22:10:50 UTC 2015 

If you don’t have that much time to debug, you may try this bcm2835 qemu
https://github.com/Torlus/qemu/tree/rpi <https://github.com/Torlus/qemu/tree/rpi>

you can use it to run the kernel elf directly.

> On Jul 1, 2015, at 11:53 PM, QIAO YANG <yangqiao0505 at me.com> wrote:
> 
> On Jun 30, 2015, at 12:41 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz <mailto:pisa at cmp.felk.cvut.cz>> wrote:
> 
>> Hello Qiao Yang,
>> 
>> I have prepared testing on RPi B+ hardware last days
>> I have got to test your RTEMS branch
>> 
>> https://github.com/yangqiao/rtems <https://github.com/yangqiao/rtems>
>> 
>> I have tried
>> 
>> e89884b add memory table entry for frame buffer (try to cover all possibility, may be larger afterward if it's not enough)
>> 
>> and then
>> 
>> b560cb2 refactor outch scratch
>  
> Both should work, I've tested before push. BTW, because I've found the way I refactor outch is not as clean as I imagined so I quickly reset and forced updated. Sorry for the conflict, but the problem is not here.
> 
>> 
>> 
>> which has been left in my local copy from the previous fetch.
>> 
>> I have been able to build RTEMS as well as graphic libraries.
>> I have tried to build my standard shell test code and some graphic
>> test.
>> 
>> My setup
>> 
>> host system Debian Linux amd64
>> 
>> -------------------------------------------------------------
>> 
>> tools - local build
>> 
>> arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils 2.24
> I'm using exactly the same version 
> 
>> 
>> Configured 
>> with: ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr --build=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-libstdcxx-pch --with-gnu-ld --with-gnu-as --enable-threads --enable-target-optspace --with-system-zlib --verbose --disable-nls --without-included-gettext --disable-win32-registry --with-newlib --enable-plugin --enable-newlib-io-c99-formats --enable-version-specific-runtime-libs --enable-newlib-iconv --disable-lto
> Sorry that I'm not sure if these parameters would affect the result while I think probably not. I just use rsb (commit e9dfd95dd Revert "add basic support for OpenBSD ) to build the bset  4.11/rtems-arm  with default configuration.  The rsb fork on my github is the one I used.
> 
> 
>> 
>> used successfully for LPC4078 and LPC1778 RTEMS
>> 
>> -------------------------------------------------------------
>> 
>> RTEMS configured
>> 
>> ../../../git/rtems-yangqiao/configure --target=arm-rtems4.11 --prefix=/opt/rtems4.11 \
>> --enable-rtems-inlines --disable-multiprocessing --enable-cxx \
>> --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
>> --enable-networking --enable-posix --disable-itron --disable-ada \
>> --disable-expada --disable-multilib --disable-docs \
>> --enable-rtemsbsp="raspberrypi"
> I tried these configurations to rebuild, it works.
> My configuration is: 
> ../rtems-git/configure --target=arm-rtems4.11 \
>             --enable-rtemsbsp=raspberrypi \
>             --enable-tests=samples \
>             --enable-networking \
>             --enable-posix \
>             --prefix=$HOME/development/rtems/bsps/4.11' 
> So I don't think the problem comes from here.
> 
>> 
>> -------------------------------------------------------------
>> 
>> Raspberry Pi direct boot by config.txt options
>> 
>> kernel=appfoo.bin
> I just leave the config empty and videocore will use the default arguments. It does no harm. 
> 
> 
>> 
>> 
>> generated by
>> 
>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"
> I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '.  -R -S should not do harm. 
> 
>> 
>> 
>> -------------------------------------------------------------
>> 
>> Raspberry Pi boot over U-boot and extlinux/extlinux.conf
>> 
>> TIMEOUT 100
>> DEFAULT default
>> MENU TITLE Boot menu
>> 
>> LABEL RTEMS appfoo
>> MENU LABEL RTEMS appfoo
>> LINUX appfoo.img
>> FDTDIR .
> Sorry that I've got no idea about extlinux..
> 
> 
>> 
>> 
>> Image generated by
>> 
>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
>> cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
>> mkimage \
>> -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -n "RTEMS" \
>> -d "$EXE_NAME.gz" "$EXE_NAME.img"
> mkimage -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -n "RTEMS" -C none -d
> I didn't use compression but should not do harm 
> 
>> 
>> 
>> -------------------------------------------------------------
>> 
>> The monitor resolution has been correctly obtained and printed for all combinations
>> but then there has been no progress/output on serial port even on HDMI output
>> 
>> Startup log for U-boot case
>> 
>> -------------------------------------------------------------
>> U-Boot 2015.04-rc2-gc5ec3a2 (Mar 05 2015 - 21:46:11)
>> 
>> DRAM: 448 MiB
>> WARNING: Caches not enabled
>> RPI Model B+
>> MMC: bcm2835_sdhci: 0
>> reading uboot.env
>> In: serial
>> Out: lcd
>> Err: lcd
>> Net: Net Initialization Skipped
>> No ethernet found.
>> Hit any key to stop autoboot: 0 
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc 0:1...
>> Found /extlinux/extlinux.conf
>> Retrieving file: /extlinux/extlinux.conf
>> reading /extlinux/extlinux.conf
>> 2176 bytes read in 20 ms (105.5 KiB/s)
>> Boot menu
>> 1: Linux 3.18.8-rt2+ with Overlay
>> 2: Linux 3.18.8-rt2+ with Aufs
>> 3: Linux 3.18.8-rt2+ RW root
>> 4: Linux 3.18.8-rt2+ NFS BusyBox
>> 5: Linux 3.18.8-rt2+ NFS Overlay
>> 6: Linux 3.18.8-rt2+ NFS RW
>> 7: RTEMS appfoo
>> 8: RTEMS demo_suitk
>> 9: Boot by localcmd
>> Enter choice: 8
>> 8: RTEMS demo_suitk
>> Retrieving file: /extlinux/demo_suitk.img
>> reading /extlinux/demo_suitk.img
>> 375420 bytes read in 89 ms (4 MiB/s)
>> Retrieving file: /extlinux/./bcm2835-rpi-b-plus.dtb
>> reading /extlinux/./bcm2835-rpi-b-plus.dtb
>> 4702 bytes read in 28 ms (163.1 KiB/s)
>> ## Booting kernel from Legacy Image at 01000000 ...
>> Image Name: RTEMS
>> Image Type: ARM RTEMS Kernel Image (gzip compressed)
>> Data Size: 375356 Bytes = 366.6 KiB
>> Load Address: 00008000
>> Entry Point: 00008000
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>> ## Transferring control to RTEMS (at address 00008000) ...
> It seems that the kernel boot successfully with uboot. I've these lines for uboot startup script but I passed nothing from uboot to kernel.:
> mmc dev 0
> fatload mmc 0:1 ${kernel_addr_r} hello.img
> bootm ${kernel_addr_r} 
> #0x8000
> 
>> 
>> [+] framebuffer initialize
>> width:1680 height:1050
>> [+] framebuffer use display resolution 1680*1050
> We havn't passed any parameter of resolution from config.txt and It retrieves resolution correctly.
> So the mailbox videocore property channel works.
> 
>> 
>> [+] write to mailbox
>> [+] read mailbox
>> [#] Done read mailbox, return val: 0
>> [#]FrameBufferInfo: width : 1680
>> [#]FrameBufferInfo: height : 1050
>> [#]FrameBufferInfo: vWidth : 1680
>> [#]FrameBufferInfo: vHeight : 1050
>> [#]FrameBufferInfo: pitch : 6720
>> [#]FrameBufferInfo: bitDepth : 32
>> [#]FrameBufferInfo: x_offset : 0
>> [#]FrameBufferInfo: y_offset : 0
>> [#]FrameBufferInfo: pointer : 0
>> [#]FrameBufferInfo: size : 0
> This means we didn't managed to allocate the frambuffer from the mailbox framebuffer channel. 
> 
> 
>> 
>> [#]_RPI_initVideo: maxCol : 210
>> [#]_RPI_initVideo: maxRow : 65
> The maxCol and maxRow are calculated from resolution and font size, so it's correct. 
> 
> So the problem is that it fails to allocate framebuffer with a working mailbox support.
> 
> Here are my suggestions:
> 1. u-boot has implemented the graphic driver and if you connected the pi with display, uboot should display something on the screen. If not, it not the problem of driver, you may refer to this page: 
> http://elinux.org/R-Pi_Troubleshooting#Display <http://elinux.org/R-Pi_Troubleshooting#Display>
> I havn't encountered such case, but I think if you've come up with such problem, the troubleshooting may fix it by adding the configuration. But in most cases, the default configuration should work.
> 
> 2.  I've read of this post at the begining of research:  
> https://www.raspberrypi.org/forums/viewtopic.php?t=36619&p=306605 <https://www.raspberrypi.org/forums/viewtopic.php?t=36619&p=306605>
> Since at that time, I didn't decide how to deal with the property tag channel, and the framebuffer channel works well with my qemu and my display, so I didn't use the property tag channel to allocate framebuffer.
> As there is a possibility that the framebuffer channel is unstable, I'm going to replace it by using property tag channel to allocate the framebuffer. I'll push it a bit later tonight.
> 
>> 
>> -------------------------------------------------------------
>> 
>> Please, report more about actual state of your work
>> and what (which examples, test code) should work or if I have
>> done some configuration incorrect way.
> I didn't create a standard test code into source code. I tested my works with the rki from
> https://github.com/alanc98/rki.git <https://github.com/alanc98/rki.git>  commit a52a73e64
> just lanch the kernel the graphic output should work.
> On my mmc, i've got  dtb, boot.scr (uboot script), bootcode.bin, start.elf (firmware), uboot.img, rki_img. Nothing special.
> 
> Status : 
> I'm now compiling, testing the graphic libraries, and integrate them into rsb with proper patches so that we can build them without the rtems-graphic-tool-kit's script, using rsb instead. About how to refactor some part of reusable code, I may need to consider it carefully. If I've got time I may add more interfaces for mailbox property tags later.  You may also trac my status from the tracking table.
> 
>> 
>> 
>> I suggest to keep console on serial port and allow framebuffer
>> testing through registered device.
> I'm considering to add a "enable-hdmi" macro, just like the "enable-vga" macro for pc386, to enable and disable the graphic output and it's console. Not use the graphic console as primary console, but out put to graphic at the side, so that we can have both graphic(display only) and serial console.
> 
> 
>> 
>> 
>> As for Microwindows build for Raspberry Pi, I have to disable
>> mouse and keyboard build because it doesnot build with micro
>> input driver (UID) RTEMS driver enabled in my Raspberry Pi config.
>> 
>> diff --git a/src/drivers/Objects.rules b/src/drivers/Objects.rules
>> index 297826c..5802748 100644
>> --- a/src/drivers/Objects.rules
>> +++ b/src/drivers/Objects.rules
>> @@ -253,8 +253,8 @@ MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_pipe.o
>> endif
>> 
>> ifeq ($(ARCH), RTEMS)
>> -MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_rtems.o
>> -MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/mou_rtems.o
>> +MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_null.o
>> +MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/mou_null.o
>> endif # RTEMS architecture
>> 
>> ifeq ($(LIRCKBD2), Y)
> I'm working with the nxlib at the moment, It helps me a lot. Thanks! 
> 
>> 
>> 
>> I would worth to collect somewhere all RTEMS on RPi bare
>> boot and U-boot options and configurations.
>> I would suggest to put it into RTEMS Wiki, i.e
>> 
>> https://devel.rtems.org/wiki/TBR/BSP/RaspberryPi <>
>> 
>> if no better name is found.
>> 
>> Best wishes,
>> 
>> Pavel
>> 
>> 
>  
> Best wishes,
> 
> YANG Qiao
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

More information about the devel mailing list