Category: ps3

Building gdb for Cell/B.E.

Trying to debug a bus error on my PS3, I realised that the version of GDB I have installed doesn’t support debugging of SPU programs. There doesn’t seem to be a Debian packaged version available that does, so I built my own.

Because I found no obvious google result, I share this with the zero other people that I expect may one day be interested : the key option for configure appears to be

--enable-targets=spu

This information was brought to you via the gdb.spec file, and a post to the gcc-testresults mailing list.

Some Linux on PS3 updates

I’ve updated the Linux distros page with links to articles about installing Ubuntu 9.10 [Joep Cremers Weblog] and Fedora 12 [Geoff Levand, Ken Werner] on the Playstation 3.

In mosty unrelated news,

IBM will not be releasing a previously planned successor to the PowerXCell 8i [heise online, Playstation University]
(neither article conveys particularly clear information to me – not least because I have only a machine translation of the first one)
Playstation 3 firmware version 3.10 seems to have added ABC iView and BBC iPlayer support to the XMB (the presence of which *may* be related to your PSN region, geographical restrictions to accessing video content still seem to apply). If you can’t see it in the TV column of your XMB, try rebooting…

PS3, Fedora 11 and OpenCL

Ken Werner has written a nice guide to installing Fedora 11 on the PS3. (And I’ve added the link to the Linux distro page).

Inside Ken’s page is some details on installing and running demos from the recent “OpenCL Development Kit for Linux on Power”, which is something I’m now even more keen to try :)

(It seems a little odd that the only place that OpenCL SPE acceleration is mentioned is in one of the FAQs…)

A summary of Linux distros for the PS3

I’ve been asked about selecting a Linux distro for use on the Playstation 3 a few times recently, so I’ve put together a page summarising some of the options which has mentions of pdaXrom, Debian, Ubuntu, Yellow Dog, Fedora, RHEL and Gentoo.

It’s all based on my own knowledge and experience – if there’s something you think is worth adding (or correcting, or improving) let me know.

[Update 20091021: Expanded the entry for Gentoo based on suggestions from unsolo & cheriff, and added a link to Windows-Hosted Cell SDK which I saw mentioned by @domipheus]

sixaxis as joystick and mouse over bluetooth

sixaxisd is a little daemon that will translate sixaxis input, sent via bluetooth, into joystick and (optionally) mouse input. I found it as part of the pdaXrom-ng distro, available here.

To set it up, grab the source here, unpack, apply the patch from here (which fixes a couple of axis mappings) and compile using make.

You need a kernel with uinput support (Device drivers -> Input device support -> Miscellaneous devices -> User level driver support – or CONFIG_INPUT_UINPUT) and appropriate bluetooth support (I use ps3_defconfig’s defaults in this area), although you don’t need any particular system bluetooth services running – we set that up ourselves.

To configure the bluetooth device using hciconfig (which is part of Debian’s bluez package), run the following commands –

hciconfig hci0 up        # bring up the interface
hciconfig hci0 lm master # set link mode to master
hciconfig hci0 piscan    # enable page and inquiry scan

And then start the daemon –

# optional -mouse param provides mouse emulation
./sixaxisd -mouse

Hit the PS button on the controller to bring it to life – all going well, there device nodes /dev/input/js0 and /dev/input/mouse0 will be created.

There’s an init script to handle the hci configuration and all of this that may be found in the pdaXrom svn repo.

(I use my sixaxis with my PS3 – if you want to use it with a different system, you’ll need to use sixpair, available here)

CellBE Buddhabrot renderer

For my next TUCS tech talk I’ll be continuing on from the Mandelbrot rendering in the last one (which can be seen here) to something a little more complex.

The Buddhabrot is conceptually not any more complex than the Mandelbrot in terms of its generation – rather than colouring points based on the number of iterations before they ‘escape’, we apply colour to each point reached while iterating escaping starting points. This has consequences for the drawing of the Buddhabrot – rather than generating one point at a time independently of all other points in the output, iterating a single input point may effect thousands of different output points. This makes it all trickier when implementing this on the Cell BE – parallel writes by SPEs to shared locations will need some form of synchronisation. That could be messy, and the process of load/modify/store when expressed in terms of SPU DMA can be quite clumsy.

