4 Bootstrap

4.1Introduction

In this chapter, the start-up of the kernel is described. It contains two phases: the initialization of the system after RESET, and the initialization of the tasks defined in the application.

4.2System Start-up

The compilation of the various source files and the linking of the resulting object files results in two files containing the .TEXT and ..DATA sections of the final system (see also Section 2.1.1). The linker has generated addresses referring to the .DATA section, which normally starts at the bottom of the system’s RAM. After RESET, however, this RAM is not initialized. Thus the .DATA section must be contained in the system’s ROM and copied to the RAM during system start-up,

??? as shown in Figure 4.1 ???

.DATA

.TEXT .TEXT .TEXT

FIGURE 4.1 ??? .DATA and .TEXT during System Start-Up ???

The .TEXT section, in contrast, does not need any special handling. Figure 4.1 shows the output of the linker on the left. The ROM image for the system is created by appending the .DATA section after the .TEXT section. The address of the .DATA section in ROM can be computed from the end of the .TEXT section; this address is provided by the linker (symbol _etext). Depending on the target system for which the linker has been installed, _etext may need to be rounded up (e.g. to the next 2Kbyte boundary) to determine the exact address of the .DATA section in RAM. Although it is not strictly necessary, it is generally a good idea to initialize the unused part of the RAM to 0. This allows to reproduce faults created by uninitialized variables.

After RESET, the CPU loads its supervisor stack pointer with the vector at address 0 and its program counter with the next vector. In our implementation, the vector for the supervisor stack pointer is somewhat abused, as it contains a branch to the start of the system initialization. This allows for issuing a JMP 0 (in supervisor mode) to restart the system, although this feature is not used yet. These two vectors are followed by the other exception vectors. Most of them are set to label _fatal, which is the handler for all fatal system errors.

Thus after RESET, processing continues at label _reset. The supervisor stack pointer is initialized to point to the top of the RAM. This is necessary because the vector for this purpose was abused for the branch to _reset. Next the vector base register (VBR) is set to the beginning of the vector table. This applies only for MC68020 chips and above and allows for relocation of the vector table. Actually, the branch to _reset is intended for jumping to the content of the VBR so that the system can be restarted with a relocated .TEXT section, provided that the VBR points to the proper vector table. For processors such as the MC68000 that do not provide a VBR, this instruction must be removed. After setting the VBR, the LEDs are turned off.

Then the RAM is initialized to 0. The end of the .TEXT section is rounded up to the next 2Kbyte boundary (assuming the linker was configured to round up the

.TEXT section to a 2Kbyte boundary), which yields the start of the .DATA section in ROM. The size of the .DATA section is computed, and the .DATA section is then copied from ROM to the RAM.

At this point, the .TEXT and .DATA sections are located at those addresses to which they had been linked. The supervisor stack pointer is set to the final supervisor stack, and the user stack pointer is set to the top of the idle task’s user stack (the code executed here will end up as the idle task).

Finally (with respect to crt0.S), the CPU enters user mode and calls function _main(). It is not intended to return from this call; if this would happen, then it would be a fatal system error.

Then a vector containing all tasks known at system start-up is initialized to 0 and setupApplicationTasks() is called. In setupApplicationTasks(), all tasks required by the application are created (see also Section 4.3). All tasks created have their status set to STARTED. That is, the task ring is completely set up, but no task is in state RUN. Next, the status for each task is set from STARTED to RUN.

85for (Task * t = Task::currTask->next; t != Task::currTask; t = t->next)

86t->TaskStatus &= ~Task::STARTED;

Here all tasks are in state RUN, but interrupts are still disabled. In the next step, variable SchedulerStarted is set to prevent subsequent calls to main() (which would have disastrous effects). Then the hardware is initialized to level Interrupt_IO, and finally interrupts are enabled. The idle task then de-schedules itself, which causes the task with the highest priority to execute. The idle task itself goes into an infinite loop. Whenever the idle task is swapped in (i.e. no other task is in state RUN), it calls os::Stop().

96return 0; /* not reached */

97}

Function os::Stop() merely executes TRAP #0.

1 /* os.cc */

...

67void os::Stop()

68{

69asm("TRAP #0");

70}

The CPU thus enters supervisor mode, fetches the corresponding vector and proceeds at label _stop.

At label _stop, the yellow LED (which is turned on at every interrupt) is turned off. The CPU then stops execution with all interrupts enabled until an interrupt