ROM Code First

By Achim Nohl
Finally, nine months after the next-generation SoC project was kicked off, the first prototype board has finally arrived! There are just six months left to get Android and Linux up and running. Because Android should take full advantage of the latest hardware additions, let’s make sure we get it ported as quickly as possible.

Unfortunately, it’s not that easy. Before you can care about porting your OS and developing the drivers for your special hardware, you have to deal with the boring, but necessary, initialization of the hardware. This is typically done by a so-called boot monitor. A boot monitor is a software program in ROM that gets launched after pressing the power-on button on your hardware. Even though the boot monitor is not a large piece of software (compared to the OS, etc.), it provides complex functions and interacts with many hardware peripherals. As an example, the classic minimal functions of a boot loader are given below:

1. Start execution on external wake-up event (e.g., power-on)
2. Examine further hardware switches to configure the boot (e.g., debug/interactive mode on/off)
3. Provide a command line interface through a UART to enable interactive mode
4. Provide a USB device driver and SD card driver that allow the user to download his OS kernel image from his PC to an SD card
5. Provide NOR flash drivers in order to move the OS kernel from the SD card into the NOR flash memory where the main CPU can boot the OS from
6. Provide functions to update the boot monitor image in the EEPROM from an SD card
7. Initialize the memory controllers to allow the OS access to DRAM/SRAM
8. Initialize clocks and voltages
9. Handover boot parameters to a second-stage boot loader, hypervisor, secure OS or the main OS
10. Kick off the main CPU to boot the OS from a kernel image in NOR flash

Often, the boot monitor is not executed on the main CPU, but by a small companion controller. With the introduced functions, the boot monitor easily sums up to a few 100KB of highly platform-hardware-dependent source code. So the boot-up effort you thought you wouldn’t need to be concerned about when the first hardware sample board arrives now requires quite some development. Instead, you would prefer to start programming and validating the advanced features of your new product, such as the new GPU, but the hardware initialization step cannot be sidestepped.

Due to the complexity of ROM code development, and because this task is right in the critical path of your time-to-market window, it has evolved to become one of the main use cases for virtual prototyping. After the board arrives, our experience tells us that the bring-up and validation of the OS and higher-level software can start immediately (same day). The ROM code, which has been developed using a virtual prototype (VP), is sufficiently equipped and tested to no longer be a gating task for the main software bring-up.

Interestingly, VPs for ROM code development are relatively easy to build. The hardware peripherals that are used by the ROM code are, to a large extent, commodity peripherals, like UART, timer, clock generator, etc. Here, the necessary TLM models typically exist. Thus, the VP can be easily assembled using the available TLM models, and the respective driver development or porting can start.

Other important components are the various system configuration controllers needed to program the oscillators, voltage regulators, etc. Those models are not complex from a hardware perspective, as they mainly consist of configuration registers that drive certain signals on a configuration bus. However, they are tricky and complex to program. A bad configuration may prevent the system from booting or can even damage the board. Having a VP that models the effects of clock and voltage settings correctly is very helpful in verifying that the ROM code works on the hardware. Summarizing, the return on investment for using a VP has turned out to be relatively high for this type of software development.

The other advantage of using a VP in this early stage of a project is that a VP does not actually need ROM code to boot the OS. Many of the functions that are provided by the boot monitor, such as loading images into RAM/NOR flash, can be done instantly. As a result, a project dependency is broken and OS kernel porting can start simultaneously with ROM code development. We have seen our users booting Android just three days after the sample board has arrived.

After one year of blogging, this is my last post for “A View From the Top.” Going forward, my colleague Nithya Ruff will bring some fresh new thoughts and continue to post for this blog. Thank you for your interest and comments during the past year.