[Gamester17]

@ CyruzDraxs, feel free to chat with our developers on IRC (#xbmc-linux on freenode)
http://wiki.xbmc.org/?title=XBMC_for_Lin...elopers.29

Please submit all and any code porting progress to us as diff patches, thanks in advance.

PS! D4rk is our resident expert on OpenGL rendering, elupus knows his way around too

[Gruso]

BUMP!

Hi. I signed up to post a similar thread, but found this one. I'm a long time XBMC fan and would love to see it ported to the ARM platform some day. My area of interest is also the TI OMAP3530 processor, and more specifically the upcoming Pandora handheld gaming console / mini Linux computer. http://www.openpandora.org

Some recent renderings:
http://www.openpandora.de/images/panda01.jpg
http://www.openpandora.de/images/panda05.jpg

Some specs:

* ARM® Cortex™-A8 600Mhz+ CPU running Linux
* 430-MHz TMS320C64x+™ DSP Core
* PowerVR SGX OpenGL 2.0 ES compliant 3D hardware
* 800x480 4.3" 16.7 million colours touchscreen LCD
* Wifi 802.11b/g, Bluetooth & High Speed USB 2.0 Host
* Dual SDHC card slots & SVideo TV output
* Dual Analogue and Digital gaming controls
* 43 button QWERTY and numeric keypad
* Around 10+ Hours battery life

Some blurb:

It is by far the most powerful handheld in the world both in terms of raw CPU power and 3D graphics capability, it will be able to handle things such as Firefox3 or Quake3 with ease.

For those who haven't heard of it, Pandora is essentially a community project born out of the GP32X forums. The community was built around the Gamepark GP32 and GP2X handhelds, and is home to many talented coders, retro gamers, and open source enthusiasts.

Pandora is an independent project (not a product of Gamepark), but remains closely tied to the GP32X community. Preorders open this month and the first batch of 3000 is expected to move pretty quickly. Another batch will follow, and as long as people keep buying them, I guess they'll keep making them.

In my view, products like Pandora and BeagleBoard are at the leading edge of a surge in OMAP powered mini/mobile computing. There is plenty of love for XBMC in the GP32X community, and the idea of mobile XBMC is very attractive. I'm also planning to go HD in my loungeroom with the use of a BeagleBoard based system - and it just wouldn't be the same without XBMC.

Just thought I'd put my thoughts out there. I'd be interested to hear if the idea of an ARM port has progressed at all.

[Gamester17]

No one has stepped up to work on an ARM port yet, but annex is working on making a OpenGL ES compatible DirectFB renderer, see here => http://forum.xbmc.org/showthread.php?tid=36711

Maybe you (and others) should try to lobby the idea to the OpenPandora.org community developers

[Gruso]

There are some discussions happening over there already. One guy is talking about taking about an OpenGL ES / Direct FB port, so I'll link him up to that thread. Thanks.

[Gamester17]

ARM emulators (virtual machine emulator) could possibly make porting easier for those developers who do not actually have any ARM hardware:
http://en.wikipedia.org/wiki/Comparison_...l_machines

QEMU emulator looks most promising at a first glance as it is both free and open source:
http://en.wikipedia.org/wiki/QEMU

QEMU emulates the armv5tej instruction set and all the derivative processors families like ARM7, ARM9E, ARM10E and XScale. It emulates full systems like Integrator/CP board, Versatile baseboard, RealView Emulation baseboard, XScale-based PDAs, Palm Tungsten|E PDA, Nokia N800 and Nokia N810 internet tablets etc. Qemu also powers the Android emulator which is part of the Android SDK (most current Android implementations are ARM based).

http://qemu.org

QEMU is a generic and open source machine emulator and virtualizer.

When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.

When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.

QEMU open source software simulator for x86 that can emulate systems with processors of various architectures, including 386, x86_64, ARM, MIPS, PowerPC and Sparc. For ARM, two emulated platforms are available -- an older "Integrator" platform, and a newly-added "Versatile" platform.

The new Versatile platform includes a SCSI hard disk controller, Ethernet card, and graphical display. According to french Debian developer Aurelien Jarno (who published a HOW-TO about installing Debian or another Linux distributions on the open-source QEMU emulator), when run on an Athlon 64 3800+, running under QEMU can perform 20 percent faster than the ARM-based LinkSys NSLU2 (an inexpensive network-attached storage appliance that is commonly pressed into service as a full Debian ARM development target).

Jarno's HOW-TO begins by describing how to download and install QEMU from CVS, to ensure that the latest Versatile platform support is included. He then configures QEMU to emulate a 10GB hard drive, and downloads a publicly shared Versatile kernel that he created (Debian ARM does not yet include a kernel that supports the image, he says). Next he downloads Debian's "Etch" installer, and bootstraps the installer using a qemu-system-arm command.

Jarno's HOW-TO next describes several harmless error messages, leading ultimately to the emulated ARM system's first boot. Jarno's HOW-TO completes the basic installation by installing a more complete kernel.

Jarno's HOW-TO goes on to explore a few more advanced topics, such as running an Xorg server, increasing the amount of RAM to the maximum supported size of 256MB, and setting up a network bridge to allow the emulated system access to the Internet. The HOW-TO closes with a list of additional resources.

The full HOW-TO can be found here (link) was first published in 2006

[devanl]

I haven't really thought very far in to this I admit but has anyone looked at the idea of running XBMC on their Samsung TV?

http://www.vistabug.com/bb/viewtopic.php?id=76

Sadly this doesn't describe much in terms of HW or packaged drivers but does this seem at all likely? Probably not since I doubt the TV has an X server environment but I was hoping there was a genius out there who knows otherwise.

Devan

[rwparris2]

XBMC can't run on ARM Processors (the post said it was running ARM Linux).

Several people have asked for ARM compatibility, search around the forums.

Having xbmc running inside your TV would be pretty sweet though...

[erito]

Is it possible, or do you think it will be possible?

The popcorn hour media player is great, but the interface is way worse than XBMC, so whith PopcornHour hardware and XBMC as interface = 100%

[pike]

you get what you pay for

and to really answer your question, not today, maybe not ever. PCH is not a compatible platform, far from it

[Gamester17]

Even if the Popcorn Hour is 'hackable' you would still have to port XBMC to ARM with DirectFB rendering first, see:
http://forum.xbmc.org/showthread.php?tid=35139
http://forum.xbmc.org/showthread.php?tid=34562

Even you did that it is questionable if the Popcorn Hour CPU and GPU would be up to render XBMC GUI smoothly.

So no, it is not possible today.

[McGeagh]

Apologies if this is the incorrect place for this, or whether its been answered elsewhere, and if so - can you please give links to it.

What im looking for is the requirements for XBMC, in terms of porting to a development board with linux.
E.G I am looking to see if a board i have has enough components for XBMC to be ported to it (its very limited)

The main things that are causing me concern is that it doesnt have DBus or GConf... but ive had a fair look around these forums and i have come to the conclusion neither of those 2 are needed.
Some other items that concern me is this board doesnt have a device management available - whether thats needed is unknown to me.
Another thing that it doesnt apparently have, but sounds like it is needed, is a media framework.

Hope this isnt too vague - i am a bit of a linux n00b.

Any info, any links, etc would be greatly appreciated.

Thanks in advance!

[malloc]

you're very vague, but i'll try to get to the root of the problem.
1) your board probably doesn't support opengl 2.0. we require that. or maybe it's 1.5. chances are your board doesn't have opengl at all.
2) a fast processor. we currently don't have any gpu or video decoding hardware support, so you need a fast cpu (~2ghz for 720p h264 content).

