OSDev.org

Hi,

I started writing a small code ( C code ) along with a bootloader that prints "ALOK's OS". I run this code by doing a tftpboot to the computer where the binary is stored.
The code files are attached.

Now i'm displaying this message by using inline assembly code. But when i use printk statements it doesn't work and all i get is a blank screen!!

I've attached both the codes one with assembly display and the other one with printk.

Regards
Alok

Why do you expect any of this to work at all? This reminds me of http://forum.osdev.org/viewtopic.php?f=1&t=21823, only even more broken. Looks like you just copied and pasted random bits of code expecting it to magically work.

Let's begin by looking at bootsect.asm. You never enter protected mode, so obviously the jmp 08h:clear_pipe won't do what you think it does. For this to be meaningful, you must be in protected mode and you must have a GDT with a code descriptor at offset 8. Otherwise, segment 8 is just a normal 16-bit segment starting at address 80h. Then, assuming 32 bit protected mode, you jump to address 1000h for some reason. Why? There's nothing there, since you haven't loaded anything there. That's what a boot loader is supposed to do, it loads things.

Then, there's main_assembly.c. Is this for GCC? I'm assuming it is, because of the AT&T syntax. GCC produces 32-bit programs, and the int 10h invocations obviously won't work in protected mode.

main_printk.c seems to have something to do with Linux. Needless to say, you can't use Linux APIs when there's no Linux around.

Hi,

The whole thing actually works despite of all the flaws you have listed

The compilation steps were:
nasm -f bin bootsect.asm -o bootsect.bin
gcc -ffreestanding -c main.c -o main.o
ld -i -e _main -Ttext 0x1000 -o kernel.o main.o
objcopy -R .note -R .comment -S -O binary kernel.o kernel.bin

dd if=bootsect.bin of=os.bin bs=512 count=1
dd if=kernel.bin of=os.bin bs=512 seek=1. i get the binary here.

Since in the linking part i'm giving the start of the main.c code to be0x1000, when the bootloader jumps to that address the c code gets executed. So it prints even with the int10h invocation.

Now could u please elaborate on the GDT part (since my comp was rebooting when i had the gdt part of the code) and how to move out of asm code in my c code i.e. using c or kernel functions.

Alok,

If your goal was to print something to the screen using int10 then I guess you have succeeded. But I suspect your success was an accident allowed by the fact that 16bit and 32bit opcodes are similar.

Judging by your comments in the bootsect.asm, I think you want to get to protected mode. Elaborating on the GDT is not possible in the email. Have you read the wiki? Intel/AMD manuals?

- gerryg400

Hi,

The bootsect.asm is a trimmed down version of the file attached. I removed the read sector part. Then it was rebooting the computer with the gdt part in the .asm. So i removed it and it worked fine. Could you tell why was that happening?

So if i understand it right i'm still in 16bit mode because of not using GDT. So is the purpose of gdt to bring the code from 16bit to 32bit, so that we can start using c functions in the code.

Regards
Alok

Hi,

Currently i'm using the attached bootloader file with gdt but the code used to switch into protected mode is commented. this is because when i run the bootloader with the following lines uncommented my computer reboots.

mov eax, cr0
or eax, 1
mov cr0, eax

Could anyone tell why this is happening!!

Regards
Alok

Since in the linking part i'm giving the start of the main.c code to be0x1000, when the bootloader jumps to that address the c code gets executed. So it prints even with the int10h invocation.

I can't even begin to describe how wrong that is. Okay, maybe I just will.

The entire thing gets loaded by the PXE environment to 0x7c00, and when it starts, it jumps to 08h:clear_pipe, which is the same location as clear_pipe+80h, at which point it just executes the 00 bytes at the end of the boot sector, which are interpreted as add [bx+si], al. Eventually, it gets to 55 aa, which is push bp followed by stosb. Then it falls right into 0x7e00, which happens to be the code in main_assembly.c, and this is all byte instructions that don't use addresses, so it just happens to work by accident.

Since you use PXE booting, the "loading" code doesn't need to be 512 bytes long, and you don't need the AA55 signature either. It's all just one big file. But if you don't link the kernel at the place where it will be loaded, you must copy it from the location where it is to where it should be. For example, if the kernel image is linked at address 0x1000 and resides at offset 0x200 in the NBP image, you must copy it from 0x7e00 to 0x1000, obviously. Otherwise, nothing will be at 0x1000.

And you can't use int 10h or any other BIOS service in protected mode. And you definitely can't call any functions that you haven't defined, such as printk from Linux, since they just aren't there.

Hi,

Thanks for the reply. Could u provide some information or links on how to achieve this (i.e. NBP image?, and creating this image and copying it to the location from where it should be loaded from)

Since you use PXE booting, the "loading" code doesn't need to be 512 bytes long, and you don't need the AA55 signature either. It's all just one big file. But if you don't link the kernel at the place where it will be loaded, you must copy it from the location where it is to where it should be. For example, if the kernel image is linked at address 0x1000 and resides at offset 0x200 in the NBP image, you must copy it from 0x7e00 to 0x1000, obviously. Otherwise, nothing will be at 0x1000.

Since i couldn't find any i had to go for the bootloader code with the AA55 signature

Thanks
Alok

The NBP image is your os.bin. You just place your kernel somewhere inside it, and it will be loaded, and then you can copy it to wherever you like. It can't get much simpler than that. You should have an advanced understanding of computers and programming before beginning on an OS, and then this should be a breeze.

Your startup code could look like this:
Of course, you can avoid the copying by just linking the kernel at the same address where it will be loaded, such as 0x7e00 with the commands you are using.

Hi,

Thanks for all the help. I agree understanding of computers and programming is a must. One last query the part where we move to the protected mode i.e

mov eax,cr0
or al,1
mov cr0,eax reboots the computer!!. Any idea why.

Thanks
Alok

That instruction doesn't reboot the computer. The crash happens somewhere later on, and to find out where, you could for example debug in in Bochs. I haven't used network booting in Bochs, so I don't know how easy it is to set it up.

Hi,

when i comment the three lines the whole thing works i.e. it reaches the jump to the kernel part.

Alok

Before entering protected mode, you need to enable the A20 Line. Have you done this?

I really don't think that's the problem at this point.

If you're using the same main_assembly.c as before, then needless to say, that obviously won't work since it uses int 10h. If not, how does the "main" function look now? I should also mention that depending on "main" to end up at the very beginning of kernel.bin is not the brightest idea. You could ensure that the execution starts at the correct function by having a stub written in assembly language as the very first part by linking it as the first file or putting it in a segment which precedes the other segments in the linker script.

hi

I am using the bootloader provided by you, my same main_assembly.c. It all works (don't know how...) with the three lines i.e.

mov eax,cr0
or al,1
mov cr0,eax commented out and i get the message in the main.c displayed.

On uncommenting them the computer reboots.

Is setting of the cr0 hardware dependent and also is the gdt correctly setup?

Thanks
Alok