Calling C code from disk sector 2

[Ali]

Hi all,

I'm learning how OS in general works, for this i wrote a bootsector program in nasm, i'm loading sector 2--->6 , basically these contain my C code which i copy it using "dd if=kernel of=/dev/sdb seek=1 bs=512b" at 1000h:0000 followed by a jump, but this is not working.

If i replace the code in sect2 with a plain binary produced by nasm, it works.

So the problem is related to the way of producing "real mode" binaries with GCC.

I have tried a lot of methods ( linker stuff, etc...) but no luck.

Any suggestions please.

[01000101]

GCC has a really hard time producing "good" 16-bit code. I would recommend entering Protected mode before jumping to your kernel @ 0x10000. Either that, or load a second stage bootloader, and then enter Protected mode or whatever, then make the jump without having the 512-byte restriction of a 1st stage bootloader.

[Troy Martin]

Yeah, finding a good 16-bit C compiler is hard these days.

[Ali]

Amazing, very quick replies.

i'll try to enter in protected mode and then load my kernel, i'll post here if i have troubles.

Many thanks.

[M-Saunders]

If you're running Linux or a similar Unix-ish OS, then BCC will help you: http://www.debath.co.uk

It's available in the Ubuntu repositories, and no doubt in other distros as well. It's a C compiler that can generate flat, 16-bit x86 executables. I haven't spent a lot of time with it, but someone wrote a library to interface it with my 16-bit OS, so it does work and looks pretty good. There may be a Cygwin port if you're on Windows.

M

[tantrikwizard]

Yeah, finding a good 16-bit C compiler is hard these days.

Open Watcom has 16-bit C and C++ compilers that work pretty good.

[jal]

It's a C compiler that can generate flat, 16-bit x86 executables

Which is a bit of a contradictary in terms, as 16-bit is usually segmented (unless < 64K of code, of course). (Yes, I know you know, but it may confuse someone less informed...)


JAL

[M-Saunders]

Sorry, yes, I should've said 'raw' executables without sections/header etc.!

M

[Ali]

If you're running Linux or a similar Unix-ish OS, then BCC will help you: http://www.debath.co.uk

It's available in the Ubuntu repositories, and no doubt in other distros as well. It's a C compiler that can generate flat, 16-bit x86 executables. I haven't spent a lot of time with it, but someone wrote a library to interface it with my 16-bit OS, so it does work and looks pretty good. There may be a Cygwin port if you're on Windows.

M

I have Linux, i don't have windows. I already installed bcc on my Ubuntu box, i haven't tried it yet, do you know if i can use inline assembly using it?

Thanks a lot.

[M-Saunders]

I have Linux, i don't have windows. I already installed bcc on my Ubuntu box, i haven't tried it yet, do you know if i can use inline assembly using it?

Yep, you can, using '#asm' and '#endasm' like this:

Code: Select all

	x = some_c_stuff();

#asm
	mov ah, 0Eh
	mov al, 'M'
	int 10h			! This is a comment
#endasm

	y = more_c_stuff();

M

[Schol-R-LEA]

While I applaud the answers given, I am not certain if they will actually help the OP in this, as none of them address the question of whether the entry point for the main() function of the C code is at the first byte of the loaded sector or not. Being able to produce a raw binary image (rather than an ELF or PE executable file, which then needs to have the dependencies resolved at load time) is a necessary condition for this, but not a sufficient one, as you'll need to know where the compiler puts the entry point.

Does anyone know what sort of binary image BCC produces, and where the entry point is? If it does indeed place it at the start of the sector, all well and good; if not, you'll need to find out where it puts it, and may need to calculate it from header information in the image itself.

[M-Saunders]

Does anyone know what sort of binary image BCC produces, and where the entry point is? If it does indeed place it at the start of the sector, all well and good; if not, you'll need to find out where it puts it, and may need to calculate it from header information in the image itself.

Pass these flags to ld86, the linker in the Dev86 bundle that includes BCC:

Code: Select all

-d -T0

-d deletes the header from the executable; -T0 (T zero) specifies the base point of what would be the 'text' section. So there you have a raw binary for execution right from the start.

M

[Ali]

Pass these flags to ld86, the linker in the Dev86 bundle that includes BCC:

Code: Select all

-d -T0

-d deletes the header from the executable; -T0 (T zero) specifies the base point of what would be the 'text' section. So there you have a raw binary for execution right from the start.

M

I have tried the above, but it is not working, i'm linking the kernel.c with -d -T0x1000. attached the bsect and kernel.c please help.

[M-Saunders]

I have tried the above, but it is not working

Tip for future posts: saying "it's not working" achieves nothing What's not working? Does it not compile? Does it not boot? Does it boot but not execute as you intended? Always try to be specific.

From a very quick glance, I see this line in your bootloader, which jumps to the kernel execution point:

Code: Select all

	call 1000h:0000

The segment offset is 1000h, but the code starts at 0000h in that segment. So should just pass -T0 to the linker. Of course, it could be any other problem, but that's the most obvious one.

Also, don't try to do too much with your kernel until you're sure that it's loading correctly. Stick something like this at the start of main():

Code: Select all

#asm
	mov ah, 0Eh
	mov al, 'X'
	int 10h
#endasm

And get rid of the cls() call for now, because the screen could blank for another reason (eg a crash). With this code, once you see an 'X' on the screen you know that your kernel has loaded and is executing correctly, and you can work from there.

M

[Ali]

And get rid of the cls() call for now, because the screen could blank for another reason (eg a crash). With this code, once you see an 'X' on the screen you know that your kernel has loaded and is executing correctly, and you can work from there.
M

Yes i'm able to see the X, so my code is loaded correctly.

Many thanks.