BSP Developer's Guide

3
Creating a New BSP
char * sysBspRev (void)
{
return (BSP_VERSION BSP_REV);
}
The file sysLib.c should also include the following stub drivers:
3
romInit.s
#include "mem/nullNvram.c"
#include "vme/nullVme.c"
The sysHwInit( ) routine is the heart of sysLib.c, and most of your work is done
here. It is the routine that resets all devices to a quiescent state so that they do not
generate interrupts later on when interrupts are enabled.
At power-up (cold start) the processor begins execution at romInit( ), which must
be the first routine in the text segment of romInit.s. For warm starts, the processor
begins execution at romInit( ) plus a small offset (see sysToMonitor( ) in sysLib.c).
Most hardware and device initialization is performed later in the initialization
sequence by sysHwInit( ) in sysLib.c. The job of romInit( ) is to perform the
minimal setup needed to transfer control to romStart( ) (in config/all/bootInit.c):
■
Initialize the processor (this code is specific to the processor and not the board,
and thus can be copied from a reference BSP):
– Mask processor interrupts
– Set the initial stack pointer to STACK_ADRS (defined in configAll.h)
– Disable processor caches
■
Initialize access to target DRAM as needed for the following (this code is
board-specific):
– Wait states
– Refresh rate
– Chip-selects
– Disabling secondary (L2) caches (if needed)
At the end, romInit( ) jumps to romStart( ) in bootInit.c, passing the start type. The
start type should be BOOT_COLD on a cold boot, or the parameter passed from
sysToMonitor( ) on a warm boot.
This file must also contain a data variable called sdata to mark the start of the data
segment. This variable typically stores a string such as “start of data.”
Refer to the template romInit.s file in the template BSP that accompanies this
product.
47