Just to clear up on this front regarding how the i.MX boots: there is an internal boot ROM built into the mask of the SoC which contains some rudimentary boot code. It can perform the following tasks:
1) boot from any SPI-based ROM this actually includes any memory-based SD card as they are just 4-bit SPI buses as standard. Every SD card manufactured absolutely must be able to be accessed using 1-bit SPI access, per the SD Assoc. standard. Isn't that fun? 2) possibly boot from i2c-based EEPROMs 3) boot from the NAND flash controller (which we don't use) 4) boot from PATA or SATA (in MX53) 5) fall back to booting from a specially connected USB host connected to the OTG port (also we don't use) 6) fall back to booting from UART
It will pick the boot method from the BT_* pins on the board, which are usually hooked to DIPs or hardwired to ground or an appropriate pullup to enforce boot behavior. We support booting from SPI and SD card, and the 4th DIP switch on all the boards determines the "chipselect" (so, chipselect 0 for SPI is valid, but chipselect 1 for SPI would be the PMIC, which is a silly combination, and 0 or 1 for the 4th pin selects SD card slot, where on the Efika MX Smarttop 1.3 revision ("TO3") there is only one valid SD card slot).
There are various padding requirements for the ROM-based boot methods.
From SPI or SD card, it will load the i.MX DCD table from 1024 bytes
into the device. The same is true of PATA and SATA boot methods on MX53. This allows partitioning information to be skipped. From NAND flash I think it picks it up from 4096 bytes into the device (to correspond to a decent multiple of a NAND flash page, on top of the requirement to have a partition table or header in the first few bytes of flash).
Older U-Boots (like ours) padded u-boot.bin but newer U-Boots (mainline right now) do not, so the offset you flash to can either be 0 (ours, if you're dding to an SD card, seek=1 skip=1 bs=1024) or 1024 (skip=1 bs=1024 I think)
That's pretty much the down low of it..