Final_report Jayanth.docx

Post Silicon Validation of Different Reset Types

On

Next Generation Xeon Processors

Thesis submitted in partial fulfillment of the

Requirements for the degree of

Master of Science (MS)

in

“Embedded Systems”

by

Mr. Dwarsala Jayanth Reddy

(111006041)

Under the guidance of

Mr. Jeyaraj k Jeyabalan Mr. Sudhakara Upadya P

System Validation Engineer, PVE Team Assistant Professor

Intel Technology India Pvt Ltd MCIS

Bangalore Manipal University, Manipal

MANIPAL CENTRE FOR INFORMATION SCIENCE

(A Constituent College of Manipal University, Manipal)

Post-Si validation of Different Reset Types on Next Gen Xeon Processors Dwarsala Jayanth Reddy

MANIPAL CENTRE FOR INFORMATION SCIENCE(A Constituent College of Manipal University, Manipal)

CERTIFICATEThis is to certify that this thesis work titled

Post Silicon Validation of Different Reset Types OnNext Generation Xeon Processors

Is a bonafide record of the work done by

Mr. Dwarsala Jayanth Reddy

101006045

In partial fulfillment of the requirements for the award of the degree of Master of

Science (MS) in “Branch of MS Program” under Manipal University, Manipal and

the same has not been submitted elsewhere for the award of any other degree

Mr. Jeyaraj k Jeyabalan Mr. Sudhakara Upadya P

System Validation Engineer, PVE Team Assistant Professor

Intel Technology India Pvt Ltd MCIS

Bangalore Manipal University, Manipal

Prof. Harishchandra Hebbar NDirector,

Manipal Centre for Information ScienceManipal University, Manipal

Manipal Center for Information Sciences 1


ACKNOWLEDGMENT

SUCCESS means achievement and behind every success there is a need of unfathomable set of gratitude to those who supported and without whom this entire project task would not have taken the shape as it meant for.

I would express my deep sense of gratitude to Intel Technology India Pvt Ltd, Bangalore for giving me an opportunity to do the project and providing all the necessary resources and expertise for this purpose.

I shall forever be indebted and grateful to my Industry guide MR. Jeyaraj K Jeyabalan, System Validation Engineer, Intel Technologies India, Bangalore whose timely, valuable guidance and encouragement in completing the project successfully.

I express my gratitude to MR. Daljeet Maini, Manager, Intel Technologies India, Bangalore for his valuable help and guidance for my project.

My sincere wholehearted gratitude to MR. Srinagesh S Monderti, Senior Manager, Intel Technologies India, Bangalore for giving me an opportunity to work on some of the most exciting projects.

I am also obliged to MS. Sudhakara Upadya, Assistant Professor, MCIS Manipal University, for his valuable support.

My profound and sincere gratitude to PROF. HARISHCHANDRA HEBBAR, Director, MCIS Manipal University, for his support in carrying out this project.

I am extremely thankful to PROF. C. S. RAMASHESHA, Project Coordinator, MCIS Manipal University, for his timely help, suggestions and guidance.

I would also thank all Faculty members and non-teaching staff of MCIS, Manipal University for their encouragement and co-operation. In addition there are many people who have helped me during the course of this study either directly or indirectly. My profound gratitude to all those wonderful people.

D Jayanth Reddy…



CONTENTS

ABSTRACT 7

1. VALIDATION METHODOLOGIES 8

1.1. SILICON VALIDATION 8

1.2. PROCESSOR VALIDATION METHODOLOGY 9

1.2.1. PRESILICON VALIDATION 9

1.2.2. POSTSILICON VALIDATION 10

1.3. PRESILICON V/S POSTSILICON 10

1.4. POSTSILICON METHODOLOGIES 11

2. RESET DESCRIPTION 12

2.1. INTRODUCTION 12

2.2. TYPES OF RESET 13

2.2.1. COLD RESET 13

2.2.2. WARM RESET 13

2.2.3. BIOS INITIATED RESET 14

2.2.4. BIOS FLOW BREAK RESET 14

2.2.5. RANDOM RESET 15

2.3. INITIATORS 15

2.4. TARGETS 15

3. GENERAL BOOT SEQUENCE 16

3.1. INITIAL PHASE 16

3.2. MEMORY DURING BOOT 17

3.3. MASTER BOOT RECORDER 18

4. IA 32 PLATFORM BOOT SEQUENCE 21

4.1. HARDWARE POWER SEQUENCES 21

4.2. MODES SELECTION 22

4.3. EARLY INITIALIZATION: 25

4.4. MEMORY CONFIGURATION AND INITIALIZATION 28

4.5AP INITIALIZATION 32

4.6. ADVANCED INITIALIZATION 33

4.6.1. General-Purpose I/O 34



4.6.2. Interrupt Controllers 34

4.6.3. Timers 37

4.6.4. Memory Caching Control 37

4.6.5. Serial Ports 38

4.6.6. Clock and Overclock Programming 38

4.6.7. PCI Device Enumeration 38

4.6.8. Graphics Initialization 39

4.6.9. Input Devices 39

4.6.10. USB Initialization 39

4.6.11. SATA Initialization 40

4.6.12. Defining the Memory Map 41

4.6.13. Loading the Operating System 42

5. PROCESSOR INITIALIZATION AND MANAGEMENT 43

5.1. INITIALIZATION OVERVIEW 43

5.1.1. PROCESSOR STATE AFTER RESET 44

5.1.2. PROCESSOR BUILT-IN SELF-TEST (BIST) 45

5.1.3. MODEL AND STEPPING INFORMATION 46

5.1.4. FIRST INSTRUCTION EXECUTED 47

5.2. X87 FPU INITIALIZATION 47

5.2.1. CONFIGURING THE X87 FPU ENVIRONMENT 48

5.3. CACHE ENABLING 49

5.4. MODEL-SPECIFIC REGISTERS (MSRS) 50

5.5. MEMORY TYPE RANGE REGISTERS (MTRRS) 50

5.6. INITIALIZING SSE/SSE2/SSE3/SSSE3 EXTENSIONS 51

5.7. SOFTWARE INITIALIZATION FOR REAL-ADDRESS MODE OPERATION 51

5.7.1. REAL-ADDRESS MODE IDT 52

5.7.2. NMI INTERRUPT HANDLING 52

5.8. SOFTWARE INITIALIZATION FOR PROTECTED-MODE OPERATION 53

5.8.1. PROTECTED-MODE SYSTEM DATA STRUCTURES 54

5.8.2. INITIALIZING PROTECTED-MODE EXCEPTIONS AND INTERRUPTS

55



5.8.3. INITIALIZING PAGING 55

5.8.4. INITIALIZING MULTITASKING 56

5.8.5. INITIALIZING IA-32E MODE 58

5.8.5.1. IA-32E MODE SYSTEM DATA STRUCTURES 58

5.8.5.2. IA-32E MODE INTERRUPTS AND EXCEPTIONS 58

5.8.5.3. 64-BIT MODE AND COMPATIBILITY MODE OPERATION58

5.8.5.4. SWITCHING OUT OF IA-32E MODE OPERATION 59

5.9. MODE SWITCHING 60

5.9.1. SWITCHING TO PROTECTED MODE 60

5.9.2. SWITCHING BACK TO REAL-ADDRESS MODE 62

6. SPECIFIC REQUIREMENTS 64

6.1. HARDWARE 64

6.1.1. PLATFORM 64

6.1.2. HOST PC 69

6.1.3. IN TARGET PROBE 69

6.2. SOFTWARE 70

7. RESET VALIDATION 71

7.1. RESET STEPS 71

7.2. TESTS 73

7.3. TEST DESCRIPTION 73

7.3.1. MANUAL COLD RESET 73

7.3.2. MANUAL WARM RESET 75

7.3.4. BIOS INITIATED RESET 77

7.3.5. BIOS FLOW BREAK RESET 77

8. CONCLUSIONS AND FUTURE WORK 79

BIBLIOGRAPHY 80

Appendix A 81

Appendix B 85



FIGURES AND TABLES

FIGURES:

Fig1.1. Product cycle 9

Fig2.1. Block Diagram of Setup 12

Fig3.1. General Boot Sequence 16

Fig3.2. Important memory regions during boot 17

Fig3.3. Master Boot Record 18

Fig4.1. Power up Sequence 22

Fig4.2. Switching Processor between modes 24

Fig4.3. Memory Map at power on 30

Fig4.4. Platform Controller Hub (PCH) PIRQ to IRA Router 35

Fig5.1. Contents of CR0 Register after Reset 45

Fig5.2. Version Information in the EDX Register after Reset 46

Fig6.1. Diagram of Mother Board 64

FLOW CHARTS:

Fig7.1. Basic Flow chart of Reset 72

Fig7.2. Flow chart of cold reset 74

Fig7.3. Flow chart for Warm Reset 76

Fig7.4. Flow chart for BIOS flow breaks reset 78

TABLES:

Table4.1 Platform Controller Hub PIRQ routing table 36

Table5.1. Recommended Settings of EM and MP flags on IA-32 Processors 48

Table7.1. Test cases 73



ABSTRACT

Reset validation is used to verify and validate the platform and components

correctly handle and recover from various platform-level resets. Reset validation is a

part of Post Silicon validation which mainly concentrates on validating the Memory,

PCI-Express, processor interconnections and some components feature correctness.

Reset is issuing a restart (rebooting) .In computing, Restart is the process by which a

running computer system is restarted, either intentionally or unintentionally. There are

different types of resets, such as Cold, Warm, Reset cycling, Random and BIOS

initiated reset. The automation of Reset reduces the manual effort in issuing the reset

and validating the different components and platform features.



1. VALIDATION METHODOLOGIES

BACKGROUND

One of the challenging tasks in server validation is to check correctness of the

product both before and after the product is released to maintain quality of product

shipped. Validation remains an integral and crucial phase of today’s microprocessor

design and manufacturing process.

1.1. SILICON VALIDATION:

Validation is the process of checking that a product, service or system meets

specifications and made available in market in time and that it fulfills its intended

purpose. Validation is needed to prevent the data corruption, unexpected machine

breakdowns, and incomplete or corrupt data transmissions over cell phones and

PDAs. It also ensures that the processor is compatible with previous generation

software’s (SW), hardware’s (HW), operating systems (OS), reliable and durable for

many years.

1.2. PROCESSOR VALIDATION METHODOLOGY:

Processor Validation consists of composition of different techniques, which

are either presilicon or postsilicon validation. Each technique has a unique advantage

in capturing a specific type of bug more quickly than others. Although there is some

duplication in the functionality tested, bugs missed by one technique can potentially

be captured by another technique thus ensuring the quality of the silicon. This fig 1.1

shows the whole cycle of product

Processor Validation techniques are broadly classified as follows

Presilicon Validation.

Postsilicon Validation.



Fig1.1. Product cycle

1.2.1. PRESILICON VALIDATION

In Presilicon validation, design analysis tools are used to simulate the design

and create the test environment before an actual silicon device is created. Most of the

presilicon validation is done either on a Register Transfer-Level (RTL) simulator or

an emulator. Typical goals of Presilicon validation are having a zero defect rate over a

specific period with no show stopper bugs before tape-out, simulating a required

number of cycles and being able to boot up a favorite operating system image on the

simulator.

Rigorous validation is performed at the microarchitecture design level, cluster

(containing a collection of design units) level and full chip level. Since the

environment is simulated, there is flexibility in setting up test cases at the block and

gate level. Inputs can be injected and outputs probed and logged from virtually

anywhere in the design. A powerful, low-level test and debug environment is the

result. A problem with design simulation and presilicon testing is that, it takes long

time to execute when compared to actual silicon which limits the amount of testing

that can be performed.



1.2.2. POST-SILICON VALIDATION:

Postsilicon validation is performed on the silicon device once it arrives from

the FAB. The tests are run on a reference or validation board containing the Target

silicon. Target silicon in the validation board interacts with other hardware and

peripherals. Postsilicon validation takes less time compared to presilicon validation.

Enumerative exercising of all processor logic is not possible because of the increase

of cases that need testing, requiring a focus on boundary cases by stressing block

interfaces and Targeting complex state machines and combinational logic.

Typical postsilicon methodology consists of booting low-level console user

interface, running legacy tests, doing a boot of the favorite operating system, running

postsilicon tests, locating and diagnosing bugs, reproducing and analyzing bugs on the

RTL model and using microcode patches to provide a work-around so that validation

may proceed. This is typically done with low observability using the small amount of

DFT (Design for Test) features available on the chip.

1.3. PRE-SILICON V/S POSTSILICON:

Postsilicon validation is done in a system environment to flush out bugs missed

in presilicon Validation. Typical reasons for this are the slow simulation speed that

prevents running a large number of tests, tests requiring long execution times, tests

not run in a particular mode, innovations in circuit technology and so forth.

Postsilicon validation has usually found fewer bugs than presilicon, as would be

expected.

But, with the complexity of the processor growing, the bugs found in

postsilicon have increased. The complexity of creating the conditions to cause the

bugs to appear and the complexity of debugging them have increased as well. Such

bugs are hard to detect in presilicon because they involve many complex interactions

between units that are hard to detect with the limited number of presilicon simulation

cycles and will continue to exist in silicon. Due to short postsilicon validation cycles,

it is important that these bugs be detected rapidly.

One difficulty with postsilicon validation is that visibility inside the chip is

limited, internal signals cannot be probed. Test and debug is a challenge at this stage.



The work is done at the device's register interfaces using software and at its external

signals using tools such as logic analyzers and oscilloscopes.

1.4. POSTSILICON METHODOLOGIES:

Postsilicon validation effort is done along two major directions as

follows

System Validation (SV)

Compatibility Validation (CV)

Electrical validation(EV)

System Validation is primarily focused on validating the CPU and chipsets in

an embedded system environment that uses the new silicon in a multi-way

configuration and has special monitor software to download the validation tests into

the platform for execution on full chip which is obtained from FAB. This platform has

many hooks to provide flexibility in testing and has external graphics and PCI or USB

peripherals that can communicate with the CPU core and generate programmable

traffic.

Compatibility validation runs on desktop and server systems that incorporate

the new chips with various configurations of the system and are run under real

operating systems, other system software and user applications. It uses real

applications and thus validates common usage models.

Electrical Validation directly addresses base-lining and monitoring the

electrical performance of the chips. Here the validation will be based on the electrical

characteristics being measured and the accuracy to which the measurement must be

made.



2. RESET DESCRIPTION

2.1. INTRODUCTION:

In computing, Reset is the process by which a running computer system is

restarted, either intentionally or unintentionally. Reset can be any one from the

different types, there should be initiator and a target.

Reset Types: Cold, Warm, BIOS initiated, and Random etc.

Initiators: User can reset the platform, through a script via a Host, or BIOS

can also act as initiator.

Targets: CPU is the main concentration in reset, even the platform

components can be our targets

The basic idea of this validation is to check the platform and some

components are recovered correctly from the different types of resets and validating

the sticky register behavior after reset. Reset can be any one from the different types,

there should be initiator and a target. The following is the block diagram which

explains how reset happens in a platform/PC.

Fig2.1. Block Diagram of Setup



2.2. TYPES OF RESET:

