It’s new year’s eve and what better way to celebrate it than by printing out your own custom calendar for the next year (okay there are far, far better ways to celebrate new years eve, but this is how I’m doing it). My friend Lian Tze has created a LaTeX template that you can autogenerate a cool printable calendar from, and you can find it here.
All posts by -
I love having nice desktop wallpaper, mainly because a lot of jobs I’ve worked in involves me being stuck in windowless labs, and having a picture of mountains and streams on your desktop is somewhat of a substitute to having a nice view (a sad one, but you have to make do).
But the same wallpaper can also get pretty boring, so that’s why many desktop managers let you rotate your wallpapers from a set of images. But then, that set gets boring too, what if you could get a fresh wallpaper from the internet every few minutes?
A simple randomized pull from Flickr, for instance, would give you a nice new photo every refresh interval. Flickr has a web service API that lets you search and download publicly accessible photos (the Creative Commons licensed ones all permit this, for example), and a simple Python script could give you a new wallpaper every time it ran. Flickr has a search parameter that lets you return photos by a metric called “interestingness“, which is an algorithm based (at least partly) on how much other Flickr users liked or commented on a particular photo. The interestingness algorithm is basically crowd-sourced photo curation, and it works quite well; the top photos really are pretty stunning. You need a Flickr API key to use this service, but it’s free to request for one.
Are we just happy with random pulling from the top interesting photos though? Well, we could be, but we’re not going to stop there. As I was playing some of my favorite tunes from my music playlist, I thought to myself, “Why don’t I set the desktop wallpaper based on the mood and imagery that the current music was creating?”
So what does that entail? First, finding the lyrics of the song that’s playing, and picking out the key words or themes from it. Then, feeding these key words into Flickr’s search parameters and then grabbing the most interesting photo of what Flickr users’ interpretation of what those words might mean photographically. The lyrics part is easy, there’s a Python module that searches a lyrics wiki and returns the words to a song if you give it a title and artist.
The hardest part it seems, is the the natural language processing required to comprehend the meaning of a song. Now this is completely subjective, and using a machine to algorithmically do this is going to give you a lot of literal keywords. Getting a machine to understand songs and poetry remains a challenge in machine learning (depending on the song or poem, it can be a challenge even for human beings). But now our silly wallpaper script is getting a bit involved, so can we cheat on the machine learning part? Turns out we can, because IBM’s Watson has several public web services you can use, one of which is a text summarizer called Alchemy Language. The service will take a blob of text and return the top keywords, entities described in the text, and even emotions associated with said words. The accuracy of the emotions part leaves a lot to be desired, but the top keywords are useful tools to search Flickr with, so I used that to feed it into the image search, with some randomization. Again, you need an API key to use Alchemy Language, but signing up for one is free, just like Flickr.
Putting it all together, I hacked up a Python script, glued together by bits of Bash, that will get the current playing song from the MPD daemon (which I use to play music with), and from there is a chain of feeding web services, and feeding the output into yet more web services, until I get a nice picture inspired by the song. The full source code to the script (which at this point is really hacky) can be found on its own Github repo. I call it Wall of Sound, because I enjoy terrible wordplay. You can try it yourself, but you’ll need the Flickr and Alchemy Language keys, plus some hacking to suit your music playing and operating system arrangements.
How well does it work? I can say the results are always interesting, if not immediately obvious what the connection between the music and the picture is. Here are a some sample runs:
The Beatles – Here Comes The Sun
The algorithm chose to use the phrase “cold lonely winter”, and it came up with this picture:
In the picture it does look like the sun is coming up, but that is just a fortuitous coincidence. It’s a beautiful picture though, and a great desktop wallpaper.
“Keep Running” by Gemma Hayes is a great source of keywords; the song mentions several city names, and they are often chosen by the algorithm as important key words.
I got this picture when the script chose “Seoul”:
This is where the script failed to bring up a relevant picture. First, the Lyrics Wiki does not seem to have Aoife O’Donovan in their database, so whenever that happens the script just feeds the song title into Flickr, so we still have something to search with. In this case, “fire engine”.
However, Flickr returned this picture.
Not a fire engine, but still an awesome picture! So even when the script fails, it still succeeds!
Led Zeppelin – Stairway To Heaven
The script chose “gold” from “There’s a lady who’s sure all that glitters is gold”:
…and I got this. It seems appropriate somehow, just from that one word.
The current state of the script still needs a bit more error checking when searching Flickr (I’ll fix it when I have the time!), but it’s still mostly usable as it is.
We take a break from writing about computers to pay tribute to a fantastic TV show that has inspired generations of scientists and engineers because their imaginations were sparked by Star Trek. On this day 50 years ago, the first episode of Star Trek aired in the United States. Curiously it wasn’t the pilot that aired first, but the third episode entitled The Man Trap (it’s the one with the shape-shifting salt monster). When the series first aired, we didn’t have cell phones or iPads or Google. In 1966, we hadn’t even landed on the moon yet. However we saw it all first imagined on Star Trek. Thanks for the fun and inspiration, Gene Roddenberry and the cast, crew, writers and producers of all the Star Trek shows.
Ever wish you could inspect N number of bytes of memory starting from a certain address? Back in the day when I as a kid and was programming in BASIC on an Apple II, we had two BASIC instructions called PEEK and POKE, which seemed like witchcraft at the time; you used PEEK and POKE to load a magic number and stuff happened! Looking back on it now, they were just instructions to inspect and set values at addresses in memory.
Nowadays, using C, we can write out memory using printf which has a conversion character for hexadecimal, and usually people dump the more compact hex values. However, occasionally we want a bitwise dump of each byte and there’s no printf conversion for that. Therefore I find myself rewriting this over and over every time I need it, so I coded up a quick one and stuck it here for my own future reference. It’s really simple but you’re welcome to use it if you like, I hereby declare it public domain code.
void print_byte(const uint8_t x)
uint8_t mask = 0x01;
printf("%u", (x & (mask << (7-i)))!=0);
mask = 0x01;
void dump_memory(const void * mem, const size_t length)
uint8_t * byte_ptr;
byte_ptr = (uint8_t *)mem;
printf("%p:\t", (void *)byte_ptr);
char sentence = "Hello World";
dump_memory((void *)sentence, 12);
Before you go about peeking at addresses in memory, you need to make sure they’re mapped; otherwise you’d get a fault.
As I am writing my tiny toy operating system, I’ll document some of the things I discover as I am doing it. I’ll gloss over things that have answers better documented in places like the OSDev Wiki, but will go into little details that was non-obvious (to me) that I had to find out through trial and error, poring over documents and asking on irc.
So, where does one start to write an OS? We can choose to start at the very beginning: booting. Example code here is from the OS I am working on called Treehouse.
What happens when an x86 system boots? It powers on, loads up the bootup firmware (UEFI or BIOS), and from there it will load up a bootloader that will load your kernel. A bootloader can be a simple thing that just loads up your kernel which it finds on a specific place on disk, or it can be pretty sophisticated, performing hardware initialization, reading different filesystems, or presenting a user menu that lets you select a kernel to boot.
Intel machines boot in real mode, the legacy mode with no memory protection and a 20-bit address space that gets you a whopping 1MB of RAM. Why? “Historical reasons”, as real mode is rarely ever has any modern uses. We’ll need protected mode, which all current operating systems need for things like being able to use your entire address space, virtual memory, paging, etc. Now, we can switch to protected mode ourselves in our kernel, but it’s a way easier to just let a bootloader like Grub do it for you, and we can assume protected mode when the system gets handed over to our kernel. It’s a cheat but it makes life simpler, and dammit Jim, we’re writing a kernel not a bootloader.
The boot.S file is the first Treehouse code that the bootloader will call. Most of it is from the OSDev Wiki Bare Bones Tutorial, and it’s well documented over there but here I’ll attempt to explain the bits that it doesn’t explain which puzzled me. It’s written in AT&T syntax assembly and it’s pretty short so I’ll just plonk it down here:
# Boot.S taken mostly from the OSDEV wiki.
# Constants for the multiboot header
.set MULTIBOOT_ALIGN, 1<<0
.set MULTIBOOT_MEMINFO, 1<<1
.set MULTIBOOT_MAGIC, 0x1BADB002
.set MULTIBOOT_FLAGS, MULTIBOOT_ALIGN | MULTIBOOT_MEMINFO
.set MULTIBOOT_CHECKSUM, -(MULTIBOOT_MAGIC + MULTIBOOT_FLAGS)
# The multiboot header
.section .bootstrap_stack, "aw", @nobits
.skip 16384 # 16 KiB
.type _start, @function
movl $stack_top, %esp
.size _start, . - _start
Lines 4-8 are setting of symbols to expressions for the multiboot header, and the .set assembler directive works a little like #define in C, except instead of a search-and-replace it is actually assigning a value to the symbol, so it expects an expression there. Next, we plonk down the multiboot header in its own section, with the intent of putting that section in the very beginning of the binary in our link file. Sections are just named parts of the source which can be called anything you like, but depending on what you’re building you’re going to need a few “canonical” sections like .text (if you’re designing an executable), .data and .bss.
The next section is the bootstrap stack, which isn’t a “canonical” section in binaries, but the assembler lets you create any kind of section that you like for your own nefarious ends, and you can describe the properties of that section with attributes. A bootstrap stack is the stack you’re going to use while the kernel is bootstrapping itself. Code usually needs a stack for us to be able to do things like use stack variables and make function calls, so we’re going to have to reserve some space for it. For the attributes we use “aw” and @nobits. The “aw” means “allocatable and writable”. Writable (implies readable too) because you’d want to write to it (obviously) and allocatable means its loaded into memory at runtime. The @nobits is an attribute to indicate it’s not a section to be stored on disk but exists only at runtime and to be initialised to zeroes when starting up. The syntax is funky if you’ve never seen it before, but you won’t need to dabble with assembler syntax very much if you’re writing most of your code in C, like I’m doing here.
Next up is the .text section, which starts with the _start function, the literal starting point of execution for our kernel. As you can see, all it does is set up the address of stack_top and put it into the stack pointer register, push the EBX register onto the stack, and call the main function (kernel_main) which we’re going implement in C.
Now we don’t ever expect to return from kernel_main, but in the case it does, we have several failsafes; first is the cli and hlt instructions, which disables interrupts and halts the CPU, but in case that fails too I have an infinite loop there in the form of .failsafeloop.
Finally the last line sets the size of the _start symbol to current location minus the start, which is something from the OSDEV tutorial which will be useful further down when I do call tracing and debugging, so we’ll talk about it later when it comes up.
Next up, we’ll talk about the linker script!
I’ve been trying to make myself learn another programming language recently, because every problem is starting to look like a nail and my C compiler is the hammer. There’s been buzz around things like Rust, which is touted as a better language than C to do systems programming in. However I thought to myself, why not find a language with a completely different paradigm altogether? Functional languages, that sounds interesting!
So I started learning Haskell.
Haskell is named after mathematician Haskell Curry, who died in 1982 but has a sizable (and growing) fan club in the form of the functional programming community. His work on combinatory logic was the groundwork for functional programming; essentially eliminate the need for (mutable) variables, and work entirely with functions. Variables can be bound to a value, but it is then immutable; functions have no side effects in Haskell.
It’s only been a week, and I’m glimpsing into very unfamiliar territory. But it does feel like fun, so I’ll write about my Haskell journey from time to time!
I am currently trying to learn how to write an operating system, from scratch, for the fun of it. I have a few ARM boards, but I also want to get my hands on the Intel Edison, which is a 32-bit 500Mhz dual core Atom SoC designed for the internet of thingamajigs. It’ll be a while before I even get something usable running, but I’ve started to write a little kernel called Treehouse which you can follow the progress of on my Github page.
I don’t have a lot of time to work on it, so progress will be slow, but I would like to document what I do on this blog, mainly for my own records but if you’re interested you can try it out too. Currently you can run it within Qemu or Bochs, and it boots up and prints a little banner. You’ll need a baremetal 32-bit x86 compiler or cross-compiler (if you’re on something else, like amd64) to compile it.
If you’re writing your own kernel, you’ll need a compiler for it. The one that comes packaged with your Linux distribution may not cut it, because it’s not a baremetal or freestanding compiler; it expects a C library to be present. When you’re starting off your OS, there won’t be any C library to link to. You’ll need a baremetal compiler at this stage.
Obtaining The Compiler
There are a number of ways you can get yourself a compiler for building a kernel project, the simplest way is to find one already built for your system. However, it also isn’t too hard to build one from scratch and a number of guides exist on how to do this. The best of which is probably the OSDev Wiki guide, which worked flawlessly when I tried it today. If you’re building from scratch and assuming you want to use GCC as your compiler, you basically need the source code to the following:
- G++ (for building GCC)
- GNU Make
- GNU GMP
- GNU MPFR
- GNU MPC
There are optional things called Cloog and ISL which I left out, because they often aren’t synced up with the latest GCC. Also if you’re building on Ubuntu you’ll need to apt-get install the following packages: build-essential, bison, gawk, and texinfo.
You need one compiler for each instruction set architecture (ISA) you’re going to target for your operating system. I intend to target ARM but I am building on an x86 workstation, so I want an ARM cross compiler. The procedure is the same for any architecture you target, you simply need to be aware of the target triplet of the compiler your chosen architecture.
There is something that I learned about ARM target triplets which isn’t entirely clear from most guides; some have claimed there is no difference between “EABI” and “GNUEABI”. This isn’t true. The GNUEABI option expects a GNU C library to be present, whereas EABI is the one you want for baremetal kernel building. This post by Mark Mitchell about compiling U-Boot enlightened me on the differences between the two:
U-Boot is not a GNU/Linux application. However, you’re using the
GNU/Linux toolchain to compile it — so the libraries assume the
presence of a GNU/Linux C library. In this case, the division routine
wants to call “raise” to signal a division-by-zero exception.
People often try to abuse the GNU/Linux toolchain to build U-Boot
because they want to use the same toolchain that they use to build the
Linux kernel and GNU/Linux applications. But, U-Boot is really a
bare-metal application, and, as such, should be built with a bare-metal
toolchain, like our “ARM EABI” toolchains. There are often these kinds
of problems with U-Boot when moving between different architectures or
toolchain versions because the U-Boot source code has tricks to try to
make the GNU/Linux toolchain work, and those tricks only work with
Also, when you have your cross-compiler, you probably also want a cross GDB too for debugging. When compiling GDB you need to set the target triplet to match the one for your cross-compiler. That took me a while to figure out.
If you want the quick and dirty steps on compilation, here they are, ripped from the OSDev wiki.
../binutils-x.y.z/configure --target=$TARGET --prefix="$PREFIX" --with-sysroot --disable-nls --disable-werror
mv gmp-x.y.z gcc-x.y.z/gmp
mv mpfr-x.y.z gcc-x.y.z/mpfr
mv mpc-x.y.z gcc-x.y.z/mpc
../gcc-x.y.z/configure --target=$TARGET --prefix="$PREFIX" --disable-nls --enable-languages=c,c++ --without-headers
Hi, I’m Nur.
I like tinkering with computers, and occasionally I even manage to make them work.
The most fun you can have (IMHO) is figuring out how the machine works at the most fundamental software level: the operating system.
This blog is to write down the stuff I find out while I’m doing my tinkering, and share it. Who knows, it might be interesting and useful for someone else too.
Starting this year I am working on a number of little projects that will hopefully let me understand the inner workings of embedded ARM systems, among other things. In the following days I hope to write about my experiences writing systems code for two embedded boards: The Pandaboard and the Raspberry Pi.
Happy new year and happy hacking!