can't load the C-Kernel

[newUser]

Hello

I made a tutorial: http://www.henkessoft.de/OS_Dev/OS_Dev1 ... ocId652294

I can assemble, compile and link the files and boot the os with qemu,
but when i want to load the c-kernel (call main), the system will hang in the protected mode.


the quellcode and the image are attached as *.zip file.

the linkscript

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(RealMode)
SECTIONS
{
  .text  0x8000 : {
    *(.text)
    *(.rodata*)
  }
  .data  : {
    *(.data)
  }
  .bss  :  { 					
    *(.bss)
  }
  
}

assemble, compile and link:
(I use 64bit kubuntu 11.10)

Code: Select all

nasm -f bin boot.asm -o boot1.bin
nasm -f elf32 kernel.asm -o kernel1.o
gcc -c -m32 ckernel.c -o ckernel1.o
ld -m elf_i386 -T kernel.ld kernel1.o ckernel1.o 
cat boot.bin a.out > testOs.img
qemu -d out_asm -fda testOs.img

but why i cant call a extern function? what i made wrong?

Edit:
the last entries in the qemu logfile:

Code: Select all

0x411b4a4f:  mov    %r13d,0x20(%r14)
0x411b4a53:  mov    $0x6,%edi
0x411b4a58:  mov    $0x6,%r13d
0x411b4a5e:  mov    %r13d,0x30(%r14)
0x411b4a62:  mov    %ebp,0x28(%r14)
0x411b4a66:  mov    %r12d,0x2c(%r14)
0x411b4a6a:  mov    %ebx,0x8(%r14)
0x411b4a6e:  mov    $0x7f9cee123160,%r10
0x411b4a78:  callq  *%r10

thanks in advance.

[Combuster]

I made a tutorial

No you didn't. You skimmed one. You didn't even follow it because the commands don't match.

[bluemoon]

That's better than writing a tutorial for something he didn't understand.

From the qemu log:

Code: Select all

0x411b4a78:  callq  *%r10

Suggest that it's running 64-bit code (while you compiling 32bits). Either you launch the wrong qemu and/or you linked it to 64-bit binary - try using a cross-compiler and tool-chain.

[xenos]

Try -d in_asm instead of -d out_asm. The latter shows the generated host assembly code, i.e., the assembly that is running on your host computer (the one that is running QEMU) - but you certainly want to log the assembly code on the simulated target computer.

[newUser]

@Combuster
Yes that's true. First of all i will have a development envirement that can can build a os with a c-kernel, then i will start develop my own bootloader and kernel.

@bluemoon:
I had try to boot qemu as 486 cpu (qemu -cpu 486 -fda os.img) : the same Error.

Try -d in_asm instead of -d out_asm. The latter shows the generated host assembly code, i.e., the assembly that is running on your host computer (the one that is running QEMU) - but you certainly want to log the assembly code on the simulated target computer.

Thanks, now its looks like 32bit code.

here are the the in_asm code:

Code: Select all

...
0x0000fe97:  add    %al,(%eax)
0x0000fe99:  add    %al,(%eax)
0x0000fe9b:  add    %al,(%eax)
0x0000fe9d:  add    %al,(%eax)
0x0000fe9f:  add    %al,(%eax)
0x0000fea1:  add    %al,(%eax)
0x0000fea3:  add    %al,(%eax)
0x0000fea5:  add    %al,(%eax)
0x0000fea7:  add    %al,(%eax)
0x0000fea9:  add    %al,(%eax)
0x0000feab:  add    %al,(%eax)
0x0000fead:  add    %al,(%eax)
0x0000feaf:  add    %al,(%eax)
0x0000feb1:  add    %al,(%eax)
0x0000feb3:  add    %al,(%eax)
0x0000feb5:  add    %al,(%eax)
0x0000feb7:  add    %al,(%eax)
0x0000feb9:  add    %al,(%eax)
0x0000febb:  add    %al,(%eax)
0x0000febd:  add    %al,(%eax)
0x0000febf:  add    %al,(%eax)
0x0000fec1:  add    %al,(%eax)
0x0000fec3:  add    %al,(%eax)
0x0000fec5:  add    %al,(%eax)
0x0000fec7:  add    %al,(%eax)
0x0000fec9:  add    %al,(%eax)
0x0000fecb:  add    %al,(%eax)
0x0000fecd:  add    %al,(%eax)
0x0000fecf:  add    %al,(%eax)
0x0000fed1:  add    %al,(%eax)
0x0000fed3:  add    %al,(%eax)
0x0000fed5:  add    %al,(%eax)
0x0000fed7:  add    %al,(%eax)
0x0000fed9:  add    %al,(%eax)
0x0000fedb:  add    %al,(%eax)
0x0000fedd:  add    %al,(%eax)
0x0000fedf:  add    %al,(%eax)
0x0000fee1:  add    %al,(%eax)
0x0000fee3:  add    %al,(%eax)
0x0000fee5:  add    %al,(%eax)
0x0000fee7:  add    %bl,%dh
0x0000fee9:  icebp  