2.2.1. Cold Reset:

A Cold Reset is a reset where the core power rail turns off and some of the

suspend power may turn off too. Cold reset is the “power on” reset.

Cold Reset (also known as a hard reboot, cold boot or cold start) is when

power to a computer is abruptly turned off and then turned back on. Since the

operating system does not have the opportunity to perform any shutdown procedures,

data loss or corruption may occur if transactions in disk caches are not written to the

file system. After the computer starts again, the file system may be in a corrupted

state, requiring an integrity check of on-disk file system structures to be performed. In

a worst case scenario, corruption may affect files that are required for the operating

system to start, thereby preventing it from booting again. A hard reboot may be

caused by power failure, by accident or deliberately as a last resort to reset

an unresponsive system or critical error

2.2.2. Warm Reset:

A Warm Reset (also known as a soft reset) involves restarting a computer

"normally" under software control, without suddenly removing power or (directly)

triggering a hardware-based reset. It usually, though not always, refers to an

orderly shutdown and restart of the machine that includes safely flushing of

any cached write operations to persistent storage. On some machines, the BIOS may

perform a shorter initialization sequence than it would for a cold start, for example by

skipping steps such a power-on self-test or wiping sensitive information in memory.

The Control-Alt-Delete combination initiated a warm restart on many legacy

operating systems, including DOS and Windows 95. This key sequence was

subsequently replaced on later operating systems, for example on Windows NT,

where it has now become a secure attention sequence.

Warm reset is typically a platform wide event and is indicated by assertion and

de-assertion of xxResetB signal on the socket. Core and suspend power rails are


http://en.wikipedia.org/wiki/Secure_attention_sequence

http://en.wikipedia.org/wiki/Windows_95

http://en.wikipedia.org/wiki/DOS

http://en.wikipedia.org/wiki/Control-Alt-Delete

http://en.wikipedia.org/wiki/Power-on_self-test

http://en.wikipedia.org/wiki/Cache_(computing)

http://en.wikipedia.org/wiki/Shutdown_(computing)

http://en.wikipedia.org/wiki/Electric_power

http://en.wikipedia.org/wiki/Fatal_error

http://en.wikipedia.org/wiki/Hang_(computing)

http://en.wikipedia.org/wiki/Booting

http://en.wikipedia.org/wiki/Cache_(computing)


maintained. This reset preserves the error log state and machine check bank states for

use by platform debug.

2.2.3. BIOS INITIATED RESET:

The BIOS initiated Reset is where the BIOS will trigger the Cold or Warm

reset, after the platform is success fully booted instead of handing over to OS the

BIOS issues a restart.

2.2.4. BIOS FLOW BREAK RESET:

The BIOS Flow Break Reset, the user has the freedom to break at particular

POST code and check the platform at desired break point.

"POST" stands for Power on Self-Test. When the BIOS start to run, it does a

Self-Test of the components on the motherboard, and in some cases, boards that are

plugged into the various slots. It goes through several steps of checking, testing and

initializing the hardware components. Before entering each step, the BIOS writes a 2

digit identifying code to an external address. This code is commonly referred to as a

POST code. The meaning of the codes varies widely. Most computer manufacturers

use a BIOS supplied by a third party, the most common are Phoenix and AMI, but

there are many others. The codes also vary depending on the motherboard and the

manufacturer's requirements. These codes are useful during the manufacturing

process to help identify problems. To the consumer, they are useful in cases where the

system won't boot up and the video screen does not work, or if you are attempting to

make modifications. If the BIOS detect a problem, it will stop on the problem, and the

last code that was output will indicate what the failure is.

In order to see the codes being generated by your BIOS, you will need a Post

Code Master Display card, which plugs into your PC and displays these codes as the

BIOS perform its tests. There are versions available for both ISA and PCI

motherboard slots. The card displays HEX digits which consist of the numbers 0-9

and the letters A-F. The POST code values can be found in the Appendices A



2.2.5. RANDOM RESET:

Random reset is a non-technical term referring to an unintended (and often

undesired) reset following a system crash, whose root cause may not immediately be

evident to the user. Such crashes may occur due to a multitude of software and

hardware problems, such as triple faults. They are generally symptomatic of an error

in kernel (ring 0) that is not trapped by an error handler in an operating system or a

hardware-triggered non-maskable interrupt.

2.3. INITIATORS:

User can reset the platform, through a script via a Host, or BIOS can also act

as initiator.

2.4. TARGETS:

CPU is the main concentration in reset, even the platform components such as

the PCIe and Memory can be our targets.


http://en.wikipedia.org/wiki/Non-maskable_interrupt

http://en.wikipedia.org/wiki/Exception_handling

http://en.wikipedia.org/wiki/Triple_fault

http://en.wikipedia.org/wiki/Crash_(computing)


3. GENERAL OS BOOT SEQUENCE

3.1. INITIAL PHASE:

When Power button is pressed things start rolling on the computer. Once the

motherboard is powered up it initializes its own firmware the chipset and other tidbits

and tries to get the CPU running. If things fail at this point then you will likely have a

system that looks completely dead except for rotating fans. A few motherboards

manage to emit beeps for an absent or faulty CPU, but the zombie-with-fans state is

the most common. Sometimes USB or other devices can cause this to happen.

If all is well the CPU starts running. In a multi-processor or multi-core system

one CPU is dynamically chosen to be the bootstrap processor (BSP) that runs all of

the BIOS and kernel initialization code. The remaining processors, called application

processors (AP) at this point, remain halted until later on when they are explicitly

activated by the kernel. Most registers in the CPU have well-defined values after

power up, including the instruction pointer (EIP) which holds the memory address for

the instruction being executed by the CPU. Intel CPUs use a hack whereby even

though only 1MB of memory can be addressed at power up, a hidden base address (an

offset, essentially) is applied to EIP so that the first instruction executed is at address

0xFFFFFFF0. This magical address is called the reset vector and is standard for

modern Intel CPUs.

Fig3.1. General Boot Sequence


http://en.wikipedia.org/wiki/Reset_vector

http://en.wikipedia.org/wiki/Processor_register


3.2. MEMORY DURING BOOT:

The motherboard ensures that the instruction at the reset vector is a jump to

the memory location mapped to the BIOS entry point. This jump implicitly clears the

hidden base address present at power up. All of these memory locations have the right

contents needed by the CPU thanks to the memory map kept by the chipset. They are

all mapped to flash memory containing the BIOS since at this point the RAM modules

have random crap in them. An example of the relevant memory regions is shown in

fig 3.2

Fig3.2. Important memory regions during boot

The CPU then starts executing BIOS code, which initializes some of the

hardware in the machine. Afterwards the BIOS kicks off the Power-on Self

Test (POST) which tests various components in the computer. Lack of a working


http://en.wikipedia.org/wiki/Power_on_self_test

http://en.wikipedia.org/wiki/Power_on_self_test

http://duartes.org/gustavo/blog/post/motherboard-chipset-memory-map


video card fails the POST and causes the BIOS to halt and emit beeps to let you know

what’s wrong, since messages on the screen aren’t an option. A working video card

takes us to a stage where the computer looks alive manufacturer logos are printed,

memory starts to be tested. Other POST failures, like a missing keyboard, lead to halts

with an error message on the screen. The POST involves a mixture of testing and

initialization, including sorting out all the resources – interrupts, memory ranges, I/O

ports – for PCI devices. Modern BIOS that follow the Advanced Configuration and

Power Interface build a number of data tables that describe the devices in the

computer; these tables are later used by the kernel.

After the POST the BIOS wants to boot up an operating system, which must

be found somewhere: hard drives, CD-ROM drives, floppy disks, etc. The actual

order in which the BIOS seek a boot device is user configurable. If there is no suitable

boot device the BIOS halts with a complaint like “Non-System Disk or Disk Error.” A

dead hard drive might present with this symptom. Hopefully this doesn’t happen and

the BIOS find a working disk allowing the boot to proceed.

3.3. MASTER BOOT RECORDER:

The BIOS now reads the first 512-byte sector (sector zero) of the hard disk.

This is called the Master Boot Record and it normally contains two vital components:

a tiny OS-specific bootstrapping program at the start of the MBR followed by a

partition table for the disk. The BIOS however does not care about any of this it

simply loads the contents of the MBR into memory location 0x7c00 and jumps to that

location to start executing whatever code is in the MBR.

Fig3.3. Master Boot Record


http://en.wikipedia.org/wiki/Master_boot_record

http://en.wikipedia.org/wiki/Disk_sector

http://en.wikipedia.org/wiki/ACPI

http://en.wikipedia.org/wiki/ACPI


The specific code in the MBR could be a Windows MBR loader, code from

Linux loaders such as LILO or GRUB, or even a virus. In contrast the partition table

is standardized it is a 64-byte area with four 16-byte entries describing how the disk

has been divided up (so you can run multiple operating systems or have separate

volumes in the same disk). Traditionally Microsoft MBR code takes a look at the

partition table, finds the (only) partition marked as active, loads the boot sector

for that partition, and runs that code. The boot sector is the first sector of a partition,

as opposed to the first sector for the whole disk. If something is wrong with the

partition table you would get messages like “Invalid Partition Table” or “Missing

Operating System.” This message does not come from the BIOS but rather from the

MBR code loaded from disk. Thus the specific message depends on the MBR flavor.

Boot loading has gotten more sophisticated and flexible over time. The Linux boot

loaders LILO and GRUB can handle a wide variety of operating systems, file

systems, and boot configurations. Their MBR code does not necessarily follow the

“boot the active partition” approach described above. But functionally the process

goes like this:

The MBR itself contains the first stage of the boot loader. GRUB calls this

stage 1.

Due to its tiny size, the code in the MBR does just enough to load another

sector from disk that contains additional bootstrap code. This sector might be

the boot sector for a partition, but could also be a sector that was hard-coded

into the MBR code when the MBR was installed.

The MBR code plus code loaded in step 2 then read a file containing the

second stage of the boot loader. In GRUB this is GRUB Stage 2, and in

Windows Server this is c:\NTLDR. If step 2 fails in Windows you’d get a

message like “NTLDR is missing”. The stage 2 code then reads a boot

configuration file (e.g., grub.conf in GRUB, boot.ini in Windows). It then

presents boot choices to the user or simply goes ahead in a single-boot system.

At this point the boot loader code needs to fire up a kernel. It must know

enough about file systems to read the kernel from the boot partition. In Linux

this means reading a file like “vmlinuz-2.6.22-14-server” containing the



kernel, loading the file into memory and jumping to the kernel bootstrap code.

In Windows Server 2003 some of the kernel start-up code is separate from the

kernel image itself and is actually embedded into NTLDR. After performing

several initializations, NTDLR loads the kernel image from file c:\Windows\

System32\ntoskrnl.exe and, just as GRUB does, jumps to the kernel entry

point.

There’s a complication worth mentioning. The image for a current Linux kernel,

even compressed, does not fit into the 640K of RAM available in real mode. Yet the

boot loader must run in real mode in order to call the BIOS routines for reading from

the disk, since the kernel is clearly not available at that point. The solution is the

venerable unreal mode. This is not a true processor mode, but rather a technique

where a program switches back and forth between real mode and protected mode in

order to access memory above 1MB while still using the BIOS. At the end of this

sticky process the loader has stuffed the kernel in memory, by hook or by crook, but it

leaves the processor in real mode when it’s done.We’re now at the jump from “Boot

Loader” to “Early Kernel Initialization” as shown in the first diagram. That’s when

things heat up as the kernel starts to unfold and set things in motion.


http://en.wikipedia.org/wiki/Unreal_mode


4. IA 32 PLATFORM BOOT SEQUENCE

Boot sequence now a day’s is far complex than the compared to the last few years.

A detailed, low-level, step-by-step walkthrough of the boot up.

4.1. HARDWARE POWER SEQUENCES:

When someone issues a cold reset or pushes a power button, the CPU can't

simply jump up and start fetching code from flash memory. When external power is

first applied, the hardware platform must carry out a number of tasks before the

processor can be brought out of its reset state.

The first task is for the power supply to be allowed to settle down to its

nominal state. Once the primary power supply settles, there is usually a number of

derived voltage levels needed on the platform. For example, on the Intel Architecture

reference platform the main input supply is a 12-volt source, but the platform and

processor require voltage rails of 1.5, 3.3, 5, and 12 volts. Voltages must be provided

in a particular order, a process known as power sequencing. The power is sequenced

by controlling analog switches, typically field-effect transistors. The sequence is often

driven by a Complex Program Logic Device (CPLD).

Platform clocks are derived from a small number of input clock and oscillator

sources. The devices use phase-locked loop circuitry to generate the derived clocks

used for the platform. These clocks take time to converge.

It is only after all these steps have occurred that the power-sequencing CPLD

can de-assert the reset line to the processor, as illustrated in Fig 4.1. Depending on

integration of silicon features, some of this logic may be on chip and controlled by

microcontroller firmware that starts prior to the main processor.



Fig4.1. Power up Sequence

Once the processor reset line has been de-asserted, the processor begins

fetching instructions. The location of these instructions is known as the reset vector.

The reset vector may contain instructions or a pointer to the starting instructions in

flash memory. The location of the vector is architecture-specific and usually in a fixed

location, depending on the processor. The first fetching instructions start at 0xFFF,

FFF0. Only 16 bytes are left to the top of memory, so these 16 bytes must contain a

far jump to the remainder of the initialization code. This code is always written in

assembly at this point as there is no software stack or cache RAM available at this

time.

4.2. MODES SELECTION:

IA-32 supports three operating modes and one quasi-operating mode:

Protected mode is the native operating mode of the processor. It provides a

rich set of architectural features, flexibility, high performance, and backward

compatibility.

Real-address mode or "real mode" provides the programming environment of

the Intel 8086 processor, with a few extensions, such as the ability to switch to



protected or system management mode. Whenever a reset or a power-on

happens, the system transitions back to real-address mode.

System management mode (SMM) is a standard architectural feature in all IA-

32 processors, beginning with the 386 SL. This mode provides an operating

system or executive with a transparent mechanism for implementing power

management and OEM differentiation features. SMM is entered through

activation of an external system interrupt pin, which generates a System

Management Interrupt (SMI). In SMM, the processor switches to a separate

address space while saving the context of the currently running program or

task. SMM-specific code may then be executed transparently. Upon returning

from SMM, the processor is placed back into its state prior to the system

management interrupt.

o The system firmware is usually responsible for creating an system

management interrupt handler, which may periodically take over the

system from the host OS. Legitimate workarounds are executed in the

SMI handler, and handling and logging-off errors may happen at the

system level. As this presents a potential security issue, there is also a

lock bit that resists tampering with this mechanism.

o Vendors of real-time operating systems often recommend disabling

this feature because it could subvert the OS environment. If this

happens, then the additional work of the SMI handler would need to be

incorporated into the RTOS for that platform, or else the potential

exists of missing something important in the way of error response or

workarounds.

Virtual-8086 mode is a quasi-operating mode supported by the processor in

protected mode. This mode allows the processor to execute 8086 software in a

protected, multitasking environment.

The Intel 64 architecture supports all operating modes of IA-32 architecture plus IA-

32e mode. In IA-32e mode, the processor supports two sub-modes: compatibility

