陈中正的网络日志

Ubuntu下使用bochs运行Linux 0.12

这几天在学习Linux内核。看赵炯的《LInux内核完全剖析——基于0.12内核》,并试着根据其中的教程先运行一下Linux 0.12。解决了一些问题后,最终得以顺利安装,在此做一下记录。

系统版本: Ubuntu 14.04  32位

仿真器版本:  bochs 2.4.6

  1. 点下面链接下载Linux 0.12相关文件。

Linux-0.12

  1. 配置文件

解压得到的文件 linux-0.12-080324.zip

解压得到的文件夹中有个文件叫 bochsrc-0.12-hd.bxrc  ,在文件最后添加一行

display_library: sdl
  1. 安装bochs相关软件

    sudo apt-get install bochs bochs-x bochs-sdl

安装得到bochs版本是2.4.6

  1. 用bochs运行Linux 0.12

    bochs -f bochsrc-0.12-hd.bxrc

SouthEast

参考:

http://blog.csdn.net/chrisniu1984/article/details/6620722

http://www.cnblogs.com/viviwind/archive/2012/12/21/2827581.html

本文章迁移自http://blog.csdn.net/timberwolf_2012/article/details/29663091

『转』intelx86为何从0xFFFF0处执行(zt)

操作系统引导

从用户按下计算机电源开关开始,到操作系统运行起来这段时间被称为“系统引导(boot)”,一般的操作系统理论都不将它看做操作系统的一部份,因 而很多操作系统教科书都这部份只字未提。但是从开发操作系统的角度来看,“引导”是非常重要的一个环节。因为,你开发的操作系统正是经过“引导”程序读进 内存,然后才开始工作的。因此,要想开发一个操作系统,了解“引导”过程,是非常必要的。

  “引导”过程与计算机硬件密切相关,这里只针对最常见的Intel x86及IBM PC体系结构进行描述,其余硬件平台的“引导”进程请参见相应资料。

 

 

第一条指令的地址

  在用户按下计算机电源开关之后,CPU会自动的将其CS寄存器设定为0xFFFF,将其IP寄存器设定为0x0000。由于CS:IP指出了下一条指令的地址[1],因此CPU会跳到0xFFFF:0x0000处进行执行。为什么是这个地址而不是其它地址呢?这其实是一个很巧妙的设计。

  我们知道,从80386开始,到后面80486、奔腾,它们都是32位的CPU,但是它们都与Intel先前开发的8086兼容。也就是说,在默认情况下,80386、80486等,只不过是一台运行得更快一些的8086罢了。因此,这里我们只讨论8086[2]

  8086是16位的CPU,但是却有20根地址线[3]。也就是说它可以寻址220 = 1M 内存空间。这段内存空间由RAM、ROM组成。ROM是随机只读存储器,里面的程序是在计算机出厂的时候直接烧录在里面的,完成一些主机自检等操作,并提 供一些访问磁盘等基本输入输出服务,因而这段程序常被称为BIOS(Basic Input/Ouput Service)。由于不同的计算机厂商生产的计算机所带的外设不一样,因此,这段程序大小也限机型的不同而不一样,有可能A厂出产的计算机所带的这段程 序的大小为1K,而B厂出产的这段程序的大小为2K。如果将这段程序放在0x0000处,那么用户写的程序就可能从0x0400处开始也可能从 0x0800处开始,非常不统一。故而,将此段程序放在1M内存的顶部,那么用户写的程序就都可以从0x0000处开始了。

  但将BIOS这段程序放在1M内存的顶部,如果这段程序大小为1K,那么应当从0xFFC00开始放。如果这段程序的大小为2K,那 么应当从0xFF800开始放,对于CPU而言,到底是应当从0xFFC00开始执行还是应当从0xFF800开始执行呢?为了解决这个问题,8086规 定,CPU均从0xFFFF0处开始执行,而在0xFFFF0处,放一条无条件转移指令JMP。如果A厂的BIOS是从0xFFC00开始放的,那么这条 转移指令就跳转到0xFFC00处开始执行。如果B厂的BIOS是从0xFF800开始放的,那么这条转移指令就跳转到0xFF800处开始执行,各个厂 家可以跟据自己所生产的BIOS程序的大小,来决定此转移指令具体跳转到的位置。

  这里有一点需要清楚的是,通常认为,内存编址是连续的,不会出现空洞,其实完全不是这样。比如,假设BIOS的编址是从 0xF0000开始,而RAM,即通常讲的内存编址是从0x00000开始,那么,如果用户只安装了32K内存,那么内存的编址范围就是 0x00000~0x07FFF,那么从0x08000至0xEFFFF处就没有安装内存,这就是一个内存空洞。

  好了,当CPU执行了放在0xFFFF0处的第一条指令后,就跳转到BIOS程序内部去执行了,下面就来看看BIOS都做了些什么。

 

