[BootLoader]系统之最初

一、可参考的网站：
(1)绝对经典网站：
操作系统资源中心
这个网站之好, 无法用言语表达............

OSD之家
好好好!

OS dev
也不错

execpc
快来看看吧......

http://www.xemean.net/
汇编编成的OS：MenuetOS
该网站有很多汇编资料，以及涉及到硬件编程的资料

(2)outportb 那里去找!？推荐网站
pc-hardware
VGADOC
一个vag包
execpc的控制台代码

(3)
openBLT
reactos
brainix team
v2os
Nachos
Thix
hello
aros
kerne link
os file
文件格式大全

(4)关于在实模式下使用bios 输出文本的方法推荐
Ralf Brown著名的中断列表
freshground (old hand) 推荐
bios中断表

二、开始编OS之前，您需要考虑：
1. 为什么写 OS ?
研究: 更高,更强,更好
高可考性, 更高的性能,实时,分布,面向对象,更易移植,挑战商业,挑战自我,新构架.

学习
多任务,内存保护,标注c库,设备驱动,文件系统,应用

兴趣
就是喜欢!


2.设计决策
移植性
受限于intel? 使用x86-only 的特性? 4 个特权级(大多机器有只有2个), 基于段的地址转换和保护 (一般都有paging), TSSes 任务切换(vs. 栈交换).

内核体系
Linux? monolithic kernel? microkernel? exokernel? SASOS? .

多任务
不支持?协作?抢占调度?

线程
无? 内核支持还是进程协作? 如何在同宗线程间协调地址空间?

多处理器
不支持?紧耦合的SMP? 松散的分布式?

多用户和安全

开发工作站
linux?没有SourceInsight!
win? ...........

开发语言
C C++ asm ......

可执行文件格式
还有是否支持动态链接? (就如 ELF 和 PE , 他们简单)

高级语言库
GNU glibc, Cygnus Newlib, homebrew, .........

兼容?

抄袭代码
拿来学习的代码.......

三、最初的版本0.0.1到0.0.5

需要从一个简单的bootsect 开始写我的操作系统吗?
下面的网站给出了一些建议:
千万不要写bootloader. 至少不要把他当作写os的第一件事.
bootloader 不是 OS.
bootloader 仅仅是os的一个非常小的部分.
写一个好些的bootloader 的工作量和写一个小 OS的工作量相当.
写一个 bootloader 需要一些神秘的知识,像什么a20等等.
如果在 DOS 或者 Windows 9x下开发,可以使用 DOS 作为你的boottloader. , 你看 GRUB 怎么样.

但是,为什么不写一个自己的?
既然如此神秘, 既然有巨多的开源bootloader......, 拷贝一些代码修剪一下也挺好

你选择写还是不写? 不惜半年的深夜...写!? bootloader的一些研究
bootloader中0.0.5版有了如下特性:
1.Boot 装载 setup+os 到 0X10000
2.在实模式下跳到 setup, setup 把 os 移动到 0x100000 (1M)
3.然后切换到保护模式,用一句长跳转 jmp dword 8:0x100000
(nasm can mix 16bit and 32bit code)
4.使用了 c++
1).setup.s 预留了2048(0x800)个字节供以后使用
2).setup.s 预留空间, setup 搬移 os 的位置(紧邻setup之后),应该一致.

总结:
系统从 1M 的地方跑起来,总算像个操作系统的 Loader 了!!!!!

第一个版本0.0.1可以说是第一步了, 可能费时也最久.
0.0.1 可以说是最最小的东西了.
相当于一个hello wold!
当初是在win下写的, 但既不知vmWare是何方神圣又不知道partcopy. 只晓得linux下的dd好使, gcc好使. 也真是移到了linux下, 才看到屏幕上的几行简单的信息. 心里的感觉真是无比xx. 那是2002.1.28 深夜23:06.中国年的前夕.

为此, 已经不知多少无眠的夜晚捧着印出来的minix bootsect, linux0.0.1 bootsect 看来看去.... 至今这种印记还在代码中. 从floppy读os的代码我实在没有兴趣, 因此至今还是linux的老样子.

如果没有 make binary use C Compier , 没有nondot, 估计到如今写不可能有0.0.1的诞生.
0.0.1 中的Makefile中, 最最有用的一句:

# 将生成的操作系统文件从 elf 格式转换到 binary 格式
os.bin: os.elf
objcopy -R .comment -R .note -S -O binary os.elf os.bin


就是来自于nondot的那篇文章.

关于这个Makefile 可能还有一句值得一看:

....
OBJS = c.o
.......
os.elf: $(OBJS)
$(LD) $(OBJS) -o os.elf -e c -Ttext 0
# 因为我们的映象是binary格式.
# 所以入口点函数应该是第一个.o文件的第一个函数


