exec 1>/dev/null

This redirects the file stream to the /dev/null device which silently swallows the output.

This is useful if for instance you are writing a cron job which you want to have log it’s steps while you are developing or debugging it, but don’t want any output except the stderr once it’s running.

1) Print predefined macros:

gcc -dM -E - </dev/null | sort | less

2) Print predefined macros and macros introduced by a specific header

echo “#include <stdlib.h>” > foo.h

gcc -dM -E foo.h | sort | less

Reference for -dM is in the cpp man page.

The KernelTeam’s KernelMaintenance page does mention a little about this but provides no examples or detail. I found out what was necessary by sending questions to the kernel team mailing list.

In my repository the “origin” repository is an Ubuntu one (ubuntu-intrepid-ports) as this is where I cloned from. But originally this will have been based on a repository from git.kernel.org. So for convenience, we can add a git “remote” definition for our target upstream kernel.org repository so that we can refer to it by a simple name. In this case I’ll just use the name of the upstream tree, linux-2.6.25.y. linux-2.6.25.y is the stable tree for maintenance releases of the 2.6.25 kernel which the ubuntu-intrepid-ports kernel is currently based on.

git remote add linux-2.6.25.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git

Now we need to fetch all the new upstream changes into our repository. This doesn’t make any changes to our current branch it just downloads upstream revisions into a remote-tracking branch in the background. You can view remote-tracking branches by running git branch -r, you should see linux-2.6.25.y/master listed.

git fetch linux-2.6.25.y

Next we can see what new revisions are available upstream by listing logs from our HEAD through to the HEAD of the upstream remote-tracking branch.

git log HEAD..linux-2.6.25.y/master

We can also see which of our local changes will be rebased by asking git log to show us commits which are in the HEAD but not in the remote. For ubuntu-intrepid-ports this will be all commits which add to or modify the packaging scripts in the “debian/” directory, and any other special patches which have been applied. Most of the commit logs for these revisions should start with “UBUNTU:”.

git log linux-2.6.25.y/master..HEAD

Now we’re ready to actually rebase. Run the following command. You should see lots of output from git as it saves away local changes, resets back to the last commit pulled from the remote, pulls in all the new revisions from the remote, then replays all our commits on top.

git rebase linux-2.6.25.y/master

That’s it. We’ve resynced with upstream. Now we’re ready to build and test.

If you’re happy the tree is in a good state the next job is to make your updates public. If you have been allocated a git tree on kernel.ubuntu.com you can push the changes there. Otherwise you’ll need to investigate other ways of hosting a remote git repository.

Add a “remote” definition for your public repo. In this example I’m accessing the remote repo using SSH as the transport.

git remote add mypublic myusername@myhost:/path/to/git/repos/dmunckton/ubuntu-intrepid-ports.git

You have to force-push the changes to your remote public tree because where we’ve rebased our history has completely changed. Any history already in your public tree will completely different. The -f option to git push forces it to make the remote repository reflect your local changes. If you don’t do this the push will fail.

git push -f mypublic master

Be careful to warn anyone following your public tree as this type of push will prevent easy tracking using git pull. They will need to follow the instructions in the KernelGitGuide wiki page to track your changes.

As usual if you find any innaccuracies or mistakes please do leave a comment.

Prerequisites

I’m going to presume the reader already has a git checkout of the ubuntu ports source tree and knows how to build the Ubuntu kernel packages on the target architecture. Notes on this can be found in the “Performing Builds” section of the KernelMaintenance wiki page.

I recommend the reader either runs Hardy or Intrepid on their x86 system so that toolchain packages from the PS3 Dev Team PPA will install easily.

The Problem

Cross compiling the Linux Kernel directly is well supported. You need only set 2 environment variables so the build scripts know the target architecture and where to find the cross build tool chain. E.g. if you’re targeting PowerPC and your build toolchain (binutils, gcc etc) binaries are named as powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld etc then you’d run something like this to build the kernel:

make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-

