Introduction to s3c2410's Bootloader (Vivi)

0. Bootloader

  Bootloader is the first code that runs after the system is powered on. It usually runs for a very short time, but it is very important for embedded systems. In our desktop computers, the bootloader consists of the BIOS (firmware program) and the operating system bootloader (such as NTLOADER, GRUB and LILO) located in the MBR of the hard disk.

   There is no firmware program like BIOS in embedded systems, but some embedded CPUs will embed a small program inside the chip, which is generally used to load the bootloader into RAM, which is a bit similar to BIOS, but the function is much weaker than BIOS. In a typical system, the entire system loading and startup task is completed by the bootloader. In ARM, the system usually starts execution from address 0x00000000 when it is powered on or reset, and at this location, the system's BOOTLOADER is usually arranged. Through this small program, hardware devices can be initialized and memory space mapping can be established, so as to set the system's hardware and software environment to a suitable state! Prepare the correct environment for the final call to the operating system kernel.

From the software perspective, the embedded LINUX system can be seen as four levels:

(1) Boot loader, including the boot code (optional) fixed in the firmware and BOOTLOADER.

(2) Kernel. A board-specific custom kernel and the parameters that control the kernel boot system.

(3) File system. This includes the root file system and the file system built on the FLASH memory device.

(4) User application: An application specific to a user, sometimes including a GUI.

———————————————————————————

| Bootloader | Parameters | Kernel | Filesystem |

———————————————————————————

 Most books BOOTLOASER includes two modes, boot loading mode and download mode

Bootloader startup process

   Most books are divided into two stages. The first stage mainly contains hardware initialization code that depends on the CPU architecture, usually implemented in assembly language. The tasks of this stage are:

● Basic hardware device initialization (shielding all interrupts, disabling processor internal instruction/data cache, etc.)

● Prepare RAM space for the second stage

● If it is from a solid state storage medium, copy the second stage code of BOOTLOADER to RAM

● Setting up the stack

● Jump to the second stage C program entry point

The second stage is usually implemented in C language. The main tasks of this stage are:

● Initialize the hardware devices used in this phase

● Detect system memory map

● Read the kernel image and root file system image from FLASH to RAM

● Set boot parameters for the kernel

● Calling the kernel

The method for BOOTLOADER to call the LINUX kernel is to jump directly to the first instruction of the kernel, that is, jump to the address MEM_START+0x8000. The following conditions must be met when jumping

● CPU registers: R0 is 0, R1 is the machine type ID, R2 is the startup parameters, and the starting base address of the tag list in RAM

● CPU mode: interrupts must be disabled and the CPU must be set to SVC mode

● Cache and MMU settings: MMU must be turned off, instruction cache can be turned on or off, data cache must be turned off

  About Vivi

Vivi is a bootloader developed by Mizi, a Korean company, for ARM9 processors. Vivi has two working modes: boot loading mode and download mode. The boot loading mode can automatically start the Linux kernel after a period of time (this time can be changed), which is the default mode of Vivi. In the download mode, Vivi provides users with a command line interface, through which some commands provided by Vivi can be used, see the table below:

1 Configuration and compilation of vivi

1.1 Establishing a cross-development environment

   There is a lot of information about this on the Internet, and you can also use the simplest cross-tool to automatically establish a development environment!

1.2 Configure and compile vivi

If the source code of Vivi has been modified according to the development board, the source code needs to be configured and compiled to generate the Vivi binary image file burned into the flash.

Some variable settings in /vivi/Makefile need to be modified: 

LINUX_INCLUDE_DIR = /usr/local/arm/2.95.3/include

CROSS_COMPILE = /usr/local/arm/2.95.3/bin/arm-linux-

ARM_GCC_LIBS = /usr/local/arm/2.95.3/lib/gcc-lib/arm-linux/2.95.3

Enter the /vivi directory and execute make distclean. (The purpose is to ensure the effectiveness of the compilation. Before compiling, delete all "*.o" and "*.o.flag" files in vivi)

Enter the /vivi directory, enter "make menuconfig", and start selecting configuration. You can load a pre-written configuration file or modify it yourself. Note that you must select "Yes" to save the configuration when exiting.

Then enter "make" to start compiling, and it will be finished in a moment. If there is no error, your own "vivi" will be in /vivi. This is the bootloader that will be burned into the flash later.

 vivi code analysis

Vivi's code includes several directories such as arch, init, lib, drivers and include, with a total of more than 200 files.

Vivi mainly includes the following directories:

       arch: This directory includes subdirectories of all target boards supported by vivi, such as the s3c2410 directory.

       drivers: This includes the device drivers (MTD and serial port) required to boot the kernel. The MTD directory is divided into three directories: map, nand, and nor.

       init: This directory contains only two files: main.c and version.c. Like a normal C program, vivi will start executing from the main function.

       lib: some platform-common interface codes, such as udelay() and mdelay() in time.c.

       include: public directory of header files, in which s3c2410.h defines some registers of this processor. Platform/smdk2410.h defines resource configuration parameters related to the development board. We usually only need to modify this file to configure the parameters of the target board, such as baud rate, boot parameters, physical memory mapping, etc.