mode and 64-bit mode. Compatibility mode allows most legacy protected-mode



applications to run unchanged, while 64-bit mode provides 64-bit linear addressing

and support for physical address space larger than 64 GB.

Fig4.2. Switching Processor between modes

When the processor is first powered on, it will be in a special mode similar to

real mode, but with the top 12 address lines asserted high. This aliasing allows the

boot code to be accessed directly from nonvolatile RAM (physical

address 0xFFFxxxxx).

Upon execution of the first long jump, these 12 address lines will be driven

according to instructions by firmware. If one of the protected modes is not entered

before the first long jump, the processor will enter real mode, with only 1 MB of

addressability. In order for real mode to work without memory, the chipset needs to

be able to alias a range of memory below 1 MB to an equivalent range just below 4

GB. Certain chipsets do not have this aliasing and may require a switch to another

operating mode before performing the first long jump. The processor also invalidates

the internal caches and translation look-aside buffers.



The processor continues to boot in real mode. There is no particular technical

reason for the boot sequence to occur in real mode. Some speculate that this feature is

maintained in order to ensure that the platform can boot legacy code such as MS-

DOS. While this is a valid issue, there are other factors that complicate a move to

protected-mode booting. The change would need to be introduced and validated

among a broad ecosystem of manufacturers and developers, for example.

Compatibility issues would arise in test and manufacturing environments. These and

other natural hurdles keep boot mode "real."

The first power-on mode is actually a special subset of real mode. The top 12

address lines are held high, thus allowing aliasing, in which the processor can execute

code from nonvolatile storage (such as flash memory) located within the lowest one

megabyte as if it were located at the top of memory.

Normal operation of firmware (including the BIOS) is to switch to flat

protected mode as early in the boot sequence as possible. It is usually not necessary to

switch back to real mode unless executing an option ROM that makes legacy software

interrupt calls. Flat protected mode runs 32-bit code and physical addresses are

mapped one-to-one with logical addresses (that is, paging is off). The interrupt

descriptor table is used for interrupt handling. This is the recommended mode for all

BIOS/boot loaders.

4.3. EARLY INITIALIZATION:

The early phase of the BIOS/bootloader initializes the memory and processor

cores. In a BIOS constructed in accord with the Unified EFI Forum's UEFI 2.0

framework, the security and Pre-EFI Initialization (PEI) phases are normally

synonymous with "early initialization." It doesn't matter if legacy or UEFI BIOS is

used. From a hardware point of view, the early initialization sequence is the same.

In a multicore system, the bootstrap processor is the CPU core (or thread) that

is chosen to boot the system firmware, which is normally single-threaded. At RESET,

all of the processors race for a semaphore flag bit in the chipset The first finds

it clear and in the process of reading it sets the flag; the other processors find the



flag set and enter a wait-for-SIPI (Start-up Inter-Processor Interrupt) or halt state. The

first processor initializes main memory and the Application Processors (APs), then

continues with the rest of the boot process.

A multiprocessor system does not truly enter multiprocessing operation until

the OS takes over. While it is possible to do a limited amount of parallel processing

during the UEFI boot phase, such as during memory initialization with multiple

socket designs, any true multithreading activity would require changes to be made to

the Driver Execution Environment (DXE) phase of the UEFI. Without obvious

benefits, such changes are unlikely to be broadly adopted.

The early initialization phase next readies the bootstrap processor (BSP) and

I/O peripherals base address registers, which are needed to configure the memory

controller. The device-specific portion of an Intel architecture memory map is highly

configurable. Most devices are seen and accessed via a logical Peripheral Component

Interconnect (PCI) bus hierarchy. Device control registers are mapped to a predefined

I/O or memory-mapped I/O space, and they can be set up before the memory map is

configured. This allows the early initialization firmware to configure the memory map

of the device as needed to set up DRAM. Before DRAM can be configured, the

firmware must establish the exact configuration of DRAM that is on the board.

System-on-a-chip (SOC) devices based on other processor architectures

typically provide a static address map for all internal peripherals, with external

devices connected via a bus interface. Bus-based devices are mapped to a memory

range within the SOC address space. These SOC devices usually provide a

configurable chip-select register set to specify the base address and size of the

memory range enabled by the chip select. SOCs based on Intel Architecture primarily

use the logical PCI infrastructure for internal and external devices.

The location of the device in the host's memory address space is defined by

the PCI Base Address Register (BAR) for each of the devices. The device

initialization typically enables all the BAR registers for the devices required for

system boot. The BIOS will assign all devices in the system a PCI base address by

writing the appropriate BAR registers during PCI enumeration. Long before full PCI



enumeration, the BIOS must enable the PCI Express (PCIe) BAR as well as the

Platform Controller Hub (PCH) Root Complex Base Address Register (RCBA) BAR

for memory, I/O, and memory-mapped I/O (MMIO) interactions during the early

phase of boot. Depending on the chipset, there are prefetchers that can be enabled at

this point to speed up data transfer from the flash device. There may also be Direct

Media Interface (DMI) link settings that must be tuned for optimal performance.

The next step, initialization of the CPU, requires simple configuration of

processor and machine registers, loading a microcode update, and enabling the Local

APIC (LAPIC).

Microcode is a hardware layer of instructions involved in the implementation

of the machine-defined architecture. It is most prevalent in CISC-based processors.

Microcode is developed by the CPU vendor and incorporated into an internal CPU

ROM during manufacture. Since the infamous "Pentium flaw," Intel processor

architecture allows that microcode to be updated in the field either through a BIOS

update or via an OS update.

Next, the LAPICs must be enabled to handle interrupts that occur before

enabling protected mode.

Software initialization code must load a minimum number of protected-mode

data structures and code modules into memory to support reliable operation of the

processor in protected mode. These data structures include an Interrupt Descriptor

Table (IDT), a Global Descriptor Table (GDT), a Task-State Segment (TSS), and,

optionally, a Local Descriptor Table (LDT). If paging is to be used, at least one page

directory and one page table must be loaded. A code segment containing the code to

be executed when the processor switches to protected mode must also be loaded, as

well as one or more code modules that contain necessary interrupt and exception

handlers.

Initialization code must also initialize certain system registers. The global

descriptor table register must be initialized, along with control registers CRxx through

CRxy. The IDT register may be initialized immediately after switching to protected



mode, prior to enabling interrupts. Memory Type Range Registers (MTRRs) are also

initialized.

With these data structures, code modules, and system registers initialized, the

processor can be switched to protected mode. This is accomplished by loading control

register CRa0 with a value that sets the PE (protected mode enable) flag. From this

point onward, it is likely that the system will not enter real mode again, legacy option

ROMs and legacy OS/BIOS interface notwithstanding, until the next hardware reset is

experienced.

4.4. MEMORY CONFIGURATION AND INITIALIZATION:

The initialization of the memory controller varies slightly depending on the

DRAM technology and the capabilities of the memory controller itself. The

information on the DRAM controller is proprietary for processor, and in such cases

the initialization Memory Reference Code (MRC) is typically supplied by the vendor.

It is likely that memory configuration will be performed by single-point-of-

entry and single-point-of-exit code that has multiple boot paths contained within it.

Settings for buffer strengths and loading for a given number of banks of memory are

chipset specific.

Once the memory controller has been initialized, a number of subsequent

cleanup events take place, including tests to ensure that memory is operational.

Memory testing is now part of the MRC, but it is possible to add more tests should the

design require it. BIOS vendors typically provide some kind of memory test on a cold

boot. Memory testing can take considerable time.

If testing is warranted, right after initialization is the time to do it. The system

is idle, the subsystems are not actively accessing memory, and the OS has not taken

over the host side of the platform. Several hardware features can assist in this testing

both during boot and at run-time. One of the most common technologies is error-

correction codes. After power-up, the state of the correction codes may not reflect the

contents, and all memory must be written to. Writing to memory ensures that the ECC

bits are valid and set to the appropriate contents. For security purposes, the memory



may need to be zeroed out manually by the BIOS — or, in some cases; a memory

controller may incorporate the feature into hardware to save time. Depending on the

source of the reset and security requirements, the system may or may not execute a

memory wipe or ECC initialization. On a warm reset sequence, memory context can

be maintained.

If there are memory timing changes or other configuration alterations that

require a reset to take effect, this is normally the time to execute a warm reset. That

warm reset would start the early initialization phase over again. Affected registers

would need to be restored.

From the reset vector, execution starts directly from nonvolatile flash storage.

This operating mode is known as execute-in-place. The read performance of

nonvolatile storage is much slower than the read performance of DRAM. The

performance of code running from flash is therefore much lower than code executed

in RAM. Most firmware is therefore copied from slower nonvolatile storage into

RAM. The firmware is then executed in RAM in a process known as shadowing.

Intel Architecture systems generally do not execute-in-place for anything but

the initial boot steps before memory has been configured. The firmware is often

compressed, allowing reduction of nonvolatile RAM requirements. Clearly, the

processor cannot execute a compressed image in place. There is a trade-off between

the size of data to be shadowed and the act of decompression. The decompression

algorithm may take much longer to load and execute than it would take for the image

to remain uncompressed. Pre-fetchers in the processor, if enabled, may speed up

execution-in-place. Some processors have internal NVRAM cache buffers to assist in

pipelining the data from the flash to the processor. Fig4.3 shows the memory map at

initialization in real mode.



Fig4.3. Memory Map at power on

Before memory is initialized, the data and code stacks are held in the

processor cache. Once memory is initialized, the system must exit that special caching

mode and flush the cache. The stack will be transferred to a new location in main

memory and cache reconfigured as part of AP initialization.

The stack must be set up before jumping into the shadowed portion of the

BIOS that is now in memory. A memory location must be chosen for stack space. The

stack will count down so the top of the stack must be entered and enough memory

must be allocated for the maximum stack.

If the system is in real mode, then SS:SP must be set with the appropriate

values. If protected mode is used, which is likely the case following MRC execution,

then SS:ESP must be set to the correct memory location.



This is where the code makes the jump into memory. If a memory test has not

been performed before this point, the jump could very well be to garbage. System

failures indicated by a Power-On Self-Test (POST) code between "end of memory

initialization" and the first following POST code almost always indicate a catastrophic

memory initialization problem. If this is a new design, then chances are this is in the

hardware and requires step-by-step debug.

For legacy option ROMs and BIOS memory ranges, Intel chipsets usually

come with memory aliasing capabilities that allow access to memory below 1 MB to

be routed to or from DRAM or nonvolatile storage located just under 4 GB. The

registers that control this aliasing are typically referred to as Programmable Attribute

Maps (PAMs). Manipulation of these registers may be required before, during, and

after firmware shadowing. The control over the redirection of memory access varies

from chipset to chipset For example; some chipsets allow control over reads and

writes, while others allow control over reads only.

For shadowing, if PAM registers remain at default values (all 0s), all

Firmware Hub (FWH) accesses to the E and F segments (E_0000–F_FFFFh) will be

directed downstream toward the flash component. This will function to boot the

system, but is very slow. Shadowing can be used to improve boot speed. One method

of shadowing the E and F segments of BIOS is to utilize the PAM registers. This can

be done by changing the enables (HIENABLE[ ] and LOENABLE[ ]) to 10 (write

only). This will direct reads to the flash device and writes to memory. Data can then

be shadowed into memory by reading and writing the same address. Once BIOS code

has been shadowed into memory, the enables can be changed to read-only mode so

memory reads are directed to memory. This also prevents accidental overwriting of

the image in memory.



4.5. AP INITIALIZATION:

The BSP starts and initializes the system. The APs must be initialized with

identical features. Before memory is activated, the APs are uninitialized. After

memory is started, the remaining processors are initialized and left in a wait-for-SIPI

state. To accomplish this, the system firmware must:

Find microcode and copy it to memory.

Find the CPU code in the Serial Peripherals Interface (SPI) and copy it to

memory — an important step to avoid execution-in-place for the remainder of

the sequence.

Send start-up inter processor interrupts to all processors.

Disable all NEM settings, if this has not already been done.

Load microcode updates on all processors.

Enable cache-on mode for all processors.

From a UEFI perspective, AP initialization may either be part of the PEI or

DXE phase of the boot flow, or in the early or advanced initialization. There is some

debate as to the final location.

Since Intel processors are packaged in various configurations, there are

different terms that must be understood when considering processor initialization. In

this context, a thread is a logical processor that shares resources with another logical

processor in the same physical package. A core is a processor that coexists with

another processor in the same physical package and does not share any resources with

other processors. A package is a chip that contains any number of cores and threads.

Threads and cores on the same package are detectable by executing the

CPUID instruction. Detection of additional packages must be done blindly. If a design

must accommodate more than one physical package, the BSP needs to wait a certain

amount of time for all potential APs in the system to "log in." Once a timeout occurs

or the maximum expected number of processors "log in," it can be assumed that there

are no more processors in the system.



In order to wake up secondary threads or cores, the BSP sends a SIPI to each

thread and core. This SIPI is sent by using the BSP's LAPIC, indicating the physical

address from which the AP should start executing. This address must be below 1 MB

of memory and must be aligned on a 4-KB boundary. Upon receipt of the SIPI, the

AP starts executing the code pointed to by the SIPI message. Unlike the BSP, the AP

starts code execution in real mode. This requires that the code that the AP starts

executing is located below 1 MB.

Because of the different processor combinations and the various attributes of

shared processing registers between threads, care must be taken to ensure that there

are no caching conflicts in the memory used throughout the system.AP behavior

during firmware initialization is dependent on the firmware implementation, but is

most commonly restricted to short periods of initialization followed by a HLT

instruction, during which the system awaits direction from the BSP before

undertaking another operation.

Once the firmware is ready to attempt to boot an OS, all AP processors must

be placed back in their power-on state. The BSP accomplishes this by sending an Init

Assert IPI followed by an Init De-assert IPI to all APs in the system (except itself).

4.6 ADVANCED INITIALIZATION:

Advanced initialization follows early initialization, as you might expect. This

second stage is focused on device-specific initialization. In a UEFI-based BIOS

solution, advanced initialization tasks are also known as DXE and Boot Device

Selection (BDS) phases. The following devices must be initialized to enable a system.

Not all are applicable to all embedded systems, but the list is prescriptive for most.

This list is applies specifically to SOCs (systems on a chip) based on Intel

architecture:

General purpose I/O (GPIO)

Interrupt controller

Timers


http://drdobbs.com/embedded-systems/228300362

http://drdobbs.com/embedded-systems/228300362


Cache initialization (this could also be accomplished during early

initialization)

Serial ports, console in/out

Clocking and overclocking

PCI bus initialization

Graphics (optional)

Universal Serial Bus (USB)

Serial Advanced Technology Attachment (SATA)

4.6.1. General-Purpose I/O: GPIOs are key to platform extensibility. GPIOs can be

configured for either input or output, but can also be configured to enable native

functionality. Depending on weak or strong pull-up or pull-down resistors, some

GPIOs can function as strapping pins that are sampled at reset by the chip-set, and

then have a second function during boot-up and at run-time. GPIOs may also act like

sideband signals to allow for system wakes.

SOC devices are designed to be used in a large number of configurations. The

