To install Linux on the PS3, the first task is to download the Fedora Core disk image (*.iso) for the Cell processor. This compressed file contains the structure of the Fedora Core file system. It’s provided free of charge, and after you’ve downloaded it, you need to burn it onto a DVD. To do so, follow these steps:

If you look at the contents of the DVD, you should not see the file F-version_num-ppc-DVD.iso. You should see the decompressed directories and files that make up the disk image. If you only see the ISO file, you need to find a new method of burning the file to DVD. For example, if you’re using Nero Burning ROM, go to the menu option Recorder and then Burn Image.

When you’ve successfully burned the disk image to a DVD, you’re ready to start the second step, which is much easier.

Before the PS3 can install Linux, you need to provide it with a compatible bootloader. This file, called kboot, interfaces with the PS3 operating system and makes it possible to load the Linux operating system. This is freely available from the web, but the hosting site changes on a regular basis. Further, the PS3 doesn’t recognize many old versions of the bootloader.

At the time of this writing, Geoff Levand at Sony has provided many useful PS3/Linux files at www.kernel.org/pub/linux/kernel/people/geoff/cell. The most important file for our purposes is CELL-Linux-CL_date-ADDON.iso. This image contains kboot and Sony’s add-on software for running Linux on the PS3. It may be located in a directory called ps3-distro-kit. Download this file to your computer.

Burn CELL-Linux-CL_date-ADDON.iso onto a CD (not a DVD) just as you burned the previous disk image. If you look at the contents of the CD, you’ll find a file called otheros.bld in the PS3/otheros directory. This is the bootloader file that the PS3 will read during the third and final step.

When you have the DVD containing Fedora Core and the CD containing Sony’s add-on tools, you’re ready begin the main installation. I’ve divided the process into 16 steps:

Congratulations! Installing a foreign operating system on a game console is no small task, and you have every right to be proud. The rest of this chapter explains how to add software to your installation, and we’ll start with the Cell SDK.

With the SDK files in /tmp/cellsdkiso, you’re nearly ready to install the Cell SDK. But first, open a terminal and enter the following command:

yum install rsync sed tcl wget

This calls on the Yellow dog Updater, Modified (YUM) to install additional packages required by the SDK. YUM can also be used to update existing packages, and it’s a good idea to update your security configuration with the following command:

yum update selinux-policy selinux-policy-targeted

The YUM updater daemon runs in the background and checks its repositories for package updates. This interferes with the SDK installation, so stop the daemon with this:

/etc/init.d/yum-updatesd stop

The last step of the preparation is to install the package containing the SDK installation tool. This is contained in the RPM that you downloaded from the developerWorks site. It’s not part of a repository, so the tool must be installed directly with the Red Hat Package Manager, rpm. Change to /tmp/cellsdkiso and enter the following:

rpm -ivh cell-install-version.noarch.rpm