[Combuster]

Debugging in four steps:
- is the code under scrutiny expected (no it isn't, it is executing unused memory consisting of all zeroes)
- what is the direct cause of this (find the instruction that tells it to go here)
- did you find the problem?
- repeat steps ad infinitum with the new location.

[bluemoon]

In boot.asm

Code: Select all

org 0x7C00  ; set up start address of bootloader
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; setup a stack and segment regs ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    xor ax, ax
    mov ds, ax
    mov es, ax
    mov ss, ax
    mov sp, ax

1. You setup a stack at 0000:0000, which can cause issues when you later do INT 13h.

2. In the linker script you did not specify the order of objects, which is a potential problem since you blindly jump to start of binary in the loader.

3. In kernel.asm

Code: Select all

   mov ss, ax
    mov sp, ax
    mov si, welcome
    call print_string

Same problem as #1.

4. I do not check the rest.

[Combuster]

You setup a stack at 0000:0000, which can cause issues when you later do INT 13h.

That actually makes the first push write at 0000:FFFE, which may still cause issues but isn't necessarily wrong.

[newUser]

Debugging in four steps:
- is the code under scrutiny expected (no it isn't, it is executing unused memory consisting of all zeroes)
- what is the direct cause of this (find the instruction that tells it to go here)
- did you find the problem?
- repeat steps ad infinitum with the new location.

ok i had comment out the line "call main", and build a image without this call and compared the two logs:
i found out, that the last call is the "call main"

Code: Select all

0x0000818d:  mov    0x81bb,%edi
0x00008193:  lods   %ds:(%esi),%al
0x00008194:  test   %al,%al
0x00008196:  je     0x819c

----------------
IN: 
0x00008198:  stos   %ax,%es:(%edi)
0x0000819a:  jmp    0x8193

----------------
IN: 
0x00008193:  lods   %ds:(%esi),%al
0x00008194:  test   %al,%al
0x00008196:  je     0x819c

----------------
IN: 
0x0000819c:  mov    %edi,0x81bb
0x000081a2:  ret    

----------------
IN: 
0x00008167:  cmpl   $0xb8fa0,0x81bb
0x00008171:  jb     0x8153

----------------
IN: 
0x00008153:  call   0x8184

----------------
IN: 
0x00008173:  movl   $0xb8000,0x81bb
0x0000817d:  call   0x8441 <<<<------- call main 
0x00008441:  add    %al,(%eax)
0x00008443:  add    %al,(%eax)
0x00008445:  add    %al,(%eax)
0x00008447:  add    %al,(%eax)
0x00008449:  add    %al,(%eax)
0x0000844b:  add    %al,(%eax)
0x0000844d:  add    %al,(%eax)
0x0000844f:  add    %al,(%eax)
0x00008451:  add    %al,(%eax)
0x00008453:  add    %al,(%eax)

[newUser]

i had try to compile the ckernel.c file on a 32bit virtual machine with gcc -c -elf32 ckernel.c -o ckernel1.o

Code: Select all

nasm -f bin boot.asm -o boot1.bin
nasm -f elf32 kernel.asm -o kernel1.o
gcc -c -elf32 ckernel.c -o ckernel1.o
ld -m elf_i386 -T kernel.ld kernel1.o ckernel1.o 
cat boot1.bin a.out > testOs.img

and i boot the image with qemu -cpu 486 -fda testOs.img
now should be the binary and virtual host 32bit(qemu).

But the error rests.
I can't anderstand. What's wrong?

Edit:
@bluemoon:

2. In the linker script you did not specify the order of objects, which is a potential problem since you blindly jump to start of binary in the loader.

the first jump to the entrypoint "RealMode" is successful.
only the last call to the main function don't work.
can you give me an example how i specify the order of objects in the linker script?

thanks in advance.

[newUser]

Or can someone give me a simple bootloader and asm kernel, thats load a c-function with linker and compiler options. then i can check whether my development envirement is working. And after this i can start to learn how i built an operation system.

thanks in advance.

[turdus]

http://wiki.osdev.org/Bare_bones
http://wiki.osdev.org/Babystep1

[Solar]

...and lest we forget, Required Knowledge...

[Combuster]

i found out, that the last call is the "call main"

- did you find the problem?

No you didn't. you found something related to a problem. You did not understand it.

- repeat steps ad infinitum with the new location.

Is the jump correct? Where should it be pointing? How did that get there? (Actually, my crystal ball says only the first part of the message arrived).

Point is, you still have to demonstrate that you are capable enough to isolate a cause. I won't tell you the next step in debugging let alone lead you all the way to the bug, I can only help you understand the bug after you found it. That's actually the key about what the forum rules expect from OS developers.