Odd Bochs Error

[Cjmovie]

APIC register 00000ff0 not implemented

And it happens only when I call the C part of my kernel:

Code: Select all

void KernelEntry(){
 for(;;);
}

This is my ASM code. If I comment out the CALL directive, it works without the error:

Code: Select all

[BITS 32]
global Start

Start:
 mov BYTE [0B8000h], 'H'
 mov BYTE [0B8001h], 0x0A
 
 ;call _KernelEntry
 jmp $

extern _KernelEntry

This is how I build my kernel. I am using Cygwin.

Code: Select all

REM Build Kernel
nasm KernelEntryAsm.asm -o Object\KernelEntry.bin -f coff

gcc -c -ffreestanding -Wall -O Kernel\Kernel.c -o Object\Main.o

REM Link Kernel

ld -e Start -Ttext 0x110000 -o Object\kernel.o Object\KernelEntry.bin Object\Main.o
ld -i -e Start -Ttext 0x110000 -o Object\kernel.o Object\KernelEntry.bin Object\Main.o

objcopy -S -O binary Object\Kernel.o Object\kernel.KRNL

It seems like it might be an error of GCC including some of its own stuff, but what would mess with APIC from GCC?

Also, my enviroment on leaving the bootloader:
0x110000 - Location of data loaded,
In protected mode, 08h=Code, 16h=Data seg.

I have also verified my bootloader is getting the file contents correctly. If you would like to see the bootloaders, just ask, but they seem completly irrevelant to this. And they are over 1000 lines total all ASM .

[AR]

The APIC is memory mapped somewhere in high physical memory. I would suggest stepping through the code with Bochs' Debugger to find any broken pointers, also specifically look for it not being linked correctly (thinking the data/bss are someplace else).

Also, you do realise you are linking the kernel twice, and that "-i" makes it relocatable, flat binary does not support relocation. "16h=Data" doesn't make sense either, h=Hex meaning 0x10 .

[Cjmovie]

The APIC is memory mapped somewhere in high physical memory. I would suggest stepping through the code with Bochs' Debugger to find any broken pointers, also specifically look for it not being linked correctly (thinking the data/bss are someplace else).

Also, you do realise you are linking the kernel twice, and that "-i" makes it relocatable, flat binary does not support relocation. "16h=Data" doesn't make sense either, h=Hex meaning 0x10 .

1. I've checked pointers, I'll see what I can do about linking...
2. Actually, I wasn't entirely sure what -i was, apart from one document which now, it seems, was incorrect. Also said to do it once with, once without.....

[Cjmovie]

If I link them together, but with my C-Code function as the entry, it works fine. So I'm guessing It's trouble with either the WAY I'm linking them (So that one can't interact etc. with other, IDK) or some crazy problem with my ASM code (Although that seems very unlikely, considering its simplicity).

[bluecode]

hi,

imho its the way you link the kernel object files into a flat binary. You really shouldn't use the -i options, because then you've to relocate the kernel executable yourself, which I assume you don't do at the moment. You should also consider using a linker script (imho in the faq there's something about that topic). To find out what is executed instead of the call instruction you should use a debug version of bochs an step through your code (use bochs breakpoints to do so).

[AR]

hi,

imho its the way you link the kernel object files into a flat binary. You really shouldn't use the -i options, because then you've to relocate the kernel executable yourself, which I assume you don't do at the moment. You should also consider using a linker script (imho in the faq there's something about that topic). To find out what is executed instead of the call instruction you should use a debug version of bochs an step through your code (use bochs breakpoints to do so).

Flat binaries cannot be relocatable, by definition, a flat binary executable has no headers, no header=no symbols=no relocation entries. Relocation doesn't require runtime support anyway IIRC, the relocation is only used if you actually want to relocate the binary otherwise the image is left as is. Position Independant Code on the other hand is rather picky (in terms of ELF), requiring configuration before the image is useable.

I would also recommend a linker script though.

[Cjmovie]

Compiling (assembling...) the asm part in elf format seems to work, then using objcopy as above to get the binary equivilent.

Oh, but I did use this:

Code: Select all

ENTRY(Start)
phys = 0x00110000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
  }
  end = .;
}