Yes, it made me feel unconfortable... By the way, I wrote some little articles but more about how to do some linux kernel stuff [here](https://github.com/GuillaumeGomez/howto-linux-kernel). Maybe you're interested to add them ?
Anyway, it was very interesting to read. Nice job !
I think the author may need introduce the Intel processor's segment
register change from 16-bit processor to 32-bit processor. In 16-bit
processor, the CS register's value is the (segment offset)/16; while in the
32-bit processor, the CS register is still a 16-bit register, but its
value is just a index of the GDT.
In 32-bit mode, I think we can use 0xf000:0xfff0 to present the reset
vector because the CS's value is 0xf000 and IP's value is 0xfff0.
To keep with the 16-bit processor's presentation, we can also use the
0x0ffff000:0xfff0, because the CS segment offset is 0xffff000 and we can
calculate the segment's selector by (0xffff0000)/16.
In http://en.wikipedia.org/wiki/Reset_vector , it said that "The reset vector for the 80386 and later x86 processors is physical linear address FFFFFFF0h. The value of the selector portion of the CS register at reset is F000h, the value of the base portion of the CS register is FFFF0000h, and the value of the IP register at reset is FFF0h to form the segmented address FFFFF000h:FFF0h in real mode.", so it should be 0xffff000:0xfff0.
I also check the <<Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1>>, in section 9.1.4 "First Instruction Excuted", it said that "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]).". So in real mode, the CS base is 0xffff0000, the CS segment selector should be treated as (CS base)/16, which is 0x0ffff000.
0xAX