Question

Recently I’m looking at the linux 0.01 source code, since the bootsect.S in 2.6.11 and upper version is useless and it is a good place to start learning linux code, therefore I choose to trace the first version of linux. 😛

I have some question in bootsect.S. The following is some of the code in bootsect.S linux v 0.01.

P.S the first version assembly code is using intel syntax instead of at&t.

mov   ax,#0x0001  | protected mode (PE) bit
lmsw  ax          | This is it!
jmpi  0,8  | jmp offset 0 of segment 8 (cs) which is the second entry of the gdt.

gdt:

.word    0,0,0,0        | dummy
.word    0x07FF        | 8Mb - limit=2047 (2048*4096=8Mb)
.word    0x0000        | base address=0
.word    0x9A00        | code read/exec
.word    0x00C0        | granularity=4096, 386

.word    0x07FF        | 8Mb - limit=2047 (2048*4096=8Mb)
.word    0x0000        | base address=0
.word    0x9200        | data read/write
.word    0x00C0        | granularity=4096, 386

The booting process seems to be like the following:

• move the bootloader code from 0x7c00 to 0x9000

• jumps to 0x9000

• set the segment registers.

• load the system code to 0x10000
  (the system code contains boot/head.S and init/main.c according to the Makefile)

• load temporary gdt and idt with lgdt and lidt

• enable A20 to access the 16mb physical memory.

• set cr0 PE bit to go to protected mode

• jump to 0x000000

the following is the Makefile for system:

tools/system:   
boot/head.o init/main.o \
$(ARCHIVES) $(LIBS)
$(LD) $(LDFLAGS) boot/head.o init/main.o \
$(ARCHIVES) \
$(LIBS) \

-o tools/system > System.map

It seems like that the head.S and main.c is link together as the system binary which the bootsect loads into memory.

My question is if the system code(which entry is head.S/startup_32 ) is loaded in 0x10000 than why not jumps to 0x10000 instead jumps to 0x000000?
Isn’t it weird to jump to 0x0 since there is no code loaded inside there??

the following is the link to download the source code:
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B1F0m2rUn8BYMjQ4ZDQxZTUtODI5My00MGZiLTgwZDQtM2ZiZWQ2ZWQxYzIx

Answer 1

Here’s the answer:

| It then loads the system at 0x10000, using BIOS interrupts. Thereafter
| it disables all interrupts, moves the system down to 0x0000, ...

and here’s the code that goes with it:

        cli                     | no interrupts allowed !

| first we move the system to it's rightful place

        mov     ax,#0x0000
        cld                     | 'direction'=0, movs moves forward
do_move:
        mov     es,ax           | destination segment
        add     ax,#0x1000
        cmp     ax,#0x9000
        jz      end_move
        mov     ds,ax           | source segment
        sub     di,di
        sub     si,si
        mov     cx,#0x8000
        rep
        movsw
        j       do_move

If you look closely at the code, you’ll notice that it indeed starts doing REP MOVSW with ES=0,DI=0 (destination) and DS=0x1000,SI=0 (source), that is, it moves stuff from 0x10000(=DS*0x10+SI) to 0(=ES*0x10+DI).