But what I wanted was a valid installable Ubuntu package at the end. Usually to avoid any chance of missing build platform related build errors Ubuntu/Debian packages are always built on the target architecture. However there’s quite a bit of work happening in Debian to help support cross building for low resource embedded platforms (e.g. mobile, set top boxes etc) so with a little hunting I was able to find out a very simple way of achieving my goal.

The Toolchain

First problem is we need to get a toolchain built for x86 but compiled to build for our target architecture which is powerpc64 with specific knowledge of the Cell CPU.

Luckily, the old Cell-SDK had already been packaged for Ubuntu by Matthias Klose, and is built for both powerpc and x86 architectures. However there was a bug which prevented kernel compilation. So I updated these packages to the latest from the Cell-SDK site. To get my updated packages add the PS3 Dev Team’s PPA to your APT sources list (basic instructions on that last page, make sure you choose ‘hardy’ or ‘intrepid’ ) and run:

sudo apt-get install ppu-gcc

Now your cross toolchain should be available as ppu-gcc and ppu-ld etc.

While the toolchain patches for the Cell were being developed they were created against GCC 4.1 and Binutils 2.17 and sources and binaries were (and still are) hosted at Barcelona Supercomputing Centre and known as the Cell-SDK. These patches have now been absorbed into the current versions of GCC and Binutils (GCC 4.3 and Binutils 2.18 I believe) so in theory it’s no longer necessary to use the Cell-SDK.

Intrepid’s toolchain is based on these newer versions and despite there being notes on a way to create Debian packaged cross toolchains using them I wasn’t able to get them both to compile. See debian/README.cross in the binutils and gcc package sources for more info. I’m sure the problem can be easily resolved but for now the Cell-SDK has got me up and running quickly.

Setting The Target Architecture For The Package Scripts

Now we have a toolchain the next problem was how to force the Ubuntu packaging scripts to use it. After much scanning of source code this turned out to be very simple indeed. There are whole a series of environment variables which need to be set. Luckily the utility dpkg-architecture makes it very simple to set these. You just need to pass it your desired architecture and evaluate it’s output in your shell, thus:

eval $(dpkg-architecture -apowerpc -s)

I’ll leave it to the reader to look at the man page for dpkg-architecture to understand more about this utility and the variables which get set.

Putting It All Together

So putting all these things together, this is roughly the script I use to cross build the kernel.

#!/bin/sh

# Decide where we're going to log to this time
LOG=$(pwd)/../$(basename $(pwd))-$(date +%F-%H%M).log

# Make sure ccache is used for HOST_CC
export PATH=/usr/lib/ccache:$PATH

# Setup the deb arch variables for cross building to target powerpc
eval $(dpkg-architecture -apowerpc -s)

# Run the build
CROSS_COMPILE="ccache ppu-" fakeroot debian/rules binary-powerpc64-smp 2>&1 | tee "$LOG"

# Let you know it's finished
aplay /usr/share/sounds/phone.wav

This script should be run from the top of the Ubuntu kernel source. It logs all the build output to a file in the directory above but also outputs everything to the shell.

Note CROSS_COMPILE is set before running the build command. Although this variable is not touched directly by debian/rules it is propogated to the kernel build scripts.

ccache can be used for cross building. For me it halved the build time to 25 mins on second run so it’s well worth using it. Caching for the host architecture is supported on Ubuntu by pre-pending the /usr/lib/ccache directory to $PATH. I’ll leave it to the reader to find out how this works. In order to support caching for the foreign architecture we can simply modify the CROSS_COMPILE variable to prepend a call to ccache.

I also like to use the screen utility so I can walk away/logout etc and return later. See my previous post on how to use that. Finally the script runs a WAV file so I know when it’s finished.

UPDATES:

30 Aug 08: Updated notes on using ccache for cross compilation. Updated the build script to use ccache for the target architecture.

Background

