StartUp Entry Point and Main Function
The StartUp entry point of the boot loader must be located in linear memory at the address where the CPU begins fetching code for execution because this routine carries out the initialization of the hardware. If the adaptation is based on a reference BSP for the same processor chipset, then most of the CPU-related and memory controller-related code can remain unchanged. On the other hand, if the CPU architecture is different, you must adapt the startup routine to perform the following tasks:
1. Put the CPU in the right mode.
2. Disable all interrupts.
3. Initialize the memory controller.
4. Setup caches, Translation Lookaside Buffers (TLBs), and Memory Management Unit (MMU).
5. Copy the boot loader from flash memory into RAM for faster execution.
6. Jump to the C code in the main function.
The StartUp routine eventually calls the main function of the boot loader, and if the boot loader is based on BLCOMMON, then this function in turn calls BootLoaderMain, which initializes the download transport by calling OEM platform functions. The advantage of using the standard libraries provided by Microsoft is that the modifications required to adapt a BSP to a new hardware platform are componentized, isolated, and minimized.
Serial Debug Output
The next step in the boot loader adaptation is the initialization of the serial debug output. This is an important part of the boot process because it enables the user to interact with the boot loader and the developer to analyze debug messages, as discussed in Chapter 4, "Debugging and Testing the System."
Table 5-2 lists the OEM platform functions required to support serial debug output in the boot loader.
Table 5-2 Serial debug output functions
| Function | Description |
|---|---|
| OEMDebugInit | Initializes the UART on the platform. |
| OEMWriteDebugString | Writes a string to the debug UART. |
| OEMWriteDebugByte | Writes a byte to the debug UART, used by OEMWriteDebugString. |
| OEMReadDebugByte | Reads a byte from the debug UART. |
Platform Initialization
Once the CPU and the debug serial output are initialized, you can turn your attention to the remaining hardware initialization tasks. The OEMPlatformInit routine performs these remaining tasks, including:
■ Initializing the real-time clock.
■ Setting up external memory, particularly flash memory.
■ Initializing the network controller.
Downloading via Ethernet
If the hardware platform includes a network controller, then the boot loader can download the run-time image over Ethernet. Table 5-3 lists the functions that you must implement to support Ethernet-based communication.
Table 5-3 Ethernet support functions
| Function | Description |
|---|---|
| OEMReadData | Reads data from the transport for downloading. |
| OEMEthGetFrame | Reads data from the NIC using function pointer pfnEDbgGetFrame. |
| OEMEthSendFrame | Writes data to the NIC using function pointer pfnEDbfSendFrame. |
| OEMEthGetSecs | Returns number of seconds passed relative to a fixed time. |
The Ethernet support functions use callbacks into network controller-specific routines. This means that you must implement additional routines and set up appropriate function pointers in the OEMPlatformInit function if you want to support a different network controller, as demonstrated in the following sample code:
cAdaptType=pBootArgs->ucEdbgAdapterType;
// Set up EDBG driver callbacks based on
// Ethernet controller type.
switch (cAdaptType) {
case EDBG_ADAPTER_NE2000:
pfnEDbgInit = NE2000Init;
pfnEDbgInitDMABuffer = NULL;
pfnEDbgGetFrame = NE2000GetFrame;
pfnEDbgSendFrame = NE2000SendFrame;
break;
case EDBG_ADAPTER_DP83815:
pfnEDbgInit = DP83815Init;
pfnEDbgInitDMABuffer = DP83815InitDMABuffer;
pfnEDbgGetFrame = DP83815GetFrame;
...
}
Flash Memory Support
Having implemented network communication capabilities, you also must enable the boot loader to download run-time image onto the new hardware platform and pass control to it. Alternately, you can save the run-time image to flash memory. Table 5-4 lists the download and flash memory support functions that you must implement for this purpose if the reference BSP's boot loader does not already support these features.
Table 5-4 Functions for supporting download and flash memory
| Function | Description |
|---|---|
| OEMPreDownload | Sets up the necessary download protocol supported by platform builder. |
| OEMIsFlashAddr | Checks if the image is for flash or RAM. |
| OEMMapMemAddr | Performs temporary remapping of the image to RAM. |
| OEMStartEraseFlash | Prepares to erase flash of enough size to fit the OS image. |
| OEMContinueEraseFlash | Continue erasing flash based on download progress. |
| OEMFinishEraseFlash | Complete the flash erasing once the download is done. |
| OEMWriteFlash | Write OS image to flash. |