EE458 - Embedded Systems Lecture 4 – Initialization ●

Outline – – – –

●

Embedded System Initialization The PC Boot Process The GRUB Boot Manager The First Project

References – –

RTC: Chapter 3 GRUB Manual

1

Embedded System Initialization Introduction ●

Getting a first “Hello World!” program to run on an embedded system can take a lot of effort: – – – –

How do we load the image on the target system? Where in memory should the image be loaded? How do we start the program? How does the program produce output?

2

Embedded System Initialization Image Transfer ●

The image is usually loaded on the target by: – –

–

●

Programming the image in EEPROM or flash. Downloading the image over a serial or network connection. (This requires a data transfer utility on the host as well as a loader, a monitor, or a debug agent on the target.) Download the image through a JTAG or BDM interface.

During development the latter two approaches are usually faster than the first. 3

Embedded System Initialization Image Transfer ●

An embedded loader: – – – – – – –

Resides in ROM on the target. Is executed on system reset. May be either written by the developer or supplied by the target board manufacturer. Must perform (some) system initialization. Uses the same protocol as the host xfer utility. May need to understand the ELF format to load image sections to their proper memory locations. Must transfer control to image after download. 4

Embedded System Initialization Image Transfer ●

An embedded monitor: – – – – – –

Resides in ROM on the target. Is executed on system reset. Supplied by the target board manufacturer. May perform complete system initialization. Has a user interface via a serial or network link. Monitor commands allow you to download image, read/write memory and registers, set/clear breakpoints, single-step through code, reset the system. 5

Embedded System Initialization Image Transfer ●

A debug agent: – – – –

Resides in ROM on the target. Is executed on system reset. Usually supplied by the RTOS vendor. Similar to a monitor, but works with a debugger running on the host to provide source level debugging.

6

Embedded System Initialization Bootstrapping ●

Typical steps in bootstrapping: –

– – –

After reset, processor executes code at a particular address in ROM. This is usually a jump instruction to loader/monitor program. The loader first initializes the system hardware. The loader then transfers the image to RAM (by copying it from ROM or via download). The end of the loader program is a jump to the application code.

7

Embedded System Initialization Application Execution ●

There are three common image execution scenarios: – – –

●

●

execute from ROM, using RAM for data execute from RAM after extracting (the usually compressed) image from ROM execute from RAM after download

The third scenario is typically used during development. The image must be properly configured (via a linker script) to run at its final location. 8

Embedded System Initialization Software Initialization ●

The image typically contains the following components: –

The board support package (BSP) contains drivers for the particular target.

–

The RTOS contains components for multitasking, synchronization, I/O, etc

–

Misc. components: networking, file system

–

The actual application.

9

Embedded System Initialization Software Initialization

Typical Software Components in the Image 10

Embedded System Initialization Software Initialization ●

The image typically goes through the following initialization steps: –

Further hardware initialization.

–

Initialization of the RTOS and RTOS objects.

–

Application initialization is then performed by a developer written function. (The Init() function in RTEMS.) Tasks and other RTOS objects (semaphores, queues, timers, etc) are typically created here. 11

Embedded System Initialization PC Bootstrapping ●

Since we are using the PC as our target it is helpful to have a basic understanding of the PC boot process: –

After power-on or reset the processor starts executing code from ROM (the BIOS ROM).

–

Basic hardware (motherboard, keyboard, video) is tested and initialized.

–

The first sector (512 bytes) is loaded into RAM from either floppy or the hard disk (based on CMOS settings) and executed. 12

Embedded System Initialization PC Bootstrapping Floppy 512 B

Boot Sector

Hard Drive MBR 512 B Boot Sector 512 B

Partition 1 512 B

Boot Sector

Partition 2

13

Embedded System Initialization PC Bootstrapping ●

●

A hard drive is split into partitions. Each partition is organized like a floppy disk. A partition starts with a 512 byte boot sector. The first sector on a hard drive is known as the Master Boot Record or MBR. You can have only four primary partitions. One of those four can be an extended partition which can hold multiple logical partitions. 14

Embedded System Initialization PC Bootstrapping ●

●

Multiple partitions are useful if you want to run multiple operating systems. Each partition may have a different file system (FAT, NTFS, EXT2, etc.) The MBR contains boot manager code and the partition table. The default boot manager (usually installed when you first install an OS) loads and executes the boot sector of the active partition. 15

Embedded System Initialization Boot Managers ●

●

Other boot managers (like GRUB – the GRand Unified Bootloader) are capable of loading any partition boot sector (based on a menu selection by the user). Boot sector code is OS specific. It knows only how to load and execute the OS on that partition (or floppy).

16

Embedded System Initialization The GRUB Boot Manager ●

GRUB can bypass the boot sector and directly load some operating systems (Linux, RTEMS, BSD, etc): grub> multiboot (hd1,1)/hello.exe grub> boot

●

In GRUB notation (hd1,1) refers to the first partition (part. 1) on the 2nd drive (drive hd1).

17

Embedded System Initialization PC Bootstrapping - Update ●

●

●

Previous slides have described a BIOS system with an MBR partitioned drive. MBR drives use 32-bit addresses (to address a 512 byte block) and are limited to 2 TiB. Newer systems use UEFI instead of BIOS and drives can use GPT partitioning. GPT drives use 64-bit block addresses can can be 232 times larger than a 2 TiB drive. Grub supports booting from a GPT drive. 18

Embedded System Initialization The First Project ●

●

Just to get started using RTEMS and QEMU our first project will be an etch-a-sketch. We won't be using any RTEMS features yet, just some routines from the PC BSP. (Our program will be highly target dependent.) You can use the getch() routine to get characters directly (unbuffered) from the keyboard. You can use rtems_kbpoll() to determine if a key has been pressed. 19

Embedded System Initialization The First Project ●

The following program displays the “ASCII” value of any key. Some keys (the cursor keys and the Function keys) generate multiple returns from getch(): while(1) { c = getch(); printf("Char has value %d\n", c); }

20

Embedded System Initialization The First Project ●

●

We will bypass the stdio output routines and directly access the PC's video text memory. The PC text screen is laid out in 25 rows of 80 columns (2000 characters). Each character uses up two bytes of video text memory. The video text memory starts at address 0xB8000. The first byte of the two byte pair contains the ASCII value of the character. 21

Embedded System Initialization The First Project ●

Here's an RTEMS program that writes a line of 'a' characters across the top of the display: unsigned char *DisplayBuffer = (unsigned char *)0xB8000; for(i=0, j=0; i