Kodi Community Forum

Another thing to consider is that unless your dev board is based on widely used architecture, you might also encounter problems with vendor toolchain, when the compiler would generates invalid machine code. Those are extremely hard to find, and good Assembler knowledge for the platform is usually necessary. We have encountered such things more than once during porting our software to various SPARC and MIPS-like boards, and it was never fun.

McGeagh Wrote:Another board im looking at is the beagleboard. Ive heard some mention of it on these forums, and i know it doesnt (currently) have opengl

Both the BeagleBoard and the Pandora handheld game-console (which also share the same ARM Cortex-A8 processor based OMAP3530 chip by Texas Instruments) fully support OpenGL ES 2.0 with 3D hardware acceleration. They also runs an unofficial version of Ubuntu Desktop today, and an official Ubuntu Desktop version is coming out in the end of April 2009.
http://en.wikipedia.org/wiki/BeagleBoard
http://en.wikipedia.org/wiki/Pandora_(console)

For more discussion about porting XBMC to ARM processor architecture please see these forum threads http://forum.xbmc.org/tags.php?tag=arm

I know - ive got ubuntu running on beagle.
Also, the processor supports opengl, but the drivers for it hasnt (or wasnt) released yet.
Ive not checked in a while, so those drivers may have been released by now.

Thanks for the input though.

Im very interested in this also.
I have a beagle board and seriously looking at getting xbmc onto it.
I dont mind it not being able to do HD yet, would just be great to get xbmc onto an ARM.

Can anyone answer the 'how portable is the rest of the XBMC source?' the guy above asked?

I will be working on porting it myself come January, but unfortunately my linux skills are somewhat noobish. Any help, any direction, any suggestions would be greatly appreciated.
Ive worked on ARM before, but not linux so for the ARM side of things, such as assembler, im not too concerned over. its mainly just the linux side of things, the xbmc side, that id need some help with.

Anyone wanna contact me about this feel free to email me:
[email protected]

Thanks!