Rather than try to implement a complex locking/synchronisation system, I have tried to apply some ideas from a set of post-it notes by Mike Acton (you can see them here). This isn’t identical to Mike’s solution, because it’s not the same problem.

To explain – each SPE thread iterates various points on the screen, and generates a list of points to be written. This list of points is sent via DMA to a buffer for the SPE’s use the PPE, which proceeds through the list plotting the points to the framebuffer. The advantage of this approach is that there is only one writer to the framebuffer (the PPE), and that each SPE has it’s own buffers to write its data into. The only synchronisation that is necessary is between each SPE and the PPE to ensure that all data in a buffer is consumed before writing more into it. This is achieved through the use of interrupt mailboxes (SPE tells PPE that there is data), a fenced DMA to act as sentinel (the PPE spins on the arrival of the sentinel data to ensure that DMA of a buffer has completed – this doesn’t feel like the right way to solve this particular problem, though), and the SPE signal register in OR mode to inform the SPE that a particular buffer has been finished with. Interrupt mailbox events are aggregated through libspe2’s spe_event_*() functions.

It’s not an especially complex piece of code – the motivation in its writing is for my own interest and to use for the tech talk. I think it will do nicely for explaining some of the complexities and curiosities of the Cell BE architecture, and the programming of it with the IBM SDK.

There are a few extra features that I’d like to add – particularly better colouring (including saturation which is unfortunately apparent in its absence), and a number of optimisations to the render_fractal() function that I need to lift from my earlier Mandelbrot efforts.

The program includes code by Jeremy Kerr (See hackfest items at http://ozlabs.org/~jk/diary/tech/cell/) and Mike Acton (framebuffer utilities, from http://cellperformance.beyond3d.com/articles/2007/03/handy-ps3-linux-framebuffer-utilities.html). My thanks to Jeremy and Mike, and to all those that have offered comments & feedback via twitter.

[edit: Oh, and it includes cheriff’s fine VNC code ;)]

Read the code: fractal.c and spe-fractal.c, or grab a tarball. Comments & suggestions most welcome.

Addition: I added pixel value saturation and experimented with some alternative approaches to colouring…

(Click for larger version)

Fedora 11, PS3 & SPU programming

Some notes on Fedora 11 on PS3

Intro to Cell, part 6 and part 7 the excellent series from NotZed continues.

2D Polygon rendering demo(3067FPS ver.) on PS3 Linux

YUV to RGB on SPU More in-depth spu programming from NotZed.

Insomniac games Nocturnal Initiative and also #nocturnal on irc.freenode.net (and Insomniac’s R&D page is always a good read)

Arbitrary problem solving

Spending a few days at the in-laws, I’ve lugged along the PS3 so that I can continue my attempts at hacking on a DirectFB driver. Unfortunately, I’d left it configured as it had been on my home network – using wired networking.

There’s no way to run network cables around this house without causing massive inconvenience, and there’s actually no cables to run. Let’s just configure this thing for wireless networking. Except I don’t have a USB keyboard.

Buggr.

Ok, what do we have? A short piece of CAT5 that connects a VoIP box to the wireless router. That’s a start. I can boot it on the wired network, connect remotely, find the IP via the router’s DHCP report (fortunately that has default login credentials), ssh in, make the changes and get on with whatever it was I was going to do.

So, I plug it in (unplugging the VoIP box), boot the PS3, look up the IP, enter username and password and then fail to be allowed access. What? Oh, I’m trying to log into the dropbear sshd that comes with petitboot – I’ve not made it past the boot screen because I didn’t specify a timeout for picking a boot option.

Grr.

Ok. Next option? Is the CF card that I was booting from recently still in the CF slot? *opens door* Aha! It is! Not of immediate help, because it doesn’t have a default option either, but if I can find a Linux machine to plug this into I can set one…

Grab card reader from camera bag, reboot laptop (wifi adapter for laptop is flakey under Linux atm, not sure why), insert card, mount device, add missing boot lines to kboot.conf (which are, I hope, correct)

default=ouros
timeout=5

save, unmount, CF card into PS3, boot and wait…. (five seconds seems like a long time).

