Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

mtlr r4 /* restore link register */

addi r4,0,14 /* prefetch 14 cache lines... */

mtctr r4 /* ...to fit this function */

/* cache (8x14=112 instr) */

..ebcloop:

icbt r0,r3 /* prefetch cache line for [r3] */

addi r3,r3,32 /* move to next cache line */

bdnz ..ebcloop /* continue for 14 cache lines */

/*--------------------------------------------------- */

/* Delay to ensure all accesses to ROM are complete */

/* before changing bank 0 timings */

/* 200usec should be enough. */

/* 200,000,000 (cycles/sec) X .000200 (sec) = */

/* 0x9C40 cycles */

/*--------------------------------------------------- */

addis r3,0,0x0

ori r3,r3,0xA000 /* ensure 200usec have passed t */

mtctr r3

..spinlp:

bdnz ..spinlp /* spin loop */

/*----------------------------------------------------*/

/* Now do the real work of this function */

/* Memory Bank 0 (Flash and SRAM) initialization */

/*----------------------------------------------------*/

addi r4,0,pb0ap /* *ebccfga = pb0ap; */

mtdcr ebccfga,r4

addis r4,0,EBC0_B0AP@h /* *ebccfgd = EBC0_B0AP; */

ori r4,r4,EBC0_B0AP@l

mtdcr ebccfgd,r4

addi r4,0,pb0cr /* *ebccfga = pb0cr; */

mtdcr ebccfga,r4

addis r4,0,EBC0_B0CR@h /* *ebccfgd = EBC0_B0CR; */

ori r4,r4,EBC0_B0CR@l

mtdcr ebccfgd,r4

/*----------------------------------------------------*/

/* Memory Bank 4 (NVRAM & BCSR) initialization */

/*----------------------------------------------------*/

addi r4,0,pb4ap /* *ebccfga = pb4ap; */

mtdcr ebccfga,r4

addis r4,0,EBC0_B4AP@h /* *ebccfgd = EBC0_B4AP; */

ori r4,r4,EBC0_B4AP@l

mtdcr ebccfgd,r4

addi r4,0,pb4cr /* *ebccfga = pb4cr; */

mtdcr ebccfga,r4

addis r4,0,EBC0_B4CR@h /* *ebccfgd = EBC0_B4CR; */

ori r4,r4,EBC0_B4CR@l

mtdcr ebccfgd,r4

blr /* return */

The example in Listing 7-7 was chosen because it is typical of the subtle complexities involved in low-level processor initialization. It is important to realize the context in which this code is running. It is executing from Flash, before any DRAM is available. There is no stack. This code is preparing to make fundamental changes to the controller that governs access to the very Flash it is executing from. It is well documented for this particular processor that executing code from Flash while modifying the external bus controller to which the Flash is attached can lead to errant reads and a resulting processor crash.

The solution is shown in this assembly language routine. Starting at the label ..getAddr, and for the next seven assembly language instructions, the code essentially prefetches itself into the instruction cache, using the icbt instruction. When the entire subroutine has been successfully read into the instruction cache, it can proceed to make the required changes to the external bus controller without fear of a crash because it is executing directly from the internal instruction cache. Subtle, but clever! This is followed by a short delay to make sure all the requested i-cache reads have completed.

When the prefetch and delay have completed, the code proceeds to configure Memory Bank 0 and Memory Bank 4 appropriately for our board. The values come from a detailed knowledge of the underlying components and their interconnection on the board. The interested reader can consult the "Suggestions for Additional Reading" at the end of the chapter for all the details of PowerPC assembler and the 405GP processor from which this example was derived.

Consider making a change to this code without a complete understanding of what is happening here. Perhaps you added a few lines and increased its size beyond the range that was prefetched into the cache. It would likely crash (worse, it might crash only sometimes), but stepping through this code with a debugger would not yield a single clue as to why.

The next opportunity for board-specific initialization comes after a temporary stack has been allocated from the processor's data cache. This is the branch to initialize the SDRAM controller around line 727 of .../cpu/ppc4xx/start.S:

bl sdram_init

The execution context now includes a stack pointer and some temporary memory for local data storagethat is, a partial C context, allowing the developer to use C for the relatively complex task of setting up the system SDRAM controller and other initialization tasks. In our EP405 port, the sdram_init() code resides in .../board/ep405/ep405.c and was customized for this particular board and DRAM configuration. Because this board does not use a commercially available memory SIMM, it is not possible to determine the configuration of the DRAM dynamically, like so many other boards supported by U-Boot. It is hard-coded in sdram_init.

Many off-the-shelf memory DDR modules have a SPD (Serial Presence Detect) PROM containing parameters defining the memory module. These parameters can be read under program control via I2C and can be used as input to determine proper parameters for the memory controller. U-Boot has support for this technique but might need to be modified to work with your specific board. Many examples of its use can be found in the U-Boot source code. The configuration option CONFIG_SPD_EEPROM enables this feature. You can grep for this option to find examples of its use.

By now, you can appreciate some of the difficulties of porting a bootloader to a hardware platform. There is simply no substitute for a detailed knowledge of the underlying hardware. Of course, we'd like to minimize our investment in time required for this task. After all, we usually are not paid based on how well we understand every hardware detail of a given processor, but rather on our ability to deliver a working solution in a timely manner. Indeed, this is one of the primary reasons open source has flourished. We just saw how easy it was to port U-Boot to a new hardware platformnot because we're world-class experts on the processor, but because many before us have done the bulk of the hard work already.

Listing 7-8 is the complete list of new or modified files that complete the basic EP405 port for U-Boot. Of course, if there had been new hardware devices for which no support exists in U-Boot, or if we were porting to a new CPU that is not yet supported in U-Boot, this would have been a much more significant effort. The point to be made here, at the risk of sounding redundant, is that there is simply no substitute for a detailed knowledge of both the hardware (CPU and subsystems) and the underlying software (U-Boot) to complete a port successfully in a reasonable time frame. If you start the project from that frame of mind, you will have a successful outcome.

Listing 7-8. New or Changed Files for U-Boot EP405 Port

$ diff -purN u-boot u-boot-ep405/ | grep +++

+++ u-boot-ep405/board/ep405/config.mk

+++ u-boot-ep405/board/ep405/ep405.c

+++ u-boot-ep405/board/ep405/ep405.h

+++ u-boot-ep405/board/ep405/flash.c

+++ u-boot-ep405/board/ep405/init.S