Version is the version number of the corresponding file in the /tmp/cellsdkiso directory. The i flag tells rpm to install, v tells it to provide messages, and h tells it to display hash marks (#) as the installation progresses.

There’s a new directory in /opt called cell, and inside /opt/cell you’ll find a shell script called cellsdk. This script is very important, but before you run it, you should understand what it does and what options are available.

The cellsdk script calls on the YUM updater to manage packages contained in the Cell SDK. When you run cellsdk, you need to enter a task name and any optional flags. Table 2.1 lists the tasks available.

Additional options are available to configure how the script receives and displays data. These flags, listed in Table 2.2, must be placed between the cellsdk command and the task name.

Installing the Cell SDK is performed with the install task, and —iso should identify where the CellSDK-Devel-Fedora_version.iso file is. Change to the /opt/cell directory and enter the following:

./cellsdk --iso /tmp/cellsdkiso install

Accept the licenses (which are discussed shortly), and the full SDK installation will proceed. Many of the packages are installed from the ISO file, but others have to be downloaded from the Barcelona Supercomputing Center (www.bsc.es). The connection between your PS3 and Barcelona may break during the course of the install, and if you receive timed-out errors, don’t worry; keep entering the cellsdk install command until the full installation succeeds.

To prevent the installed BLAS package from being overwritten by the YUM updater, enter the following:

exclude=blas

If you want to restart the YUM update daemon, enter this:

/etc/init.d/yum-updatesd start

Finally, it’s a good idea to run the following to see which packages have been installed and which haven’t.

./cellsdk verify

The next subsection shows how to access and install optional SDK packages.

cellsdk installs many tools and libraries for the SDK, but not all of them. Table 2.3 groups the SDK RPMs into components and lists each one. Every component is listed as Default (installed automatically) or Optional (installed separately).

The installed components will differ depending on whether you’re installing the SDK on a Cell system or not. For example, components ending in -cross-devel will be installed only if the system doesn’t have a Cell.

The Cell SDK installs a large number of libraries and tools by default, but there’s also a great deal left uninstalled. To install an optional package, make sure that the CellSDK-Extras-Fedora_version.iso file is in the /tmp/cellsdkiso directory. Then mount the Extras ISO with the following command:

./cellsdk --iso /tmp/cellsdkiso mount

This tells the YUM updater to search through /tmp/cellsdkiso when it looks for new packages. For example, to install the optional RPMs that provide Feedback-Directed Programming Restructuring (FDPR) and the Cell Performance Counter Tools, enter the following:

yum install fdprpro cellperfctr-tools

You can see that YUM automatically checks for dependencies and includes any dependency packages in the install.

This book doesn’t describe all the SDK’s capabilities, but the subsequent chapters delve into quite a few. As you link your code to SDK libraries, keep in mind the legal restrictions that apply. Software licensing is an important topic to understand, and is the subject of the next section.

The good news is that IBM’s SDK software is free of charge, powerful, and easy to use. The bad news is that the ILAR license is very restrictive; it requires that ILAR-licensed software be used only for evaluation. Using an ILAR-licensed library or tool in a production environment is forbidden, as is modifying, distributing, or transferring the code. Evaluation is allowed for 90 days, and after that period, the tool may contain a “disabling device” that prevents it from operating.

One question that has stirred a great deal of interest on the developerWorks forum involved whether an application dependent on an ILAR-licensed library could be sold commercially. IBM’s response was that the application couldn’t be sold with the library, but it would be acceptable to require customers to install the SDK. This way, the application will still be able to run. Therefore, if your application depends on an ILAR-licensed library, you may still sell it so long as the user has the SDK installed.

The executables in Sony’s Cell development toolchain (ppu-gcc, spu-gcc, ppu-ld, spu-ld, and so on) are released under the GNU General Public License, or GPL. This is the oldest and best known of the open source licenses, and is “free as in speech,” although not necessarily “free as in beer.” That is, GPL-licensed software can be released for free or sold for a profit, but any user must be able to run, modify, and redistribute the code.

There’s a catch. When you release an application containing any GPL code, you must make all the application’s source code available to users. This released code must also be subject to the GPL, so users can modify and redistribute it under the terms of the GPL. So if you intend to sell a GPL-licensed application, keep in mind that customers must be able to acquire and redistribute its source code.

If a code library is released under the GPL, any application that links against it must also be GPL licensed. The Lesser GNU General Public License (LGPL) removes this restriction, and allows applications linked against LGPL-licensed libraries to be sold under a proprietary, closed source license. However, “derivative works” of LGPL-licensed software must have their source code released as if they were licensed under the LGPL.

For example, if your application links against the LGPL-licensed SPE Runtime Management Library (the subject of Chapter 7, “The SPE Runtime Management Library (libspe)”), you can sell the application under whatever terms you choose. But if you create a product by slightly modifying this library, your product is a derivative work and its source code must be released according to the terms of the LGPL.

If you’ve installed the SDK on a Cell-based system, then the primary tools are either in /usr/bin or /opt/cell/sdk. As a rule of thumb, the basic executables needed to build applications are placed in /usr/bin and everything else, such as SDK libraries, performance tools, and ILAR-licensed features, are placed in /opt/cell/sdk.

echo $PATH

As mentioned earlier, the SDK for x86 systems is quite different from the SDK for Cell-based systems. The reason is simple: The x86 can’t run Cell executables, so all the installed libraries and tools are geared toward cross-development. For example, the SDK for the Cell contains the libspe2-devel package for creating applications with the SPE Runtime Management Library. But the SDK for an x86 system contains libspe2-cross-devel, which makes it possible to compile applications on an x86 that can later run on a Cell. The SDK for the x86 contains essentially the same tools as the SDK for Cell systems, but they’re located in different locations.

The PuTTY executable is an SSH/Telnet client that allows you to log in to the Cell operating system from Windows. Currently, it can be downloaded without charge from www.chiark.greenend.org.uk/~sgtatham/putty/. Once the executable is downloaded, double-click it. The window that appears should look similar to Figure 2.2.

Figure 2.2. The PuTTY Configuration window

The only information PuTTY needs is the host name or IP address assigned to the Cell system. You can find this by accessing your router (go to http://192.168.0.1 in your browser) or by running ifconfig on the Cell command line (find the inet addr field). In the preceding example, the IP address of the Cell system is 192.168.0.102. This must be entered in the Host Name (or IP address) box.

Click Open. If PuTTY is configured correctly and Linux is running on the remote system, a window will appear asking for a username and password. Log in and you’ll see a Linux shell prompt. This means you’ve established remote access to the Cell system.

There are many different ways to send files across a network, and most file transfer tools will suffice. The open source WinSCP tool from http://winscp.net/ is particularly helpful, and it’s as simple to use as PuTTY: Just download, configure, and start running. Figure 2.3 shows what the WinSCP configuration window looks like.

Figure 2.3. The WinSCP Configuration window

Enter the same host name or IP address as you did for the PuTTY configuration, and enter the username/password that you want to log in with. You can save this profile with the Save button, and when you click Login, WinSCP will attempt to connect to the Cell system. If it succeeds, you’ll see a window similar to that shown in Figure 2.4.

Figure 2.4. The WinSCP file-transfer window

You can switch directories on either the host or target system by right-clicking the pathname above the file listing and selecting Open Directory/Bookmark and Browse. In Figure 2.4, if you right-click the C:example-folder box and select Open Directory/Bookmark and Browse, a dialog will allow you to change the Windows directory. On the other side, if you right-click the box containing /root/Documents and select Open Directory/Bookmark and Browse, the dialog will allow you to change the directory on the Cell system.

To transfer files, click a file or folder on one side and drag it across to the other. As the transfer finishes, you can watch its progress toward the bottom of the window.