Question about Interrupts and Exceptions

[Midas]

Couldn't be the A20 gate - if the A20 line wasn't enabled, you can't address memory that high up.

The limit value should be 0x7FF, which is what I had it at.

What compiler are you using? I had all sorts of grief before setting up a cross-compiler.

[elderK]

GCC Version 3.3.6
LD Version 2.15.0.2 (20040927)

I got the right Limit being loaded, and I even got the right address being put into the k_idtp.ip_base, (the address is backwards in memory view). But, After lidt, the IDTR register is still bjorked. Differently bjorked, but still bjorked.

Cross COmpiler?... Wha?

~zeii.

[Midas]

The reason that you'll see things as 'backwards' in memory is that the x86 architecture is little-endian. There is a reason (that isn't the obvious one!) that it's called this, but I forget. Basically what it means is that the lowest bytes get stored at a lower address than the higher bytes. So, say you have a short (2 byte integer) 0xABCD; if you then stored this in memory, and started reading linearly from the start address of that short, then it would appear to be 0xCDAB to you.

A cross-compiler is a compiler which runs on one platform, but produces code for another. So a fairly extreme version of a cross compiler would be a cross compiler that runs on Linux on a i586 architecture processor, and produces code for some embedded system running on an ARM processor.

[elderK]

Well, Im getting this now:
idtr:base=0x10000000, limit=0x7ff

Checking IDTP.base after loadIDT, shows that its still the same - and right.

But still, the IDTR holds the wrong value.

idtr:base=0x10000000, limit=0x7ff
The base should be : 0x00011000, the limit is correct.

~Zeii.
PS: Im in the process of trying to setup a Cross compiler now.

[elderK]

Same problem, even after the Kernel source, etc is compiled with my Cross compiler.

~zeii.

[elderK]

Using your Script (With a few modifications).

The IDT address is : 0x12260
but the IDTR is being set to: 0x22600000

Its like... its being bitshifted to the left... by one place or something.

~zeii

[elderK]

I got it!

In the code you have Midas, the ip_base is a unsigned int.
I changed it to an unsigned char array of 6 elements.

and set it like so:

unsigned int tempAddresss = (unsigned int)&k_idt;
unsigned char* addressGrabber = (unsigned char)&tempAddress;
k_idtp.ip_base[0] = addressGrabber[0];
k_idtp.ip_base[1] = addressGrabber[1];
k_idtp.ip_base[2] = addressGrabber[2];
k_idtp.ip_base[3] = addressGrabber[3];
k_idtp.ip_base[4] = 0x0;
k_idtp.ip_base[5] = 0x0;

IDTR now has the correct IDT address, and exceptions now work .
IS this just a dirty hack to fix a hidden bug? or is it perfectly valid code?

~zeii.
PS: Now im working on resetting the GDT.
My Bootloader sets up Protected Mode GDT before it gets into the kernel.
But my Kernel has GDT setting code too, which im trying to get working.

However, when I try and load the new GDT, it dies horribly.
Also, is there any point to give the Kernel the ability to reset the GDT?
or is the GDT something that is likely to never change, once its been setup?

[Midas]

Agh... That'd be why. Try making the base address an unsigned long. I'm currently booted into Windows so I can't check, but the base address pointer is a 32-bit address.

As for the kernel resetting the GDT... Em, I'm sure others can give better answers, but if you intend to switch back to real mode, it might be nice to have a 16-bit GDT.

[elderK]

Of all places, I found the answer to the problem for the IDT in the Intel Docs .

*shudder*
hehe.

Now, I suppose I better learn how to remap the Interrupt Controller, so I can actually deal with Hardware / Peripheral requests.

~zeii.