OSDev.org

Hey guys!

I hope you can give me a little help here with this!

I use GRUB that doesn't allow me to load a kernel below 1 MB; solution is to set my text segment to start at 1 MB (0x100000), right? (linker script below).
I also use NASM to compile my boot.asm file. This file sets GDT and IDT properly and enters protected mode. But NASM won't mix 16- and 32-bit code; solution is to use the a.out format, right? So I mix 16- and 32-bit in one single file.
I also use DJGPP linker that is able to link the a.out format but here the problem comes in :

I got "relocation truncated to fit: 16 text" when linking the boot.asm with my kernel.o objects because no 16-bit object can be at an offset > 0xFFFF and my linker script sets text segment to 0x100000 and I can't set this value below because GRUB won't load my kernel.

I would like to know where I'm doing mistakes when implementing the OS. I'm wondering if I really have to use different VMA and LMA addresses in the linker script and if this will work or not.

OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
.text 0x100000 : {
code = .; _code = .; __code = .;
*(.text)
. = ALIGN(4096);
}
.data : {
data = .; _data = .; __data = .;
*(.data)
. = ALIGN(4096);
}
.bss :
{
bss = .; _bss = .; __bss = .;
*(.bss)
. = ALIGN(4096);
}
end = .; _end = .; __end = .;
}

Thanks to all.
Luis

why do you have both a function for going to pmode, and are you using grub which puts you in pmode? Is there a reason for doing both?

you may not leave "open references" to external symbols in your 16 bits code. The placeholder for the offset will then be of 16 bits and the linker needs to place a 32bits value there ... obviously it won't work.

Now, do you have a strong reason for wanting your code to be *under* the 1MB barrier ? ppl usually prefer being above that barrier, having whatever free space they wish for themselves.

You know GRUB virtually does whatever you could wish to do in realmode and then moves to protected mode, right ? ... Could you by any chance want to have 16bits code because of a V8086 stuff ? If that's the case, what about incbin code16.bin somewhere in your 32 bits code and then memcpy(some_low_address,ptr_to_code16_dot_bin,sizeof_code_16) ?

Ok guys, sorry for my stupid question. In fact, I didn't know that GRUB enters in protected mode. It was my fault. But by the way, as I was thinking I was in real mode, I have defined my IVT to start at address 0 and it worked fine with all interruptions (I was able even to use the keyboard interrupt). Is that really possible? Anyway, thank you all for the clarifying me.

The ld error is that it tried to make a jump similar to

jmp 0x102589

which it couldn't make in 16-bit jumps. It has thus changed it to

jmp 0x002589

which it warns you about that it isn't the same, but is the best it can do.If you're doing this in a segment with a base of 0x100000 it doesn't make a single difference, and if you told nasm about the ORG of the stuff, but didn't tell LD about it (which is very common, and I forgot how to tell it about it) it craps out and "truncates" it, after adding the new base to it. If the new base was 0 (when leaving out the last 16 bits) it stays the same and just works.