分类: LINUX
2011-11-05 21:17:39
使用GRUB2不能正确引导X86_64 linux-2.6.21 bzImage内核。为解决这一问题,本文展开研究GRUB2加载方式,X86_64 bzImage生成结构、解压缩和启动过程。
bzImage的生成步骤如下:
1) 内核vmlinux是由arch/x86_64/kernel/vmlinux.lds文件链接规则由LD链接而成的elf64格
式文件;本文称之为第一个vmlinux;
2) objcopy将vmlinux转成二进制的vmlinux.bin;本文称之为第一个vmlinux.bin;
3) gzip将vmlinux.bin压缩成vmlinux.bin.gz;
4) vmlinux.bin.gz由arch/x86_64/boot/compressed/vmlinux.scr链接规则链接成piggy.o,此文件只有数据段;vmlinux.scr链接规则如下:
SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; } } |
5) arch/x86_64/boot/compressed/下的misc.c, head.S以及生成的piggy.o链接成另外一个压缩vmlinux elf32格式的文件,head.S和misc.c是为了解压piggy.o中包含的vmlinux.bin.gz所用;本文称之为第二个vmlinux;
6) objcopy将压缩vmlinux转成vmlinux.bin二进制格式文件;本文称之为第二个vmlinux.bin;
7) arch/x86_64/boot/tools/build.c编译生成build程序,arch/x86_64/boot/bootsect.S和arch/x86_64/boot/setup.S编译生成二进制类型的bootsect和setup程序;
8) build程序将setup和bootsect二进制格式文件,以及步骤6)中生成的vmlinux.bin二进制格式文件打包成一个最终的bzImage.
因此,bzImage组成结构:
1) bzImage: bootsect+setup+vmlinux.bin
2) vmlinux.bin:head.S+misc.c+vmlinux.bin.gz
3) vmlinux.bin.gz: gzip压缩的vmlinux.bin即最终的内核
一个C程序的生成过程包括:预处理、编译、汇编和链接过程。
Linux下的链接过程是由LD完成的,它可以控制生成目标程序的格式,以及各个部分的组成特点,包括加载地址(LMA)和运行地址(VMA),这些行为可以通过配置链接文件完成,可理解为链接文件是LD程序执行的参数配置文件,决定了链接出来的目标文件的组成;程序由许多节(section)组成,因此链接文件主要是围绕节的定义展开的。
本小节通过简单分析arch/x86_64/kernel/vmlinux.lds.S链接文件来介绍LD的用法:
a) OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
OUTPUT_FORMAT命令表示生成的目标默认格式,大端字节序时的目标格式以及小端
字节序时的目标格式;
b) OUTPUT_ARCH(i386:x86-64)
OUTPUT_ARCH表示特定的输出机器架构
c) ENTRY(phys_startup_64)
ENTRY表示目标程序的入口地址;
有多种不同的方法来设置入口点,连接器会通过按顺序尝试以下的方法来设置入口点,
如果成功了就会停止:
* ‘-e’入口命令行选项
* 连接脚本中的ENTRY(SYMBOL)命令
* 如果定义了start,就使用start的值
* 如果存在,就使用’.text’节的首地址
* 地址0
d) SECTIONS{}含有目标程序的各个节的定义
e) 节中的定义:. = __START_KERNEL;
.在链接文件表示一种特殊的符号,对它赋值可以改变当前的地址,此语句即将目标
文件的起始地址设成了__START_KERNEL,定义为CONFIG_PHYSICAL_START +0xffffffff80000000,CONFIG_PHYSICAL_START为menuconfig时设定的内核代码开始物理地址(默认为0x1000000);
另外,-Ttext
更详细的GNU LD详细用法请自行阅读:
启动qemu至rootfs,将/dev/hda用fdisk分区并格式成ext2或ext3,并挂载到rootfs的/boot/目录上:
1) 将grub_install/拷至/xlpang/中(安装时的放置路径需确保和编译时的路径一致;也可以
修改/xlpang/grub_install/sbin/ grub-install脚本文件开头的变量路径),执行:
/xlpang/grub_install/sbin/grub-install --no-floppy /dev/hda命令将grub2安装到/boot目录下(实际硬盘挂载后的/目录下),并将boot.img, diskboot.img和kernel.img写入其相应扇区中,其它文件安装在/boot/grub/目录下。
注意事项:
由于busybox不支持grep –qx选项,需要修改grub-install脚本,否则在执行过程中会报错
修改前: ……… if [ "x${devabstraction_module}" = "x" ] ; then if [ x"${install_device}" != x ]; then if echo "${install_device}" | grep -qx "(.*)" ; then install_drive="${install_device}" ……… |
修改后:(蓝色部分是对grepqx函数的实现) ……… grepqx() { local line="$1" local file="$2" local ret ret=$(sed -n "/^${line}$/p" ${file}) if [[ -z ${ret} ]] then return 1 else return 0 fi } if [ "x${devabstraction_module}" = "x" ] ; then if [ x"${install_device}" != x ]; then if echo "${install_device}" | grepqx "(.*)" ; then install_drive="${install_device}" ……… |
2) 生成/boot/grub/grub.cfg文件(在hda1挂载的根目录下放置bzImage内核映像):
编辑/xlpang/grub_install/etc/grub.d/40_custom文件,增加:
menuentry "linux_x86_64-2.6.21" { set root=(hd0,1) linux /bzImage ro initrd /initramfs } |
3) 执行:/home/grub-mkconfig -o /boot/grub/grub.cfg
注意事项:
如果“/”是挂载到ramdisk文件系统,/boot是mount到第一块硬盘第一个分区(/dev/hda1),且grub是安装在/boot上,则grub-mkconfig执行时会报如下错误:
解决方法:
修改grub-mkconfig脚本,设置grub-probe --target=device的路径为/boot,即grub安装路径,如下所示:
修改前: # Device containing our userland. Typically used for root= parameter. GRUB_DEVICE="`${grub_probe} --target=device /`" GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`" || true |
修改后: # Device containing our userland. Typically used for root= parameter. GRUB_DEVICE="`${grub_probe} --target=device /boot`" |
1) 使用仿真硬盘启动并进入调试模式命令:
qemu-x86_64.exe –S -boot c -hda hda500M.qcow -net tap,ifname=CEEE_TAP -m 512 -smp 4
-S表示进入调试模式,-boot c表示从硬盘启动,后面紧跟创建的虚拟硬盘文件
2) 进入后按ctrl+alt+2进入调试界面,输入”gdbserver”在qemu上启动调试服务器;按
ctrl+alt+1可返回qemu运行界面;
3) 使用gdb_linux_x86.exe或gdb_linux_x8664.exe进行相关调试
a) 运行gdb_linux_x86.exe vmlinux,此处vmlinux为第二个vmlinux
b) 连接qemu的gdbserver:target remote localhost:1234
连接成功后有类似如下打印:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
[New Thread 1]
warning: shared library handler failed to enable breakpoint
0x00000001 in ?? ()
c)后续就类似于标准gdb调试应用程序的流程了,附几个常用命令:
b *0x100000 /* 在0x100000处设置断点 */
x/32i 0x1000000 /* 查看0x1000000开始处的指令 */
info reg /* 查看寄存器 */
info b /* 查看断点 */
d
stepi /* 汇编级单步调试 */
c /* 程序继续运行 */
qemu-x86/qemu_x86_64在启动过程中注册了一组特殊的io端口用来显示bochs bios的调试输出。我们将这组特殊的io端口称为boch调试端口。qemu-x86的启动函数pc_init1()中调用了boch端口注册函数bochs_bios_init完成调试端口的注册过程;写入调试端口0x402,0x403的数据将被打印出来,因此在内核启动初期可以采用向端口0x402或者ox403端口写入数据来完成信息的打印。
由于x86_64的qemu用gdb调试有问题,可以通过添加打印来查看某此信息。
字符打印函数
可以采用如下x86汇编函数完成一个字符的打印。要求输入参数存储在eax寄存器中。
################################ # function print char ################################ outchar: #pramater al push %dx movw $0x402,%dx outb %al,%dx pop %dx ret |
数字打印函数
8字节打印函数
打印一个8bit数,输入参数放置到寄存器al中
outnum8: #pramater %al push %bx push %cx push %dx movb %al,%bl movw $0x402,%dx mov %bl,%cl #print highest half byte shrb $4, %bl cmpb $10,%bl movb $48,%al jb ship_add1 addb $7,%al ship_add1: addb %al,%bl movb %bl,%al outb %al,%dx #print lower half byte movb %cl,%bl andb $0x0f,%bl cmpb $10,%bl movb $48,%al jb ship_add2 addb $7,%al ship_add2: addb %al,%bl movb %bl,%al outb %al,%dx pop %dx pop %cx pop %bx ret |
16bit、32bit数字打印函数
outnum16: #pramater ax push %bx movw %ax,%bx shrw $8,%ax call outnum8 movw %bx,%ax andw $0xff,%ax call outnum8 pop %bx ret outnum32: #pramater eax push %ebx mov %eax,%ebx shr $16,%eax call outnum16 mov %ebx,%eax call outnum16 pop %ebx ret |
eip寄存器打印函数
##################################################### # function print eip ################################################### prt_eip: movl (%esp), %eax call outnum32 ret |
例子
我们可以通过以上定义的函数在内核启动初期Setup.S中打印一些信息。一下是一个使用实例:
打印esi的值
#zhangxy printf esi push %eax push %esi mov %esi,%eax call outnum32 pop %esi pop %eax |
在setup.S代码中加打印eip的代码:
#pangxunlei print ip push %ax call prt_eip pop %ax |
有了以上对各流程的理解和准备,可以逐步有序开展问题定位工作。
采用GRUB2启动X86_64内核失败,初步怀疑与重定向有关,由于LD链接时会对bzImage生成0x100000的符号地址。
arch/x86_64/boot/Makefile中:$(obj)/bzImage: IMAGE_OFFSET := 0x100000
arch/x86_64/boot/ compressed /Makefile中:
LDFLAGS_vmlinux := -Ttext $(IMAGE_OFFSET) -e startup_32 -m elf_i386 /* 参考第3节 */
因此第二个vmlinux会采用0x100000代码段起始地址(compressed中的head.S和misc.c)。
1) arch/x86_64/boot/compressed/head.S的执行入口startup_32,CPU处于保护模式(未
开启分页);
2) 设置了段寄存器、堆栈和一些初始化后,执行decompress_kernel函数(位于misc.c);
esi寄存器指向实模式下搜集的一些实模式数据起始物理内存地址;
3) decompress_kernel()检查是大内核后,进入gunzip解压代码,将内核解压至2个区域:
a) 记low_buffer_end为esi > 0x90000? 0x90000 : (unsigned int)esi) & ~0xfff;
区间1:[0x2000, low_buffer_end);
区间2:[0x1000000+ 区间的大小, 内核数据结束位置)
注:0x1000000为内核编译起始地址CONFIG_PHYSICAL_START
b) 之后再进入head.S中,将区间1搬运到区间2的开头,形成0x1000000开头的完
整内核数据;
为排除解压过程发生错误,修改decompress_kernel()行为:直接解压至0x1000000处,并且head.S中不进入搬运流程,然后跳转至内核入口,仍然启动失败。
用gdb查看0x1000000处的指令,如下:
1) 设置b decompress_kernel断点,显示在0x00105826内存地址处;说明bzImage被
GRUB2放置在了0x100000处;显示0x1000000处的值为:“x1000000: int3”,不是内核数据,因为还没完成解压;
2) x/32i 0x100000显示compressed/head.S在内存中的指令,并在call decompress_kernel
之后设置断点(保证内核解压完成),重新执行qemu;
3) 断住后,再次查看内核解压数据,x/10i 0x1000000:
(gdb) x/3i 0x1000000
0x1000000: mov $0x18,%eax
0x1000005: movl %eax,%ds
0x1000007: lgdtl 0x1000f00
结论:与arch/x86_64/kernel/head.S开头的相符,至此可以表明内核解压缩正常,排
除bzImage加载位置不对以及内核解压部分的因素。
精简compressed/head.S代码如下,修改解压代码如下(执行环境:32位保护模式,未开启分页):
.code32 .globl startup_32
startup_32: /* 0x100000入口地址 */ cld cli movl $(__KERNEL_DS),%eax movl %eax,%ds movl %eax,%es movl %eax,%fs movl %eax,%gs
lss stack_start,%esp movl 0x000000,%ecx xorl %eax,%eax
ljmp $(__KERNEL_CS), $0x100000 /* 从头开始。用grub2加载会不停返回到grub2的加载界面;不用grub2加载就不会有问题,即会一直循环解压不退出 */ |
结论:在ljmp远指针远跳转指令时,使用grub2会出问题,但一直理不清为什么会跳转回grub2
加载界面。
compressed/head.S分析不下去了,转战setup.S,呵呵!
arch/x86_64/boot/setup.S为bzImage中的第二个512B开始的代码,大小在bootsect中有记录,setup的功能如下:
1) 在ACPI兼容的系统中,调用BIOS例程建立描述系统物理内存布局的表。在早期系统中,它调用BIOS例程返回系统可以的RAM大小;
2) 设置键盘的重复延迟和速率;
3) 初始化显卡;
4) 检测IBM MCA总线、PS/2鼠标设备、APM BIOS支持等;
5) 如果BIOS支持Enhanced Disk Drive Services (EDD),将调用正确的BIOS例程建立描述系统
可用硬盘的表;
6) 如果内核加载在低RAM地址0x00010000,则把它移动到0x00001000处;如果映像加载在高内存1MB位置,则不动;
7) 启动位于8042键盘控制器的A20 pin;
8) 建立一个中断描述表IDT和全局描述表GDT表;
9) 如果有的话,重启FPU单元;
10) 对可编程中断控制器进行重新编程,屏蔽所以中断,级连PIC的IRQ2不需要;
11) 设置CR0状态寄存器的PE位使CPU从实模式切换到保护模式,PG位清0,禁止分页功能;
12) 跳转到startup_32()汇编函数, jmpi 0x100000, __BOOT_CS,终于进入内核解压head.S;
setup二进制程序开头部分是Linux内核与bootloader的协议约定(linux2.6.21用的是protocol 2.04),请参考documentation/i386/boot.txt的“THE REAL-MODE KERNEL HEADER”。
GRUB2在loader/i386/pc/linux.c的grub_cmd_linux()函数中处理此实模式头部信息(位于bzImage的0x200开头的512B内容中)的解析,根据这些信息来加载bzImage至相应的位置,GRUB2关于这些字段的信息位于include/grub/i386/linux.h中,其中:
“#define GRUB_LINUX_BZIMAGE_ADDR 0x100000”定义了第二个vmlinux.bin文件被放置的内存地址,与5.1节中的分析一致,也即bzImage的解压部分被放置在0x100000处。
在qemu上,正常流程(不使用GRUB2加载)setup.S被放置在0x10200处(可用qemu的调试功能验证)。
在qemu上,使用GRUB2加载bzImage,在0x10200处设置断点,发现断点不命中。
结论:qemu上,GRUB2对bzImage的加载流程发生了改变。
最终在setup.S中,增加了打印地址的代码(参考4.3节,关于qemu的特色打印功能)想看看setup.S被加载到了哪个位置,发现打印不出来,比较奇怪,于是干脆在setup.S的入口处增加了死循环,结果GRUB2加载却没有死循环,仍然不停的异常重启。
结论:GRUB2没有加载setup
GRUB加载的时候已经处于保护模式,正常的流程是:加载bzImage->切至实模式->跳至setup执行->切至保护模式->跳至compressed/head.S中执行。
GRUB2则是加载完bzImage后,完成了一些setup.S的工作后(如生成实模式数据,并设置esi),从保护模式直接跳转至了compressed/head.S中。
GRUB2加载linux-2.6.21 X86_64时不停的异常重启GRUB2,是在远跳转指令发生的,远跳转指令会更改CS寄存器,由于是保护模式会用到GDT,应该是由于没有正确设置GDT而造成的,只要正确设置GDT,而不用GRUB2的时候会跳转至setup.S中设置GDT,因此,我们相信只要将setup.S中的GDT移至compressed/head.S中,就可以完成GRUB2的正确加载,又由于是重复setup.S中的设置,不会影响不用GRUB2时的加载流程。
在compressed/head.S最后添加:
.data pxl_gdt: .word 0, 0, 0, 0 # dummy
.word 0, 0, 0, 0 # unused
.word 0xFFFF # 4Gb - (0x100000*0x1000 = 4Gb) .word 0 # base address = 0 .word 0x9A00 # code read/exec .word 0x00CF # granularity = 4096, 386 # (+5th nibble of limit)
.word 0xFFFF # 4Gb - (0x100000*0x1000 = 4Gb) .word 0 # base address = 0 .word 0x9200 # data read/write .word 0x00CF # granularity = 4096, 386 # (+5th nibble of limit) .align 256 pxl_gdt_48: .word 31 # gdt limit .long pxl_gdt # gdt base
|
在compressed/head.S开始处添加:
startup_32: cld cli
movl $(__KERNEL_DS),%eax movl %eax,%ds movl %eax,%es movl %eax,%fs movl %eax,%gs lss stack_start,%esp lgdt pxl_gdt_48 |
AMD64架构设计原因:无缝兼容legacy x86,更大的寻址空间和高性能(尤其是大块数据操作)。表现为更多的寄存器,64bit的寄存器,64bit的虚拟地址和物理地址。
AMD64内存模型兼容传统的(Legacy)X86内存模型,系统软件通过AMD64内存模型可以安全地管理用户程序和数据。类似于X86,AMD64设计了硬件转换机制将虚拟地址映射到物理地址,这样就能保证系统软件透明地重定向物理内存空间(或操作系统管理的硬盘驱动器)的应用程序和数据。
AMD64包括2种运行模式:长模式和传统模式。长模式的64-bit子模式实现了平坦内存模型(flat-memory model),传统模式实现了X86架构的所有内存模型。
X86支持4种运行模式,不同模式下提供了不同的内存管理、虚拟内存大小、物理内存大小,以及保护;4种模式为:
Ø 实模式(Real Mode)
Ø 保护模式(Protected Mode)
Ø 虚8086模式(Virtual-8086 Mode)
Ø 系统管理模式(System Management Mode)
AMD64支持X86的所有运行模式,称为“传统模式”(Legacy Mode);并设计了一种全
新的模式,称为“长模式”(Long Mode);因此,AMD64共有2种模式:传统模式和长模式;传统模式包括了X86的4种子模式,长模式包括64-bit模式和兼容模式。
软件可以实现在这些模式之间的切换,如下图所示。
长模式包含2个子模式:64-bit模式(64-bit模式)和兼容模式(Compatible Mode)。64-bit模式支持一些新特性,如64-bit虚拟地址空间;兼容模式允许在64位的系统软件(如64位操作系统)下,运行16位/32位应用程序(是二进制兼容的,不需要重新编译);长模式下取消了硬件多任务机制。
声明:使用“长模式”描述时表示64-bit模式和兼容模式共有的特性,当子模式特有的功能时,会直接使用子模式的名称进行描述。
使能和激活长模式(通过改变EFER.LME位,EFER:Extended Feature Enable Register)之前,系统软件必须先使能操作模式(即只能从保护模式进入长模式)。
AMD64引入了长模式和它的2个子模式:64-bit模式和兼容模式。
64-bit模式 完全支持64位的应用程序和系统软件,开启64-bit模式,需要64位的操作系统和64位的工具链支持。
兼容模式 此模式实现了在64位的操作系统上兼容运行16位/32位X86架构的应用程序,这些应用程序不需要重新编译;
长模式不支持如下2种模式:
Ø 虚8086模式 – 虚8086模式位(EFLAGS.VM)在长模式下被处理器忽略;当长模式使能时,试图开启虚8086模式将自动被处理器忽略,需要进入虚8086模式的系统软件必须先退出长模式。
Ø 实模式 – 进入长模式需要事先开启保护模式,所以长模式下不支持实模式。
传统X86模式
AMD64架构支持纯粹的传统X86模式,此模式二进制兼容16位/32位X86架构应用程序;更进一步地,与兼容模式不同的是,传统模式二进制兼容16位/32位操作系统。传统模式支持实模式、保护模式和虚8086模式。复位时处理器总是处于传统模式(实模式)下,直到系统软件激活长模式。
64-bit模式支持64-bit的系统软件和应用程序,引入了如下新新性:
Ø 64-bit虚拟地址空间(具体处理器可能实现较小的空间)
Ø 通过REX指令前缀扩展寄存器:
- 增加R8-R15通用寄存器
- 所有通用寄存器扩充到64位
- 增加了8个YMM/XMM8-15 SSE 256/ 128位寄存器
Ø 64位RIP寄存器
Ø 增加RIP相对数据寻址
Ø 平坦段地址空间
64-bit模式通过CS寄存器使能(控制64-bit模式和兼容模式之间的切换),传统的段机制
被禁用,分页机制需要使能,软件方面需要64位的系统软件和工具来运行此模式。
对现有的X86下的16位/32位应用程序保持二进制兼容,此模式下运行有长模式下的64位系统软件。
兼容模式下,应用程序只能够访问4GB虚拟地址空间;CS寄存器控制兼容模式和64-bit模式之间的切换;与64-bit模式另一个不同,段机制和X86的保护模式保持一致,但与X86不同的是,分页机制是使能的。
从应用程序的角度来看,兼容模式和开启了分页机制的X86保护模式是一致的;从系统软件(操作系统)的角度来看,兼容模式下运行的是长模式的系统软件、地址转换机制、中断异常处理,和系统数据结构。
AMD64的传统模式包括:实模式、保护模式和虚8086模式。传统模式下不仅能提供与X86架构的16位/32位应用程序兼容,还能保持16位/32位系统软件的兼容(相比,兼容模式下的系统软件必须是64位的)。
实模式
又称为实地址模式。此模式下,处理器支持1MB的物理内存空间,操作数默认是16位,AMD64的实模式可能通过指令前缀(操作数大小指令前缀,66h)变成32位的;中断处理和地址生成和80286处理机保持一致;不支持分页;所有软件在特权等级0下运行。
上电或重启时,处理器会运行在实模式下;长模式下没有实模式,原因是长模式需要从开启分页的保护模式切入。
保护模式
保护模式支持4GB的虚拟内存空间,4GB的物理内存空间,16位或32位操作数;所有的段式转换,段保护和硬件多任务机制都是可用的;分页是可选的;系统软件可以通过分段在虚拟地址空间中重定向有效地址。
保护模式下,软件可以在特权等级0~3运行;通常应用程序运行在特权等级3,系统软件运行在特权等级0和1;80286处理器首先引入了16位保护模式特性。
虚8086模式
通过保护模式切入;虚8086模式下,可以运行16位的实模式下运行的软件,在8086, 8088, 80186和80188处理上运行的程序都可以在此模式下运行,但运行特权等级为3;支持虚拟地址空间1MB,操作数大小为16位,AMD64虚8086模式下可以通过操作数大小指令前缀来使用32位的操作数;使用实地址模式转换;与实模式不同的是,分页是可选的,并且开启分页后的物理地址是32位的。
EFLAGS.VM位控制虚8086模式的切入切出,POPF指令不能改变VM位,VM位只能通过2种方式访问:
a) 任务切换时,从TSS段中载入EFLAGS;
b) 特权软件执行IRET指令(中断发生时,硬件会自动将EFLAGS压栈)。
长模式不支持虚8086模式,当长模式使能时,岂图使能虚8086模式将自动被硬件忽略。
AMD64支持X86支持的所有形式的段,然而大部分现在系统软件并没有利用段来隔离任务,取而代之的是分页机制。因此AMD64长模式中的64-bit(子)模式取消了段的设计,使用了平坦内存模型,这使得新的64-bit系统软件的设计变得更加简单和高效。
长模式的地址转换过程如下图所示:
传统模式下的代码/数据段描述符如下:
长模式下的代码/数据段描述符如下:
图中灰色的部分表示忽略,长模式下忽略了段机制,只保留了几个字段用于控制作用。
抛开灰色字段被忽略的行为,X86和AMD64两种架构的数据段字段定义是一样的,因此只要不发生远跳转,CPU就可以正常的执行指令。
注意到arch/x86_64/kernel/head.S中的GDT表(cpu_gdt_table)的数据段描述符的值和setup.S中设置的是一样的,第一个远跳转指令为进入长模式的指令(已经进入了长模式):
ljmp $__KERNEL_CS, $(startup_64 - __START_KERNEL_map),因此,可以做如下修改:
a) compressed/head.S中,将文件中的3处远跳转指令替换为近跳转指令,示例:
ljmp $(__KERNEL_CS), $__PHYSICAL_START
修改为 ->
movl $__PHYSICAL_START, %ebp
jmp *%ebp
b) arch/x86_64/kernel/head.S中,将
movl $__KERNEL_DS,%eax
movl %eax,%ds
lgdt pGDT32 - __START_KERNEL_map
修改为 ->
lgdt pGDT32 - __START_KERNEL_map
movl $__KERNEL_DS,%eax
movl %eax,%ds
c) 针对SMP,arch/x86_64/kernel/trampoline.S中,跳至arch/x86_64/kernel/head.S前即
ljmpl $__KERNEL32_CS, $(startup_32-__START_KERNEL_map)前
增加 ->
mov $__KERNEL_DS, %ax
mov %ax, %ds