Mouse Location Always Zero

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Mikumiku747
Member
Member
Posts: 64
Joined: Thu Apr 16, 2015 7:37 am

Re: Mouse Location Always Zero

Post by Mikumiku747 »

Code: Select all

Interrupt Descriptor Table (base=0x0000000000000000, limit=0):
You don't have an IDT loaded. You should, at the very least, make sure that you're using the LIDT instruction before you come back, but, more importantly, read the wiki articles on Interrupts, the IDT, setting up the IDT, and Interrupt service routines. You're missing some basic knowledge. In fact, there's a whole article on getting interrupts working (http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working), make sure you read through the whole thing.

Apart from that, make sure your LIDT instruction actually loads something reasonable (put a breakpoint right before the LIDT instruction, and check that you're actually giving it the exact values you think you are, and that they point to the right things too.)
Your second code block looks like it just got loaded with garbage data, and while Bochs will do its best to interpret that, it doesn't look at all like a normal IDT. It would also be helpful to tell us what you actually did, instead of just saying "Sometimes when I mess around."
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Mikumiku747 wrote:

Code: Select all

Interrupt Descriptor Table (base=0x0000000000000000, limit=0):
You don't have an IDT loaded. You should, at the very least, make sure that you're using the LIDT instruction before you come back, but, more importantly, read the wiki articles on Interrupts, the IDT, setting up the IDT, and Interrupt service routines. You're missing some basic knowledge. In fact, there's a whole article on getting interrupts working (http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working), make sure you read through the whole thing.

Apart from that, make sure your LIDT instruction actually loads something reasonable (put a breakpoint right before the LIDT instruction, and check that you're actually giving it the exact values you think you are, and that they point to the right things too.)
Your second code block looks like it just got loaded with garbage data, and while Bochs will do its best to interpret that, it doesn't look at all like a normal IDT. It would also be helpful to tell us what you actually did, instead of just saying "Sometimes when I mess around."
My bad, I forgot to call my load IDT function. :| Even when I call it, nothing significant happens. Still no IDT insertion. I have IRQ common stubs and ISR routines set up and working, I know that because once I got general protection fault and devision by zero. I only get IDT info when I enable writeTSS and flushTSS functions inside my GDT. Also my first and second GDT descriptors are returning ???

Code: Select all

 GDT[0x00]=??? descriptor hi=0x00000000, lo=0x00000000 GDT[0x01]=??? descriptor hi=0x00000000, lo=0x00000000 
Second is ??? only when I enable fulshTSS and writeTSS functions. :/ When I don't enable them I only see zero descriptor as ???.

Also here is my info tss:

Code: Select all

<bochs:5> info tss
tr:s=0x0, base=0x0000000000000000, valid=1
ss:esp(0): 0xff53:0xf000ff53
ss:esp(1): 0xff53:0xf000ff53
ss:esp(2): 0xff53:0xf000ff53
cr3: 0xf000ff53
eip: 0xf000fea5
eflags: 0xf000e987
cs: 0xe3fe ds: 0xf859 ss: 0xe739
es: 0xf841 fs: 0xe82e gs: 0xefd2
eax: 0xf000e9df  ebx: 0xf000e9df  ecx: 0xf000e9df  edx: 0xf000e9df
esi: 0xc0000151  edi: 0xf000f84d  ebp: 0xf000e9df  esp: 0xf000ef57
ldt: 0x9695
i/o map: 0xf000
<bochs:6> 

My TSS and IDT loaders:

Code: Select all

global tss_flush
tss_flush:
    mov ax, 0x2B
    ltr ax
    ret

global idt_load
idt_load:
mov [4+esp], eax
lidt[eax]
ret
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Techel
Member
Member
Posts: 215
Joined: Fri Jan 30, 2015 4:57 pm
Location: Germany
Contact:

Re: Mouse Location Always Zero

Post by Techel »

Check line 9.
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Techel wrote:Check line 9.
How am I supposed to do that.
I really really sound like a noob, but I am not Bochs expert.
So I need to insert a breakpoint inside my code? Or while Bochs is running?

Meanwhile:

Code: Select all

Panic:
Exception 3rd 13 resolution no implemented, once Bochs loads my os I get that
<bochs:1> c
(0).[240240156] [0x000000000011004b] 0008:000000000011004b (unk. ctxt): ltr ax                    ; 0f00d8
Next at t=240240157
(0) [0x000000000011004b] 0008:000000000011004b (unk. ctxt): ltr ax                    ; 0f00d8
<bochs:2> 

OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Octocontrabass
Member
Member
Posts: 5587
Joined: Mon Mar 25, 2013 7:01 pm

Re: Mouse Location Always Zero

Post by Octocontrabass »

You wrote "mov [4+esp], eax".

Is that really what you want?
User avatar
Ch4ozz
Member
Member
Posts: 170
Joined: Mon Jul 18, 2016 2:46 pm
Libera.chat IRC: esi

Re: Mouse Location Always Zero

Post by Ch4ozz »

If your using Intel syntax then your line 9 is wrong and should be:
mov eax, [esp + 4]

I'd suggest to use inline asm if your not familar with function prototypes:
asm volatile("lidt %0" : : "m" (_ip));
User avatar
Mikumiku747
Member
Member
Posts: 64
Joined: Thu Apr 16, 2015 7:37 am

Re: Mouse Location Always Zero

Post by Mikumiku747 »

With bochs, you can set breakpints on memory addresses, or if it's enabled in your bochs config, you can use a hacky functionality of bochs which acts like a debug opcode (bochs magic breakpoint). When I'm debugging something that only seems to have minor problems, I'll just use the magic breakpoint, but if it looks like debugging is going to be a bit more difficult, I'll use the proper address breakpoint.

For a proper breakpoint, while bochs is open, you just use the "break <addr>" to make bochs break when it gets to that address. If you don't know the address of something, use objdump (make sure you use the one that was made with your cross compiler) to disassemble your kernel and find the address where you want to break.

A sometimes quicker, and definitely dirtier way to add a breakpoint is to use bochs' magic breakpoint function (which has to be enabled in your config) is to do an "EXCHGW %bx, %bx" (use inline asm in a C source file), which will cause bochs to break as if there was a breakpoint immediately after the instruction. With this method, you have to recompile your kernel every time you change the breakpoint, but it also means you don't have to bother looking up addresses to break on, so pick whichever.

You should probably have a look at the wiki page on bochs, since it summarises *some* of the important information. That goes for everything, make sure you check the wiki first. (I used to not check the wiki, and it made me look like an idiot when the answer was laid out in plain words on the wiki.)
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Octocontrabass wrote:You wrote "mov [4+esp], eax".

Is that really what you want?
Nope.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Ch4ozz wrote:If your using Intel syntax then your line 9 is wrong and should be:
mov eax, [esp + 4]

I'd suggest to use inline asm if your not familar with function prototypes:
asm volatile("lidt %0" : : "m" (_ip));
I see it is supposed to be vice versa. ;)
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Mikumiku747 wrote:With bochs, you can set breakpints on memory addresses, or if it's enabled in your bochs config, you can use a hacky functionality of bochs which acts like a debug opcode (bochs magic breakpoint). When I'm debugging something that only seems to have minor problems, I'll just use the magic breakpoint, but if it looks like debugging is going to be a bit more difficult, I'll use the proper address breakpoint.

For a proper breakpoint, while bochs is open, you just use the "break <addr>" to make bochs break when it gets to that address. If you don't know the address of something, use objdump (make sure you use the one that was made with your cross compiler) to disassemble your kernel and find the address where you want to break.

A sometimes quicker, and definitely dirtier way to add a breakpoint is to use bochs' magic breakpoint function (which has to be enabled in your config) is to do an "EXCHGW %bx, %bx" (use inline asm in a C source file), which will cause bochs to break as if there was a breakpoint immediately after the instruction. With this method, you have to recompile your kernel every time you change the breakpoint, but it also means you don't have to bother looking up addresses to break on, so pick whichever.

You should probably have a look at the wiki page on bochs, since it summarises *some* of the important information. That goes for everything, make sure you check the wiki first. (I used to not check the wiki, and it made me look like an idiot when the answer was laid out in plain words on the wiki.)
After I fixed my syntax issue with ax, everything is the same. Also once my OS loads I see this.
Error code I get:

Code: Select all

<bochs:1> c
(0).[240239919] [0x000000000011004b] 0008:000000000011004b (unk. ctxt): ltr ax                    ; 0f00d8
Next at t=240239920
(0) [0x000000000011004b] 0008:000000000011004b (unk. ctxt): ltr ax                    ; 0f00d8
I will try and use break <addr> first, thanks for explaining.
Attachments
PANIC_010.png
PANIC_010.png (3.06 KiB) Viewed 2237 times
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Awesome News!!!
Looks like I fixed my GDT and ITD. No more crashes. I think that my issue was not passing any values to IDT and GDT flush methods.
I disabled TSS flush, and like bammmm it works like a charm, no triple fault.
Last edited by Octacone on Wed Jul 20, 2016 9:11 am, edited 1 time in total.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Now, that mouse drives me crazy.
Still getting X=0 and Y=0...
As far I as know I can only use one while loop for my entire OS, since I don't have tasking implemented yet.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

Anybody? Any ideas? :( :|
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: Mouse Location Always Zero

Post by neon »

Do not assume something works just because it does not crash. Verify it. Using the debugger, use info gdt and info idt to verify the entries look correct. Also recall that the logical IRQ used by the mouse is dependent on where you map physical->logical IRQ's via the PIC. If you followed a tutorial, it is most probably at IDT[44]. You can verify that the IRQ is being executed properly by writing its values to the serial port.

Check that the variables that define the mouse position are marked as volatile. Check that the IRQ is being called properly. If you are using paging, let us know - that opens up more things to check. If the IRQ is not being called, make sure it is unmasked. Make sure it is at the correct location in the IDT - check your PIC code to get it. Check your Bochs crash logs for any warnings.

Without the source code and without access to your debugging information, all we can really do is provide you with what to watch for and look for.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
User avatar
Octacone
Member
Member
Posts: 1138
Joined: Fri Aug 07, 2015 6:13 am

Re: Mouse Location Always Zero

Post by Octacone »

neon wrote:Do not assume something works just because it does not crash. Verify it. Using the debugger, use info gdt and info idt to verify the entries look correct. Also recall that the logical IRQ used by the mouse is dependent on where you map physical->logical IRQ's via the PIC. If you followed a tutorial, it is most probably at IDT[44]. You can verify that the IRQ is being executed properly by writing its values to the serial port.

Check that the variables that define the mouse position are marked as volatile. Check that the IRQ is being called properly. If you are using paging, let us know - that opens up more things to check. If the IRQ is not being called, make sure it is unmasked. Make sure it is at the correct location in the IDT - check your PIC code to get it. Check your Bochs crash logs for any warnings.

Without the source code and without access to your debugging information, all we can really do is provide you with what to watch for and look for.
Wait wait wait wait. You said "volatile"? I did not mark my coordinates as volatile. When I do that I get: error: conflicting type qualifiers for ‘mouse_x’

Code: Select all

volatile uint8 mouse_x = 0;
volatile uint8 mouse_y = 0;
I already checked IDT and GDT, they seem fine to me. (using info xyz)
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Post Reply