git rebase -x

My latest CToTW goes to Git – not because git is a new cool toy, but because of a new feature that has been added.

git rebase -x ‘make test’

Will interactively rebase your commits, but run tests, or commands on each commit. Stopping if a test fails to allow you to fix it up.

The guys over at github have done a far better write up than me, and they also highlight some of the great new changes in diffs:

gst-debug-viewer – The Gstreamer Log File Viewer

Have you ever worked with GStreamer? I mean really worked with Gstreamer, where you set GST_DEBUG=7 ….

The volume of data that comes out is immense. Useful, and not-useful at the same time. Until now, this moment when you discover there is a tool that helps you digest the verbosity.

gst-debug-viewer  is a tool which lets you browse the log file data, and visualise the output along a timeline. Errors and warnings are highlighted, and become easy to find.

It’s a python installation, so it’s easy to just “sudo ./ install”

Build Systems

Things I want from a buildsystem

  • Binary packages for most packages and hassle free base
  • SCM managed source integration for source packages
  • Kernel configuration management for multiple targets
  • QEMU/Virtualised testing of both development and environments
  • GDB integration to the virtual environment
  • NFS/TFTP support/integration where applicable.


Today’s Cool Toy of the Week is J-Core – the open implementation of SH cores. Jeff Dione, Rob Landley, and Rich Felker, along with a team of VHDL developers have been creating an open core implementation which can be run on a low-cost FPGA board, or processed to silicon using under-utilised fab’s without licensing fees.

Tracking power state changes

My laptop has decided to find itself in the habit of waking up in the middle of the night. You’d think that as it’s nearly 2 now – it would have learnt to sleep right through – but no. It just won’t (always) sleep when it’s supposed to.

At times, I have put my HP to sleep, let it rest in my laptop back-pack – and having arrived at my destination – come to find that it has woken up, mid-transport – and has got itself all hot and bothered by being awake in a confined space. Not useful. Not good at all.

To start to track down this issue, we can look at /sys/kernel/debug/wakeup_sources, but I’m not interested in it’s current state. I’m interested in seeing the differences, and also determining when it is waking up. (Hours can go by in the night while I sleep myself of course)

To that end, I pulled together a quick and simple script to cp the wakeup_sources file, and store it in git. This gives me timestamps, of when the file is updated, and the ability to see the differences between each commit easily using the existing gitk/git diff tools.

cd /home/kbingham/wakeup
# Obtain the latest debug content
cp /sys/kernel/debug/wakeup_sources .
# Then add and commit it to the git history, passing $* to the commit log
git add .
git commit -m "Update wakeup source file $*"
git show

Simple but effective … when it is called at the right times! Having pm-utils installed, I believed I could link this script into /etc/pm/power.d, or sleep.d – however I hadn’t realised that systemd has now taken over my suspend resume script hooks – so PM-Utils is no longer effective here. (Leaving me confused as to why the directories are still there in my distribution, however I suspect they are remnants of upgrade cycles)

So, new-world-order suspend-resume scripts are still just as easy. Perhaps more so – as systemd does not use any c-like sorted ordering – but simply executes all scripts in /lib/systemd/system-sleep in parallel

With my script above linked in to the system-sleep directory, I now have automated logging in git – of the content changes to my wakeup_sources file. Hopefully I’ll be able to identify any patterns that arise from when the wakeups occur, or what the wakeup source actually was.

Debugging the Linux Kernel with GDB

At the Embedded Linux Conference – San Diego this week, I feel privilidged to have been able to give a talk on some of the work I’ve been doing recently.

If you’ve come here looking for my slides, you’ll find them at DebuggingtheLinuxKernelwithGDB.pdf. You can find out more about the Embedded Linux Conference at the Linux foundation event page

Update: Video now online

A quick disclaimer – this was my first public presentation. I think I did ok – but I certainly want to improve my presentation skills. At least I’ve started!

You can find the links to the rest of the presentations from San Diego ELC 2016  at

Git –to-cmd

Hrm … a new cool toy of the week for me!

When sending patches to LKML, one should ensure that the patches have any maintainers on the To: line of the e-mails.
An effective way to ensure/automate this is to pass get_maintainer into git-send-email using the –to-cmd.
git send-email patches/* --to-cmd 'scripts/ --no-git-fallback'
This automagically adds the appropriate e-mails and mailinglists to the e-mail targets for you!

It looks like git-send-email filters out the duplicates, which is also nice. The –no-git-fallback is needed, as otherwise will add anyone who’s ever touched the file that you are modifying to the destination list!

FastLED Scale8 optimisation and improvements

I’ve been following the work done on the FastLED project recently, and really enjoyed Daniel Garcia’s write up of the improvements he has made to his scale8 function.

The speed of modern computers makes it easy to forget how when working with embedded systems, saving clock cycles really can make a difference.

And as he posted it as a ‘gist’ it appears it embeds into wordpress directly: So for clarity, the following is neither my work, nor words!

Continue reading FastLED Scale8 optimisation and improvements

NFS Root on QEmu with Debian/Ubuntu

I’m surprised there aren’t more pages out there that match these keywords. Why? because I wanted to boot a Linux Kernel, with an NFS Root filesystem, inside QEmu on an Ubuntu based platform.

Why is this important? because it doesn’t work by default.

QEmu uses TCP ports > 1024, because it runs as non-root … and NFS Server in its secure wisdom prevents accesses from ports above 1024 by default.

/opt/STM/STLinux-2.4/devkit/armv7/target *(rw,sync,no_subtree_check,no_root_squash)

What this means however is that the kernel will not mount the filesystem. Nor will it give you much reason; and considering you already know that your NFS Server is working (you can boot a real device after all) you will pull your hair out believing that the kernel running in the Qemu is misconfigured.

Not so – You need to tell your NFS server to be ‘insecure’; that is to allow it to accept connections from user based ports. Try something like the following

/opt/STM/STLinux-2.4/devkit/armv7/target *(rw,sync,no_subtree_check,no_root_squash,insecure

Now you just need to go glue your hair back in place…