Enabling user access to another spu

Rip Cord

Staff member
Using Linux to Enable Access to Another Spu

When booting up, in the petitboot menu highlight the entry for the linux kernel that will be booted.
Press "e" (edit) to add a command line boot parameter.
The edit screen appears with something like:
imag: /var/petitboot....powerpc64-otheros
initrd: /var/petitboot...powerpc64-otheros
args: root=...video=ps3fb:mode:0

line three, args, is for command line arguments (space separated)
append "spu_base.enum_shared=1" to whatever arguments are already there

args: root=...video=ps3fb:mode:0 spu_base.enum_shared=1

To see if it worked, install spu-tools_2.3.0.136-1_powerpc.deb which has commands to view spu statistics. After installing spu-tools, enter "spu-top" at the commandline to view the spu activity.
push "h" to see the spu-top commands (s to view spu list, q to quit, etc)
After pushing "s", you should see spu's 0-6 listed (booting without spu_base.enum_shared=1 would only show spu's 0-5).

If entering the spu-top command results in a message like "segment fault", then maybe the spu file system is not mounted. You can check with the mount command.
To mount it, first create a directory /spu (either right click the background in file manager, create folder or else at a command line mkdir /spu)
Then mount with: mount -t spufs spufs /spu
Try again: spu-top

spu_base.enum_shared=1 is for more recent kernels; earlier kernels used spu_base.enumerate_shared=1
I couldn't get either one to work with 2.6.38; spu_base.enum_shared works for 3.7.1
The mkdir, mount, and spu-top commmands should be entered as root.
Manually entered boot parameters are only in effect for that boot. To enable the spu permanently, add the boot argument to the kboot.conf or yaboot.conf (or .cnf or whatever the distro uses to configure boot options).
I don't know any use for this, and it can interfere with the features that only function with ss patched firmware.
There is one more spu that could be enabled as discussed here: http://techbliss.org/threads/7th-spu.387/

edit: fixed typos above in commandline
(NOT ..._share=1, accidentally left off letter "d")
Last edited:

Rip Cord

Staff member

someone enabled one more spu, the 8th spe, by using linux to change the value in the syscon.

I read this may cause brick if the 8th spu is faulty, but I have also read in the IBM hardware initialization guide that the system controller reads the rd_partial_good register:
"...Because the spe_available MMIO register receives its value from the SPE Disable field on the configuration ring during POR, the external system controller must read the rd_partial_good register before the configuration ring write has taken place in order to set the SPE Disable field to match the rd_partial_good register."