[SOLVED] How to bootload a kernel

smeezekitty · 09-29-2009, 12:20 PM

ok, sorry for dragging this thread out but i have alot of questions
anyway
i tried assembling the start code
and linking it with the kernel object
then i got the kernel image out
then i commented out evreything after the comment in the bootloader
and appended the kernel to that
when i try to boot from the diskette i get the words on screen
BnL ver 0.1 and it freezes right there

smeezekitty · 09-29-2009, 01:00 PM

YES!
after alot of frustration
i got my kernel to bootload
but it cant find its data
for example instead of saying HELLO THERE!
it says EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEU

theNbomr · 09-29-2009, 02:04 PM

Okay, my hypothesis is that the correct entry point for you to call is not _main(), but whatever code runs prior to it, and which itself calls main(). This is known as the crt, C Run-TIme, startup code which is a standard module that the toolchain links. It is responsible for setting up argc/argv, probably setting up stack and other segment registers (for X86 real-mode, at least), and sometimes copying data out of non-volatile ROM into RAM (such as for ROMmed code); probably a host of other stuff, too. Your mission, then, is to find out what the entry point for this code is. It might simply be byte zero of your object module. Which brings up the next question, since you seem to be using a DOS hosted toolchain. What kind of object code are you generating? '.COM' vs '.EXE' formated files? This will dictate where your entry point is, and probably how you need to invoke the kernel. If it is a '.COM' format, I think you need to set a code segment prefix of 100H bytes, set the CS, DS, and SS registers to the appropriate values, and then call or jump to the entry point at CS:0000. For .EXE formatted files, I do not know what is needed, except that it is more complex, and involves having your bootloader knowing something about the format of .EXE files, and manipulating elements within it prior to invoking it.

This is pretty much all I know about DOS executables and the launching thereof. I suspect that there are websites around which spell this stuff out in some detail. The free DOS project probably has a lot of such data.

--- rod.

smeezekitty · 09-29-2009, 04:17 PM

its exe format converted to bin with exe2bin and i am not using the
C runtime so i have to call main directly

theNbomr · 09-29-2009, 04:24 PM

I think if you are not using the C runtime, you will have to do some or all of the work that it does (it is there for a reason, after all). I'm not sure how you avoid using it, actually. Can you explain?
--- rod.

smeezekitty · 09-29-2009, 04:32 PM

i made the kernel larger now it will not boot

smeezekitty · 09-29-2009, 04:47 PM

Quote:

Originally Posted by theNbomr

I think if you are not using the C runtime, you will have to do some or all of the work that it does (it is there for a reason, after all). I'm not sure how you avoid using it, actually. Can you explain?
--- rod.

i dont knwo if i have the stact and segments setup properly
ut i just arent linking with it because it assumes you are using DOS
i have created screen and file io functions
and basically anything you need for simple progams

smeezekitty · 09-29-2009, 04:54 PM

here is a sample of my kernel
call.asm:

Code:

    .MODEL TINY
    .CODE
    extrn _main:far

START:
jmp _main
END START

Code:

int getkey(){
asm mov ah,0
asm int 0x16
return (_AL);
}
int main(){
movecursor(35, 13);
outstring("HELLO THERE!");
int k = getkey();
movecursor(0, 0);
outstring("You pressed: ");
outch(k);
getkey();
return terminate();
}

note: this is just a sample code
i will not release the source to my kernel till its done

jlinkels · 09-29-2009, 05:38 PM

Your problem seems to be twofold. You have tried to create a bootloader, and now your bootloader is calling you 'kernel'. The first you have succeeded, the second is your problem, and there will be many more problems to follow.

Since your program runs in real mode on a 80x86 compatible computer, could install DOS, run debug, load your executable and off you go. Debug is one of the few native DOS programs which came for free with DOS which are not totally useless, as a matter of fact for the complexity of program you are writing now it is almost perfect.

Make sure you create a mixed source/assembly listing when compiling, it aids in debugging while single stepping.

jlinkels

jlinkels · 09-29-2009, 05:56 PM

Quote:

Originally Posted by smeezekitty

its exe format converted to bin with exe2bin and i am not using the
C runtime so i have to call main directly

If you don't use C runtime, how can you use high level I/O functions like outstring and movecursor??

And if you use some sort of library anyway, how comes you write your own version of getkey?

jlinkels

smeezekitty · 09-29-2009, 06:08 PM

no, i am writing the library from scratch
i think the problem is that theNbomr's bootloader is not loading my whole kernel

jlinkels · 09-29-2009, 06:19 PM

So you have written the outstring() function from scratch. Did you test it? Your output is 'EEEEEEEEEEEEEEEEEEEEE'. That might be a problem with your outstring function, but how are we able to find that out if you don't even care to post that code? I'll give you a hint. You are printing output from a buffer, and most likely you are not increasing the character pointer value.

And I'll give you another hint, if you are using C-like strings, you have to test on the terminator character, otherwise you'll be printing your own code. There is no such thing as a segfault in real mode.

I wish you all the best of luck if you want to try to get this to work without a debugger. You didn't intend to post every bug here from undiscloed code, would you?

jlinkels

smeezekitty · 09-29-2009, 06:27 PM

ok heres some more code

Code:

#define outstring kernel_print
void kernel_print(char *data){
int str = strlen(data);
for(int h = 0;h < str;h++){
_video_putchar(data[h]);
}
}

and

Code:

int strlen(char *s){
 int i=0;
 while(s[i]!='\0'){
 i++;
 }
 return (i);
 }

and

Code:

void _video_putchar(char c){
_AH = 0xE;
_AL = c;
_BL = 0xF;
asm {int 10h}
}

theNbomr · 09-29-2009, 06:45 PM

I second jlinkels' comment about breaking out the DOS debugger. It will allow you to debug your basic C code in a sane environment. It will also allow you understand the C startup code and object module entry points, which are vital to understand for implementation of the bootloader.
What procedure have you used to load the bootloader and kwasi-kernel onto the floppy disk? Is the bootloader code reading the correct number of sectors from the disk, and then storing it in the correct location? As I said before, a DOS '.COM' formatted file expects to be loaded at offset 100h of its code segment, and the first 100h bytes should/must be formatted according to the layout of a DOS Program Segment Prefix (PSP). Using a .COM formatted file will limit the size of your kernel to 64K, which may be kind of small, depending on what services it is expected to provide.
--- rod.

smeezekitty · 09-29-2009, 06:49 PM

i expect the finished kernel to be about 30 K so 64 is fine
i will try to debug it and report back
thank you so so much
most people dont even go near kernel questions