jk: blog

Yufeng Zhang has recently posted that support for the aarch64 architecture (ie., 64-bit ARMv8 processors) has now landed in the official binutils git repository. This code should make its way into the next release of binutils, version 2.23. The relevant commit is e7dff39c, the ChangeLog update is here.

Over the last couple of weeks I've been working on a set of secure-boot tools. Originally, this project was intended as a quick implementation of an EFI-image-signing utility, but it has since grown a little. I've now added code to help maintain the UEFI signature databases from within a running OS.

Now that we have a basic aarch64 toolchain, it's possible to build Catalin Marinas' aarch64 kernel tree.

Most of the components of the 64-bit ARM toolchain have been released, so I've put together some details on building a cross compiler for aarch64. At present, this is only binutils & compiler (ie, no libc), so is probably not useful for applications. However, I have a 64-bit ARM kernel building without any trouble.

A group of us at Canonical have been working on a document to define the technical requirements for firmware on machines that are to be preinstalled with Ubuntu. Our aim is to make it easier for OEMs and ODMs to configure their firmware to be compatible with Ubuntu.

[jk@pingu ~]$ mkdir ~/sshfs
[jk@pingu ~]$ afuse -o mount_template="sshfs %r:/ %m" \
                    -o unmount_template="fusermount -u -z %m" ~/sshfs/
[jk@pingu ~]$ cat ~/sshfs/ozlabs.org/etc/hostname
ozlabs
[jk@pingu ~]$ 

I've recently been doing some performance analysis work on Linux, which requires profiling various applications to see how they perform under load. One of the handy tools for profiling this behaviour is oprofile, but the output can be a little difficult to interpret.

In the previous article in this series, we finished with a parellel SPE-based fractal renderer. This article will cover some of the major optimisations we can do to make use of the Cell Broadband Engine.

In my previous post here, I mentioned that:

At present, the spufs code has the invariant that a context is only ever loaded to an SPE when it is being run; ie, a thread is calling the spu_run syscall on the context.