[i.MX6] XBMC running on Freescale SoC's - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93) +--- Thread: [i.MX6] XBMC running on Freescale SoC's (/showthread.php?tid=161793) |
RE: [i.MX6] XBMC running on Freescale SoC's - aplund - 2014-02-08 @wolfgar, OK. The kernel that GeeXbox used was unclear to me. I cannot switch VTs on the prebuilt image. I had a look at the packaging and found that I didn't understand it as it wasn't one of the more common systems. However, it does seem to me that the the userspace libraries are not the ones that come with BSP 4.1.0. See for example here: http://hg.openbricks.org/openbricks/file/484e724645f2/packages/imx6-graphics/meta That would explain why the md5sum I gave above is different to the files in the prebuilt image. I'm not too worried about software rendering. Though I'm not sure why my mpeg2 videos are using it. I thought the vpu could do mpeg2. I'm wondering about this Keying transparency issue though. What do you mean by "pure framebuffer libs"? Do you mean linking /usr/lib/libVIVANTE.so and friends to the "-fb" library and not "-dfb" nor "-x11" or whatever? That I have confirmed. I have also supplied an md5sum from the binary blob I'm using in a previous post. My framebuffer is set to: Quote:$ sudo fbset RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-08 Hi Wolfgar Did you already tried not using V4L for output but using XBMC's standard EGL route? If not mistaken, the VPU outputs YUV420 frames which can be simply passed to XBMC. That'd make the code much simpler, avoid hacks, allow, e.g., 3D support to work and (probably) allow the code to be reused for Android. RE: [i.MX6] XBMC running on Freescale SoC's - joko - 2014-02-09 Has anyone tried running a 1080p movie? I get some flickering issues, my TV goes blank (as if the HDMI signal is lost) and video returns after a while. At least it is not halting anymore, as it did in the previous version of XBMC I had compiled. VLC reports the following information for the file I'm trying to watch:
I think I get the following kernel warnings due to the 1080p playback: Quote:[ 94.064973] mxc_v4l2_output mxc_v4l2_output.0: Bypass IC. Also, if I stop the playback, I cannot play afterwards any video file at all. I can hear the audio, but only the XBMC menu appears. The kernel currently running is 3.0.35_4.1.0-5-ARCH+, imx-vpu and gpu-viv-bin-mx6q-fb 3.10.17_1.0.0-1 (by CruX's PKGBUILDs). I have also compiled XBMC via CruX's PKGBUILD, it checked out from Wolfgar's repo, the imx-wip branch (04f006c). RE: [i.MX6] XBMC running on Freescale SoC's - mijanek - 2014-02-10 @stephan, I just built your commit 04f006cfb4 and this looks really good now :-) Thanks a lot! Miro RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-10 (2014-02-08, 14:58)Koying Wrote: Hi Wolfgar Hi Koying, No I have not yet tried this because I was not familiar with Vivante direct texture extensions which allow efficient way of working with VPU output... Also, the V4L2 path was the reference solution which was demonstrated in fsl BSP (and with natural plug for IPU hw functions like deinterlacing) so it seemed a safer way as a first implementation. I have voluntary isolated most of V4L stuff in a dedicated class so that switching should not be so intrusive for core decoding function But I know it is a path that would be interesting to explore... (On my todo list) Best regards Stephan (2014-02-10, 01:14)mijanek Wrote: @stephan, Thanks Miro @joko Which target and which kernel do you use ? (As far as I can tell 1080p movies work just perfectly on all the targets I support...) Regards Stephan RE: [i.MX6] XBMC running on Freescale SoC's - aplund - 2014-02-10 Quote:[ 108.508354] imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00100000 I get this warning too. Is it safe to ignore? RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-10 (2014-02-10, 03:00)wolfgar Wrote: No I have not yet tried this because I was not familiar with Vivante direct texture extensions which allow efficient way of working with VPU output...Okido. I'll start working on it. In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering. Too slow, unfortunately, but there might be bugs. RE: [i.MX6] XBMC running on Freescale SoC's - joko - 2014-02-10 (2014-02-10, 03:00)wolfgar Wrote: Which target and which kernel do you use ? Hello, Stephan, And many thanks for your work! I'm using a Wandboard Quad and Arch Linux ARM. The reported kernel is 3.0.35_4.1.0-5-ARCH+, it's b8d0163 from the wandboard_imx_3.0.35_4.1.0 branch of your linux repo on GH along with a couple of patches to support the newest GPU blobs from Freescale (I'm using CruX's PKGBUILD from here). I would like also to add that XBMC accesses files from SMB shares mostly. Maybe setting up some NFS shares would be better? RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-10 (2014-02-10, 14:14)Koying Wrote: Okido. Oki, have you tried to use the vivante direct extension I mentioned ? I mean using glTexDirectVIVMap... Regards Stéphan RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-10 (2014-02-10, 20:27)wolfgar Wrote: Oki, have you tried to use the vivante direct extension I mentioned ? I mean using glTexDirectVIVMap...That's what meant by "start working on it" RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-10 (2014-02-10, 14:54)joko Wrote: And many thanks for your work! I'm using a Wandboard Quad and Arch Linux ARM. The reported kernel is 3.0.35_4.1.0-5-ARCH+, it's b8d0163 from the wandboard_imx_3.0.35_4.1.0 branch of your linux repo on GH along with a couple of patches to support the newest GPU blobs from Freescale (I'm using CruX's PKGBUILD from here). OK,, I asked because the reported IPU error is a sync error which occurs when the IPU does not get the display data on time to display them (kind of underrun). Harmless issue as long as your don't loose screen sync. This issue is largely mitigated by boosting IPU exchanges on the AXI bus (that's why I asked which kernel you use : I little patch enables this tweak but you have it...) Have you tried another image before the archi linux arm one ? I ask to be sure we are safe regarding hw setup (board+screen) but it should work fine based on crux packaging. Regarding SMB I use it everyday flawlessly even for demanding bitrates so I don't think it is the issue but you can try to play a file stored locally to be sure it is not about network... Stephan (2014-02-10, 20:31)Koying Wrote: That's what meant by "start working on it"ok, I get it ! It makes sense as you already switched to gpu rendering 3 days ago... I cross my fingers but I am confident it will really help... RE: [i.MX6] XBMC running on Freescale SoC's - LeoKesler - 2014-02-10 Hello, I have a wandboard quad and I am using a TV Sony KDL32W656 as monitor. The rootfs is in a HD. The movies are in the same HD. The command line is: console=ttymxc0,115200 consoleblank=0 fixrtc root=/dev/sda3 rootfstype=ext4 rootwait video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=16 dmfc=3 I tested the xbmc using archlinux and this pkgbuilds: https://github.com/CrawX/PKGBUILDs So, after some minutes using the menus, the video hangs. Sometimes, the audio still play. Sometimes, all xbmc hangs. I have this errors in dmesg and logs: Code: [root@alarm ~]# [ 635.321399] __dma_free_remap: trying to free invalid coherent area: (null) After that, the screen goes blank / standby. And I got this error: Code: [INFO] Product Info: i.MX6Q/D/S I have make a video showing the problem. Its happen at 2:20 . Link: https://mega.co.nz/#!tMtDgIiS!gmHq5zonfIA2UebipdTCcM9twz8gPUS-GLAzu7lJ-0Y RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-10 Hi LeoKesler I fear it is a regression with VPU allocations. In fact I have applied the patch provided by wandboard team here : https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 (you can also refer to the post "January 17 2014 - Video playback using the Wandboard VPU, part 1" on http://wandboard.org/) and it seems it is responsible for this crash... You can revert my commit https://github.com/wolfgar/linux/commit/a17b68b211efac2884d20936a8ace0a41883ca5e and give it a try without this change Generally speaking I thing we should move to the new wandboard kernel and only apply the few relevant patches I have done to improve xbmc behavior on top of this one to check whether it helps regarding stability .. Regards RE: [i.MX6] XBMC running on Freescale SoC's - mijanek - 2014-02-11 Hi Stephan, steven@tbs reported the same issue with the same patch, so I seems to make some troubles with hdtv playback. In fact I didn't tried this one out yet, but I guess it will endup same.. Regarding to xbmc, so using still the same build as I reported last, I'm having on some interlaced SDTV Videos stottering behaviour, like it was on the HDTV (but not so heavy) I will try out to find some exaple video for you.. Miro RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-12 Hi Miro, Yes I had private mail exchange with steven. So as immediate action I would advise to revert this commit. I am trying to reproduce the issue to investigate and try to solve it for good. I pushed this wandboard commit because many users reported VPU allocation issues and I hoped to improve their experience ... I guess I missed my point Kind regards Stephan |