Pfc - Julio Merino (jmmv.dev)

Degree completed

After five years of intensive work, I've finally completed my degree in Informatics Engineering (I think Computer Science is a valid synonym for that) at the FIB Faculty. This has concluded today after I defended my PFC, the project that concludes the degree. So you can now call me engineer :-) Yay!

In other words: I'm free until October, when I'll start a Masters in Computer Architecture, Networks and Systems (CANS). Time to work intensively on SoC!

July 6, 2007 · Tags: pfc
Continue reading (about 1 minute)

PFC report almost ready

The deadline for my PFC (the project that will conclude my computer science degree) is approaching. I have to hand out the final report next week and present the project on July 6th. Its title is "Efficient resource management in heterogeneous multiprocessor systems" and its basic goal is to inspect the poor management of such machines in current operating systems and how this situation could be improved in the future.

Our specific case study has been the Cell processor, the PlayStation 3 and Linux, as these form a clear example of an heterogeneous multiprocessor system that may become widespread due to its relatively cheap price and the attractive features (gaming, multimedia playback, etc.) it provides to a "home user".

Most of the project has been an analysis of the current state of the art and the proposal of ideas at an abstract level. Due to timing constraints and the complexity of the subject (should I also mention bad planning?), I have been unable to implement most of them even though I wanted to do so at the very beginning. The code I've done is so crappy that I won't be sharing it anytime soon, but if there is interest I might clean it up (I mean, rewrite it from the ground up) and publish it to a wider audience.

Anyway, to the real point of this post. I've published an almost definitive copy of the final report so that you can take a look at it if you want to. I will certainly welcome any comments you have, be it mentioning bugs, typos, wrong explanOctations or anything! Feel free to post them as comments here or to send me a mail, but do so before next Monday as that's the deadline for printing. Many thanks in advance if you take the time to do a quick review!