devices often have more capabilities than the device is capable of exposing on the I/O

pins concurrently. That is because multiple functions may be multiplexed to an

individual I/O pin. Before the pins are used they must be configured to implement a

specific function or serve as general-purpose I/O pins. The system firmware developer

must work through 64 to 256 GPIOs and their individual options with the board

designer of each platform to ensure that this feature is properly enabled.

4.6.2. Interrupt Controllers: The Intel Architecture supports several different

methods of handling interrupts. No matter which method is chosen, all interrupt

controllers must be initialized at start-up.

When the Programmable Interrupt Controller (PIC) is the only enabled

interrupt device, the system is in PIC mode. This is the simplest mode. All APIC

components are bypassed and the system operates in single-thread mode

using LINT0. The BIOS must set the IRQs per board configuration for all onboard,



integrated, and add-in PCI devices. Platfrom Control

Fig4.4. Platform Controller Hub (PCH) PIRQ to IRA Router

The PIC contains two cascaded 8259s with fifteen available IRQs. IRQ2 is not

available because it is used to connect the 8259s. On mainstream components, there

are eight PIRQ pins supported by the PCH, named PIRQ[A# :H#]. These route PCI

interrupts to IRQs of the 8259 PIC. PIRQ[A#:D#] routing is controlled by PIRQ

routing registers 60h—63h (D31:F0:Reg 60- 63h). PIRQ[E#:H#] routing is controlled

by PIRQ routing registers 68h—6Bh (D31:F0:Reg 68 — 6Bh). This arrangement is

illustrated in Fig4.4. The PCH also connects the eightPIRQ[A#:H#] pins to eight

individual I/O Advanced Programmable Interrupt Controller input pins, as shown in

Table .



PIRQ# Pin Interrupt Router Register

for PIC

Connected to IOxAPIC

pin

PIRQA# D31:F0:Reg 60h INTIN16

PIRQB# D31:F0:Reg 61h INTIN17

PIRQC# D31:F0:Reg 62h INTIN18

PIRQD# D31:F0:Reg 63h INTIN19

PIRQE# D31:F0:Reg 68h INTIN20

PIRQF# D31:F0:Reg 69h INTIN21

PIRQG# D31:F0:Reg 6Ah INTIN22

PIRQH# D31:F0:Reg 6Bh INTIN23

Table4.1. Platform Controller Hub PIRQ routing table.

The Local Advanced Programmable Interrupt Controller (LAPIC) is inside the

processor. It controls interrupt delivery to the processor. Each LAPIC has its own set

of associated registers as well as a Local Vector Table (LVT). The LVT specifies the

manner in which the interrupts are delivered to each processor core.

The I/O Advanced Programmable Interrupt Controller (IOxAPIC) is contained

in the I/O Controller Hub (ICH) or the I/O Hub (IOH). It expands the number of IRQs

available to 24. Each IRQ's entry in the redirection table may be enabled or disabled.

The redirection table selects the IDT vector for the associated IRQ. This mode is

available only when running in protected mode.

The boot loader typically does not use Message Signaled Interrupts (MSIs) for

interrupt handling.

The Interrupt Vector Table (IVT) is located at memory location 0p. It contains

256 interrupt vectors. The IVT is used in real mode. Each 32-bit vector address

consists of the CS:IP for the interrupt vector.

The Interrupt Descriptor Table (IDT) contains the exceptions and interrupts in

protected mode. There are 256 interrupt vectors, and the exceptions and interrupts are

defined in the same locations as in the IVT. Exceptions are routines that handle error



conditions such as page faults and general protection Real-mode Interrupt Service

Routines (ISRs) communicate information between the boot loader and the OS. For

example, INT10h is used for video services such as changing video mode and

resolution. Some legacy programs and drivers, assuming these real-mode ISRs are

available, call INT routines directly.

4.6.3. Timers: A variety of timers can be employed in an Intel Architecture system:

The Programmable Interrupt Timer (PIT) resides in the IOH or ICH and

contains the system timer, also referred to as IRQ0.

The High Precision Event Timer (HPET) resides in the IOH or ICH. It

contains three timers. Typically, the boot loader need not initialize the

HPET, and the functionality is used only by the OS.

The Real Time Clock (RTC) resides in the IOH or ICH. It contains the

system time. These values are contained in CMOS. The RTC also contains

a timer that can be used by firmware.

The System Management Total Cost of Ownership (TCO) timers reside in

the IOH or ICH. They include the Watch Dog Timer (WDT), which can be

used to detect system hangs and reset the system.

The LAPIC contains a timer that can be used by firmware.

4.6.4. Memory Caching Control: Memory regions that must have different caching

behaviors will vary from design to design. In the absence of detailed caching

requirements for a platform, the following guidelines provide a safe caching

environment for typical systems:

Default Cache Rule: Uncached.

00000000-0009FFFF: Write Back.

000A0000-000BFFFF: Write Combined/Uncached

000C0000-000FFFFF: Write Back/Write Protect

00100000-TopOfMemory: Write Back.

Top of Memory Segment (TSEG): Cached on newer processors.

Graphics Memory: Write Combined or Uncached.

Hardware Memory-Mapped I/O: Uncached.



While MTRRs are programmed by the BIOS, Page Attribute Tables (PATs) are used

primarily with the OS to control caching down to the page level.

4.6.5. Serial Ports: An RS-232 serial port or UART 16550 is initialized for either

run-time or debug solutions. Unlike USB ports, which require considerable

initialization and a large software stack, serial ports have a minimal register-level

interface requirements. A serial port can be enabled very early in POST to provide

serial output support.

Console In/Console Out: During the DXE portion of the UEFI phase, the boot

services include console in and console out protocols.

4.6.6. Clock and Overclock Programming: Depending on the clocking solution of

the platform, the BIOS may have to enable the clocking of the system. It is possible

that a subsystem such as the ME or a server platform's Baseboard Management

Controller (BMC) has this responsibility. It is also possible that beyond the basic

clock programming, there are expanded configuration options for overclocking, such

as:

Based on enumeration, enable or disable clock-output enables.

Adjust clock spread settings. Enable, disable, and adjust amount. Note that

settings are provided as fixed register values determined from expected

usages.

Under-clock CPU for adaptive clocking support.

Lock out clock registers prior to transitioning to host OS.

4.6.7. PCI Device Enumeration: PCI device enumeration is a generic term that

refers to detecting and assigning resources to PCI-compliant devices in the system.

The discovery process assigns the resources needed by each device, including the

following:

Memory, prefetchable memory, I/O space.

Memory mapped I/O space.

IRQ assignment.

Expansion ROM detection and execution.



PCI device discovery applies to all newer interfaces such as PCIe root ports,

USB controllers, SATA controllers, audio controllers, LAN controllers, and various

add-in devices. These newer interfaces all comply with the PCI specification.

It is interesting to note that in UEFI-compliant systems, it is not during the

DXE phase but during BDS that most required drivers are loaded.

4.6.8. Graphics Initialization: The video BIOS or Graphics Output Protocol (GOP)

UEFI driver is normally the first option ROM to be executed. Once the main console-

out is up and running, the console-in line can be configured.

4.6.9. Input Devices: Refer to schematics to determine which I/O devices are in the

system. Typically, a system will contain one or more of the following devices:

Embedded Controller (EC): An EC is typically used in mobile or low-

power systems. The EC contains separate firmware that controls power-

management functions as well as PS/2 keyboard functionality.

Super I/O (SIO): An SIO typically controls the PS/2, serial, and parallel

interfaces. Most systems still support some of the legacy interfaces.

Legacy-Free Systems: Legacy-free systems use USB as the input device. If

pre-OS keyboard support is required, then the legacy keyboard interfaces

must be trapped. Refer to the IOH/ICH BIOS Specification for more

details on legacy-free systems.

4.6.10. USB Initialization: The USB controller supports both Enhanced Host

Controller Interface (EHCI) and Extensible Host Controller Interface (xHCI)

hardware. Enabling the host controller for standard PCI resources is relatively easy. It

is possible to delay USB support until the OS drivers take over. If pre-OS support for

EHCI or xHCI is required, then the tasks associated with the USB subsystem become

substantially more complex. Legacy USB requires an SMI handler be used to trap port

60 and 64 accesses to I/O space, converting these to the proper keyboard or mouse

commands. This pre-OS USB support is required if booting to USB is preferred.

4.6.11. SATA Initialization: A SATA controller supports the ATA/IDE

programming interface as well as the Advanced Host Controller Interface (AHCI). In



the following discussion, the term "ATA-IDE Mode" refers to the ATA/IDE

programming interface that uses standard task file I/O registers or PCI IDE Bus

Master I/O block registers. The term "AHCI Mode" refers to the AHCI programming

interface that uses memory-mapped register and buffer space and a command-list-

based model.

The general guidelines for initializing the SATA controller during POST and

S3 resume are described in the following sections. Upon resuming from S3, system

BIOS is responsible for restoring all the registers that it initialized during POST.

The system BIOS must program the SATA controller mode prior to beginning

other initialization steps. The SATA controller mode is set by programming the

SATA Mode Select (SMS) field of the port mapping register (D31:F2:Reg 90h[7:6]).

The system BIOS may never change the SATA controller mode during run-time.

Please note that the availability of the following modes is dependent on which PCH is

in use. If system BIOS is enabling AHCI Mode or RAID Mode, system BIOS must

disable D31:F5 by setting the SAD2 bit, RCBA + 3418h[25]. The BIOS must ensure

that it has not enabled memory space, I/O space, or interrupts for this device prior to

disabling the device.

IDE mode is selected by programming the SMS field, D31:F2:Reg

90h[7:6] to 00. In this mode, the SATA controller is set up to use the ATA/IDE

programming interface. The 6/4 SATA ports are controlled by two SATA functions.

One function routes up to four SATA ports,D31:F2, and the other routes up to two

SATA ports, D31:F5. In IDE mode, the Sub Class Code, D31:F2:Reg

0Ah and D31:F5:Reg 0Ah are set to 01h. This mode may also be referred to as

"compatibility mode," as it does not have any special OS driver requirements.

AHCI mode is selected by programming the SMS field, D31:F2:Reg 90h[7:6],

to 01h. In this mode, the SATA controller is set up to use the AHCI programming

interface. The six SATA ports are controlled by a single SATA function, D31:F2. In

AHCI mode the Sub Class Code,D31:F2:Reg 0Ah, is set to 06h. This mode does

require specific OS driver support.



RAID mode is selected by programming the SMS field, D31:F2:Reg

90h[7:6] to 10b. In this mode, the SATA controller is set up to use the AHCI

programming interface. The 6/4 SATA ports are controlled by a single SATA

function, D31:F2. In RAID mode, the Sub Class Code,D31:F2:Reg 0Ah, is set to 04h.

This mode does require specific OS driver support.

To allow the RAID option ROM to access all 6/4 SATA ports, the RAID

option ROM enables and uses the AHCI programming interface by setting the AE

bit, ABAR + 04h[31]. One consequence is that all register settings applicable to

AHCI mode set by the BIOS have to be set in RAID as well. The other consequence

is that the BIOS is required to provide AHCI support to ATAPI SATA devices, which

the RAID option ROM does not handle.

PCH supports stable image-compatible ID. When the alternative ID

enable, D31:F2:Reg 9Ch [7] is not set, the PCH SATA controller will report the

Device ID as 2822h.

It has been observed that some SATA drives will not start spin-up until the

SATA port is enabled by the controller. In order to reduce drive detection time, and

hence the total boot time, system BIOS should enable the SATA port early during

POST (for example, immediately after memory initialization) by setting the Port x

Enable (PxE) bits of the Port Control and Status register, D31:F2:Reg

92h and D31:F5:Reg 92h, to initiate spin-up.

4.6.12. Defining the Memory Map:

In addition to defining the caching behavior of different regions of memory for

consumption by the OS, it is also firmware's responsibility to provide a "map" of

system memory to the OS so that it knows what regions are available for use.The

most widely used mechanism for a boot loader or an OS to determine the system

memory map is to use real mode interrupt service 15h, function E8h, sub-function 20h

(INT15/E820), which must be implemented in firmware.

Region Types: There are several general types of memory regions that are described

by this interface:



Memory (1): General DRAM available for OS consumption.

Reserved (2): DRAM addresses not for OS consumption.

ACPI Reclaim (3): Memory that contains ACPI tables to which firmware

does not require run-time access.

ACPI NVS (4): Memory that contains all ACPI tables to which firmware

requires run-time access. See the applicable ACPI specification for details.

ROM (5): Memory that decodes to nonvolatile storage (for example,

flash).

IOAPIC (6): Memory that is decoded by IOAPICs in the system (must also

be uncached).

LAPIC (7): Memory that is decoded by local APICs in the system (must

also be uncached).

Region Locations: The following regions are typically reserved in a system memory

map:

00000000-0009FFFF: Memory

000A0000-000FFFFF: Reserved

00100000-xxxxxxxx: Memory (The xxxxxxxx indicates that the top of

memory changes based on "reserved" items listed below and any other

design-based reserved regions.)

TSEG: Reserved

Graphics Stolen Memory: Reserved

FEC00000-FEC01000*: IOAPIC

FEE00000-FEE01000*: LAPIC

4.6.13. Loading the Operating System:

Following configuration of the memory map, a boot device is selected from a

prioritized list of potential bootable partitions. The "Load Image" command, or Int

19h, is used to call the OS loader, which in turns load the OS.

5. PROCESSOR INITIALIZATION AND MANAGEMENT



5.1. INITIALIZATION OVERVIEW:

Following power-up or an assertion of the RESET# pin, each processor on the

system bus performs a hardware initialization of the processor (known as hardware

reset) and an optional built-in self-test (BIST). Hardware reset sets each processor’s

registers to a known state and places the processor in real-address mode. It also

invalidates the internal caches; translation lookaside buffers (TLBs) and the branch

target buffer (BTB). At this point, the action taken depends on the processor family:

Pentium 4 and Intel Xeon processors - All the processors on

the system bus (including a single processor in a uniprocessor system)

execute the multiple processor (MP) initialization protocol. The processor

that is selected through this protocol as the bootstrap processor (BSP) then

immediately starts executing software-initialization code in the current code

segment beginning at the offset in the EIP register. The application (non-

BSP) processors (APs) go into a Wait For Startup IPI (SIPI) state while the

BSP is executing initialization code as explained in the previous, “Multiple-

Processor (MP) Initialization,” . Note that in a uniprocessor system, the

single Pentium 4 or Intel Xeon processor automatically becomes the BSP.

P6 family processors - The action taken is the same as for the

Pentium 4 and Intel Xeon processors (as described in the previous

paragraph).

Pentium processors — In either a single- or dual- processor

system, a single Pentium processor is always pre-designated as the primary

processor. Following a reset, the primary processor behaves as follows in

both single- and dual processor systems. Using the dual-processor (DP)

ready initialization protocol, the primary processor immediately starts

executing software-initialization code in the current code segment

beginning at the offset in the EIP register. The secondary processor (if there

is one) goes into a halt state.

Intel486 processor — The primary processor (or single

processor in a uniprocessor system) immediately starts executing software-

initialization code in the current code segment beginning at the offset in the



EIP register. (The Intel486 does not automatically execute a DP or MP

initialization protocol to determine which processor is the primary

processor.)

The software-initialization code performs all system-specific initialization of

the BSP or primary processor and the system logic.

At this point, for MP (or DP) systems, the BSP (or primary) processor wakes

up each AP (or secondary) processor to enable those processors to execute self-

configuration code.

When all processors are initialized, configured, and synchronized, the BSP or

primary processor begins executing an initial operating-system or executive task. The

x87 CPU is also initialized to a known state during hardware reset. x87 FPU software

initialization code can then be executed to perform operations such as setting the

precision of the x87 FPU and the exception masks. No special initialization of the x87

FPU is required to switch operating modes.

Asserting the INIT# pin on the processor invokes a similar response to a

hardware reset. The major difference is that during an INIT, the internal caches,

MSRs, MTRRs, and x87 FPU state are left unchanged (although, the TLBs and BTB

are invalidated as with a hardware reset). An INIT provides a method for switching

from protected to real-address mode while maintaining the contents of the internal

caches.

5.1.1. PROCESSOR STATE AFTER RESET:

Appendixes B shows the state of the flags and other registers following power-

up for the Pentium 4, Intel Xeon, P6 family, and Pentium processors. The state of

control register CR0 is 60000010H (see Fig5.1). This place the processor is in real-

address mode with paging disabled.



Fig5.1. Contents of CR0 Register after Reset

5.1.2. PROCESSOR BUILT-IN SELF-TEST (BIST):

Hardware may request that the BIST be performed at power-up. The EAX

register is cleared (0H) if the processor passes the BIST. A nonzero value in the EAX

register after the BIST indicates that a processor fault was detected. If the BIST is not

requested, the contents of the EAX register after a hardware reset is 0H.

The overhead for performing a BIST varies between processor families. For

example, the BIST takes approximately 30 million processor clock periods to execute

on the Pentium 4 processor. This clock count is model-specific; Intel reserves the

right to change the number of periods for any Intel 64 or IA-32 processor, without

notification.

5.1.3. MODEL AND STEPPING INFORMATION:

Following a hardware reset, the EDX register contains component

identification and revision information (see Fig5.2). For example, the model, family,

and processor type returned for the first processor in the Intel Pentium 4 family is as

follows: model (0000B), family (1111B), and processor type (00B).



Fig5.2. Version Information in the EDX register after Reset

The stepping ID field contains a unique identifier for the processor’s stepping ID or

revision level. The extended family and extended model fields were added to the IA-

32 architecture in the Pentium 4 processors.

5.1.4. FIRST INSTRUCTION EXECUTED:

The first instruction that is fetched and executed following a hardware reset is

located at physical address FFFFFFF0H. This address is 16 bytes below the

processor’s uppermost physical address. The EPROM containing the software

initialization code must be located at this address.

The address FFFFFFF0H is beyond the 1-MByte addressable range of the

processor while in real-address mode. The processor is initialized to this starting

address as follows. The CS register has two parts: the visible segment selector part

and the hidden base address part. In real-address mode, the base address is normally

formed by shifting the 16-bit segment selector value 4 bits to the left to produce a 20-

bit base address. However, during a hardware reset, the segment selector in the CS

register is loaded with F000H and the base address is loaded with FFFF0000H. The

starting address is thus formed by adding the base address to the value in the EIP

register (that is, FFFF0000 + FFF0H = FFFFFFF0H).

The first time the CS register is loaded with a new value after a hardware

reset, the processor will follow the normal rule for address translation in real-address

mode (that is, [CS base address = CS segment selector * 16]). To insure that the base

address in the CS register remains unchanged until the EPROM based software



initialization code is completed, the code must not contain a far jump or far call or

allow an interrupt to occur (which would cause the CS selector value to be changed).

5.2. X87 FPU INITIALIZATION:

Software-initialization code can determine the whether the processor contains

an x87 FPU by using the CPUID instruction. The code must then initialize the x87

FPU and set flags in control register CR0 to reflect the state of the x87 FPU

environment.

A hardware reset places the x87 FPU in the state shown in Appendix B. This

state is different from the state the x87 FPU is placed in following the execution of an

FINIT or FNINIT instruction . If the x87 FPU is to be used, the software-initialization

code should execute an FINIT/FNINIT instruction following a hardware reset. These

instructions, tag all data registers as empty, clear all the exception masks, set the

TOP-of-stack value to 0, and select the default rounding and precision controls setting

(round to nearest and 64-bit precision). If the processor is reset by asserting the INIT#

pin, the x87 FPU state is not changed.

5.2.1. CONFIGURING THE X87 FPU ENVIRONMENT:

Initialization code must load the appropriate values into the MP, EM, and NE

flags of control register CR0. These bits are cleared on hardware reset of the

processor. Table5.1 shows the suggested settings for these flags, depending on the IA-

32 processor being initialized. Initialization code can test for the type of processor

present before setting or clearing these flags. The EM flag determines whether

floating-point instructions are executed by the x87 FPU (EM is cleared) or a device-

not-available exception (#NM) is generated for all floating-point instructions so that

an exception handler can emulate the floating point operation (EM = 1). Ordinarily,

the EM flag is cleared when an x87 FPU or math coprocessor is present and set if they

are not present. If the EM flag is set and no x87 FPU, math coprocessor, or floating-

point emulator is present, the processor will hang when a floating-point instruction is

executed.



EM MP NE IA-32 Processor

1 0 1 Intel486™ SX, Intel386™ DX, and Intel386™ SX

processors only, without the presence of a math

coprocessor.

0 1 1 or 0* Pentium 4, Intel Xeon, P6 family, Pentium, Intel486™

DX, and Intel 487 SX processors, and Intel386 DX and

Intel386 SX processors when a companion math

coprocessor is present.

0 1 1 or 0* More recent Intel 64 or IA-32 processors

Table5.1. Recommended Settings of EM and MP flags on IA-32 Processors

The MP flag determines whether WAIT/FWAIT instructions react to the

setting of the TS flag. If the MP flag is clear, WAIT/FWAIT instructions ignore the

setting of the TS flag; if the MP flag is set, they will generate a device-not-available

exception (#NM) if the TS flag is set. Generally, the MP flag should be set for

processors with an integrated x87 FPU and clear for processors without an integrated

x87 FPU and without a math coprocessor present. However, an operating system can

choose to save the floating-point context at every context switch, in which case there

would be no need to set the MP bit.

The NE flag determines whether unmasked floating-point exceptions are

handled by generating a floating-point error exception internally (NE is set, native

mode) or through an external interrupt (NE is cleared). In systems where an external

interrupt controller is used to invoke numeric exception handlers (such as MS-DOS-

based systems), the NE bit should be cleared.

5.3. CACHE ENABLING:

IA-32 processors (beginning with the Intel486 processor) and Intel 64

processors contain internal instruction and data caches. These caches are enabled by

clearing the CD and NW flags in control register CR0. (They are set during a

hardware reset.) Because all internal cache lines are invalid following reset



initialization, it is not necessary to invalidate the cache before enabling caching. Any

external caches may require initialization and invalidation using a system-specific

initialization and invalidation code sequence.

Depending on the hardware and operating system or executive requirements,

additional configuration of the processor’s caching facilities will probably be

required. Beginning with the Intel486 processor, page-level caching can be controlled

with the PCD and PWT flags in page-directory and page-table entries. Beginning with

the P6 family processors, the memory type range registers (MTRRs) control the

caching characteristics of the regions of physical memory. (For the Intel486 and

Pentium processors, external hardware can be used to control the caching

characteristics of regions of physical memory.) “Memory Cache Control,” for

detailed information on configuration of the caching facilities in the Pentium 4, Intel

Xeon, and P6 family processors and system memory.

5.4. MODEL-SPECIFIC REGISTERS (MSRS):

Most IA-32 processors (starting from Pentium processors) and Intel 64

processors contain a model-specific registers (MSRs). A given MSR may not be

supported across all families and models for Intel 64 and IA-32 processors. Some

MSRs are designated as architectural to simplify software programming; a feature

introduced by an architectural MSR is expected to be supported in future processors.

Non-architectural MSRs are not guaranteed to be supported or to have the same

functions on future processors. MSRs that provide control for a number of hardware

and software-related features include:

Performance-monitoring counters

Debug extensions

Machine-check exception capability and its accompanying machine-

check architecture

MTRRs (“Memory Type Range Registers”).

Thermal and power management.

Instruction-specific support (for example: SYSENTER, SYSEXIT,

SWAPGS, etc.).



Processor feature/mode support (for example: IA32_EFER,

IA32_FEATURE_CONTROL).

The MSRs can be read and written to using the RDMSR and WRMSR

instructions, respectively. When performing software initialization of an IA-32 or

Intel 64 processor, many of the MSRs will need to be initialized to set up things like

performance-monitoring events, run-time machine checks, and memory types for

physical memory. Lists of available performance-monitoring events, “Performance

Monitoring Events”, “Model-Specific Registers (MSRs)” The references earlier in

this section show where the functions of the various groups of MSRs are described in

this manual.

5.5. MEMORY TYPE RANGE REGISTERS (MTRRS):

Memory type range registers (MTRRs) were introduced into the IA-32

architecture with the Pentium Pro processor. They allow the type of caching (or no

caching) to be specified in system memory for selected physical address ranges. They

allow memory accesses to be optimized for various types of memory such as RAM,

ROM, frame buffer memory, and memory-mapped I/O devices. In general, initializing

the MTRRs is normally handled by the software initialization code or BIOS and is not

an operating system or executive function. At the very least all the MTRRs must be

cleared to 0, which selects the uncached (UC) memory type.

5.6. INITIALIZING SSE/SSE2/SSE3/SSSE3 EXTENSIONS:

For processors that contain SSE/SSE2/SSE3/SSSE3 extensions, steps must be

taken when initializing the processor to allow execution of these instructions.

1. Check the CPUID feature flags for the presence of the

SSE/SSE2/SSE3/SSSE3 extensions (respectively: EDX bits 25 and 26,

ECX bit 0 and 9) and support for the FXSAVE and FXRSTOR

instructions (EDX bit 24). Also check for support for the CLFLUSH

instruction (EDX bit 19). The CPUID feature flags are loaded in the EDX

and ECX registers when the CPUID instruction is executed with a 1 in the

EAX register.



2. Set the OSFXSR flag (bit 9 in control register CR4) to indicate that the

operating system supports saving and restoring the

SSE/SSE2/SSE3/SSSE3 execution environment (XXM and MXCSR

registers) with the FXSAVE and FXRSTOR instructions, respectively

3. Set the OSXMMEXCPT flag (bit 10 in control register CR4) to indicate

that the operating system supports the handling of SSE/SSE2/SSE3 SIMD

floating-point exceptions (#XF).

4. Set the mask bits and flags in the MXCSR register according to the mode

of operation desired for SSE/SSE2/SSE3 SIMD floating-point instructions.

5.7. SOFTWARE INITIALIZATION FOR REAL-ADDRESS MODE

OPERATION:

Following a hardware reset (either through a power-up or the assertion of the

RESET# pin) the processor is placed in real-address mode and begins executing

software initialization code from physical address FFFFFFF0H. Software

initialization code must first set up the necessary data structures for handling basic

system functions, such as a real-mode IDT for handling interrupts and exceptions. If

the processor is to remain in real-address mode, software must then load additional

operating-system or executive code modules and data structures to allow reliable

execution of application programs in real-address mode.

If the processor is going to operate in protected mode, software must load the

necessary data structures to operate in protected mode and then switch to protected

mode. The protected-mode data structures that must be loaded are described in

Software Initialization for Protected-Mode Operation.

5.7.1. REAL-ADDRESS MODE IDT:

In real-address mode, the only system data structure that must be loaded into

memory is the IDT (also called the “interrupt vector table”). By default, the address of

the base of the IDT is physical address 0H. This address can be changed by using the

LIDT instruction to change the base address value in the IDTR. Software initialization



code needs to load interrupt- and exception-handler pointers into the IDT before

interrupts can be enabled.

The actual interrupt- and exception-handler code can be contained either in

EPROM or RAM; however, the code must be located within the 1-MByte addressable

range of the processor in real-address mode. If the handler code is to be stored in

RAM, it must be loaded along with the IDT.

5.7.2. NMI INTERRUPT HANDLING:

The NMI interrupt is always enabled (except when multiple NMIs are nested).

If the IDT and the NMI interrupt handler need to be loaded into RAM, there will be a

period of time following hardware reset when an NMI interrupt cannot be handled.

During this time, hardware must provide a mechanism to prevent an NMI interrupt

from halting code execution until the IDT and the necessary NMI handler software is

loaded. Here are two examples of how NMIs can be handled during the initial states

of processor initialization:

o A simple IDT and NMI interrupt handler can be provided in EPROM.

This allows an NMI interrupt to be handled immediately after reset

initialization.

o The system hardware can provide a mechanism to enable and disable

NMIs by passing the NMI# signal through an AND gate controlled by

a flag in an I/O port. Hardware can clear the flag when the processor is

reset, and software can set the flag when it is ready to handle NMI

interrupts.

5.8. SOFTWARE INITIALIZATION FOR PROTECTED-MODE

OPERATION:

The processor is placed in real-address mode following a hardware reset. At

this point in the initialization process, some basic data structures and code modules

must be loaded into physical memory to support further initialization of the processor,

as described in Software Initialization for Real-Address Mode Operation. Before the

processor can be switched to protected mode, the software initialization code must



load a minimum number of protected mode data structures and code modules into

memory to support reliable operation of the processor in protected mode. These data

structures include the following:

o A IDT.

o A GDT.

o A TSS.

o (Optional) An LDT.

o If paging is to be used, at least one page directory and one page table.

o A code segment that contains the code to be executed when the

processor switches to protected mode.

o One or more code modules that contain the necessary interrupt and

exception handlers.

Software initialization code must also initialize the following system registers

before the processor can be switched to protected mode:

o The GDTR.

o (Optional.) The IDTR. This register can also be initialized immediately

after switching to protected mode, prior to enabling interrupts.

o Control registers CR1 through CR4.

o (Pentium 4, Intel Xeon, and P6 family processors only.) The memory

type range registers (MTRRs).

With these data structures, code modules, and system registers initialized, the

processor can be switched to protected mode by loading control register CR0 with a

value that sets the PE flag (bit 0).

5.8.1. PROTECTED-MODE SYSTEM DATA STRUCTURES:

The contents of the protected-mode system data structures loaded into memory

during software initialization, depend largely on the type of memory management the

protected-mode operating-system or executive is going to support: flat, flat with

paging, segmented, or segmented with paging.



To implement a flat memory model without paging, software initialization

code must at a minimum load a GDT with one code and one data-segment descriptor.

A null descriptor in the first GDT entry is also required. The stack can be placed in a

normal read/write data segment, so no dedicated descriptor for the stack is required. A

flat memory model with paging also requires a page directory and at least one page

table (unless all pages are 4 MBytes in which case only a page directory is required).

See Initializing Paging.

Before the GDT can be used, the base address and limit for the GDT must be

loaded into the GDTR register using an LGDT instruction.

A multi-segmented model may require additional segments for the operating

system, as well as segments and LDTs for each application program. LDTs require

segment descriptors in the GDT. Some operating systems allocate new segments and

LDTs as they are needed. This provides maximum flexibility for handling a dynamic

programming environment. However, many operating systems use a single LDT for

all tasks, allocating GDT entries in advance. An embedded system, such as a process

controller, might pre-allocate a fixed number of segments and LDTs for a fixed

number of application programs. This would be a simple and efficient way to

structure the software environment of a real-time system.

5.8.2. INITIALIZING PROTECTED-MODE EXCEPTIONS AND INTERRUPTS:

Software initialization code must at a minimum load a protected-mode IDT

with gate descriptor for each exception vector that the processor can generate. If

interrupt or trap gates are used, the gate descriptors can all point to the same code

segment, which contains the necessary exception handlers. If task gates are used, one

TSS and accompanying code, data, and task segments are required for each exception

handler called with a task gate.

If hardware allows interrupts to be generated, gate descriptors must be

provided in the IDT for one or more interrupt handlers.



Before the IDT can be used, the base address and limit for the IDT must be

loaded into the IDTR register using an LIDT instruction. This operation is typically

carried out immediately after switching to protected mode.

5.8.3. INITIALIZING PAGING:

Paging is controlled by the PG flag in control register CR0. When this flag is

clear (its state following a hardware reset), the paging mechanism is turned off; when

it is set, paging is enabled. Before setting the PG flag, the following data structures

and registers must be initialized:

o Software must load at least one page directory and one page table into

physical memory. The page table can be eliminated if the page

directory contains a directory entry pointing to itself (here, the page

directory and page table reside in the same page), or if only 4-MByte

pages are used.

o Control register CR3 (also called the PDBR register) is loaded with the

physical base address of the page directory.

o (Optional) Software may provide one set of code and data descriptors

in the GDT or in an LDT for supervisor mode and another set for user

mode.

With this paging initialization complete, paging is enabled and the processor is

switched to protected mode at the same time by loading control register CR0 with an

image in which the PG and PE flags are set. (Paging cannot be enabled before the

processor is switched to protected mode.)

5.8.4. INITIALIZING MULTITASKING:

If the multitasking mechanism is not going to be used and changes between

privilege levels are not allowed, it is not necessary load a TSS into memory or to

initialize the task register.

If the multitasking mechanism is going to be used and/or changes between

privilege levels are allowed, software initialization code must load at least one TSS



and an accompanying TSS descriptor. (A TSS is required to change privilege levels

because pointers to the privileged-level 0, 1, and 2 stack segments and the stack

pointers for these stacks are obtained from the TSS.) TSS descriptors must not be

marked as busy when they are created; they should be marked busy by the processor

only as a side-effect of performing a task switch. As with descriptors for LDTs, TSS

descriptors reside in the GDT.

After the processor has switched to protected mode, the LTR instruction can

be used to load a segment selector for a TSS descriptor into the task register. This

instruction marks the TSS descriptor as busy, but does not perform a task switch. The

processor can, however, use the TSS to locate pointers to privilege-level 0, 1, and 2

stacks. The segment selector for the TSS must be loaded before software performs its

first task switch in protected mode, because a task switch copies the current task state

into the TSS.

After the LTR instruction has been executed, further operations on the task

register are performed by task switching. As with other segments and LDTs, TSSs

and TSS descriptors can be either pre-allocated or allocated as needed.

5.8.5. INITIALIZING IA-32E MODE:

On Intel 64 processors, the IA32_EFER MSR is cleared on system reset. The

operating system must be in protected mode with paging enabled before attempting to

initialize IA-32e mode. IA-32e mode operation also requires physical-address

extensions with four levels of enhanced paging structures.

Operating systems should follow this sequence to initialize IA-32e mode:

1. Starting from protected mode, disable paging by setting CR0.PG = 0. Use

the MOV CR0 instruction to disable paging (the instruction must be

located in an identity-mapped page).

2. Enable physical-address extensions (PAE) by setting CR4.PAE = 1.

Failure to enable PAE will result in a #GP fault when an attempt is made

to initialize IA-32e mode.



3. Load CR3 with the physical base address of the Level 4 page map table

(PML4).

4. Enable IA-32e mode by setting IA32_EFER.LME = 1.

5. Enable paging by setting CR0.PG = 1. This causes the processor to set the

IA32_EFER.LMA bit to 1. The MOV CR0 instruction that enables paging

and the following instructions must be located in an identity-mapped page

(until such time that a branch to non-identity mapped pages can be

effected).

64-bit mode paging tables must be located in the first 4 GBytes of physical-

address space prior to activating IA-32e mode. This is necessary because the MOV

CR3 instruction used to initialize the page-directory base must be executed in legacy

mode prior to activating IA-32e mode (setting CR0.PG = 1 to enable paging).

Because MOV CR3 is executed in protected mode, only the lower 32 bits of the

register are written, limiting the table location to the low 4 GBytes of memory.

Software can relocate the page tables anywhere in physical memory after IA-32e

mode is activated.

The processor performs 64-bit mode consistency checks whenever software

attempts to modify any of the enable bits directly involved in activating IA-32e mode

(IA32_EFER.LME, CR0.PG, and CR4.PAE). It will generate a general protection

fault (#GP) if consistency checks fail. 64-bit mode consistency checks ensure that the

processor does not enter an undefined mode or state with unpredictable behavior.

64-bit mode consistency checks fail in the following circumstances:

o An attempt is made to enable or disable IA-32e mode while paging is

enabled.

o IA-32e mode is enabled and an attempt is made to enable paging prior

to enabling physical-address extensions (PAE).

o IA-32e mode is active and an attempt is made to disable physical-

address extensions (PAE).

o If the current CS has the L-bit set on an attempt to activate IA-32e

mode.



o If the TR contains a 16-bit TSS.

5.8.5.1 IA-32E MODE SYSTEM DATA STRUCTURES:

After activating IA-32e mode, the system-descriptor-table registers (GDTR,

LDTR, IDTR, TR) continue to reference legacy protected-mode descriptor tables.

Tables referenced by the descriptors all reside in the lower 4 GBytes of linear-address

space. After activating IA-32e mode, 64-bit operating-systems should use the LGDT,

LLDT, LIDT, and LTR instructions to load the system-descriptor-table registers with

references to 64-bit descriptor tables.

5.8.5.2. IA-32E MODE INTERRUPTS AND EXCEPTIONS:

Software must not allow exceptions or interrupts to occur between the time

IA-32e mode is activated and the update of the interrupt-descriptor-table register

(IDTR) that establishes references to a 64-bit interrupt-descriptor table (IDT). This is

because the IDT remains in legacy form immediately after IA-32e mode is activated.

If an interrupt or exception occurs prior to updating the IDTR, a legacy 32-bit

interrupt gate will be referenced and interpreted as a 64-bit interrupt gate with

unpredictable results. External interrupts can be disabled by using the CLI instruction.

Non-maskable interrupts (NMI) must be disabled using external hardware.

5.8.5.3. 64-BIT MODE AND COMPATIBILITY MODE OPERATION:

IA-32e mode uses two code segment-descriptor bits (CS.L and CS.D) to

control the operating modes after IA-32e mode is initialized. If CS.L = 1 and CS.D =

0, the processor is running in 64-bit mode. With this encoding, the default operand

size is 32 bits and default address size is 64 bits. Using instruction prefixes, operand

size can be changed to 64 bits or 16 bits; address size can be changed to 32 bits.

When IA-32e mode is active and CS.L = 0, the processor operates in

compatibility mode. In this mode, CS.D controls default operand and address sizes

exactly as it does in the IA-32 architecture. Setting CS.D = 1 specifies default operand



and address size as 32 bits. Clearing CS.D to 0 specifies default operand and address

size as 16 bits (the CS.L = 1, CS.D = 1 bit combination is reserved).

Compatibility mode execution is selected on a code-segment basis. This mode

allows legacy applications to coexist with 64-bit applications running in 64-bit mode.

An operating system running in IA-32e mode can execute existing 16-bit and 32-bit

applications by clearing their code-segment descriptor’s CS.L bit to 0.

In compatibility mode, the following system-level mechanisms continue to

operate using the IA-32e-mode architectural semantics:

o Linear-to-physical address translation uses the 64-bit mode extended

page translation mechanism.

o Interrupts and exceptions are handled using the 64-bit mode

mechanisms.

o System calls (calls through call gates and SYSENTER/SYSEXIT) are

handled using the IA-32e mode mechanisms.

5.8.5.4. SWITCHING OUT OF IA-32E MODE OPERATION:

To return from IA-32e mode to paged-protected mode operation. Operating

systems must use the following sequence:

1. Switch to compatibility mode.

2. Deactivate IA-32e mode by clearing CR0.PG = 0. This causes the

processor to set IA32_EFER.LMA = 0. The MOV CR0 instruction used to

disable paging and subsequent instructions must be located in an identity-

mapped page.

3. Load CR3 with the physical base address of the legacy page-table-

directory base address.

4. Disable IA-32e mode by setting IA32_EFER.LME = 0.

5. Enable legacy paged-protected mode by setting CR0.PG = 1

6. A branch instruction must follow the MOV CR0 that enables paging. Both

the MOV CR0 and the branch instruction must be located in an identity-

mapped page. Registers only available in 64-bit mode (R8-R15 and



XMM8-XMM15) are preserved across transitions from 64-bit mode into

compatibility mode then back into 64-bit mode. However, values of R8-

R15 and XMM8-XMM15 are undefined after transitions from 64-bit mode

through compatibility mode to legacy or real mode and then back through

compatibility mode to 64-bit mode.

5.9. MODE SWITCHING:

To use the processor in protected mode after hardware or software reset, a

mode switch must be performed from real-address mode. Once in protected mode,

software generally does not need to return to real-address mode. To run software

written to run in real-address mode (8086 mode), it is generally more convenient to

run the software in virtual-8086 mode, than to switch back to real-address mode.

5.9.1. SWITCHING TO PROTECTED MODE:

Before switching to protected mode from real mode, a minimum set of system

data structures and code modules must be loaded into memory, as described in

“Software Initialization for Protected-Mode Operation.” Once these tables are created,

software initialization code can switch into protected mode.

Protected mode is entered by executing a MOV CR0 instruction that sets the

PE flag in the CR0 register. (In the same instruction, the PG flag in register CR0 can

be set to enable paging.) Execution in protected mode begins with a CPL of 0.

Intel 64 and IA-32 processors have slightly different requirements for

switching to protected mode. To insure upwards and downwards code compatibility

with Intel 64 and IA-32 processors, we recommend that you follow these steps:

1. Disable interrupts. A CLI instruction disables maskable hardware

interrupts. NMI interrupts can be disabled with external circuitry.

(Software must guarantee that no exceptions or interrupts are generated

during the mode switching operation.)

2. Execute the LGDT instruction to load the GDTR register with the base

address of the GDT.



3. Execute a MOV CR0 instruction that sets the PE flag (and optionally the

PG flag) in control register CR0.

4. Immediately following the MOV CR0 instruction, execute a far JMP or far

CALL instruction. (This operation is typically a far jump or call to the next

instruction in the instruction stream.)

5. The JMP or CALL instruction immediately after the MOV CR0 instruction

changes the flow of execution and serializes the processor.

6. If paging is enabled, the code for the MOV CR0 instruction and the JMP

or CALL instruction must come from a page that is identity mapped (that

is, the linear address before the jump is the same as the physical address

after paging and protected mode is enabled). The target instruction for the

JMP or CALL instruction does not need to be identity mapped.

7. If a local descriptor table is going to be used, execute the LLDT instruction

to load the segment selector for the LDT in the LDTR register.

8. Execute the LTR instruction to load the task register with a segment

selector to the initial protected-mode task or to a writable area of memory

that can be used to store TSS information on a task switch.

9. After entering protected mode, the segment registers continue to hold the

contents they had in real-address mode. The JMP or CALL instruction in

step 4 resets the CS register. Perform one of the following operations to

update the contents of the remaining segment registers.

o Reload segment registers DS, SS, ES, FS, and GS. If the ES,

FS, and/or GS registers are not going to be used, load them

with a null selector.

o Perform a JMP or CALL instruction to a new task, which

automatically resets the values of the segment registers and

branches to a new code segment.

10. Execute the LIDT instruction to load the IDTR register with the address

and limit of the protected-mode IDT.

11. Execute the STI instruction to enable maskable hardware interrupts and

perform the necessary hardware operation to enable NMI interrupts.



Random failures can occur if other instructions exist between steps 3 and 4 above.

Failures will be readily seen in some situations, such as when instructions that

reference memory are inserted between steps 3 and 4 while in system management

mode.

5.9.2. SWITCHING BACK TO REAL-ADDRESS MODE:

The processor switches from protected mode back to real-address mode if

software clears the PE bit in the CR0 register with a MOV CR0 instruction. A

procedure that reenters real-address mode should perform the following steps:

1. Disable interrupts. A CLI instruction disables maskable hardware

interrupts. NMI interrupts can be disabled with external circuitry.

2. If paging is enabled, perform the following operations:

a. Transfer program control to linear addresses that are identity

mapped to physical addresses (that is, linear addresses equal

physical addresses).

b. Insure that the GDT and IDT are in identity mapped pages.

c. Clear the PG bit in the CR0 register.

d. Move 0H into the CR3 register to flush the TLB.

3. Transfer program control to a readable segment that has a limit of 64

Kbytes (FFFFH). This operation loads the CS register with the segment

limit required in real-address mode.

4. Load segment registers SS, DS, ES, FS, and GS with a selector for a

descriptor containing the following values, which are appropriate for real-

address mode:

a. Limit = 64 KBytes (0FFFFH)

b. Byte granular (G = 0)

c. Expand up (E = 0)

d. Writable (W = 1)

e. Present (P = 1)

f. Base = any value



The segment registers must be loaded with non-null segment selectors or

the segment registers will be unusable in real-address mode. Note that if

the segment registers are not reloaded, execution continues using the

descriptor attributes loaded during protected mode.

5. Execute an LIDT instruction to point to a real-address mode interrupt table

that is within the 1-MByte real-address mode address range.

6. Clear the PE flag in the CR0 register to switch to real-address mode.

7. Execute a far JMP instruction to jump to a real-address mode program.

This operation flushes the instruction queue and loads the appropriate

base-address value in the CS register.

8. Load the SS, DS, ES, FS, and GS registers as needed by the real-address

mode code. If any of the registers are not going to be used in real-address

mode, write 0s to them.

9. Execute the STI instruction to enable maskable hardware interrupts and

perform the necessary hardware operation to enable NMI interrupts.



6. SPECIFIC REQUIREMENTS

6.1. HARDWARE:

As the Reset is mainly targeted for the validation of the CPU and some

platform components, the following are the details

6.1.1. PLATFORM:

The Platform is the just like an ordinary mother board which can be used to

connect multiple CPU (IA 32 architecture). The given is the general description of the

Motherboard

Fig6.1. Diagram of Mother Board



A motherboard provides the electrical connections by which the other

components of the system communicate. Unlike a backplane, it also connects

the central processing unit and hosts other subsystems and devices.

A typical desktop computer has its microprocessor, main memory, and other

essential components connected to the motherboard. Other components such

as external storage, controllers for video display and sound, and peripheral devices

may be attached to the motherboard as plug-in cards or via cables, in modern

computers it is increasingly common to integrate some of these peripherals into the

motherboard itself.

An important component of a motherboard is the microprocessor's

supporting chipset, which provides the supporting interfaces between the CPU and the

various buses and external components. This chipset determines, to an extent, the

features and capabilities of the motherboard.

Modern motherboards include, at a minimum:

Sockets (or slots) in which one or more microprocessors may be installed. In

the case of CPUs in BGA packages, such as the VIA C3, the CPU is directly

soldered to the motherboard.

Slots into which the system's main memory is to be installed (typically in the

form of DIMM modules containing DRAM chips)

A chipset which forms an interface between the CPU's front-side bus, main

memory, and peripheral buses

Non-volatile memory chips (usually Flash ROM in modern motherboards)

containing the system's firmware or BIOS

A clock generator which produces the system clock signal to synchronize the

various components

Slots for expansion cards (these interface to the system via the buses supported

by the chipset)

Power connectors, which receive electrical power from the computer power

supply and distribute it to the CPU, chipset, main memory, and expansion

cards. Some graphics cards (e.g. GeForce 8 and Radeon R600) require more


http://en.wikipedia.org/wiki/Radeon_R600

http://en.wikipedia.org/wiki/GeForce_8

http://en.wikipedia.org/wiki/Graphics_card

http://en.wikipedia.org/wiki/Computer_power_supply

http://en.wikipedia.org/wiki/Computer_power_supply

http://en.wikipedia.org/wiki/Expansion_card

http://en.wikipedia.org/wiki/Clock_signal

http://en.wikipedia.org/wiki/Clock_generator

http://en.wikipedia.org/wiki/BIOS

http://en.wikipedia.org/wiki/Firmware

http://en.wikipedia.org/wiki/Flash_ROM

http://en.wikipedia.org/wiki/Non-volatile_memory

http://en.wikipedia.org/wiki/Bus_(computing)

http://en.wikipedia.org/wiki/Front-side_bus

http://en.wikipedia.org/wiki/Chipset

http://en.wikipedia.org/wiki/Dynamic_random_access_memory

http://en.wikipedia.org/wiki/DIMM

http://en.wikipedia.org/wiki/VIA_C3

http://en.wikipedia.org/wiki/Ball_grid_array

http://en.wikipedia.org/wiki/Microprocessor

http://en.wikipedia.org/wiki/CPU_socket


http://en.wikipedia.org/wiki/Peripheral

http://en.wikipedia.org/wiki/Sound_card

http://en.wikipedia.org/wiki/Video_card

http://en.wikipedia.org/wiki/External_storage

http://en.wikipedia.org/wiki/Primary_storage


http://en.wikipedia.org/wiki/Desktop_computer

http://en.wikipedia.org/wiki/Central_processing_unit


power than the motherboard can provide, and thus dedicated connectors have

been introduced to attach them directly to the power supply. Most disk

drives also connect to the power supply via dedicated connectors.

Additionally, nearly all motherboards include logic and connectors to support

commonly used input devices, such as PS/2 connectors for a mouse and keyboard.

Early personal computers such as the Apple II or IBM PC included only this minimal

peripheral support on the motherboard. Occasionally video interface hardware was

also integrated into the motherboard; for example, on the Apple II and rarely on IBM-

compatible computers such as the IBM PC Jr. Additional peripherals such as disk

controllers and serial ports were provided as expansion cards.

Given the high thermal design power of high-speed computer CPUs and

components, modern motherboards nearly always include heat sinks and mounting

points for fans to dissipate excess heat.

CPU SOCKETS:

A CPU socket or slot is an electrical component that attaches to a printed

circuit board (PCB) and is designed to house a CPU (also called a microprocessor). It

is a special type of integrated circuit socket designed for very high pin counts. A CPU

socket provides many functions, including a physical structure to support the CPU,

support for a heat sink, facilitating replacement (as well as reducing cost), and most

importantly, forming an electrical interface both with the CPU and the PCB. CPU

sockets on the motherboard can most often be found in most desktop and server

computers (laptops typically use surface mount CPUs), particularly those based on

the Intel x86 architecture. A CPU socket type and motherboard chipset must support

the CPU series and speed.

INTEGRATED PERIPHERALS:

With the steadily declining costs and size of integrated circuits, it is now

possible to include support for many peripherals on the motherboard. By combining

many functions on one PCB, the physical size and total cost of the system may be


http://en.wikipedia.org/wiki/Printed_circuit_board

http://en.wikipedia.org/wiki/Peripherals

http://en.wikipedia.org/wiki/Integrated_circuit

http://en.wikipedia.org/wiki/Intel_x86

http://en.wikipedia.org/wiki/Server_computer

http://en.wikipedia.org/wiki/Server_computer

http://en.wikipedia.org/wiki/CPU_socket

http://en.wikipedia.org/wiki/Computer_fan

http://en.wikipedia.org/wiki/Heat_sink

http://en.wikipedia.org/wiki/Thermal_design_power

http://en.wikipedia.org/wiki/Serial_port

http://en.wikipedia.org/wiki/Disk_controller


http://en.wikipedia.org/wiki/IBM_PC_Jr

http://en.wikipedia.org/wiki/IBM_PC

http://en.wikipedia.org/wiki/Apple_II

http://en.wikipedia.org/wiki/Personal_computer

http://en.wikipedia.org/wiki/Computer_mouse

http://en.wikipedia.org/wiki/PS/2_connector

http://en.wikipedia.org/wiki/Disk_drive

http://en.wikipedia.org/wiki/Disk_drive


reduced; highly integrated motherboards are thus especially popular in small form

factor and budget computers.

For example, the ECS RS485M-M, a typical modern budget motherboard for

computers based on AMD processors, has on-board support for a very large range of

peripherals:

Disk controllers for a floppy disk drive, up to 2 PATA drives, and up to

SATA drives (including RAID 0/1 support)

integrated graphics controller supporting 2D and 3D graphics,

with VGA and TV output

integrated sound card supporting 8-channel (7.1) audio and S/PDIF output

Fast Ethernet network controller for 10/100 Mbit networking

USB 2.0 controller supporting up to 12 USB ports

IrDA controller for infrared data communication (e.g. with an IrDA-

enabled cellular phone or printer)

Temperature, voltage, and fan-speed sensors that allow software to

monitor the health of computer components

Expansion cards to support all of these functions would have cost hundreds of dollars

even a decade ago; however, such highly integrated motherboards are available for as

little as $30 in the US.

PERIPHERAL CARD SLOTS:

A typical motherboard of 2012 will have a different number of connections

depending on its standard.

A standard ATX motherboard will typically have two or three PCI-E 16x

connection for a graphics card, one or two legacy PCI slots for various expansion

cards, and one or two PCI-E 1x (which has superseded PCI). A

standard EATX motherboard will have two to four PCI-Express 16x connection for

graphics cards, and a varying number of PCI and PCI-E 1x slots. It can sometimes

also have a PCI-E 4x slot. (This varies between brands and models.)


http://en.wikipedia.org/wiki/PCI-Express

http://en.wikipedia.org/wiki/EATX

http://en.wikipedia.org/wiki/Conventional_PCI

http://en.wikipedia.org/wiki/Software

http://en.wikipedia.org/wiki/Infrared_Data_Association

http://en.wikipedia.org/wiki/Universal_Serial_Bus

http://en.wikipedia.org/wiki/Megabit

http://en.wikipedia.org/wiki/Network_card

http://en.wikipedia.org/wiki/Fast_Ethernet

http://en.wikipedia.org/wiki/S/PDIF

http://en.wikipedia.org/wiki/Sound_card#Integrated_sound_on_the_PC

http://en.wikipedia.org/wiki/TV-out

http://en.wikipedia.org/wiki/Video_Graphics_Array

http://en.wikipedia.org/wiki/3D_computer_graphics

http://en.wikipedia.org/wiki/2D_computer_graphics

http://en.wikipedia.org/wiki/Integrated_Graphics#Integrated_graphics_solutions

http://en.wikipedia.org/wiki/RAID#Standard_RAID_levels

http://en.wikipedia.org/wiki/Serial_ATA

http://en.wikipedia.org/wiki/AT_Attachment

http://en.wikipedia.org/wiki/Floppy_disk_drive


http://en.wikipedia.org/wiki/Advanced_Micro_Devices

http://en.wikipedia.org/wiki/Elitegroup_Computer_Systems

http://en.wikipedia.org/wiki/Small_form_factor

http://en.wikipedia.org/wiki/Small_form_factor


Some motherboards have two or more PCI-E 16x slots, to allow more than 2

monitors without special hardware, or use a special graphics technology

called SLI (for NVidia) and Crossfire (for ATI). These allow 2 to 4 graphics cards to

be linked together, to allow better performance in intensive graphical computing

tasks, such as gaming, video editing, et cetera.

NORTH BRIDGE:

The northbridge is part of a family of Intel microchips, used to manage data

communications between a CPU and a motherboard within Intel chipsets based

on Intel's Hub Architecture. It is designed to be paired with a second support chip

known as a Southbridge.

The northbridge has historically been one of the two chips in the core

logic chipset on a PC motherboard, the other being the Southbridge. Increasingly

these functions have migrated to the CPU chip itself, beginning with memory and

graphics controllers.

The northbridge typically handles communications among the CPU, in some

cases RAM, and PCI Express (or AGP) video cards, and the Southbridge. Some

Northbridge’s also contain integrated video controllers, also known as a Graphics and

Memory Controller Hub (GMCH) in Intel systems. Because different processors and

RAM require different signaling, a given northbridge will typically work with only

one or two classes of CPUs and generally only one type of RAM.

There are a few chipsets that support two types of RAM (generally these are

available when there is a shift to a new standard). For example, the northbridge from

the NVidia nForce2 chipset will only work with Socket A processors combined

with DDR SDRAM; the Intel i875 chipset will only work with systems using Pentium

4processors or Celeron processors that have a clock speed greater than 1.3 GHz and

utilize DDR SDRAM, and the Intel i915g chipset only works with the Intel Pentium 4

and the Celeron, but it can use DDR or DDR2 memory.


http://en.wikipedia.org/wiki/DDR2_SDRAM

http://en.wikipedia.org/wiki/Celeron

http://en.wikipedia.org/wiki/Pentium_4

http://en.wikipedia.org/wiki/Pentium_4

http://en.wikipedia.org/wiki/Intel

http://en.wikipedia.org/wiki/DDR_SDRAM

http://en.wikipedia.org/wiki/Socket_A

http://en.wikipedia.org/wiki/NForce2

http://en.wikipedia.org/wiki/Nvidia

http://en.wikipedia.org/wiki/Southbridge_(computing)

http://en.wikipedia.org/wiki/Accelerated_Graphics_Port

http://en.wikipedia.org/wiki/PCI_Express

http://en.wikipedia.org/wiki/Random-access_memory



http://en.wikipedia.org/wiki/PC_motherboard



http://en.wikipedia.org/wiki/Intel_Hub_Architecture


http://en.wikipedia.org/wiki/Motherboard

http://en.wikipedia.org/wiki/CPU

http://en.wikipedia.org/wiki/I/O

http://en.wikipedia.org/wiki/I/O

http://en.wikipedia.org/wiki/Microchip


http://en.wikipedia.org/wiki/ATI_(brand)

http://en.wikipedia.org/wiki/ATI_CrossFire

http://en.wikipedia.org/wiki/Nvidia

http://en.wikipedia.org/wiki/Scalable_Link_Interface


SOUTHBRIDGE:

The Southbridge is one of the two chips in the core logic chipset on a personal

computer (PC) motherboard, the other being the northbridge. The southbridge

typically implements the slower capabilities of the motherboard in a

northbridge/southbridge chipset computer architecture. In Intel chipset systems, the

southbridge is namedInput/Output Controller Hub (ICH). AMD, beginning with

its Fusion APUs, has given the label FCH, or Fusion Controller Hub, to its

southbridge.

The southbridge can usually be distinguished from the northbridge by not

being directly connected to the CPU. Rather, the northbridge ties the southbridge to

the CPU. Through the use of controller integrated channel circuitry, the northbridge

can directly link signals from the I/O units to the CPU for data control and access.

A southbridge chipset handles all of a computer's I/O functions, such as USB,

audio, serial, the system BIOS, the ISA bus, the interrupt controller and the IDE

channels. Different combinations of Southbridge and Northbridge chips are possible,

but these two kinds of chip must be designed to work together; there is no industry-

wide standard for interoperability between different core logic chipset designs.

Traditionally, the interface between a northbridge and southbridge was the PCI bus.

The main bridging interfaces used now are DMI (Intel) and UMI (AMD).

6.1.2. HOST PC:

The platform which I am validating doesn’t have an operating system so we

will be using a Host PC to interact with the platform

6.1.3. IN TARGET PROBE:

In-target probe, or ITP is a device used in computer hardware and microprocessor

design, to control a target microprocessor or similar ASIC at the register level. It

generally allows full control of the target device and allows the computer engineer

access to individual processor registers, program counter, and instructions within the

device. It allows the processor to be single-stepped or for breakpoints to be set.


http://en.wikipedia.org/wiki/Breakpoint

http://en.wikipedia.org/wiki/Program_animation

http://en.wikipedia.org/wiki/Instruction_set

http://en.wikipedia.org/wiki/Program_counter

http://en.wikipedia.org/wiki/Processor_register

http://en.wikipedia.org/wiki/ASIC


http://en.wikipedia.org/wiki/Microprocessor_design

http://en.wikipedia.org/wiki/Microprocessor_design

http://en.wikipedia.org/wiki/Computer_hardware

http://en.wikipedia.org/wiki/AMD

http://en.wikipedia.org/wiki/UMI_AMD


http://en.wikipedia.org/wiki/Direct_Media_Interface


http://en.wikipedia.org/wiki/AMD_Fusion

http://en.wikipedia.org/wiki/I/O_Controller_Hub


http://en.wikipedia.org/wiki/Northbridge_(computing)

http://en.wikipedia.org/wiki/Motherboard




http://en.wikipedia.org/w/index.php?title=Core_logic&action=edit&redlink=1


6.2. SOFTWARE:

The following are the software which I have used

PYTHON:

The Python is scripting language which I will be using in the reset validation.

Python is a general-purpose, interpreted high-level programming language whose

design philosophy emphasizes code readability


http://en.wikipedia.org/wiki/Readability

http://en.wikipedia.org/wiki/High-level_programming_language

http://en.wikipedia.org/wiki/Interpreted_language

http://en.wikipedia.org/wiki/General-purpose_programming_language


7. RESET VALIDATION

7.1. RESET STEPS:

The Next Generation Xeon Processors have distributed cache and significant

amount of IO integration on chip. In addition it supports advanced power

management technologies. These Processors are intended to be used in the various

platform configurations ranging from single socket to up to 4 or 8 sockets.

The validation of both warm and cold reset will be done in 5 steps.

The following steps give a brief idea how reset happens

Step0: assertion of xxPWRGOOD

Step1:xxPWRGOOD assertion to xxRESET# de-assertion

Step2: xxReset# de-assertion to start of ucode execution

Step3:ucode execution through BIOS

Step4:BIOS execution through writing I_AM_DONE

In Step0 the start condition is power off and end condition is assertion of the

xxPWRGOOD. Here in this step the platform will be provided with the minimum

voltage levels.

In the second step the controller unit begins the execution of the microcode,

here all the basic fuses will be de-asserted, and the configuration registers will be

loaded.

Third step will take care of assigning the logical id’s to the processors(multi-

processor configuration) and initialization of the message channels and loads the

patch which comes with the processor.

Fourth and Fifth steps will run the BIOS patch codes and BIOS will enable all

the features on the platform and signals the controller unit by setting the reset done

bit. The flow chart for the test phases is show



Fig7.1. Basic Flow chart of Reset



7.2. TESTS:

The following are test involved in the validation of different reset types.

S.no Test

1 Manual Cold Reset

2 Manual Warm Reset

3 BIOS initiated Reset

4 BIOS flow break reset

Table7.1. Test cases

7.3. TEST DESCRIPTION:

7.3.1. MANUAL COLD RESET:

Cold Resets will be tested by manually imitating a Cold Reset. Once the Power cycle

has occurred, the expected recovery occurred is verified by checking the various

status and configuration bits. Test also includes checking the various platform

components, sticky registers behavior and memory.

For validating the cold reset the platform will be setup according to the required

topology.

The following is the algorithm

Algorithm for Cold Reset:

i. Start

ii. Platform is in Stable state

iii. Configuration details are collected

iv. Cold reset is issued by cmd (writing into the port)

v. If platform booted = True go to step vi else report failure and stop

vi. If BIOS completion = True go to step vii else report failure and stop

vii. If Collected details == Ideal config data report Reset successful else

report failure and stop

viii. Stop



Fig7.2. Flow chart of cold reset



7.3.2. MANUAL WARM RESET:

Warm Resets will be tested by manually imitating a Cold Reset. Once the Power

cycle has occurred, the expected recovery occurred is verified by checking the various

status and configuration bits. Test also includes checking the various platform

components, sticky registers behavior and memory.

For validating the cold reset the platform will be setup according to the required

topology.

The following is the algorithm

Algorithm for Cold Reset:

i. Start

ii. Platform is in Stable state

iii. Configuration details are collected

iv. Write value xyz in to Sticky register

v. Warm reset is issued by cmd (writing into the port)

vi. If platform booted = True go to step vii else go to step x

vii. If BIOS completion = True go to step viii else go to step x

viii. If sticky registers == xyz then go to step ix else go to step x

ix. If Collected details == Ideal config data go to step xi else step x

x. Reset failure, dump the failure condition step xii

xi. Reset Successful

xii. Stop

Here the platform components are verified by doing warm reset cycling with checks

in place to verify the CPU and chipset errors, proper detection of all system memory

and devices during each cycle.

The Flow chart for the Warm reset is given in diagram.



Fig7.3. Flow chart for Warm Reset



7.3.3. BIOS INITIATED RESET:

The test is intended to issue a reset by the BIOS. The BIOS reset test can be

run in both mode, i.e. in cold reset mode and in warm reset mode

The test is intended to issue a reset by the BIOS. The BIOS reset test can be run in

both mode, i.e. in cold reset mode and in warm reset mode

Cold Resets will be tested by running the BIOS “reset test” in cold reset mode.

Warm resets will be tested by running the BIOS “ reset test” in warm reset mode.

The Basic algorithm for the BIOS Initiated reset is , BIOS will boot as normal for a

cold reset / warm reset then do system checks and instead of passing control to the OS

it will perform a Cold reset/ Warm reset

7.3.4. BIOS FLOW BREAK RESET:

Here in this test the main focus is to give control to the user. The user can

break the boot flow at particular break points in the BIOS, and can check the desired

features at that break point. This test case enables validation at several key points of

the BIOS boot flow.

The algorithm for the BIOS flow Break reset is

i. System is booted properly

ii. Program the BIOS register with the Value of Postcode intended to

break at

iii. Issue a warm Reset / Cold reset

iv. BIOS break at Postcode value go to step v else step vii

v. Checking the signals. If signals are correct step vi else wrong step

viii

vi. BIOS Break pass

vii. Next BIOS break Value repeat from step ii

viii. BIOS break fail step

ix. Stop



The Following Flow chart will give a brief flow of the BIOS flow break reset

Fig7.4. Flow chart for BIOS flow breaks reset

The test scripts were return for the different resets using python scripting language,

these test has been ran on the host machine to issue reset and then collect the

configuration details. Reset tests were run on different platform with different

configurations and different topologies setup and with various BIOS versions.



8. CONCLUSIONS AND FUTURE WORK

Reset Validation of Different Reset types that are Warm reset, Cold reset,

BIOS initiated Reset and BIOS Flow break reset was successful tested. The Memory,

PCI Express, Processor interconnections and component features were collected as

per the reset flows and were compared with the original data for the correctness and

various component register were checked for correct values. The test scripts are fully

automated for different reset types. The automation of the tests has improved the

validation process in the following ways:

o The automation of the test for issuing multiple resets and check the

platform correctness reduced the manual effort of issuing the reset and

checking.

o The scripts were fully automated in logging the platform details if the

reset doesn’t go fine for debugging purpose.

Reset scripts need to developed to issues resets from the OS and make sure

that the platform comes and OS boots fine.

The further tests can be automated to run some basic memory transaction

using OS and trigger the reset (cold/warm) when memory transaction is happening

and check the OS boots fine without any hang.



BIBLIOGRAPHY

IA 32 Architecture Software developer manual

Intel internal reference manuals

Intel internal sites

http://www.python.org/

http://code.google.com/edu/languages/google-python-class/

Validating the Intel Pentium Processors

o Bob Bentley, Desktop Platforms Group, Intel Corp.

o Rand Gray, Desktop Platforms Group, Intel Corp.

Intel Architecture Boot Flow – http://www.drdobbs.com/parallel/booting-an-intel-

architecture-system-par

POST CODES for Intel Server Motherboards -

http://www.postcodemaster.com/intelstl2.shtml

General Operating System Boot

Sequence-http://duartes.org/gustavo/blog/post/how-computers-boot-up


http://duartes.org/gustavo/blog/post/how-computers-boot-up

http://www.postcodemaster.com/intelstl2.shtml

http://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par

http://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par

http://code.google.com/edu/languages/google-python-class/

http://www.python.org/


Appendix A

Intel STL2 Server Motherboard BIOS Post Codes

The following are the Post codes which give the description of about the each POST

code value and its description.

POST Code Description02- Verify Real Mode04 - Get Processor type06 - Initialize system hardware08 - Initialize chipset registers with initial POST values09 - Set in POST flag0A - Initialize Processor registers0B - Enable Processor cache0C - Initialize caches to initial POST values0E - Initialize I/O0F - Initialize the local bus IDE10 - Initialize Power Management11 - Load alternate registers with initial POST values12 - Restore Processor control word during warm boot14 - Initialize keyboard controller16 - BIOS ROM checksum18 - 8254 timer initialization1A - 8237 DMA controller initialization1C - Reset Programmable Interrupt Controller20 - Test DRAM refresh22 - Test 8742 Keyboard Controller24 - Set ES segment register to 4 GB

28 - Autosize DRAM, system BIOS stops execution here if the BIOS does not detect any usable memory DIMMs

2A - Clear 8 MB base RAM2C - Base RAM failure, BIOS stops execution here if entire memory is bad32 - Test Processor bus-clock frequency34 - Test CMOS35 - RAM Initialize alternate chipset registers36 - Warm start shut down37 - Reinitialize the chipset38 - Shadow system BIOS ROM39 - Reinitialize the cache3A - Autosize cache3C - Configure advanced chipset registers3D - Load alternate registers with CMOS values



40 - Set Initial Processor speed new42 - Initialize interrupt vectors44 - Initialize BIOS interrupts46 - Check ROM copyright notice47 - Initialize manager for PCI Option ROMs48 - Check video configuration against CMOS49 - Initialize PCI bus and devices4A - Initialize all video adapters in system4B - Display QuietBoot screen4C - Shadow video BIOS ROM4E - Display copyright notice50 - Display Processor type and speed52 - Test keyboard54 - Set key click if enabled55 - USB initialization56 - Enable keyboard58 - Test for unexpected interrupts5A - Display prompt 'Press F2 to enter SETUP'5C - Test RAM between 512 and 640 k60 - Test extended memory62 - Test extended memory address lines64 - Jump to UserPatch166 - Configure advanced cache registers68 - Enable external and processor caches6A - Display external cache size6B - Load custom defaults if required6C - Display shadow message6E - Display non-disposable segments70 - Display error messages72 - Check for configuration errors74 - Test real-time clock76 - Check for keyboard errors7A - Test for key lock on7C - Set up hardware interrupt vectors7D - Intelligent system monitoring7E - Test coprocessor if present82 - Detect and install external RS232 ports85 - Initialize PC-compatible PnP ISA devices86 - Re-initialize on board I/O ports88 - Initialize BIOS Data Area8A - Initialize Extended BIOS Data Area8C - Initialize floppy controller90 - Initialize hard disk controller



91 - Initialize local bus hard disk controller92 - Jump to UserPatch293 - Build MPTABLE for multi-processor boards94 - Disable A20 address line95 - Install CD-ROM for boot96 - Clear huge ES segment register

98 - Search for option ROMs. One long, two short beeps on checksum failure

9A - Shadow option ROMs9C - Set up Power Management9E - Enable hardware interruptsA0 - Set time of dayA2 - Check key lockA4 - Initialize typematic rateA8 - Erase F2 promptAA - Scan for F2 key strokeAC - Enter SETUPAE - Clear in-POST flagB0 - Check for errorsB2 - POST done - prepare to boot Operating SystemB4 - One short beep before bootB5 - Display MultiBoot menuB6 - Check password, password is checked before option ROM scanB7 - ACPI initializationB8 - Clear global descriptor tableBC - Clear parity checkersBE - Clear screen (optional)BF - Check virus and backup remindersC0 - Try to boot with INT 19C8 - Forced shutdownC9 - Flash recoveryDO - Interrupt handler errorD2 - Unknown interrupt errorD4 - Pending interrupt errorD6 - Initialize option ROM errorD8 - Shutdown errorDA - Extended Block MoveDC - Shutdown 10 errorE0 - Initialize chip setE1 - Initialize bridgeE2 - Initialize processorE3 - Initialize timerE4 - Initialize system I/O



E5 - Check forced recovery bootE6 - Validate checksumE7 - Go to BIOSE8 - Initialize processorsE9 - Set 4 GB segment limitsEA - Perform platform initializationEB - Initialize PIC and DMAEC - Initialize memory typeED - Initialize memory sizeEE - Shadow boot blockEF - Test system memoryF0 - Initialize interrupt servicesF1 - Initialize real time clockF2 - Initialize videoF3 - Initialize beeperF4 - Initialize bootF5 - Restore segment limits to 64 KBF6 - Boot mini DOSF7 - Boot full DOS



Appendix B

IA-32 Processor States Following Power-up, Reset, or INIT

Register Pentium 4 and Intel Xeon Processor

P6 Family Processor

Pentium Processor

EFLAGS1 00000002H 00000002H 00000002HEIP 0000FFF0H 0000FFF0H 0000FFF0HCRO 600000010H 600000010H 600000010HCR2,CR3,Cr4 00000000H 00000000H 00000000HCS Selector = F000H;

Base = FFFF0000H; Limit = FFFFH; AR = Present, R/W,Accessed

Selector = F000H; Base = FFF0000H; Limit = FFFFH; AR = Present, R/W,Accessed

Selector = F000H; Base =FFFF0000H; Limit = FFFFH; AR = Present, R/W,Accessed

SS, DS, ES, FS, GS Selector = 0000H; Base = 00000000H; Limit = FFFFH; AR = Present, R/W,Accessed

Selector = 0000H; Base =00000000H; Limit = FFFFH; AR = Present, R/W,Accessed

Selector = 0000H; Base = 0000000H; Limit = FFFFH; AR = Present, R/W,Accessed

EDX 00000FxxH 000n06xxH 000005xxHEAX 0 0 0EBX,ECX,ESI,EDI,EBP,ESP

00000000H 00000000H 00000000H

ST0 through ST7

x87 FPU ControlWord

x87 FPU StatusWord

x87 FPU TagWord

x87 FPU DataOperand and CSSeg. Selectors

x87 FPU DataOperand and Inst.Pointers

MM0 through

Pwr up or Reset: +0.0FINIT/FNINIT: UnchangedPwr up or Reset: 0040HFINIT/FNINIT: 037FHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset: 5555HFINIT/FNINIT: FFFFHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset:00000000HFINIT/FNINIT: 00000000H

Pwr up or

Pwr up or Reset: +0.0FINIT/FNINIT: UnchangedPwr up or Reset: 0040HFINIT/FNINIT:037FHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset: 5555HFINIT/FNINIT: FFFFHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset:00000000HFINIT/FNINIT: 00000000H

Pentium II and

Pwr up or Reset: +0.0FINIT/FNINIT: UnchangedPwr up or Reset: 0040HFINIT/FNINIT: 037FHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset: 5555HFINIT/FNINIT: FFFFHPwr up or Reset: 0000HFINIT/FNINIT: 0000HPwr up or Reset:00000000HFINIT/FNINIT: 00000000H

Pentium with



MM75 Reset:0000000000000000HINIT orFINIT/FNINIT:unchanged

Pentium III processors only Pwr up or Reset:0000000000000000HINIT orFINIT/FNINIT:unchanged

MMX Pwr up or Reset:0000000000000000HINIT orFINIT/FNINIT:unchanged

XMM0 throughXMM7

Pwr up or Reset:0000000000000000H INIT: Unchanged

Pentium II and Pentium III processors only Pwr up or Reset:0000000000000000H INIT:nchanged

NA

MXCSR Pwr up or Reset: 1F80H INIT: Unchanged

Pentium III processor only-Pwr up or Reset:1F80HINIT: Unchanged

NA

GDTR, IDTR Base = 00000000H Limit = FFFFH AR = Present, R/W

Base = 00000000H Limit = FFFFH AR = Present, R/W

Base = 00000000H Limit = FFFFH AR = Present, R/W

LDTR, TaskRegister

Selector = 0000H Base = 00000000H Limit = FFFFHAR = Present, R/W



DR0, DR1, DR2,DR3 000000000H 000000000H 000000000HDR6 FFFF0FF0H FFFF0FF0H FFFF0FF0HDR7 00000400H 00000400H 00000400HTime-Stamp CounterPower up or

Reset:0H INIT: Unchanged

Power up or Reset:0H INIT: Unchanged

Power up or Reset:0H INIT: Unchanged

Machine-CheckArchitecture

Power up or Reset:undefined INIT: Unchanged

Power up or Reset:Undefined INIT: Unchanged

Not Implemented

APIC Power up or Reset:Enabled INIT: Unchanged

Power up or Reset:Enabled INIT: Unchanged

Power up or Reset:Enabled INIT: Unchanged


Documents

Final_report Jayanth.docx