hi, Carsten, (1) On mer-tv-rootfs, I uninstall Sage'XBMC and then install XBMC we built, XBMC still cannot work.
(2) under /etc/rpm/, no "platform" exists; instead, there are three files: macros.gconf2, macros.imgcreate, macros.prelink. 2012-01-04 zhanghui 发件人： Carsten Munk 发送时间： 2012-01-04 16:04:20 收件人： mer-general 抄送： 主题： Re: Fw: Re: Re: [mer-general] cannot start Mer-XBMC on hi3716m 4. jan. 2012 08.35 skrev zhanghui <[email protected]>: > Additional information: > > We build XBMC against Mer in COBS, and this XBMC can work in meego 1.2.0 > rootfs(boot from hi3716m, chroot to meego and run XBMC). So the same XBMC can run with software rendering in a MeeGo 1.2.0 rootfs? interesting cat /etc/rpm/platform please from the meego 1.2.0 rootfs BR Carsten Munk > > 2012-01-04 > ________________________________ > zhanghui > ________________________________ > 发件人： zhanghui > 发送时间： 2012-01-04 14:58:33 > 收件人： mer-general > 抄送： > 主题： Re: Re: [mer-general] cannot start Mer-XBMC on hi3716m > > Hi Carsten, > Thanks for the reply! > > (1) /proc/cpuinfo is: > Processor : ARMv7 Processor rev 2 (v7l) > BogoMIPS : 1199.30 > Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x2 > CPU part : 0xc09 > CPU revision : 2 > Hardware : godbox > Revision : 0000 > Serial : 0000000000000000 > > > (2) Before further disscussion, I explain something first: > (a) The reason we test a platform without 3D hardware is: A lot of STBs > will be free to family users, and the government will pay for it. Since the > STBs are free, the cost should be low. So the hi3716m comes. > Of course, many TV chips and other STB chips do have 3D hardware. > (b) Since MeeGo-TV has chosen XBMC as its reference UI, We are > considering it for our TVOS reference UI. > > (3) We need suggestion now. whether we wait for LLVMpipe, or just give up > XBMC on platform without 3D? Would you please suggest another UX we can > try? > > (4) Can we just comment out some code(or change some configuration) that > heavily depends on 3D hardware, then XBMC can be acceptable on platforms > without 3D? > > Thanks a lot! > > > > 2012-01-04 > ________________________________ > zhanghui > ________________________________ > 发件人： Carsten Munk > 发送时间： 2012-01-04 14:27:34 > 收件人： mer-general > 抄送： > 主题： Re: [mer-general] cannot start Mer-XBMC on hi3716m > 4. jan. 2012 03.35 skrev zhanghui <[email protected]>: >> Hi everyone, >> We are testing Mer-XBMC on our hi3716m platform(this platform is for >> STB/TV), and we cannot start XBMC for the moment. Our steps are: >> (1) download Sage's >> http://sage.kapsi.fi/Mer/images/0.20111120.1.CE.2011.11.20.1/mer-tv-armv7l-pandaboard/, >> and test it on Pandaboard, everything is OK. >> (2) Copy rootfs from mer-tv-armv7l-pandaboard Image to our nfs server: >> 192.168.129.76/home/zhangh/nfs/mer-tv-rootfs >> (3) Boot our hi3716m(ARM Cortex A9, with 2D hardware, without 3D hardware) >> platform. >> (4) copy some necessary files from hi3716m-rootfs to mer-tv-rootfs, >> including /lib/modules/2.6.35.7_hi3716m etc... >> (5) In order to use hi3617m's framebuffer, delete >> mer-tv-rootfs/usr/share/X11/xorg.conf.d/99-pvr.conf, create >> mer-tv-rootfs/etc/X11/20-hifb.conf: >> Section "Screen" >> Identifier "Default Screen" >> Device "Configured Video Device" >> DefaultDepth 16 >> SubSection "Display" >> Depth 24 >> # Modes "1280x720" >> EndSubSection >> EndSection >> >> Section "Device" >> Identifier "Configured Video Device" >> Driver "fbdev" >> Option "fb" "/dev/fb0" >> EndSection >> >> (6) execute following script to prepare for CHROOT: >> MEEGO_ROOT=/mnt/ >> mount -t nfs -o nolock -o tcp 192.168.129.76:/home/zhangh/nfs/mer-tv-rootfs >> ${MEEGO_ROOT} >> mount -o bind /proc ${MEEGO_ROOT}/proc >> mount -o bind /sys ${MEEGO_ROOT}/sys >> mount -o bind /dev ${MEEGO_ROOT}/dev >> mount -o bind /dev/pts ${MEEGO_ROOT}/dev/pts/ >> >> (7) #chroot /mnt /bin/bash >> (8) Uninstall all pvr drivers of pandaboard, and Install all mesa releated >> drivers. >> mesa releated drviers are downloaded from >> http://releases.merproject.org/releases/latest/builds/armv7l/packages/ >> glx-utils are downloaded from >> http://repo.pub.meego.com/CE:/Utils/Mer_Core_armv7l/ > Hi, > This is where you go wrong :) GLX is for OpenGL, and on ARM devices > it's typically OpenGL ES instead. When running glxgears, you're in > fact using the software rendering for GL. > I'd try to use http://www.daimi.au.dk/~cvm/glestest.cc if I were you > instead - http://www.daimi.au.dk/~cvm/glestest is a armv7l binary, > chmod +x it and ./glestest > I'm a little unsure if the EGL/GLESv2 -> GLX -> swrast works properly > in Mesa, which may be why it's crashing. I know that Sage's XBMC is > built for EGL/GLESv2 for sure. > We have some work ongoing to support Mesa with LLVMpipe, which is a > kind of fast software rendered EGL/GLESv2, utilizing the CPU instead > of a GPU, but the LLVM JIT has problems on ARM chips currently, while > it works fine on X86. > XBMC would also require EGL/GLESv2 support and is very slow with > software rendering, an actual chip is recommended for that - it was > even slow on my 2.3ghz X86 with swrast. >> >> (9) Execute the following commands: >> #Xorg & >> #export DISPLAY=":0.0" >> #glxgears >> glxgears can work fine! >> >> (10) #xbmc & >> XBMC cannot work with following error: >> /usr/bin/xbmc: line 133: 1064 Illegal instruction >> "$LIBDIR/xbmc/xbmc.bin" $SAVED_ARGS >> Crash report available at /root/xbmc_crashlog-19691231_161444.log (See >> attachment) >> In the crashlog, We can confirm that XBMC have used Mesa 3D drivers, Not pvr >> 3D drivers. What's wrong then?? > I'd like to see /proc/cpuinfo since this is a new chipset we haven't > tested Mer on (we've tested on Tegra2, OMAP3/4, Marvell, ST-Ericsson, > Freescale, etc, but not this one). >> >> Any help or instruction is appreciated! >> Thanks in advance! > BR > Carsten Munk >> >> >> >> 2012-01-04 >> ________________________________ >> zhanghui >> ________________________________ >> 发件人： Carsten Munk >> 发送时间： 2012-01-03 01:26:16 >> 收件人： mer-general >> 抄送： >> 主题： [mer-general] Available tasks to do, 2/1/2012 >> As promised, I will start posting weekly 'task' bug lists, If you see >> a bug/task >> that you'd like to work on, assign the bug to yourself within the Mer >> bugtracker. The bugtracker will bother you on email if you don't touch >> the bug within seven days. If you have any questions, this mailing >> list or #mer IRC channel is open to get help within :) >> Over time, we might start meetings to establish priority of tasks as well. >> The currently available tasks for taking are: >> bug - priority - short_desc >> http://bugs.merproject.org/show_bug.cgi?id=46 Low mpc has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=47 Low nano has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=48 Low openvpn has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=49 Low qt has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=38 Low binutils, >> binutils-devel has a possible bashism in RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=50 Low time has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=39 Low cvs has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=51 Low glibc-devel has >> possible bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=41 Low libassuan-devel has >> possible bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=42 Low libffi-devel has >> possible bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=43 Low libtasn1-devel has >> possible bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=44 Low m4 has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=45 Low make has possible >> bashisms in it's RPM scriptlets >> http://bugs.merproject.org/show_bug.cgi?id=29 Undecided Drop gamin from core >> http://bugs.merproject.org/show_bug.cgi?id=69 Undecided PAM should use >> system db4, not it's own >> http://bugs.merproject.org/show_bug.cgi?id=30 Undecided bash should >> link against system readline, not against it's own copy >> http://bugs.merproject.org/show_bug.cgi?id=70 Undecided e2fsprogs >> should be upgraded to 1.42 >> http://bugs.merproject.org/show_bug.cgi?id=31 Undecided Move ntpdc and >> ntpq to ntp-utils package to save footprint >> http://bugs.merproject.org/show_bug.cgi?id=54 Undecided Include >> package build logs to the releases >> http://bugs.merproject.org/show_bug.cgi?id=35 Undecided pixman should >> be upgraded to 0.24 >> http://bugs.merproject.org/show_bug.cgi?id=15 Undecided Switch from >> libjpeg to libjpeg-turbo >> http://bugs.merproject.org/show_bug.cgi?id=19 Undecided Drop GL >> support from Mer Core >> http://bugs.merproject.org/show_bug.cgi?id=52 Undecided Switch from >> DWARF-3 to DWARF-4 in order to save debuginfo space >> http://bugs.merproject.org/show_bug.cgi?id=20 Undecided Evaluate >> necessity of consolekit >> http://bugs.merproject.org/show_bug.cgi?id=53 Undecided Switch db4 to >> libdb, 5.2.36 and switch RPM to it >> http://bugs.merproject.org/show_bug.cgi?id=26 Undecided Evaluate dash >> as /bin/sh vs /bin/bash, disk/memory footprint/boot time/impact >> http://bugs.merproject.org/show_bug.cgi?id=57 Undecided dbus-glib is >> now merged to glib upstream so we should remove it >> http://bugs.merproject.org/show_bug.cgi?id=27 Undecided Evaluate >> benefits eglibc vs glibc, in terms of packaging, cross compilation and >> footprint/impact >> http://bugs.merproject.org/show_bug.cgi?id=58 Undecided nss should be >> upgraded to NSS_3_13_1_RTM >> http://bugs.merproject.org/show_bug.cgi?id=28 Undecided >> Drop gamin dependancy >> http://bugs.merproject.org/show_bug.cgi?id=59 Undecided nspr should be >> upgraded to 4.8.9 >> BR >> Carsten Munk
