I have written a bootloader in ASM (I can post code if you like) and I plan to write a kernel in C /c++ because I don't want to have to deal with a Kernel written ENTIRELY in ASM. Is there any way (Got to keep this under or at 512 bytes) to allow the bootloader, written in ASM, to pass control (like call a method or something) to the C kernel?
I'm a newbie to this kind of thing, and I thought I would ask the pros.
Please be nice, this is my first post! :icon_cheesygrin:
bump!
I'm sure some one out there knows the answer!!!
I WISH it was so simple as to call a function and give control to another program. *sigh* I suppose you'll just have to execute the loader for the c kernel, or if the kernel is one file, then call the file and exit or return your bootloader.
I WISH it was so simple as to call a function and give control to another program. *sigh* I suppose you'll just have to execute the loader for the c kernel, or if the kernel is one file, then call the file and exit or return your bootloader.
Thanks so much for the reply! Yeah, I really wish it was too...
do you know if you could provide code of sorts that could do as you described? I mean, I'm not sure if I could write some ASM code to do that, because I am kind of a noob.
heres a basic way
.........................................
**call kernel**
put this into your bootload.asm
.........................................
**void kernel(void)
{
/* code */
}**
this would be kernel.c
.........................................
hope this helps
I would strongly recommend not responding to threads that have been dead for over two years, especially when the answer you're giving is unquestionably incorrect.
Why is your answer wrong? Well, first off, it does not address the matter of loading the compiled code into memory, and more importantly, of loading it correctly. Unlike with assembly language, there really isn't any option with most compilers to generate raw binary image files which can be loaded directly into memory; rather the generated code is going to be in an 'executable' format that contains relocation tables and other information that needs to be handled before the actual binary can be computed.
Worse, on the x86 and x86-64 platforms, your answer pre-supposes 16-bit C/C++ code, which few modern compilers will generate. In order to run the 32-bit or 64-bit code which are the mainstays of modern operating systems, you would need to switch into protected mode (or long protected mode) before running the C code, which means that the page tables, interrupt descriptors, and so forth would have to be in place before calling the compiled code.
he's q was how to get to the kernel and this does work yeah in 16 bit but he didnt let us know what bits and this worked for me when i built a small kernel.
Oh? What compiler were you using, and how did you coax it to produce raw binaries?
(On a guess, it was Turbo C, correct? And you simply created a .COM file? That would work, but it would be quite limited.)
No it wasnt Turbo C it was gcc on Linux using ld to Link them together and it didnt produce .COM it produced .BIN
This thread is ancient. I hope that you already found an answer. Anyways I am writing for people who are having the same question.
After you are done setting up gdt and switching to protected mode.
Jmp to a memory location like, jmp 0x8000 in your assembly. Assemble to generate boot.bin file
Write your C program and compile it with a cross-compiler to generate kernel.o file.
Then use the linker to create a binary from kernel.o file which loads at 0x8000 mem location
ld -o kernel.bin -Ttext 0x8000 kernel.o --oformat binary
Concatenate both .bin files and run with VM.
cat boot.bin kernel.bin > os-image
Tell us if this works.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.