And it boots! ssh login (from putty on restarted laptop), mount /boot, modify kboot.conf in the same way, shutdown, remove card, boot, wait . . . . .

Huzzah! Problem solved. Now for some hackery :D

Oh, wait, that wasn’t the problem. *sigh*. The PS3 still isn’t speaking wifi.

Boot PS3 (after shutting it down expecting to be able to relocate it further away than the short blue tether that I’d been using), ssh in again and make changes to /etc/network/interfaces.

I’m not normally a wifi user nor a debian user so this is where it gets a little tricky. The network I’m trying to connect to is WEP, and the debian wiki doesn’t want to tell me how to set that up in case I hurt myself. Fine. A little more googling, and I find what appears to be a suitable incantation :

wireless_essid in_laws
wireless_key manycharactersthataddlittlesecurity

Good. So I uncomment the wlan0 section and add those two lines.

Playing with networking configs over ssh is where things get fun.

/etc/init.d/networking restart

Did it work? Actually, I think it did – eth0 re-DHCPs, and then wlan0 does, b0rking (it would seem) access via eth0.

Bah.

Reboot. The same thing happens – eth0 comes up ok, and then wlan0 confuses the matter (the PS3’s two interfaces share a lot in common, so you can’t configure them both like this without hassle. It would seem)

Ok, so what do I have now? A machine that won’t boot to having a functional network connection, no keyboard, and I can’t boot it back up from the CF (I think) because the internal HDD is set with a timeout and (I expect) will take precedence over the config on the CF because the HDD was the last used boot device.

Expletive.

Wait, what happens if I unplug the CAT5? Reboot, wait. Nothing. Nothing. No response to pings. Nothing. Nothing. Ping! DHCP times out on eth0 and then wlan0 starts up correctly. Diggity! So all appears to be (sufficiently) functional for now.

Why was I doing this again?

A new compiler and a visual guide

From http://t-platforms.ru/en/cell/cellcompiler.php :

T-Platforms Cell Compiler is a single source compiler that explores the power of Cell/B.E.™ multicore architecture through auto-parallelization and auto-vectorization of source code of applications written in a sequential manner and language (C/C++, Fortran).

They’re looking for beta-testers – I’ve applied.

Visual guide for SPU instructions Jon has put together a fantastic document illustrating the behaviour of most SPU instructions – very enlightening and a wonderful reference.

Mars 1.1.3 has been released. “MARS is a multi-tasking runtime system for multi-core processors. The current implementation is for the Cell BE. The system is co-processor centric, in that the co-processors each run a micro kernel that generally runs independent of the host processor.”

Mandelbrot, Cell BE and Linux distros

There must be something “special” about the Cell BE, Mandelbrot fractals and Australians – I’ve found another implementation, and this one is really good (not to disparage jk’s implementation, especially when it was so useful). NotZed at cell.grondklont.nl is up to part 5 in a fantastic in-depth series on implementing a optimised Mandelbrot renderer on the Cell BE – of particular interest to me was the load balancing implemented using the atomic cache unit, which is quite impressive.

A number of #ps3dev residents have decided to put some work into a PS3-targeted Linux distro. Hanging out in #ouros (on freenode) some progress is being made on getting some basics together, with a rudimentary tarball for (aspiring) developers now available as well as a lot of effort on supporting infrastructure (bots, hosting, planning, etc). If you are at all interested, check out #ouros and/or #ps3dev on irc.freenode.net

From conversations in #ouros yesterday, it would seem that DirectFB is worth investigating as a PS3-Linux friendly way of providing a fast, light-weight graphical user interface for the PS3. First of all because X is a behemoth and largely undesirable on the limited-resource PS3, but also because DirectFB has a number of design characteristics that seem to make it a good match to Linux on the PS3 – it needs only access to the framebuffer (it already works), and it allows creation of device driver for specific hardware. It seems likely that DirectFB rendering can be accelerated without much hassle by using the SPEs. As well as this, SDL supports DirectFB (which means a large number of games and other programs should Just Work) and there appears to be current QT support as well. All up, this seems quite promising.

Otherwise, I’ve spent time this evening playing the Uncharted 2 beta. Apart from the eons spent waiting to join a game, it was quite enjoyable, if occasionally buggy and clumsy.