Testing of the Raspberry Pi graphic support
Pavel Pisa
pisa at cmp.felk.cvut.cz
Wed Jul 1 22:58:26 UTC 2015
Hello Qiao Yang,
thanks for status report.
On Wednesday 01 of July 2015 23:53:51 QIAO YANG wrote:
> On Jun 30, 2015, at 12:41 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
>
> 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.
really no problem, because I am fully aware that work is in the
active development I have tried to test more versions which I have spotted.
I archived dead end branch after forced update and reset to main course.
> > arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils
> > 2.24
OK
> 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.
I do not expect problem from there too. This is mainly to document state.
> > 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'
Seem same and more straightforward, some of mine options
are accumulated over years with RTEMS on more targets
and some can be superfluous on actual version.
> 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.
I have added "--strip-debug" to be sure but binary is exactly the same.
> > -------------------------------------------------------------
> >
> > 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..
No problem, this is some addon layer to unite Linux configs over different
loaders. It allows to search for kernel images even over TFTP on RPi,
but I stayed wit local SD card boot. It is more or less that it can be
interesting for somebody.
> > 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
Image seems to extract and start correctly.
> > ## 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.
Yes that seems to work well with different monitors.
> > [#]FrameBufferInfo: pointer : 0
> > [#]FrameBufferInfo: size : 0
>
> This means we didn't managed to allocate the frambuffer from the mailbox
> framebuffer channel.
Hmm.
I have tried with and without different memory setup options,
U-boot reporst change in memory but no luck till now
gpu_mem=128
> > [#]_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
> 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.
U-boot works correctly and displays it console output.
When I use direct boot to RTEMS bin file by kernel=ticker.bin
from config.txt, RTEMS application starts, prints display found
parameters and display is switched to active mode from
standby (state when RPi is disconnected or boot is not started ready).
Display behaves different way (rainbow shown) when there is RTEMS
application without framebuffer support.
> 2. I've read of this post at the begining of research:
> 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.
Do not hurry, I look at it next week.
> > -------------------------------------------------------------
> >
> > 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 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.
The final - RTEMS-4.11 intended option for i386 is named video
--video=auto|off|1024x768-32
console selection is controlled by option
--console=com1
So something like --console=uart and fb is reasonable option
to select console output.
Best wishes,
Pavel
More information about the devel
mailing list