C code rebooting for no reason

[azblue]

You can't get GRUB to work, so you write your own bootloader.
You can't parse your ELF file, so you want to re-write all in assembly or write a C interpreter.

You keep running into problems that would take x effort to solve and you instead avoid the problem with solutions that take 50x effort

[issamabd]

Hi,

Possible causes of the Triple-Fault (infinite hardware reboot) that you have gotten:

1. You have loaded the GDTR with a non physical address, so that when you switch to protected mode the CPU will not
find the GDT and a stupid TF will be triggered ! Following is how I used to load GDTR in my bootloader (using GNU assembler):

Code: Select all

         lgdt 	gdt_ptr
         ...
         ...
         gdt_ptr: .word	. - gdt - 1		# Limit = (8*3) - 1
	             .word	gdt,0x9		# 0x9xxxx: a physical address!

NOTE: Here my bootloader program was moved from physical addresses 0x7c00 to 0x90000

2. You have not purged the instruction queue of the processor before switching to protected mode, so that the processor continue executing 16-bit
code in 32-bit mode. You can empty the queue by executing a long JMP from a 16-bit code segment to a 32-bit segment. And here you have to use
the 0x66 prefix. Somewaht like this (GNU assembler syntax):

Code: Select all

	.byte	0x66,0xea		# prefix (0x66) + ljmp opcode (0xea)
	.word	ok_pm,0x9		# offset: 32-bit size
	.word	0x8			# CS = 0x8: GDT[1]

	.code32

ok_pm:	

	ljmp	$0x8, $0x0		# Long JAMP to kernel head (CS:EIP)

So, please check your bootloader for those two points!

Advise: Use Qemu to test your OS instead of rebooting you PC several times!

If you want, you can study this example that I have written: https://github.com/issamabd/timeros

[NunoLava1998]

Hi,

Possible causes of the Triple-Fault (infinite hardware reboot) that you have gotten:

1. You have loaded the GDTR with a non physical address, so that when you switch to protected mode the CPU will not
find the GDT and a stupid TF will be triggered ! Following is how I used to load GDTR in my bootloader (using GNU assembler):

Code: Select all

         lgdt 	gdt_ptr
         ...
         ...
         gdt_ptr: .word	. - gdt - 1		# Limit = (8*3) - 1
	             .word	gdt,0x9		# 0x9xxxx: a physical address!

NOTE: Here my bootloader program was moved from physical addresses 0x7c00 to 0x90000

2. You have not purged the instruction queue of the processor before switching to protected mode, so that the processor continue executing 16-bit
code in 32-bit mode. You can empty the queue by executing a long JMP from a 16-bit code segment to a 32-bit segment. And here you have to use
the 0x66 prefix. Somewaht like this (GNU assembler syntax):

Code: Select all

	.byte	0x66,0xea		# prefix (0x66) + ljmp opcode (0xea)
	.word	ok_pm,0x9		# offset: 32-bit size
	.word	0x8			# CS = 0x8: GDT[1]

	.code32

ok_pm:	

	ljmp	$0x8, $0x0		# Long JAMP to kernel head (CS:EIP)

So, please check your bootloader for those two points!

Advise: Use Qemu to test your OS instead of rebooting you PC several times!

If you want, you can study this example that I have written: https://github.com/issamabd/timeros

QEMU refuses to boot any NASM media and BOCHS too, for some reason.

[issamabd]

What you mean by "NASM media" ?

[Mikumiku747]

QEMU refuses to boot any NASM media and BOCHS too, for some reason.

That's likely because they're not bootable, or you're passing the incorrect options to qemu or using bochs with a bad config.

Try just running QEMU or bochs with a known working CD image (eg. a live CD or somebody else's kernel or whatever) and make sure that works first. You'll need to use an emulator eventually, there's no way around it, so it's better to start fixing your problems sooner than later.

At the very least, you can check for certain whether or not your C code is faulty by compiling the kernel and using qemu's -kernel option to run it. If it works, then you know something is definitely wrong with the bootloader. If not, well then, you know that the kernel is faulty, and you have one more thing to worry about.

As others have mentioned, it seems like you're escaping minor problems by creating major ones, just try to get the bare bones working with GRUB and an emulator like everyone else, you'll thank yourself later. Once you've mastered the basics, then you can start to become more independent.

What you mean by "NASM media" ?

I believe he just means something he compiled with NASM, which means it's probably not bootable for a number of reasons.

- Mikumiku747

[Ycep]

Nuno,
wouldn't be great idea to show us your bootloader code so we could speed up helping?

[NunoLava1998]

Nuno,
wouldn't be great idea to show us your bootloader code so we could speed up helping?

I've deleted it already (only can get it with a decompiler since i still have the img file with the bootloader).
I have made a new kernel that loads a file using my WaveFS file system in 16 bits real mode. I'll now implement a change to run in V8086 when i fix the 2 errors (C:\Users\#####\Desktop\WaveSystem\WaveSystem>nasm kernel.asm -o kernel.bin
kernel.asm:75: error: operand 1: expression is not simple or relocatable
kernel.asm:76: error: comma or end of line expected
)


Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!

[matt11235]

Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!

Did you create an ELF file by hand or something?

[issamabd]

Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!

Did you create an ELF file by hand or something?

There is no ELF (Executable Linkable Format) files here ! Just a raw binary image, man !

[NunoLava1998]

Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!

Did you create an ELF file by hand or something?

i meant ELF doesn't need to be translated into binary, it works fine.

[glauxosdever]

Hi,

Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!

Did you create an ELF file by hand or something?

i meant ELF doesn't need to be translated into binary, it works fine.

So the CPU executes the ELF header? Unexpected things will happen this way.

Furthermore, unless your ELF binary is compiled as position-independent code, jumps and calls will be mangled and won't point to the correct addresses (since code will not start at 0x00007E00, but somewhere further, possibly just after the ELF header, or after data, or something).


Regards,
glauxosdever

[NunoLava1998]

Hi,

So the CPU executes the ELF header? Unexpected things will happen this way.

Furthermore, unless your ELF binary is compiled as position-independent code, jumps and calls will be mangled and won't point to the correct addresses (since code will not start at 0x00007E00, but somewhere further, possibly just after the ELF header, or after data, or something).


Regards,
glauxosdever

I think you never heard of

Code: Select all

qemu-system-i386 -kernel myos.bin

.

[Roman]

Code: Select all

qemu-system-i386 -kernel myos.bin

QEMU is able to parse ELF executables. Now what?

I think you never heard

Don't pretend to be more knowledgable than someone else, especially when you're not.

[NunoLava1998]

Tested on real hardware, same result.

[ziggyfish2]

So firstly use QEMU as this will give you access to some debugging information, that you can use to identify what the problem is. Use either the qemu -d , or the QEMU monitor to checkout what problems you are facing ( http://wiki.qemu.org/download/qemu-doc.html for more information on how to use it correctly).

Secondly, can you provide the qemu log file so we can tell you exactly what your problem is (I will not detail how to fix it though). Also provide your boot loader, as 0x07E00 address looks suspicious.

From what you have posted it looks like a problem with your interrupts, it seems you haven't disabled interrupts before you jump into protected mode. This needs to be done as the default interrupts that the BIOS provides are only 16bit, and will not work in 32 bit mode.