Page 2 of 3
Re: C code rebooting for no reason
Posted: Mon Oct 24, 2016 8:00 pm
by 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
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 3:15 am
by 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 
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 3:29 am
by NunoLava1998
issamabd wrote: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.
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 3:53 am
by issamabd
What you mean by "NASM media" ?
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 4:07 am
by Mikumiku747
NunoLava1998 wrote: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.
issammabd wrote: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
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 4:56 am
by Ycep
Nuno,
wouldn't be great idea to show us your bootloader code so we could speed up helping?
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 5:53 am
by NunoLava1998
Lukand wrote: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!
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 7:38 am
by matt11235
NunoLava1998 wrote:Booted it. Suprisingly, ELF is not needed to be compiled. Here i go, correct!
Did you create an ELF file by hand or something?
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 8:40 am
by issamabd
zenzizenzicube wrote:NunoLava1998 wrote: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 !
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 11:38 am
by NunoLava1998
zenzizenzicube wrote:NunoLava1998 wrote: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.
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 1:18 pm
by glauxosdever
Hi,
NunoLava1998 wrote:zenzizenzicube wrote:NunoLava1998 wrote: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
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 2:04 pm
by NunoLava1998
glauxosdever wrote: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
.
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 2:30 pm
by Roman
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.
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 2:50 pm
by NunoLava1998
Tested on real hardware, same result.
Re: C code rebooting for no reason
Posted: Tue Oct 25, 2016 7:04 pm
by 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.