Today I encountered a bug that was quite difficult to find regarding strings. In order for strings to work they must be null-terminated, and this implies that an array of characters can contain a string with a length equal to the array size minus one, because there must be space for the null character. I found out that, when initializing array of chars with strings, the compiler does not complain if just the null character doesn’t fit.
Before I started playing with the BeagleBoard XM I’ve had never booted a board directly from an MMC card and I didn’t have a clue what an ‘MLO’ file was. After some research on the internet it seemed apparent that it was used in place of the traditional first stage boot loader: XLoader. In fact it in most cases it is XLoader – a quick invocation of my toolchain’s string implementation seemed to correlate with this:
$ arm-none-linux-gnueabi-strings /media/boot/MLO | grep X-Loader ()*+,-./0123456789:;< =>?Texas Instruments X-Loader 1.5.0 (Mar 27 2011 - 17:37:56) X-Loader hangs
I was curious as to why it was named MLO, how the board boots into this Image and how I can create my own MLO with some bare metal code. This post answers these questions and results in a very simple executable MLO file. It will probably satisfy those readers who like to understand and write all the code that runs on a board. It’s very easy to use a boot loader like UBoot to obtain and execute an image from an MMC card – but it adds boot time, duplication and complexity. Besides it’s fun to get close to the metal…
I recently decided to embark on writing my own C++ real-time operating system for embedded systems – I’ve so far made some progress using software emulation with QEMU but I feel it’s time to move on to real hardware. I’ve chosen to use the very popular BeagleBoard XM – mostly because it represents incredible value for money given but also due to it’s extensive user community.
This blog post provides an overview of the components required to get started with a BeagleBoard XM and JTAG emulator. I will also include my experience/rationale in selecting and buying the various components required (Board, JTAG Emulator, etc).
As a kernel developer you’ll probably find yourself treating the ‘printk’ function as a drop-in replacement for the ‘printf’ function provided by any useful C library such as uclibc or glibc – After all, it’s usage is virtually the same. It was for this reason that I found my self naively surprised when reading the source for the kernel’s implementation – I was surprised because it offers many more features than the typical C libraries’ implementation. As I was unable to find any useful documentation on this – I thought I’d provide a brief overview.
Let’s start with the typical ‘%p’ type format specifier – we usually use it for printing the address of a pointer. However if you take a peek at the ‘pointer’ function in lib/vsprintf.c you’ll notice that you can further specify the pointer type to print additional information. We’ll look at some examples.
printk("%pf %pF\n", ptr, ptr) will print:
module_start module_start+0x0/0x62 [hello]