OSDev.org

Hi,



This isn't boot loader code - you're probably using GRUB as the boot loader.



You're using sections "strangely". Typically the ".text" section only contains executable code and not data (and data like "idt_info" should be in a ".data" or ".rodata" section). Also note that normally you'd have a special section for the multi-boot header so that you can write a linker script that ensures the multi-boot header is within the first 8 KiB of the file (which is required by multi-boot).



It fails to link because (with "dw idt_start - 1") you're asking for a 16-bit piece of data ("dw") that contains a 32-bit address (the result of "idt_start - 1") and the linker can't figure out how to make 32 bits of stuff fit in 16 bits of space.

Note that this is all very wrong, and that it looks like you're using a variation of "brute force coding practices" where you randomly change lines of code with no understanding of what the code is supposed to do and then wondering why nothing works. For example, you can't just set a single bit and expect virtual8086 mode to work, and "IRET to virtual 8086 mode" requires a lot more on the stack (the values to use for all segment registers). You will need to read and understand the part of the Intel manual that describes all of the details of virtual8086 mode (which includes requiring a valid GDT and a valid TSS descriptor, and a valid IDT with a general protection fault handler that emulates a bunch of "sensitive" instructions - e.g. CLI, STI, IN, OUT, HLT, ...).



Once upon a time (80286) Intel created a horrible 16-bit protected mode that had a 16-bit "machine status word", and had an instruction (smsw) to set the machine status word. Not long after that Intel added a lot of changes (including adding support for 32-bit, adding paging, adding hardware task switching, adding virtual8086 mode, ...) and added a set of 32-bit control registers and new instructions (like "mov cr0, ...") for the new control registers. For backward compatibility the obsolete 16-bit machine status word became the lowest 16 bits of the new 32-bit "CR0" control register.

Essentially, 32-bit didn't exist when SMSW was created, and then SMSW was deprecated when 32-bit was introduced so Intel had no reason to make it work for 32-bit.



For NASM, there's a "warn on orphan labels" command line option (that should be enabled by default?) that you should be using to make sure that simple typos (e.g. "pushfs") don't get treated as labels (e.g. like "pushfs: ") and accepted by the assembler.


Cheers,

Brendan

hi,


i know it isn't the bootloader, as you said, grub is the bootloader, if you see in one of my previus reply, i've put this file as "kernelloader.asm", or something like that.

in the idt_info i made a mistake, cause it was .data and i wrote it like .text

´

don't worry, i'll learn as soon as is in my hand to make it, 'cause i don't have much time to do learn about it.. i know, when i say "will it work" i mean if it won't crash or something like that... also in pushfs and pushfd, i forgot to mean, it should be, i think

anyway the osdev wiki does not contain much information about how to do it, and it's wrong. see in the code for "enabling VM86 mode" it makes an 16-bit label and another 32-bit label. also i didn't found anything by the web which explain how to do it.can you send me another link with more information please??

Thanks!

Hi,



You're right; that wiki page is relatively horrible - the example code to enter virtual8086 mode is wrong and there's lots of things it doesn't mention. There's also a different wiki page called Virtual Monitor that does mention a lot more of the things you'll need to worry about, but it's more of an introduction than a full reference. Ideally, both of these pages would be rewritten and combined into a single "Using Virtual 8086 Mode" page; but mainly you shouldn't be relying on the wiki for more than an introduction anyway. Instead; you should read (and understand) the whole "8086 emulation" chapter of Intel's software developer's manual.

Please note that this is not something you will get working in a few days; it's something that is probably going to take a month to get working, where after that month you won't be sure if there is/isn't a "corner case" that your code (e.g. your GPF exception handler) doesn't handle correctly - you'll just reach a "works for the video cards I tested it on (but may crash on other video cards)" state (and then maybe you might spend a few more weeks writing a set of "virtual8086 tests" to try to make sure there aren't any of these corner cases).


Cheers,

Brendan

If you're interested, I've fabricobbled some little demo of what is actually needed to make vm86 working in 32 bit protected mode and C. Most of this code you would have to implement anyway for any OS. But if you're just starting, then there is a lot to do.

Thanks PVC for your file, i think it will help me a lot.but for me it isn't enought for get it working, i want to know how does it work.i used Virtual 8086 Mode and Virtual Monitor also with intel developer's manual, but i didn't get a full explanation of how to make it work.anyway its good to get a file with references

Thanks!

Actually there is a lot of weird hacks involved so it takes time to understand. I've gotten it to work just recently myself.

it worked!!:)but i dont how to post the img

Thanks!

You're welcome

gcc doesn't advice of any error, but LD makes: undefined reference to 'idtInitialize', also to 'vm86Initialize', 'vm86Int' (x2 times), '__stack_chk_fail' --> in some codes this happens, i dunno why..

-fno-stack-protector should take care of it. are you trying to compile it with different flags?

i'll try with it.. im using ld -m elf_i386 -o bootloader.bin bootloader.o kernel.o

i tried, but when kernel boots, it comes back to grub. i'm tired of that error

That, and from what I see you only have functions referenced from main.c marked as undefined. So the problem seems to be that your kernel.o is just my main.o file which won't work without other .o files. You have to link them. main.c is just a demo code.

lol forgot that step XD

aaaaahhhh linker what problem you got with me!! multiple definitions of kmain, first in kernel.c(my kernel).. the problem is that in my kernel the only reference to kmain is when i call it