Arch Linux – Finally!!!!

I have tried Ubuntu 10.04, Ubuntu 11.10, Ubuntu 12.04, Debian Squeeze, Mint Maya and Fedora. Of these, i have enjoyed Mint Maya the most. I got pissed with the Unity interface and though Mint was super nice, i wanted something more to fiddle with. Having heard of Arch and Gentoo being the two distributions which are toughest to install, but, customizable exactly the way one wants it, i decided to try one of these.

I surfed the net for a while trying to find which one will suit my need. Gentoo was super customizable, but, then i don’t want to spent hours on customization. I decided to go with Arch Linux. When i checked out, 2011.08.19 was available and i started with that. After trying around five different times in the last three months, i gave up. Kept having problems with pacman update and glibc. I tried 2012.08.04 when it became available, but, i got problems with grub after rebooting.

Just recently, 2012.09.07 became available and i decided to try this out. Followed the instructions given here https://wiki.archlinux.org/index.php/Beginners%27_Guide to the letter. And viola, i successfully booted in Arch Linux. And it boots well even with just 256MB RAM allotted to it in VM. Took XFCE for a spin and gonna check out KDE along with Cinnamon and Mate as well.

Arch was not so tough to install after all. One just has to follow the instructions. Next step is to see if i can contribute to Arch Linux in any way.

A little something on Linux Device Drivers

I have been struggling for a while now, trying to learn device drivers and system programming in Linux. One of the many questions i had was, how does the CPU using the Linux kernel know, which devices are present and what are the drivers for them. The answer to this question is through “Platform Device and Platform Data”. Though soon enough, you may find them obsolete as Linux very well might completely start using Device Trees. Below, are a few links from which you can learn about the Platform Device API and Device Tree.

http://lwn.net/Articles/448499/

http://lxr.free-electrons.com/source/Documentation/driver-model/

http://www.devicetree.org/Device_Tree_Usage

You will find extra information at http://lxr.free-electrons.com/source/Documentation/ under various sub divisions. For example, check out http://lxr.free-electrons.com/source/Documentation/i2c/writing-clients and  http://lxr.free-electrons.com/source/Documentation/i2c/instantiating-devices

What is MLO file?

I have had the Beagle-xM for a while now. If you have worked on it, you must have noticed the MLO file, which is required to be present in the boot partition of the Micro SD card. The file is necessary for booting the system. So ever wondered, what is this MLO file? No? What are you doing with the Beagle-xM anyways? Yes? Well, then read on.

As far as i know, all TI SOC’s like DM368 and DM3730 (on which i have worked) have a ROM bootloader. On sytem start up or reset, the ROM bootloader (RBL) starts running. The job of this RBL, is to do some very bare minimum initialisation and then find and boot from a device such as MMC card or flash. The RBL has got the capability to boot from a variety of devices like NOR flash, NAND flash, MMC, USB or UART. To know everything in detail, read the 26th chapter of the DM3730 Technical Reference Manual having the TI document number SPRUGN4N.

Now, how does the chip know which device to boot from you ask?. The chip has got a set of pins, sys_boot[4:0] pins, whose state decides what memory or peripheral to boot from. Also, there is a predefined booting order in the case of both memory booting or peripheral booting. For example, let’s say the state of sys_boot[4:0] pins is 0b01110. Then, the booting order will be XIPwait, DOC, USB, UART3 and finally MMC1. XIPwait is Execute in Place memory with wait monitoring and DOC is DiskOnChip memory. You can find this information on Page 3549 of the DM3730 TRM.

In the case of Beagle-xM, the state of the sys_boot pins cause it to boot from the MMC card at the start. As a result, on power on, the ROM will initialise the SD/MMC device, detect a card and look for a boot image. The ROM is capable of reading from the card with a filesystem. It will search for a file named MLO which should be located on the boot partition, on a partition of type FAT16/32. So, this explains the name MLO.

Now, let’s talk about the flow of control. The sys_boot pins specify where the first external boot loader MLO can be found. After the MLO is located and executed, it passes the control to the second external boot loader viz. uboot. Have you seen the uboot.bin file in the boot partition of the micro SD card? No? Jeez, have you been sleeping? U-boot is the application which passes control to the Linux system.  The main goal of u-boot is to retrieve the Linux kernel and provide the kernel with information about the location of the Linux filesystem.  U-boot can be configured to retrieve the kernel from a variety of options like NFS or flash. U-boot then boots the Linux kernel.  The Linux kernel mounts the Linux root filesystem.

In case, you are interested further in knowing the boot sequence, below is a link, which describes the boot sequence. http://blog.techveda.org/ . It uses AT91RM9200 as the reference, but, still should be very informative enough. Also, you can use this link http://lxr.free-electrons.com/ to browse the source.

Hope you found this “What is MLO file?” post informative.

Addendum: Mikkel Nielsen shared quite a few important links and had this to quote. You can also find this in the comments.

Think it could also be Memory LOader, as it is a file containing (apart from metadata) binary code that is loaded directly into internel SoC memory.

TI also refers to it as X-loader; http://processors.wiki.ti.com/index.php/Boot_Sequence.

This suggests it is short for Memory LOcator; https://groups.google.com/forum/#!msg/beagleboard/M-ew_WGjE_A/W2OerOFV3yYJ

Some history about why it is like that here; http://lists.denx.de/pipermail/u-boot/2013-December/168481.html.