Intel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Exa

This chapter is OS dependent. We chose to follow the kernel initialization process in the linear order in which it occurs. We begin with a discussion of what happens _disibledevent=>imageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
We begin with a discussion of BIOS and Open Firmware, which is the first code that runs in the x86 upon power _disibledevent=>
1. BIOS
For x86 systems, this is where the system BIOS resides. The Basic Input Output System (BIOS) is a block of hardware-specific system initialization code that boots the system. In x86 systems, the boot loader and, in turn Linux, depend _disibledevent=>
2. Boot Loaders
Boot loaders are programs that reside _disibledevent=>imageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
The MBR's partition table holds information pertinent to each of the hard disk primary partitions. The following table shows what each 16-byte entry of the MBR's partition table looks like:
imageimageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
At the end of BIST and hardware identification, the system initialization code (BIOS) accesses the hard drive controller to read the MBR. After the type of boot drive is identified, _disibledevent=>imageimageimageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
2.1 Common Bootloader—GRUB(Grand Unified Bootloader)
GRUB is an x86-based bootloader that's used to load Linux.
GRUB recognizes filesystems _disibledevent=>imageimageimageimageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
imageimageimageimageimageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
imageimageimageimageimageimageimageIntel® IA-32 Architecture Learning 3.2 PROCESSOR MANAGEMENT AND INITIALIZATION---Taking Linux As Example
This configuration specifies that Linux boots and loads the executable image to linear address 0x9000 and jumps to 0x9020. At this point, the uncompressed part of the Linux kernel decompresses the compressed portion to address 0x10000 and kernel initialization begins.
3 Intel x86 based hardware memory management
Memory management is _disibledevent=>
The code in setup.S performs several important functions with respect to memory initialization:
/*********************************/
# method E820H:
# the memory map from hell. e820h returns memory classified into
# a whole bunch of different types, and allows memory holes and
# everything. We scan through this memory map and build a list
# of the first 32 memory areas, which we return at [E820MAP].
# This is documented at http://www.acpi.info/, in the ACPI 2.0 specification.
#define SMAP 0x534d4150
meme820:
xorl %ebx, %ebx # continuation counter
movw $E820MAP, %di # point into the whitelist
# so we can have the bios
# directly write into it.
jmpe820:
movl $0x0000e820, %eax # e820, upper word zeroed
movl $SMAP, %edx # ascii 'SMAP'
movl $20, %ecx # size of the e820rec
pushw %ds # data record.
popw %es
int $0x15 # make the call
jc bail820 # fall to e801 if it fails
cmpl $SMAP, %eax # check the return is `SMAP'
jne bail820 # fall to e801 if it fails
# cmpl $1, 16(%di) # is this usable memory?
# jne again820
# If this is usable memory, we save it by simply advancing %di by
# sizeof(e820rec).
#
good820:
movb (E820NR), %al # up to 128 entries
cmpb $E820MAX, %al
jae bail820
incb (E820NR)
movw %di, %ax
addw $20, %ax
movw %ax, %di
again820:
cmpl $0, %ebx # check to see if
jne jmpe820 # %ebx is set to EOF
bail820:
/*********************************/
the memory map can be obtained by three methods: 0xe820, 0xe801, and 0x88. All three methods have to do with compatibility with existing BIOS distributions and their platforms.
/*********************************/
# Now we move the system to its rightful place ... but we check if we have a
# big-kernel. In that case we *must* not move it ...
testb $LOADED_HIGH, %cs:loadflags
jz do_move0 # .. then we have a normal low
# loaded zImage
# .. or else we have a high
# loaded bzImage
jmp end_move # ... and we skip moving
do_move0:
movw $0x100, %ax # start of destination segment
movw %cs, %bp # aka SETUPSEG
subw $DELTA_INITSEG, %bp # aka INITSEG
movw %cs:start_sys_seg, %bx # start of source segment
cld
do_move:
movw %ax, %es # destination segment
incb %ah # instead of add ax,#0x100
movw %bx, %ds # source segment
addw $0x100, %bx
subw %di, %di
subw %si, %si
movw $0x800, %cx
rep
movsw
cmpw %bp, %bx # assume start_sys_seg > 0x200,
# so we will perhaps read _disibledevent=>BIOS:
--POST
--初始化硬件设备
--搜索启动操作系统的设备(U盘、硬盘、CD-ROM)
--并把MBR读到内存绝对地址0x7c00处同时将控制权交出。

Main Ref:
Kernel Primer- A Top Down Approach for x86 and PowerPC architectures
Tags: 

延伸阅读

最新评论

发表评论