[McGeagh]

thanks for the reply.

I do understand opengl is recommended, not neccessarily required as SDL (should) work - although stupidly slow...
The board does have OpenGL ES 2.0 (apparently)

As for the processor speed, its 600MHz, which doesnt sound a lot compared to PC cpu's (which this isnt) - but it CAN do 720p at this speed (not H264 mind)
Im currently just looking to see if it will run, not caring about how many fps it achieves...

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, not to mention problems with ELSA drivers.... but both are being fixed very soon.

Anyways this is turning more into hardware spec - whereas i was thinking more low-level components such as:
c-libraries
glib
dbus
gconf
X
etc etc

i feel im still being vague here, and apologies for that!

[althekiller]

The code is only known to compile on x86, x84_64, ppc and ppc64. The latter two aren't in regular development, so they may not anymore. Presumably the board you're working with is ARM based, so you'll need to at least tweak with the build system. The non-gl build also isn't really developed anymore and may not compile. It really was useless anyway and more of a stepping stone in the porting process. However it isn't completely far fetched to write a gl es renderer.

[brucej]

I guess this is a far ranging question, but once you have an appropriate Linux port running on ARM (assuming that I had, say, an ARM 11 @ 1GHz) how portable is the rest of the XBMC source? Are there any really x86-specific parets of the code that are going to be painful to unpick (like chunks of hand written x86 assembler)?