[ 编辑]

 

BIOS的工作

  BIOS的工作相当简单,主要的工作就是执行主机自检(POST),然后查找操作系统存在在哪个磁盘上,将操作系统载入。BIOS在查找各磁盘 的操作系统时,主要是查找磁盘上的第一个扇区(0面0磁道1扇区),每个扇区是512字节,如果这是一个引导扇区,那么就将它载入0x7C00的内存地址 上,然后跳转到此地址上执行。如果此不是一个引导扇区,就继续查找下一个磁盘,看其上面是否存在引导扇区。如果所有的磁盘上都不存在引导扇区,则在屏幕上 打印出一条出错信息。

 

[ 编辑]

 

引导扇区的工作

  引导扇区只有一扇区即512字节大,因此它的主要目的是把操作系统的内核读进内存,然后跳转到操作系统内核处开始执行。从编写操作系统角度来 说,前面的CPU上电及BIOS的工作都不是操作系统能控制的,而从引导扇区开始,就完完全全可由操作系统来控制了,因此,编写引导扇区也是编写操作系统 必要的工作之一。从BIOS跳入引导扇区后,计算机系统引导工作就算完成,怎样把操作系统内核读进内存,然后再安排一条跳转指令跳到内核处执行就是操作系 统开发人员的工作了。

 

[ 编辑]

 

其它资源

  • 对于引导过程更详细的描述及示例程序可以参见谢煜波的《操作系统引导探究》。

 

转自:

人走茶凉

http://blog.163.com/terrcy.j@126/blog/static/49300638200798445695/

 

本文章迁移自http://blog.csdn.net/timberwolf_2012/article/details/8821377

『转』Memory Map (x86)

Memory Map (x86)

Revision as of 05:41, 22 May 2012 by  Amirsaniyan  (Talk | contribs)

