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 <yangqiao0...@me.com> wrote: > > On Jun 30, 2015, at 12:41 PM, Pavel Pisa <p...@cmp.felk.cvut.cz > <mailto:p...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
