some thoughts on writing boot code for omap

This following post is based on a reply I send to Vishal Bhoj, thought I'd share with all..
In general before starting, I suggest one does read the TRM and Data Manual pretty well.
If you are starting from scratch, it may not be quick to get things running on OMAP,but the basics are same no matter which OMAP you do take.. Unfortunately, I don't think I could start explaining the entire OMAP architecture even if I wanted to.. :( I am not saying it is an herculean task doing a boot code, but it is challenging and is a good way to start really know OMAP's potential. The question was related to UART and character LCD on SDP2430/3430, and the following is a very very brief overview of what to think of as a starter..

Some basic Fundamentals:

OMAP is a SOC (System On Chip) -containing ARM, DSP and other peripherals.
ARM has a memory mapped interface to it's peripherals it can talk to.
UART is one such peripheral,
character LCD on SDP2430 on the other hand is emulated over FPGA on the board. So, you need to look at how to talk to FPGA from ARM.

Now, every peripheral has a few basic stuff:
a) Basic clocks: Interface clock -> clock to enable register access, functional clock -> clock for it's functionality.
b) Another generic stuff is called pin muxing -> OMAP has hundreds of peripherals with tons of possible pins flowing out.. so the logic is simplified by muxing multiple pins to a single pin out and OMAP allows configuration of which pin you want in what mode.

Note: the above is the bare minimum stuff you need to take care, there
may be more per peripheral.

So when you boot up you need to get your clocks right(to make the module functional) and also the pin muxing right if you intend to talk to the world outside OMAP. Now every peripheral has it's own internal methodology of programming and operation.. + you may have specific needs
of power and timing -> esp when you speak with the peripherals outside of OMAP. Remember OMAP is designed to talk to as many things as possible, so you'd need to configure things as per the device you want to.. usually one-size-fits all is not optimal esp in the embedded
world.. so you'd need to tweak timings..

You also need to remember what you need to do when your code gets control - esp while you boot up. what things are active and can cause a reset(e.g. watchdogs), where are you booting from -> sram, NOR, NAND, sdram etc.. things are bit different and constraints different for a
boot code..

If you intend to write boot code, you need to understand the hardware pretty well.. it usually a mite tougher to write a boot code from scratch compared to writing a simple driver once everything is setup and you just need to call apis to get things done..

So, U-Boot, X-Loader might be good places to look at, but dont stop there.. you could write your own boot loader.. or even port something like grub, lilo or anything out there.. doing it is fun.. but getting it to work and be stable gives an even high level of exhilaration..

happy hunting.. Remember in boot code, most things are logical.. so knowing the hardware as well as your code is of equal importance :)...