<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">If you don’t have that much time to debug, you may try this bcm2835 qemu</div><div class=""><a href="https://github.com/Torlus/qemu/tree/rpi" class="">https://github.com/Torlus/qemu/tree/rpi</a></div><div class=""><br class=""></div><div class="">you can use it to run the kernel elf directly.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 1, 2015, at 11:53 PM, QIAO YANG <<a href="mailto:yangqiao0505@me.com" class="">yangqiao0505@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="">On Jun 30, 2015, at 12:41 PM, Pavel Pisa <<a href="mailto:pisa@cmp.felk.cvut.cz" class="">pisa@cmp.felk.cvut.cz</a>> wrote:<br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content">Hello Qiao Yang,<br class=""><br class="">I have prepared testing on RPi B+ hardware last days<br class="">I have got to test your RTEMS branch<br class=""><br class=""> <a href="https://github.com/yangqiao/rtems" class="">https://github.com/yangqiao/rtems</a><br class=""><br class="">I have tried<br class=""><br class=""> e89884b add memory table entry for frame buffer (try to cover all possibility, may be larger afterward if it's not enough)<br class=""><br class="">and then<br class=""><br class=""> b560cb2 refactor outch scratch</span></div></div></blockquote><span class=""> </span><br class="">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.<br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class="">which has been left in my local copy from the previous fetch.<br class=""><br class="">I have been able to build RTEMS as well as graphic libraries.<br class="">I have tried to build my standard shell test code and some graphic<br class="">test.<br class=""><br class="">My setup<br class=""><br class=""> host system Debian Linux amd64<br class=""><br class=""> -------------------------------------------------------------<br class=""><br class=""> tools - local build<br class=""><br class=""> arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils 2.24</span></div></div></blockquote><span class=""><span class="">I'm using exactly the same version</span> </span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""> Configured <br class="">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<br class=""></span></div></div></blockquote><span class="">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.<br class=""></span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""> used successfully for LPC4078 and LPC1778 RTEMS<br class=""><br class=""> -------------------------------------------------------------<br class=""><br class=""> RTEMS configured<br class=""><br class=""> ../../../git/rtems-yangqiao/configure --target=arm-rtems4.11 --prefix=/opt/rtems4.11 \<br class=""> --enable-rtems-inlines --disable-multiprocessing --enable-cxx \<br class=""> --enable-rdbg --enable-maintainer-mode --enable-tests=samples \<br class=""> --enable-networking --enable-posix --disable-itron --disable-ada \<br class=""> --disable-expada --disable-multilib --disable-docs \<br class=""> --enable-rtemsbsp="raspberrypi"<br class=""></span></div></div></blockquote><span class=""><span class="">I tried these configurations to rebuild, it works.<br class="">My configuration is: <br class="">../rtems-git/configure --target=arm-rtems4.11 \<br class=""> --enable-rtemsbsp=raspberrypi \<br class=""> --enable-tests=samples \<br class=""> --enable-networking \<br class=""> --enable-posix \<br class=""> --prefix=$HOME/development/rtems/bsps/4.11'</span> </span><br class="">So I don't think the problem comes from here.<br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""> -------------------------------------------------------------<br class=""><br class=""> Raspberry Pi direct boot by config.txt options<br class=""><br class=""> kernel=appfoo.bin</span></div></div></blockquote><span class="">I just leave the config empty and videocore will use the default arguments. It does no harm. </span><br class=""><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class=""> generated by<br class=""><br class=""> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"</span></div></div></blockquote><span class="">I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '. -R -S should not do harm. </span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class=""> -------------------------------------------------------------<br class=""><br class=""> Raspberry Pi boot over U-boot and extlinux/extlinux.conf<br class=""><br class=""> TIMEOUT 100<br class=""> DEFAULT default<br class=""> MENU TITLE Boot menu<br class=""><br class=""> LABEL RTEMS appfoo<br class=""> MENU LABEL RTEMS appfoo<br class=""> LINUX appfoo.img<br class=""> FDTDIR .</span></div></div></blockquote><span class="">Sorry that I've got no idea about extlinux</span>..<br class=""><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class=""> Image generated by<br class=""><br class=""> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1<br class=""> cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"<br class=""> mkimage \<br class=""> -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -n "RTEMS" \<br class=""> -d "$EXE_NAME.gz" "$EXE_NAME.img"</span></div></div></blockquote><span class="">mkimage -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -n "RTEMS" -C none -d<br class="">I didn't use compression but should not do harm </span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class=""> -------------------------------------------------------------<br class=""><br class="">The monitor resolution has been correctly obtained and printed for all combinations<br class="">but then there has been no progress/output on serial port even on HDMI output<br class=""><br class="">Startup log for U-boot case<br class=""><br class="">-------------------------------------------------------------<br class="">U-Boot 2015.04-rc2-gc5ec3a2 (Mar 05 2015 - 21:46:11)<br class=""><br class="">DRAM: 448 MiB<br class="">WARNING: Caches not enabled<br class="">RPI Model B+<br class="">MMC: bcm2835_sdhci: 0<br class="">reading uboot.env<br class="">In: serial<br class="">Out: lcd<br class="">Err: lcd<br class="">Net: Net Initialization Skipped<br class="">No ethernet found.<br class="">Hit any key to stop autoboot: 0 <br class="">switch to partitions #0, OK<br class="">mmc0 is current device<br class="">Scanning mmc 0:1...<br class="">Found /extlinux/extlinux.conf<br class="">Retrieving file: /extlinux/extlinux.conf<br class="">reading /extlinux/extlinux.conf<br class="">2176 bytes read in 20 ms (105.5 KiB/s)<br class="">Boot menu<br class="">1: Linux 3.18.8-rt2+ with Overlay<br class="">2: Linux 3.18.8-rt2+ with Aufs<br class="">3: Linux 3.18.8-rt2+ RW root<br class="">4: Linux 3.18.8-rt2+ NFS BusyBox<br class="">5: Linux 3.18.8-rt2+ NFS Overlay<br class="">6: Linux 3.18.8-rt2+ NFS RW<br class="">7: RTEMS appfoo<br class="">8: RTEMS demo_suitk<br class="">9: Boot by localcmd<br class="">Enter choice: 8<br class="">8: RTEMS demo_suitk<br class="">Retrieving file: /extlinux/demo_suitk.img<br class="">reading /extlinux/demo_suitk.img<br class="">375420 bytes read in 89 ms (4 MiB/s)<br class="">Retrieving file: /extlinux/./bcm2835-rpi-b-plus.dtb<br class="">reading /extlinux/./bcm2835-rpi-b-plus.dtb<br class="">4702 bytes read in 28 ms (163.1 KiB/s)<br class="">## Booting kernel from Legacy Image at 01000000 ...<br class=""> Image Name: RTEMS<br class=""> Image Type: ARM RTEMS Kernel Image (gzip compressed)<br class=""> Data Size: 375356 Bytes = 366.6 KiB<br class=""> Load Address: 00008000<br class=""> Entry Point: 00008000<br class=""> Verifying Checksum ... OK<br class=""> Uncompressing Kernel Image ... OK<br class="">## Transferring control to RTEMS (at address 00008000) ...</span></div></div></blockquote><span class="">It seems that the kernel boot successfully with uboot. I've these lines for uboot startup script </span><span class=""><span class="">but I passed nothing from uboot to kernel.</span>:<br class="">mmc dev 0<br class="">fatload mmc 0:1 ${kernel_addr_r} hello.img<br class="">bootm ${kernel_addr_r} <br class="">#0x8000</span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class="">[+] framebuffer initialize<br class="">width:1680 height:1050<br class="">[+] framebuffer use display resolution 1680*1050</span></div></div></blockquote><span class="">We havn't passed any parameter of resolution from config.txt and It retrieves resolution correctly.<br class="">So the mailbox videocore property channel works.</span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class="">[+] write to mailbox<br class="">[+] read mailbox<br class="">[#] Done read mailbox, return val: 0<br class="">[#]FrameBufferInfo: width : 1680<br class="">[#]FrameBufferInfo: height : 1050<br class="">[#]FrameBufferInfo: vWidth : 1680<br class="">[#]FrameBufferInfo: vHeight : 1050<br class="">[#]FrameBufferInfo: pitch : 6720<br class="">[#]FrameBufferInfo: bitDepth : 32<br class="">[#]FrameBufferInfo: x_offset : 0<br class="">[#]FrameBufferInfo: y_offset : 0<br class="">[#]FrameBufferInfo: pointer : 0<br class="">[#]FrameBufferInfo: size : 0</span></div></div></blockquote><span class="">This means we didn't managed to allocate the frambuffer from the mailbox framebuffer channel. </span><br class=""><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class="">[#]_RPI_initVideo: maxCol : 210<br class="">[#]_RPI_initVideo: maxRow : 65</span></div></div></blockquote><span class="">The maxCol and maxRow are calculated from resolution and font size, so it's correct. </span><br class=""><br class="">So the problem is that it fails to allocate framebuffer with a working mailbox support.<br class=""><br class="">Here are my suggestions:<br class="">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: <br class=""><a href="http://elinux.org/R-Pi_Troubleshooting#Display" class="">http://elinux.org/R-Pi_Troubleshooting#Display</a><br class="">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.<br class=""><br class="">2. I've read of this post at the begining of research: <br class=""><a href="https://www.raspberrypi.org/forums/viewtopic.php?t=36619&p=306605" class="">https://www.raspberrypi.org/forums/viewtopic.php?t=36619&p=306605</a><br class="">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.<br class="">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.<br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class="">-------------------------------------------------------------<br class=""><br class="">Please, report more about actual state of your work<br class="">and what (which examples, test code) should work or if I have<br class="">done some configuration incorrect way.</span></div></div></blockquote><span class="">I didn't create a standard test code into source code. I tested my works with the rki from<br class=""><a href="https://github.com/alanc98/rki.git" class="">https://github.com/alanc98/rki.git</a> commit a52a73e64<br class="">just lanch the kernel the graphic output should work.<br class="">On my mmc, i've got dtb, boot.scr (uboot script), bootcode.bin, start.elf (firmware), uboot.img, rki_img. Nothing special.<br class=""><br class="">Status : <br class="">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. </span><span class=""><span class="">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</span>.<br class=""></span><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class="">I suggest to keep console on serial port and allow framebuffer<br class="">testing through registered device.</span></div></div></blockquote><span class="">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</span>.<br class=""><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class="">As for Microwindows build for Raspberry Pi, I have to disable<br class="">mouse and keyboard build because it doesnot build with micro<br class="">input driver (UID) RTEMS driver enabled in my Raspberry Pi config.<br class=""><br class="">diff --git a/src/drivers/Objects.rules b/src/drivers/Objects.rules<br class="">index 297826c..5802748 100644<br class="">--- a/src/drivers/Objects.rules<br class="">+++ b/src/drivers/Objects.rules<br class="">@@ -253,8 +253,8 @@ MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_pipe.o<br class=""> endif<br class=""><br class=""> ifeq ($(ARCH), RTEMS)<br class="">-MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_rtems.o<br class="">-MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/mou_rtems.o<br class="">+MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/kbd_null.o<br class="">+MW_CORE_OBJS += $(MW_DIR_OBJ)/drivers/mou_null.o<br class=""> endif # RTEMS architecture<br class=""><br class=""> ifeq ($(LIRCKBD2), Y)<br class=""></span></div></div></blockquote><span class="">I'm working with the nxlib at the moment, It helps me a lot. Thanks! </span><br class=""><br class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br class=""><br class="">I would worth to collect somewhere all RTEMS on RPi bare<br class="">boot and U-boot options and configurations.<br class="">I would suggest to put it into RTEMS Wiki, i.e<br class=""><br class=""><a class="">https://devel.rtems.org/wiki/TBR/BSP/RaspberryPi</a><span style="overflow:hidden;line-height:0px" id="mce_540_start" class=""></span><br class=""><br class="">if no better name is found.<br class=""><br class="">Best wishes,<br class=""><br class=""> Pavel<br class=""><br class=""><br class=""></span></div></div></blockquote><span class=""> </span><br class="">Best wishes,<br class=""><br class="">YANG Qiao<br class=""></div></div><div class=""><br dir="ltr" id="tinymce" class=" windows mceContentBody" applecontenteditable="true"></div></div>_______________________________________________<br class="">devel mailing list<br class=""><a href="mailto:devel@rtems.org" class="">devel@rtems.org</a><br class="">http://lists.rtems.org/mailman/listinfo/devel</div></blockquote></div><br class=""></body></html>