Page 1 of 1
Problem with multiboot compliance
Posted: Thu Feb 09, 2006 4:12 pm
by beyondsociety
For the last week I have been trying to get my kernel to be multiboot compliant. If I boot my kernel from grub it displays the correct amount of memory that I have. But if I use my own bootloader with my kernel and either boot it from bochs or real hardware I get weird results. My bootloader sets all the required stuff that the multiboot standard needs to make it multiboot compilant. I have even checked to make sure my print and string functions are working. What could be the problem?
Code: Select all
Grub: mem_lower: 639k, mem_upper: 31744k
Code: Select all
Bochs or real hardware: mem_lower: 51/4000.4k, mem_upper: 51/4000.4k
Re:Problem with multiboot compliance
Posted: Thu Feb 09, 2006 6:45 pm
by nick8325
It's hard to tell with just that information. I can think of two things:
* Your kernel is getting confused about where the multiboot struct is.
* Your bootloader isn't really setting everything up properly.
As part of the second one: does your bootloader zero out the BSS? Otherwise, uninitialised variables won't be set to zero in your kernel but could contain anything.
Perhaps you should step through the kernel in Bochs to see what the problem is. If you're on windows, you should have bochsdbg.exe. Otherwise, you'll need to compile bochs with --enable-debugger --enable-disasm. The instructions to use it are at
http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html.
Re:Problem with multiboot compliance
Posted: Fri Feb 10, 2006 2:43 am
by Pype.Clicker
beyondsociety wrote:
Code: Select all
Grub: mem_lower: 639k, mem_upper: 31744k
Code: Select all
Bochs or real hardware: mem_lower: 51/4000.4k, mem_upper: 51/4000.4k
Sorry to ask that, but ... how the **** could your code be printing a flat number with GRUB (assuming "...: %dk") and something as strange as "...: %d/%d.%dk" with the other bootloader ??
Re:Problem with multiboot compliance
Posted: Fri Feb 10, 2006 1:52 pm
by beyondsociety
It's hard to tell with just that information. I can think of two things:
* Your kernel is getting confused about where the multiboot struct is.
* Your bootloader isn't really setting everything up properly.
Im thinking my problem is #1, the kernel is getting confused about where the multiboot struct is. I could be wrong and its #2, but Ive already checked this.
As part of the second one: does your bootloader zero out the BSS? Otherwise, uninitialised variables won't be set to zero in your kernel but could contain anything.
Yes it does. It also sets everything that is required in the "machine state" section in the multiboot standard spec.
Sorry to ask that, but ... how the **** could your code be printing a flat number with GRUB (assuming "...: %dk") and something as strange as "...: %d/%d.%dk" with the other bootloader ??
Im as stumped by it as you are. Do you have any suggestions besides what nick8325 posted?
Re:Problem with multiboot compliance
Posted: Fri Feb 10, 2006 3:48 pm
by nick8325
Sorry to ask that, but ... how the **** could your code be printing a flat number with GRUB (assuming "...: %dk") and something as strange as "...: %d/%d.%dk" with the other bootloader ??
Im as stumped by it as you are. Do you have any suggestions besides what nick8325 posted?
Hmm, just had an idea. Does your code to print numbers use signed ints internally? If it does, it will get confused by very big numbers: if your algorithm is something like
Code: Select all
int pos = 1000000000; /* position of digit we're considering */
int number; /* number we're meant to print */
while (pos >= 1) {
char digit = (number / pos) % 10;
put('0' + digit);
pos /= 10;
}
then when you pass in a big number, it will be negative. So digit will become negative, and it will print out something below '0' instead of above! As it happens, '/' is '0' - 1, and '.' is '0' - 2. So I suppose something like this is probably happening, although maybe not the exact thing.
(it's just a guess, though)
Re:Problem with multiboot compliance
Posted: Sat Feb 11, 2006 7:21 am
by Pype.Clicker
well, i cannot remember of having seen the remainder of a division being negative so far, but that could very well be the explaination... i guess printing the number _both_ in decimal and hex will give more info about what might get wrong, then.
Re:Problem with multiboot compliance
Posted: Sat Feb 18, 2006 12:03 pm
by beyondsociety
I still cant figure out the problem, Im wondering if there's something wrong in either my itoa or vsprintf function. Would someone be able to take a look at those two functions and see if there's something wrong that you spot.
Re:Problem with multiboot compliance
Posted: Sat Feb 18, 2006 2:21 pm
by nick8325
beyondsociety wrote:
I still cant figure out the problem, Im wondering if there's something wrong in either my itoa or vsprintf function. Would someone be able to take a look at those two functions and see if there's something wrong that you spot.
Yes, your itoa doesn't work properly with negative numbers
That's because n /= base; n *= base will work slightly differently to how you expect with negative numbers in C - it will round towards zero, I think. In two's complement arithmetic on a 32-bit machine, 0x80000000 is the most negative number and 0xffffffff is -1. So the unsigned version of a slightly negative number is lower than the unsigned version of a very negative number.
n will be closer to 0 than j (as you want), so n will actually be bigger as an unsigned number than j. That means digit will be below 0, so you will print digits below ASCII code '0', which explains the funny symbols you get.
You can avoid all these problems by changing int n to unsigned n
Re:Problem with multiboot compliance
Posted: Sat Feb 18, 2006 2:22 pm
by nick8325
Also, you can get the isolated digitally more easily with "n % base"...