有件事情我很抱歉, 0.0.1中没有使用head.s.
只有boot.s 和c.c.

boot.s 把c.c 生成的bin文件os.bin从磁盘上载入内存, 切换到保护模式, 跳到os.bin.
看看makefile中的

# 最终生成文件 bootimg
bootimg:os.bin Boot
cat Boot os.bin>bootimg
# Boot 是引导扇区内容,内核 os.bin 紧跟其后的扇区

应该能够想象整个的流程.

c.c 除了打印了一句信息外好像什么都没有做.
从c.c生成的os.bin是32位的代码, 需要保护模式才能运行. 其中的函数

/*
Text mode kprint
Show 'c' at
line : x (0...24 )
col : y (0...79 )
*/
void kputc(char c,char color,int x,int y)
{
/* p ponitor to Video Memory */
char *p = (char*)0xb8000;

/* calc line pos*/
p += 2*x*80+y*2;

/* show char whith color*/
*p = c;

*(p+1) = color;
}

要想正确工作, os的ds选择子选择的描述符所描述的段之基址必须从0 开始, 可读写, limit 大于video mem上限(0.0.1是8m, 见boot.s).


0.0.1是我的希望之光.
0.0.1 太简单, 不知道他能够做什么工作.
0.0.2 中, 好像只是把c.c 搞来搞去,没有实质性的工作.

0.0.3 中多了两个文件, setup.s, head.s . 这个可以从Makefile中看出来.
关键在于, boot.s中不再切换到保护模式了, 这样的话,我可以在setup.s 中多做一些事情. 因为boot.s 只有512 字节,太少了!
可以看到, 0.0.3 重的setup.s 所作的事情也很简单. 它把os(head.s, c.c)搬到物理地址0. 然后使用临时的gdt切换到保护模式.最后跳到os的head.s.
head.s 重新加载了os自己的gdt, 因为setup.s 不属于操作系统的一部分!
可以看到setup.s 和head.s 的基本功能. 更重要的是基于这样一个设想, 在setup.s中, 未切换到保护模式前, 可以写更多的代码完成更多的功能.甚至我使用16bit 的c编译器, 配合bios, 那就方便的多了. head.s主要是os的一个入口, 单独放到一个文件中使入口管理更方便. 其中的idt,gdt也使os的全局变量更加集中.

考虑到把os放到地址0:0 不合适, 所以0.0.3.5中, os 被移到0x20000, 位于物理内存 128k处.

但是还是觉得不爽, 干脆在0.0.4中, 切换到保护模式后直接把os放到1M的地方. 离开常规内存这个是非之地.

从Makefile 中ld -T 的选项可以清楚的看到这种变化.
中间遇到很多问题, 一些记录了下来,一些却没有.


0.0.5 中我想试一试c++ 好不好玩.
新的简单内核中,比如说bootloader 0.0.5----, 还没有多任务支持, 没有中断机制的支持, 没有应该有的一切.

怎么在这种情况下做一些简单的i/o可能是开发到这个阶段比较关心的问题.
找一些资料, 比如kbd, hd, vga......

0.0.5对vga的支持仅仅是操作默认的framebuffer, 甚至连光标都移动不了.
国外有些好资料, 前面我也推荐了不少网站.

看看这些资料...... 拿来我们先用用!


感谢 execpc.osd 的兄弟们杰出无私的奉献.

0.0.5 以前的版本再linux下编译. 当时对boch vmWare不太了解.
调试及其痛苦. linux下的vim虽然语法加亮,虽然....我却不太会使用.

倒是非常喜欢SourceInsight.
知道windows下的nasm djgpp也是free,但是当时从没有再win下编译出一个bin核.
试图找出一个linux版本,有很好的中文支持, 有一个类似sourceinsight的工具, 我当然不希望用蹩足的英文注释我的代码....
但是始终没有一个中文环境, 使自己满意.
大四时玩turbo 4.1, 只会安装而已,
现在在linux下体验os, 感叹啊.......

还是不断的努力做到在win下开发.......
windows下我很容易找到16bit的C编译器,可以增强loader.

2002.9.16这天, 又找出nasm, vmWare, djgpp.....
没想到, 这么顺利的在vmWare下调出了熟悉的画面.
真是让人兴奋.
上穿的版本中如果make会找不到一个文件 pad .
这个pad什么都不是,仅仅为了在vmWare下调试时把bootimg扩展到1.4M以上, 可以随便找个什么东西代替!


新的特性
见0.0.5.1的readme.txt
5.移植到djgpp 使用windows 下的gcc nasm 编译成功,并且使用vmWare调试.
至此,使用下面的工具: sourceinsight, vmvare, djgpp, nasm. (这是我梦中的环境^_^)
下一步考 虑使用tc 或者其他的编译器制作setup中的16位程序. (使用C 加强setup.s 的功能)