Beagleboard: Designing the 2nd stage Bootloader (XLOADER)

One of the main functionality of this 2nd stage bootloader is to setup a basic Interrupt Vector Table to catch exceptions that might occur during the initial boot stages, setting up external SDRAM for early availability, basic console setup to track the boot progress and finally setting up stacks for all available ARM modes in preparation for a complete C runtime environment.
As there are no initialized segments or stacks available to run a C program, we will start with ARM assembly instructions for the first few steps.

We compile and link our loader image using the ARM GNU compiler toolchain for all development purposes here.
As soon as our program is loaded onto the board, we need to ensure that the control jumps to our program's entry point. We will label our entry point as '_start' as this is the most common entry point label generated by most of the compilers for any program, by default.
For any source file when being compiled and linked, we can notify the entry point of our code to the Linker using the directive ENTRY. So in our case, we write a linker script file called "PB.ld" and add the following directives:

OUTPUT_FORMAT ("elf32-littlearm")
OUTPUT_ARCH (arm)
ENTRY (_start)

Here the first directive OUTPUT_FORMAT notifies the linker that our file will be linked as an ELF32 executable, executed in LITTLE ENDIAN mode.
The second line OUTPUT_ARCH specifies that the file is to be linked in for an ARM architecture platform.
Finally, the third line, ENTRY specifies the label of entry point of our image to be _start.

To be continued.........

OMAP3530 Memory Map classification

STEP1: Beagle learns to crawl with its first stage XLOADER

Beagleboard comes preflashed with Xloader and U-Boot on the NAND. This can always be helpful during the early days of customised XLoader development, as I need not have to worry much about bricking my board. This is especially true sometimes, when I need to develop without any help from the JTAG.

But that also means that I should find some way of loading my loader onto the board and ensure it gets executed before the preflashed XLoader does. Since OMAPs can be re-ordered with its booting device sequences using certain hardware pins [sys_boot], such that I can change the boot device detections from NAND to UART/USB/MMC, I can get my loader copied onto the internal SRAM without much of a problem.

I decided to start off with UART booting method and thanks to Nishanth, who has developed a tool called pserial, I can download my images without any issues. The only requirement for booting loader from UART is to hold down the USER button on the Beagle and then powering up the board. When the board powers up, the bootrom code residing within the OMAP's internal ROM checks the sys_boot config pins to decide which boot devices must be scanned first. With the press of USER button, bootrom code detects that it must first check on USB/UART/MMC before falling back to the default NAND flash.

Customized Open Source software solution for Beagle

With the possession of my  newly acquired fanless embedded platform - The BeagleBoard incorporating state of the art ARM Cortex A8 based TI OMAP3530, I have started to work on a complete software solution customized for Beagle, based on the Linux OS.

The plan is to develop a simple bootloader, that would provide the required functionality of both 1st stage (XLDR) and the 2nd stage (U-Boot) bootloader in a single loader and support booting an ARM Linux OS.
At a secondary level, I envision to customize even the Linux OS specifically for Beagle, by removing unwanted/generalized code that mostly reside to support wide varieties of OMAP platforms, in order to obtain a swift running Linux OS.