assembly problem

[yemista]

I am having a very strange problem. My bootloader worked fine before, I change nothing, the only thing is now on the disk image I am loading a different kernel then before, however, for some reason, when running the bootloader, the computer keeps reseting. It seems that one instruction is not executing as it should. The disassembled code makes the instruction appear as it should, but when stepping through the instruction it does not appear the same. Also, right before that instruction executes, cs changes from 0x0000 to 0xf000, for no apparent reason. Here is the bochs dump

Code: Select all

(0) Breakpoint 2, 0x00007c9d in ?? ()
Next at t=306458801
(0) [0x00007c9d] 0000:7c9d (unk. ctxt): out 0x60, al              ; e660
<bochs:12> u /10
00007c9d: (                    ): out 0x60, al              ; e660
00007c9f: (                    ): call .+0x000b             ; e80b00
00007ca2: (                    ): mov al, 0xae              ; b0ae
00007ca4: (                    ): out 0x64, al              ; e664
00007ca6: (                    ): call .+0x0004             ; e80400
00007ca9: (                    ): sti                       ; fb
00007caa: (                    ): jmp .+0x000e              ; e90e00
00007cad: (                    ): in al, 0x64               ; e464
00007caf: (                    ): test al, 0x02             ; a802
00007cb1: (                    ): jnz .+0xfffa              ; 75fa
<bochs:13> sreg
cs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
ds:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=3
ss:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
es:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
fs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
gs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
ldtr:s=0x0000, dl=0x0000ffff, dh=0x00008200, valid=1
tr:s=0x0000, dl=0x0000ffff, dh=0x00008b00, valid=1
gdtr:base=0x000fb787, limit=0x30
idtr:base=0x00000000, limit=0x3ff

after stepping, the next instruction does not appear as it did in the disassembled code,
and cs has changes

Code: Select all

<bochs:14> s
Next at t=306458802
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:15> sreg
cs:s=0xf000, dl=0x0000ffff, dh=0xff0093ff, valid=7
ds:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
ss:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
es:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
fs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
gs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=7
ldtr:s=0x0000, dl=0x0000ffff, dh=0x00008200, valid=1
tr:s=0x0000, dl=0x0000ffff, dh=0x00008b00, valid=1
gdtr:base=0x00000000, limit=0xffff
idtr:base=0x00000000, limit=0xffff

here is the actual assembly code before being assembled

Code: Select all

	out 0x60, al

	call a20wait
	mov al, 0xae
	out 0x64, al

	call a20wait
	sti
	jmp A20enabled

also here is a memory dump of the code in question.

Code: Select all

0x00007c9f <bogus+       0>:	0xb0000be8	0xe864e6ae	0xe9fb0004	0x64e4000e
0x00007caf <bogus+      16>:	0xfa7502a8	0xa864e4c3	0xc3fa7501	0x7c07befb
0x00007cbf <bogus+      32>:	0x66ffa1e8	0x0566c031

[Brendan]

Hi,

Code: Select all

<bochs:14> s
Next at t=306458802
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0

The instruction at 0xF000:0xFFFF0 is the first instruction the CPU executes at power-on or after a reset - it's in the BIOS/ROM, and it's not your code. Something you did made the CPU reset.

You may have caused a triple fault (which is the most common cause of reset for OS developers), but you're also messing with the keyboard controller so it's possible that you triggered a reset using the keyboard controller - the bit that controls reset (bit 0 in the keyboard controller's output port) is right next to the bit that controls A20 (bit 1 in the keyboard controller's output port).


Cheers,

Brendan