( diff← Older revision | Latest revision (diff) | Newer revision → (diff)

This article describes the contents of the computer's physical memory at the moment that the BIOS jumps to your bootloader code.

Contents

 [hide

"Low" memory (< 1 MiB)

When a typical x86 PC boots it will be in Real Mode, with an active BIOS. During the time the CPU remains in Real Mode, IRQ0 (the clock) will fire repeatedly, and the hardware that is used to boot the PC (floppy, hard disk, CD, Network card, USB) will also generate IRQs. This means that during the PC boot process, the Real Mode IVT (see below) must be carefully preserved, because it is being used.

When the IVT is activated by an IRQ, it will call a BIOS routine to handle the IRQ. Bootloaders will also access BIOS functions. This means that the two memory workspaces that the BIOS uses (the BDA and the EBDA) must also be carefully preserved during boot. Also, every time the BIOS handles an IRQ0 (18 times a second), several bytes in the BDA get overwritten by the BIOS -- so do not attempt to store anything there while IRQs are active in Real Mode.

After all the BIOS functions have been called, and your kernel is loaded into memory somewhere, the bootloader or kernel may exit Real Mode forever (often by going into 32bit Protected Mode). If the kernel never uses Real Mode again, then the first 0x500 bytes of memory in the PC may be reused and overwritten. (However, it is very common to temporarily return to Real Mode in order to change the Video Display Mode.)

When the CPU is in Protected Mode, System Management Mode (SMM) is still invisibly active, and cannot be shut off. SMM also seems to use the EBDA. So the EBDA memory area should never be overwritten.

Note: the EBDA is a variable-sized memory area (on different BIOSes). If it exists, it is always immediately below 0xA0000 in memory. It is absolutely guaranteed to be less than 128 KiB in size. It is often 1 KiB. The biggest ones ever actually seen are 8 KiB. You can determine the size of the EBDA by using BIOS function INT 12h, or (often) by examining the word at 0x40E in the BDA (see below). Both of those methods will tell you the location of the bottom of the EBDA.

It should also be noted that your bootloader code is probably loaded and running in memory at physical addresses 0x7C00 through 0x7DFF. So that memory area is likely to also be unusable until execution has been transferred to a second stage bootloader, or to your kernel.

Overview

start end size type description
Low Memory (the first MiB)
0x00000000 0x000003FF 1 KiB RAM - partially unusable (see above) Real Mode IVT (Interrupt Vector Table)
0x00000400 0x000004FF 256 bytes RAM - partially unusable (see above) BDA (BIOS data area)
0x00000500 0x00007BFF almost 30 KiB RAM (guaranteed free for use) Conventional memory
0x00007C00 (typical location) 0x00007DFF 512 bytes RAM - partially unusable (see above) Your OS BootSector
0x00007E00 0x0007FFFF 480.5 KiB RAM (guaranteed free for use) Conventional memory
0x00080000 0x0009FBFF approximately 120 KiB, depending on EBDA size RAM (free for use, if it exists) Conventional memory
0x0009FC00 (typical location) 0x0009FFFF 1 KiB RAM (unusable) EBDA (Extended BIOS Data Area)
0x000A0000 0x000FFFFF 384 KiB various (unusable) Video memory, ROM Area

BIOS Data Area (BDA)

The BDA is only partially standardized, and almost all the values stored there are completely obsolete and uninteresting. The following is a partial list. See the External Links references below for more detail.

address (size) description
0x0400 (4 words) IO ports for COM1-COM4 serial (each address is 1 word, zero if none)
0x0408 (3 words) IO ports for LPT1-LPT3 parallel (each address is 1 word, zero if none)
0x040E (word) EBDA base address >> 4 (usually!)
0x0410 (word) packed bit flags for detected hardware
0x0417 (word) keyboard state flags
0x041E (32 bytes) keyboard buffer
0x0449 (byte) Display Mode
0x044A (word) number of columns in text mode
0x0463 (2 bytes, taken as a word) base IO port for video
0x046C (word) # of IRQ0 timer ticks since boot
0x0475 (byte) # of hard disk drives detected
0x0480 (word) keyboard buffer start
0x0482 (word) keyboard buffer end
0x0497 (byte) last keyboard LED/Shift key state

Extended BIOS Data Area (EBDA)

You may see "maps" of the EBDA if you search the web. However, those maps are for the original IBM BIOS EBDA. They do not apply to any current EBDA, used by any current BIOS. The EBDA area is not standardized. It does contain data that your OS will need, but you must do a bytewise pattern search to find those tables. (SeePlug-and-Play.)

ROM Area

start end size region/exception description
Standard usage of the ROM Area
0x000A0000 0x000BFFFF 128 KiB video RAM VGA display memory
0x000C0000 0x000C7FFF 32 KiB (typically) ROM Video BIOS
0x000C8000 0x000EFFFF 160 KiB (typically) ROMs and unusable space Mapped hardware & Misc.
0x000F0000 0x000FFFFF 64 KiB ROM Motherboard BIOS

"Upper" Memory (> 1 MiB)

The region of RAM above 1 MiB is not standardized, well-defined, or contiguous. There are likely to be regions of it that contain memory mapped hardware, that nothing but a device driver should ever access. There are likely to be regions of it that contain ACPI tables which your initialization code will probably want to read, and that then can be overwritten and reused. Some ACPI areas cannot be "reclaimed" this way. Some of the computer's RAM may extend above 4 GiB.

Use the BIOS function INT 15h, EAX=0xE820 to get a reliable map of Upper Memory.

start end size region/exception description
High Memory
0x00100000 0x00EFFFFF 0x00E00000 (14 MiB) RAM -- free for use (if it exists) Extended memory 1, 2
0x00F00000 0x00FFFFFF 0x00100000 (1 MiB) Possible memory mapped hardware ISA Memory Hole 15-16MB 3
0x01000000  ????????  ???????? (whatever exists) RAM -- free for use More Extended memory 1
0xC0000000 (sometimes, depends on motherboard and devices) 0xFFFFFFFF 0x40000000 (1 GiB) various (typically reserved for memory mapped devices) Memory mapped PCI devices, PnP NVRAM?, IO APIC/s, local APIC/s, BIOS, ...
0x0000000100000000 (possible memory above 4 GiB)  ????????????????  ???????????????? (whatever exists) RAM -- free for use (PAE/64bit) More Extended memory 1
 ????????????????  ????????????????  ???????????????? Possible memory mapped hardware Potentially usable for memory mapped PCI devices in modern hardware (but typically not, due to backward compatibility)

1: Different computers have different amounts of RAM, therefore the amount of extended memory you might find will vary and may be anything from "none" (e.g. an old 80386 system) to "lots".

2: Free for use except that your bootloader (ie. GRUB) may have loaded your "modules" here, and you don't want to overwrite those.

3: The "ISA Memory Hole" (from 0x00F00000 to 0x00FFFFFF) was used for memory mapped ISA devices (e.g. video cards). Modern computers have no need for this hole, but some chipsets still support it (as an optional feature) and some motherboards may still allow it to be enabled with BIOS options, so it may exist in a modern computers with no ISA devices.

转自: http://wiki.osdev.org/index.php?title=Memory_Map_(x86)&oldid=13415

本文章迁移自http://blog.csdn.net/timberwolf_2012/article/details/8811060