In my last post we looked at the basic theory of an MMU and what it can do for us. In this post we are going to produce and understand the absolute minimum amount of code required (just 20 lines of assembler) to turn on an ARM MMU and come out the other side in one piece.
In my last post I wrote some bare metal code which ran on a BeagleBoard xM as an MLO – I’d like to extend this by running this code with the MMU switched on. I want to write the absolute minimum amount of code required to turn on an ARM MMU and to come out the other side in one piece. This post describes the basic principles of operation of an MMU – we’ll come on to writing code in my next post.
One of the most fundamental tasks of an MMU is to translate virtual addresses into physical addresses. How virtual addresses map onto physical addresses is entirely a matter of software design – the ARM MMU design provides great flexibility for helping you in this area. Just to illustrate this and to demonstrate the capability of these MMUs, I’ve come up with some perfectly valid schemes (though some of which at first may seem nonsensical):
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…
In my last blog post I described my rationale for buying a BeagleBoard XM and a compatible JTAG emulator – the XDS100v2. This post follows on from that and describes the steps required for setting up TI’s Code Composer Studio such that you can use the XDS100v2 with the BeagleBoard XM to find out what the board is doing.
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).