I am not a developer myself but IIRC davilla and althekiller said that it would probably be time consuming however XBMC should be very 'portable' to open hardware platforms as long as it runs Linux and graphics drivers supports OpenGL and GLSL (as otherwise you might have to write a DirectFB renderer for XBMC), other than that all that is needed is an ARM cross-compiler under Ubuntu on any x86 computer to compile ARM binaries (however Ubuntu apparently doesn't package a ARM cross-compiler by default but is easy enough to build yourself).

As I understand it cross-compiling is merely compiling code for one architecture on another, the end-result is the same as if you had compiled it on the native architecture. So the compiler produces binaries for ARM even though the compilation is being done on an x86 for instance. An ARM targeted GCC can be built by passing the --target=arm-*-elf option to configure (along with a few others as I don't think all languages support ARM).

..google is my friend I am not reading up on cross compilers:
http://www.google.com/search?hl=en&q=x86...s+compiler
and
http://www.google.com/search?hl=en&q=ARM+cross+compiler

First software tools I found seem promising; Scratchbox, and Scratchbox 2 (Sbox2/SB2):
http://www.scratchbox.org
http://www.freedesktop.org/wiki/Software/sbox2

and CodeSourcery Tool-chains:
http://www.codesourcery.com

http://www.linuxquestions.org/questions/...er-412190/

PS! These seem like good sources of information (contains many URL links) on 'HOW-TO' port software to OMAP ARM:
http://opensource.ti.com
http://linux.omap.com
http://tree.celinuxforum.org/CelfPubWiki/OSK
http://www.muru.com/linux/omap/devices/
http://www.handhelds.org/moin/moin.cgi/S...eldSummary

Might even be worth it to collect and purchase a copy of (OMAP) Code Composer Studio IDE (from Texas Instruments):
http://focus.ti.com/dsp/docs/dspsupporta...lTypeId=30
http://focus.ti.com/docs/toolsw/folders/...tudio.html

Thanks very much for the links.
I have scratchbox and currently in the process of cross compiling... but thats put on hold for now during xmas... will try keep u all updated of my progress!

Gamester17 Wrote:I am not a developer myself but IIRC davilla and althekiller said that it would probably be time consuming however XBMC should be very 'portable' to open hardware platforms as long as it runs Linux and graphics drivers supports OpenGL and GLSL (as otherwise you might have to write a DirectFB renderer for XBMC), other than that all that is needed is an ARM cross-compiler under Ubuntu on any x86 computer to compile ARM binaries (however Ubuntu apparently doesn't package a ARM cross-compiler by default but is easy enough to build yourself)...

Also... Thanks for the Links and keeping the idea alive here.

Question, is there anyway to combine this effort with hardware accelerated decoding (OpenCL)? I think (and someone please correct me if I'm wrong) that the usual PowerVR kit wouldn't be up to snuff, but with Nvidia recently making noise in the netbook/MID spaces we may indeed see some interesting developments come to market latter half of next year.

Furthermore, if I get it functionally coded I'd like to understand the limitations of its use per existing and alternative purposes. Please PM/email me at your leisure to discuss/clarify.

Soju Wrote:Question, is there anyway to combine this effort with hardware accelerated decoding (OpenCL)? I think (and someone please correct me if I'm wrong) that the usual PowerVR kit wouldn't be up to snuff, but with Nvidia recently making noise in the netbook/MID spaces we may indeed see some interesting developments come to market latter half of next year.

I think that is off-topic and unrelated for this discussion about an initial port to ARM-architecture, or at least way too early.

Besides, FFmpeg (libavcodec, the audio/video codec library that XBMC uses) already contain DSP (Digital Signal Processor) optimizations specific for Texas Instruments OMAP3 (OMAP3530) based platforms such as the BeagleBoard and the Pandora handheld game console.

For more information see the FFmpeg development mailing-list:
https://lists.mplayerhq.hu/mailman/listi...peg-devel/
and threads like "ARM NEON optimisations":
http://lists.mplayerhq.hu/pipermail/ffmp...html#57003
and also this BeagleBoard forum:
http://groups.google.com/group/beagleboard/

My guess it that the OMAP3530 will have no problem with 720p H.264 videos, and might someday even be able to playback 1080p H.264 videos with future optimizations from FFmpeg developers.

PS! Did you guys read about the ongoing progress (with patches) with porting XBMC to PPC (PowerPC) architecture? See http://forum.xbmc.org/showthread.php?tid=34439 and http://trac.xbmc.org/ticket/5544 Those patches for PPC could help this port too as it will have to workaround or fix the same endian problems and x86 dependencies, and at the very least you should can see what Makefiles that you might have to change to get XBMC to compile on a other platform than x86.

well then let me put it back on topic....

Ive began working on porting XBMC onto ARMv7 architecture.
Initially in scratchbox (a crosscompiler/emulator), then onto the beagleboard, then onto further more beefier hardware that will be released soon...
Ive successfully (i think) configured xbmc, and when i do make, it fails on a particular file due to there being assembly code in it (obv x86)...
The file in question is: XBMC\xbmc\cores\DllLoader\ldt_keeper.c (Line 132)

just thought id post my progress here, and perhaps someone is able to help with this. while i wait, i will be looking into x86 assembly and try understand what that chunk of assembler is trying to do... and perhaps recreate a C version.
Incase its relevant, the error i get when 'make' is... unknown register name eax in asm

see DllLoader.h

http://en.wikipedia.org/wiki/Local_Descriptor_Table

Ah, thanks! its all good now, (i believe - just commented it out as its unlikely to be used)

While im here, might as well mention a few things...
The screensavers stuff wont let ./configure run if u use the option --disable-gl
I know SDL is not exactly supported, and u all prefer us to use openGL, but i just thought --disable-gl would actually still work.... nvm. Im not interested in screensavers, so just ignored that whole part of xbmc.

Also, i think i may have found a bug...
XBMC/xbmc/Picture.cpp
line 223.... i believe it should be . not ->
as with a -> it fails to make, and . doesnt

And finally, Im getting errors now about XBMC/xbmc/lib/libPython/XBPythonDllFuncs.S e.g:
unrecognised symbol type ""

loads of these errors, linked to every line that has FUNCTION in that file...
Are those important? I dont wanna remove chunks without knowing what it does

those are again assembly files. you need to disable the entire python stuff at first i think (it's a substantial amount of work getting that working). also see the ppc thread in the dev forum.

that picture.cpp thing is definitely wrong, trac it please (i'm at work and will surely forget)

you might want to look at the usage of ppc and powerpc. There were additions to build XBMC for Mac on ppc and several of the same issues existed regarding XBPythonDllFuncs and DllLoader.

Ive removed the python stuff as (as far as im aware) its only used for scripts... and as this is really just a... a proof of concept, if you will.... im not bothered with having scripts.
Its a bit annoying though as have to edit it out of the configure AND makefile... and everytime i do ./configure, i then have to remove it from the makefile again... nvm

My next issue is to do with the linker (undefined reference for some of the libs)... seems i may have missed a few dependency packages

edit Makefile.in not Makefile. voila