(And yes... this means I'll be completely free from now on to work on my SoC project, which is being delayed too much already...)

Edit (Oct 17th): Moved the report in the server; fixed the link here.

June 19, 2007 · Tags: cell, linux, pfc, ps3
Continue reading (about 2 minutes)

Piled Higher and Deeper

I've been told today about the Piled Higher and Deeper website, also known as phdcomics (easier to remember). And so far I'm hooked. I love this comic strip! May it be because I'm already involved in the research area due to my PFC and I know what they are talking about? Possibly. And it also illustrates what I can "expect" if I finally enroll in a Ph.D. course.

May 24, 2007 · Tags: pfc, phd, research
Continue reading (about 1 minute)

Building an updated kernel for the PS3

The mainstream Linux sources have some support for the PlayStation 3, but it is marked as incomplete. Trying to boot such a kernel results in a stalled machine, as the kernel configuration option says:

CONFIG_PPC_PS3: This option enables support for the Sony PS3 game console and other platforms using the PS3 hypervisor. Support for this platform is not yet complete, so enabling this will not result in a bootable kernel on a PS3 system.

To make things easier, I'd simply have used the Linux sources provided by YellowDog Linux 5 (YDL5), which correspond to a modified 2.6.16 kernel. However, as I have to do some kernel development on this platform, I objected to using such old sources: when developing for an open source project, it is much better to use the development branch of the code — if available — because custom changes will remain synchronized with mainstream changes. This means that, if those changes are accepted by the maintainers, it will be a lot easier to later merge them with the upstream code.

So, after a bit of fiddling, I found the public kernel branch used to develop for the PS3. It is named ps3-linux, is maintained by Geoff Levand and can be found in the kernel's git repository under the project linux/kernel/git/geoff/ps3-linux.git.
Fetching the code was "interesting". I was (and still am) a novice to git, but fortunately my prior experiences with CVS, Subversion and specially Monotone helped to understand what was going on.

Let's now see how to fetch the code, cross-build a custom kernel and install it on the PS3 using YDL5.

To checkout the latest code, which at this moment corresponds to a patched Linux 2.6.21-rc3 sources, do this:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git ps3-linux

This will clone the ps3-linux project from the main repository and leave it in a directory with the same name. You can keep it up to date by running git pull within the directory, but I'm not going to talk about git any more today.

As I cross-compile the PS3 kernel from a FC6 Intel-based machine with the Cell SDK 2.0, I need to tell it which is the target platform and which is the cross-compiler before being able to build or even configure a kernel. I manually add these lines to the top-level Makefile, but setting them in the environment should work too:

ARCH=powerpc CROSS_COMPILE=ppu-

Now you can create a sample configuration file by executing the following command inside the tree:

$ make ps3_defconfig

Then proceed to modify the default configuration to your likings. To ease development, I want my kernels to be as small and easy to install as possible; this reduces the test-build-install-reboot cycle to the minimum (well, not exactly; see below). Therefore I disable all stuff I do not need, which includes modules support. Why? Keeping all the code in a single image will make later installation a lot easier.

Once the kernel is configured, it is time to build it. But before doing so you need to install a helper utility used by the PS3 build code: the Device Tree Compiler (or dtc). Fetch its sources from the git repository that appears in that page, run make to build it and manually install the dtc binary into /usr/local/bin.

With the above done, just run make and wait until your kernel is built. Then copy the resulting vmlinux file to your PS3; I put mine in /boot/vmlinux-jmerino to keep its name version-agnostic and specific to my user account. Note that I do not have to mess with modules as I disabled them; otherwise I'd have to copy them all to the machine — or alternatively set up a NFS root for simplicity as described in Geoff Levand's HOWTO.

To boot the kernel, you should know that the PS3 uses the kboot boot loader, a minimal Linux system that chainloads another Linux system by means of the kexec functionality. It is very powerful, but the documentation is scarce. Your best bet is to mimic the entries already present in the file. With this in mind, I added the following line to /etc/kboot.conf:

jmerino='/dev/sda1:/vmlinux-jmerino root=/dev/sda2 init=/sbin/init 4'

I'd much rather fetch the kernel from a TFTP server, but I have not got this to work yet. Anyway, note that the above line does not specify an initrd image, although all the other entries in the file do. I did this on purpose: the less magic in the boot, the better. However, bypassing the initrd results in a failed boot with:

Warning: Unable to open an initial console.

This is because the /dev directory on the root partition is unpopulated, as YDL5 uses udev. Hence the need for an initrd image. Getting a workaround for this is trivial though: just create the minimum necessary devices on the disk — "below udev" —, as shown below.

# mount --bind / /mnt # MAKEDEV -d /mnt/dev console zero null # umount /mnt

And that's it! Your new, fresh and custom kernel is ready to be executed. Reboot the PS3, wait for the kboot prompt and type your configuration name (jmerino in my case). If all goes fine, the kernel should boot and then start userland initialization.

Thanks go to the guys at the cbe-oss-dev mailing list for helping me in building the kernel and solving the missing console problem.

Update (23:01): Added a link to a NFS-root tutorial.

March 16, 2007 · Tags: linux, pfc, ps3, yellowdog
Continue reading (about 5 minutes)

Building the libspe2 on the PS3

The Linux kernel, when built for a Cell-based platform, provides the spufs pseudo-file system that allows userland applications to interact with the Synergistic Processing Engines (SPEs). However, this interface is too low-level to be useful for application-level programs and hence another level of abstraction is provided over it through the libspe library.

There are two versions of the libspe:

1.x: Distributed as part of the Cell SDK 2.0, is the most widely used nowadays by applications designed to run on the Cell architecture.
2.x: A rewrite of the library that provides a better and cleaner interface — e.g. less black boxes —, but which is currently distributed for evaluation and testing purposes. Further development will happen on this version, so I needed to have it available.

The YellowDog Linux 5.0 (YDL5) distribution for the PlayStation 3 only provides an SRPM package for the 1.x version, but there is no support for 2.x. Fortunately, installing the libspe2 is trivial if you use the appropriate binary packages provided by BSC, but things get interesting if you try to build it from sources. As I need to inspect its code and do some changes in it, I have to be able to rebuild its code, so I had to go with the latter option.

Let's see how to build and install libspe2 from sources on a PS3 running YDL5.

The first step is to download the most up-to-date SRPM package for the libspe2, which at the time of this writing was libspe2-2.0.1-1.src.rpm. Once downloaded, install it on the system:

# rpm -i libspe2-2.0.1-1.src.rpm

The above command leaves the original source tarball, any necessary patches and the spec file all properly laid out inside the /usr/src/yellowdog hierarchy.

Now, before we can build the libspe2 package, we need to fulfill two requisites. The first is the installation of quilt (for which no binary package exists in the YDL5 repositories), a required tool in libspe2's build process. The second is the updating of bash to a newer version, as the one distributed in YDL5 has a quoting bug that prevents quilt from being built properly.

The easiest way to solve these problems is to look for the corresponding SRPM packages for quilt and an updated bash. As YDL5 is based on Fedora Core, a safe bet is to fetch the necessary files from the Fedora Core 6 (FC6) repositories; these were: quilt-0.46-1.fc6.src.rpm and bash-3.1-16.1.src.rpm. After that, proceed with their installation as shown above for libspe2 (using rpm -i).

With all the sources in place, it is time to build and install them in the right order. Luckily the FC6 SRPMs we need work fine in YDL5, but this might not be true for other packages. Here is what to do:

# cd /usr/src/yellowdog/SRPMS # rpmbuild -ba --target=ppc bash.spec # rpm -U ../RPMS/ppc/bash-3.1-16.1.ppc.rpm # rpmbuild -ba --target=ppc quilt.spec # rpm -i ../RPMS/ppc/quilt-0.46-1.ppc.rpm # rpmbuild -ba libspe2.spec # rpm -i ../RPMS/ppc64/libspe2-2.0.1-1.ppc64.rpm # rpm -i ../RPMS/ppc64/libspe2-devel-2.0.1-1.ppc64.rpm

And that's it! libspe2 is now installed and ready to be used. Of course, with the build requisites in place, you compile libspe2 in your home directory for testing purposes by using the tar.gz package instead of the SRPM.

At last, complete the installation by adding the elfspe2-2.0.1-1.ppc.rpm package to the mix.

March 14, 2007 · Tags: cell, pfc, ps3, yellowdog
Continue reading (about 3 minutes)

PFC subject chosen

A while ago, I was doubtful about the subject of my undergraduate thesis (or PFC as we call it). At first, I wanted to work on a regression testing framework for NetBSD. This is something I really want to see done and I'd work on it if I had enough free time now... Unfortunately, it didn't fit quite well my expectations for the PFC: it was a project not related at all with the current research subjects in my faculty, hence it was not appropriate enough to integrate into one of these work groups.

So, after inverstigating some of the projects proposed by these research groups, I've finally settled on one that revolves around heterogeneous multiprocessor systems such as the Cell Broadband Engine. The resulting code will be based on Linux as it is the main (only?) platform for Cell development, but the concepts should still be applicable to other systems. Who knows, maybe I'll end up trying to port NetBSD to a Cell machine — shouldn't be too hard if that G5 support is integrated ;-)

The preliminary title: Efficient resource management in heterogeneous multiprocessor systems. For more details, check out the Project proposal (still not concreted, as you can see).

January 27, 2007 · Tags: cell, pfc
Continue reading (about 1 minute)

A subject for my undergraduate thesis

It has finally come the time when I have to choose a subject for my undergraduate thesis on which I'll be working on full time next semester. My first idea was to make a contribution to NetBSD by developing an automated testing framework. I have had interest in this for a long while (I even proposed it as part of this year's SoC), and there is a lot of interest in it within the project too.

