Testing of the Raspberry Pi graphic support
桥 杨
yangqiao0505 at me.com
Wed Jul 1 23:23:24 UTC 2015
---------------
Qiao YANG
Université de Technologie de Compiègne
Génie Informatique
> 在 2015年7月2日，00:58，Pavel Pisa <pisa at cmp.felk.cvut.cz> 写道：
>
> 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
I tried to retrieve ATAG cmdline by mailbox property tag channel, but failed as it cannot asure the string is terminated by certain character('/0') and I didn't fix the implementation of tag structure at that moment. It reminds me that I should take some time back to it, and maybe the freebsd, rasbian's source code can do help. I've just found some posts on arm atags . I'll look into the detail and try to implement it this weekend.
>
> So something like --console=uart and fb is reasonable option
> to select console output.
>
> Best wishes,
>
> Pavel
More information about the devel
mailing list