The kernel used for PS3 in Ubuntu is the generic powerpc64-smp flavour. Unfortunately the PowerPC architecture is no longer an officially supported architecture in Ubuntu and therefore it falls to the community to keep it alive. The kernel source for this and the other unsupported architectures have been moved out into a separate git source tree to reduce the complexity and fragility of kernel maintenance. E.g. a bad change in the ports tree won’t break the build for the supported flavours. For the upcoming Intrepid release this is the ubuntu-intrepid-ports tree.

The important thing to note here is the PS3 kernel source is still shared with other architectures such as HPPA, ia64, SPARC etc, as well as for the standard PowerPC platform so any changes we make for PS3 must not break the kernel for any of these platforms. To verify this I will need to find interested parties who have relevant equipment to test on as I will not have access to any of these platforms myself. More on this in later posts.

Stuff To Do

First thing to do is read the KernelTeam/KnowledgeBase articles on the Ubuntu Wiki. In particular the KernelGitGuide and the KernelMaintenance pages.

Presuming you’re already subscribed to and known on the ubuntu-cell list, next subscribe to the Ubuntu Kernel Team mailing list and introduce yourself and your intentions. You will also need to monitor or subscribe to the actual kernel mailing list, and also specifically to the PS3/Cell Kernel development list.

Geoff Levand is (one of the folks) employed by Sony to work on the Linux Kernel for Cell and PS3. He keeps releases of the PS3 “Distro Kit” and lots of interesting documentation in his directory on kernel.org: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/. You’ll need to be familiar with what’s there and hoover up the information provided.

Having done all this you should now have

• A local clone of the ubuntu-<codename>-ports tree (replace <codename> with ‘intrepid’ or whichever is the current codename as you read this) to work in.
• A good (but theoretical) idea of the maintenance process to follow.
• And you should know where ‘upstream’ is and where relevant development discussion is happening.

Getting More Official

The way development is structured is each of the Ubuntu Kernel Devs have their own Git source trees on http://kernel.ubuntu.com/git. They work locally then push there changes to their tree hosted there. Changes from their hosted tree can then be pulled into the intended mainline source trees as necessary, e.g. I may push my changes to dmunckton/ubuntu-intrepid-ports and when ready the changes will be moved to ubuntu/ubuntu-intrepid-ports. In theory this is how it works, still to get my changes approved and moved across.

Ben Collins is the guardian of kernel.ubuntu.com (a.k.a. zinc). To get your own tree there you need to convince him you’re serious and he can then get you a login setup. Expect this to take a while - until I had a login I made my own local builds and uploaded them to my website for review.

Once you have a login follow the instructions under the section titled “Developers with access to kernel.ubuntu.com” on the KernelGitGuide page to get your hosted tree setup.

What Next?

In the next few posts I will hopefully deal with building, cross-compiling, rebasing against new official upstream kernel releases, looking for PS3 specific fixes, testing, and (fingers crossed) hopefully record the process of getting an updated build into the repos.

One of the first things that needed doing was to update the bootloader (otheros.bld) as the old Gutsy one wasn’t able to boot Hardy’s kernel. Once this was achieved (thanks to some great mentoring by a very busy Colin Watson and others) I was able to upgrade to Hardy and start fire-fighting.

Unfortunately we weren’t able to fix things in time for Hardy’s first release. X was crashing and trying to choose the wrong video driver (both now fixed), and the Kernel (still) has a memory allocation problem (fix on the way). There are various other problems waiting to be resolved, and a few suggested features too, but we’ll get to them all in good time.

Although initially the plan was to try and have an installable/usable Hardy by 8.04.1 in July, I think focus will probably be on Intrepid from now on. Getting fixes back into critical components such as the kernel and X for Hardy in time would be tough as this is considered an “unmaintained port” in Hardy.

So far working on this project has been a great experience for me. I am gaining a very broad knowledge of all aspects of how Ubuntu works, and also how Linux works on the PS3. I highly recommend any folks who are using Ubuntu on PS3 and have Debian/Ubuntu dev experience please jump on the development mailing list and look out for ways to contribute.

A status update has just been posted to the dev list today. I’ve tried to outline as best as I can the current state of the project.