However, this specific project does not fit correctly into the current research groups at my faculty. This wouldn't be a problem if I wasn't thinking in taking a CS Master or Ph.D. later on. But as I'm seriously considering this possibility, it'd be better if I worked on a project that lets me integrate into an existing research group as early as possible. This could also teach me several new stuff that I'd not learn otherwise: if you look at the paper linked above, you can see I already have several ideas for the testing framework. That is, I already know how I'd address most of it, hence there'd not be a lot of "research". Furthermore, the teacher I talked to about this project felt the core of the project could not be long enough to cover a full semester.

So what are the other possible ideas? I went to talk to a teacher that currently directs some of the research groups and he proposed me several ideas, organized in three areas:

Code analysis and optimization: Here I'd work on tools to analyze existing code and binaries to understand how they work internally; this way one could later generate a better binary by reorganizing related code and/or removing dead bits. They already have done a lot of work on this subject, so I'd be working on a tiny part of it. No matter what, dealing with the compiler/linker and the resulting binaries sounds quite well.

Improve heterogeneous multiprocessor support: This group contains ideas to improve the management of heterogeneous systems such as those based on the Cell processor. I'm "afraid" any project here would be completely Linux-based, but the background idea also feels interesting. Haven't got too much details yet, though.

Distributed systems: This doesn't interest me as much as the other two, but this may be because there was not enough time during the meeting to learn about this group. However, next week we are taking a guided visit to the BSC which will hopefully clear some of my doubts and let me decide if I'm really interested in this area.

I shall make a decision as soon as possible, but this is hard!

Oh, and don't worry about the testing framework project. I'll try to work on this in my spare time because I feel it's something NetBSD really needs and I'm sure I'll enjoy coding it. Not to mention that nowadays, whenever I try to apply any fix to the tree, I feel I should be adding some regression test for it! Plus... I already have a tiny, tiny bit of code :-)

December 15, 2006 · Tags: netbsd, pfc
Continue reading (about 3 minutes)