[Cbe-oss-dev] Questions about running kernels/Linux under custom firmwares

[Declan Malone]

Hi,

I've recently had to install custom "OtherOS++" firmware after someone
updated my 2.x firmware despite me warning them not to. I'm now
running firmware 3.55 and debian squeeze based on the instructions on
gitbrew, including the 2.6 git kernel tree stored there. I've been
trying to rebuild all the tools I was previously using (from about 2
years ago) with the intention of getting back into programming on the
platform. I have a few questions that I'm hoping someone here can
answer. My apologies in advance if it's not the correct forum.

The main difficulty I'm having is with the spufs module included with
the kernel. It works OK for quite a few of my programs, in that it
allows me to load and run the SPE code and do most of the usual stuff
that was working before (mailboxes, dma to/from SPEs, etc.). However
the biggest problem I'm noticing is that the /spu virtual filesystem
isn't being populated with process information, and as a result spu-ps
or spu-top aren't showing any results (though they do report on % cpu
usage for the SPEs correctly).

I've tried downloading other kernels from kernel.org, from Debian
(linux-image packages) and from Geoff Levand (the official ps3
kernels?) but the initial bootloader (kboot in petitboot?) just hangs
without even printing any messages when I try running them. Apparently
there are some changes made to the kernel to enable it to run under
OtherOS++, but I've no idea how to go about finding out what these
changes are or how to apply them to the official kernel sources.

So my first question is: how do I either (a) get the official kernels
to boot in this custom firmware environment, or (b) how do I get spufs
working properly with the custom kernel. As for (b), I came across
some discussion of the exact problem I'm having, and I think it was
ultimately solved by a set of kernel patches. I suspect that those
patches never got into the custom kernel I'm using.

I've also come across other problems relating to spufs, and some other
problems that might not be related.

Firstly, I tried recompiling the tests for libspe2-2.2.0. I had to
install libspe2 by hand since the package seems to have been dropped
from Debian Squeeze (is there actually any active development for
Debian on PS3? I don't know). All the tests passed except the testmap1
test, which tries to access SPE memory at 0xf7e52000 directly from the
PPE. Checking the status of the process it shows it's waiting on
.spufs_ps_fault. As I understand it, the kernel should be able to page
in the SPE memory into the PPE address space, but it's not working for
some reason (and there are no kernel log messages, even with the debug
mount option set on the spu filesystem in my fstab).

All the other programs I'd written before to work with libspe2 work
fine, with the possible exception of one test program which now often
crashes with a bus error. I can't discount the possibilty that I never
debugged that one properly before, though.

The other thing I wanted to do to bring the system back to the same
state as I had before is to install the mars libraries. Unfortunately,
while it seems to compile OK, all the test programs in there are
crashing with bus errors, segfaults or format errors (when trying to
load a 32-bit elf image into a SPU). I'm not sure what's going wrong
here, but I suspect that it might by my toolchain that's at fault. I
know there are problems with compiling kernel.c with gcc-4.4 since it
doesn't let you compare (!=/==) vectors. I fixed that problem, but I'm
not sure if there are other problems lurking there. My own programs
that use mars also fail with a format error when trying to load an elf
image (tested standalone and embedded).

I can live without fixing mars for the moment, but not being able to
load other kernels to see if they have a working spufs is really
throwing up a roadblock for me. Any help anyone can offer here would
be much appreciated.

Regards,
dec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20111218/21a533bf/attachment.html>