Thanks to everyone upstream, downstream (ubuntu-ps3-dev, ubuntu-x, kernel-team), and in the community who has helped out so far!

As well as blogging about general Ubuntu stuff I’ll also be talking about the Ubuntu PS3 Port project which I’m currently obsessed with.

I followed the instructions on PSUbuntu.com to install the port of 7.10 Gutsy Gibbon. The instructions are good but this is very early days for Linux on PS3; naturally there’s plenty of work still to do to smooth over the user experience. The Ubuntu builds for PS3 are maintained voluntarily by literally only 2 or 3 guys at Canonical, so it’s impressive it works as well as it does.

Setting up the screen resolution didn’t work quite as described - stopping gdm (the Gnome Display Manager) and setting the screen mode only changes the resolution for the current terminal not for the one which Xorg starts in, and if you specify a non-compatible mode your display may be a mess so you have to type blind to fix it (or better use the up/down cursor keys to access a previous working mode using shell history). Not a big deal for a techy but obviously could be quite a hurdle for your average punter. Anyway once the correct mode has been found setting up a script under /etc/event.d/ ensures it always boots into the desired mode.

Second issue was that the OS didn’t seem to be finding the ethernet network card. Luckily browsing the PSUbuntu Networking and Connectivity forum revealed the solution - disable NetworkManager and configure the network settings manually using the Gnome Network tool (or by editing /etc/network/interfaces directly if you know how). Seems NetworkManager doesn’t work quite right with the PS3 ethernet card yet.

Having got it up and running the next task was to choose a lighter desktop system than Gnome. I love Gnome but there’s only 256MB of RAM on the PS3 and the Gnome desktop on it’s own uses most of that so applications are likely to be swapped out to disk way to too quickly for my liking. There are some interesting instructions on the PSUbuntu forum which suggest all sorts of things like disabling the graphical login screen (gdm) and changing to use the Fluxbox window manager instead of the default Metacity, but I felt I wanted something less custom and more complete so I decided to install the Xfce desktop.

Xfce is the base of the XUbuntu distribution and is a lightweight Gtk based desktop system with its own window manager. It has some slick themes and also supports pretty features like transparency and drop shadows (using Xorg’s Composite extension). You can choose to install the entire XUbuntu default installation by installing the xubuntu-desktop package from Synaptic, but this will pull in all sorts of other peripheral tools such as the Abiword office suite. I didn’t need this stuff so I opted to install just the Xfce components by installing the xfce4 package.

Of course one thing which I want to take advantage of is the chance to experiment programming the amazing Cell Microprocessor. Included in the package repositories are the required development libraries and tools. Just search for the keyword ‘cell’ in Synaptic to find the relevant packages. There’s also a packaged copy of the Cell Programming Primer from kernel.org.

I happened to test out a Java game which uses Full Screen Exclusive Mode with a DisplayMode of 800×600. So far this app has been working ok on Feisty but when I tested it today on Gutsy it couldn’t change display mode. I discovered that Java was only able to see the current screen mode of 1280×1024 and no others.

I’ve opened a bug on Launchpad here: #154613: Java cannot change display modes / screen resolution in Gutsy, and I’ve been digging in trying to work out what’s going wrong.

I managed to locate the JNI function call in Java’s native C source code where it gets the list of modes. It’s called Java_sun_awt_X11GraphicsDevice_enumDisplayModes(...) and is in the file j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c. As expected the Ubuntu packages are built from the Sun Linux binaries - no source code. I couldn’t find the Java 6 source on Sun’s site, the link appears to be wrong. Instead I found the file in the Icedtea/OpenJDK source tree. Icedtea on Gutsy has the same problem so I’m fairly happy this is the the same or roughly the same code as in Java 6.

The function makes use of the XRandr Xorg extension to query the available display modes. I coded up a small test to see if XRandr was behaving correctly. It is, on both Gutsy and Feisty. So it looks like it could be something in Java 6 u3.

Will keep digging, as I really need this to work.