KERNEL LOADS...MACHINE RESETS

[slacker]

any ideas why my kernel would reset one of my PCs..IT works fine on one PC but makes the other PC reboot.

[gtsphere]

that could be happening due to a number of things.

first of all is the architecture different?
If it isnt, is the 2nd processor older? Because if you are using commands unknown to that other processor that will definatly cause it to fault.

Are you setting up any type of memory/memory manager? A faulty GDT or setup of paging could do this.

Any calls to a video card? If its a monochrome vs. vga, it could be writting to unknown memory, causing a fault.

There are many different reasons one pc could restart compared to another with your kernel. Maybe if you give us some more information it would be easier to help you. Also if anyone else has anything to add or correct please do so!

I hope this does help though
-GT

[LOneWoolF]

Erm... i think i'd like to add my problem here...:
My kernel lets all 6 machines I have here reboot --
BUT
if i put the whole code of my stdlib.c, vsprintf.c etc. into my main c file: kernel.c it works

but i wanna split my kernel - i think you know that it's not the best idea to put everything into ONE file...

K.J. from osdev.neopages.net told me that i don't have to define the c function extern - but it doesn't work either

could it be a linker problem? i already changes my LD two times
(i use cygwin...<-)

[Pype.Clicker]

did you check the kernel function included every code component ? (clue: let a constant string in each of them, with the filename, for instance, and check it appears in the final file ...

How do your kernel starts its executuion ? With a single file, you can roughly assume that your very first function will start at offset 0 and that you just have to jmp KERNEL_CODE:0 (or some other compile-time defined value) to make it run. With a multi-files technique, the order in which the object files are given to the linker may change the offset of your very first function.

A possible turnaround would be a asm-generated file with just "jmp start" code as the very first instruction that you force to be the first file assembled (using some LD script, for instance).

Finally, you could put a "magic field" just after that JMP so that you can make sure you got your starter-stub at offset 0 by just looking an hexdump of your file

[LOneWoolF]

trying to understand the high english language...<-<-

what do you mean with multi-file technique? more final files which are loaded on startup, or just what I've done: more .C files -> objects?

my linker script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
  .text  0x100000 : {
    code = .; _code = .; __code = .;
    *(.text)
    . = ALIGN(4096);
  }
  .data  : {
    data = .; _data = .; __data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .; _end = .; __end = .;
}

isn't it right, that just the order of the file-arguments for the linker is the important thing?

[tt]ld -T kernel/link.ld -o kernel.bin ks.o(the entry) kernel.o(the main kernel) stdlib_1.o(some functions) string.o(stringmanipulation...)[/tt]


(kernel attached...)

[attachment deleted by admin]

[Pype.Clicker]

Code: Select all

000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000fff70  00 00 00 00 e9 30 00 00  00 4b 45 52 4e 45 4c 20  |....?0...KERNEL |
000fff80  45 4e 54 52 59 20 50 4f  49 4e 54 60 0f a8 0f a0  |ENTRY POINT`.?. |

i've added a small "db 'KERNEL ENTRY POINT'" in kentry.asm, and it appears to be at offset fff70 in your final binary file. Imho, it seems that your linker script doesn't work fine.

note: i'm compiling under linux. I don't have the cygwin stuff installed ...

[LOneWoolF]

but but but but but but

my hex editor it at the beginning...:

Code: Select all

00000000: E9 1E 00 00 00 60 0F A8|0F A0 1E 06 66 50 E4 60 | ?   `??fP?`
00000010: E8 5B 00 00 00 B0 20 E6|20 66 58 07 1F 0F A1 0f | ?[   ? ? fX?
00000020: A9 61 Cf 4B 45 52 4E 45|4C 20 45 4E 54 52 59 20 | ?a?KERNEL ENTRY 
00000030: 50 4F 49 4E 54 E8 06 00|00 00 FA F4 00 00 00 00 | POINT?   ??    

[slacker]

when my ASM code jumps to my kernel at 0x100000 my first line in my c code is...
asm("jmp _main");
could this cause a problem with resetting?
btw...the PC that doesnt reboot my code is an older one....

[slacker]

ok, in my c kernel all i have is:

asm("hlt");

and i compiled it and used debugand the first line in the binary is hlt. that means it compiled fine.

i was thinking that since the kernel worked on one pc and not the other..maybe the a20 line needs to be enabled differently. how would i go about doing this not using the keyboard controller?

[Pype.Clicker]

The keyboard controller fashion is the best. However, it seems weird to me that your file is >1MB (if i'm correct), and that you still load it before entering pmode. Where is your A20 enabling code ? in your bootsector ?
If not, your code will not be loaded properly.

You should try to set the section's virtual address rather than the file offset.
maybe add .=SIZEOF_HEADERS before your very first section.

[slacker]

i found the problem...i was calling the a20 line function in my ASM code but when i called it the actual code was at the end of my asm file and i used [bits 32] after going to pmode so i guess the compiler thought the a20 line code was 32 bit code but its not supposed to be. oh well it works now.