how to use bochs?

[ckzippo]

Hi, i use qemu to debug my kernel before, but when a bug generates,i can not find why this bug happens.
So, i want to use bochs.

Here is my problem:
i set my kernel at address 0x100000, and the Boot will jmp to 0x100000 to start kernel.
In qemu, it works fine.

i set break point at 0x7c00, and it works.
but when i set breakpoint at 0x100000(this is the start of kernel), it cannot jmp to 0x100000 directly.
and the screen will display:

Code: Select all

00036698513e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036731283e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036764053e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036796823e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036829593e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036862363e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036895133e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036927926e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036960696e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00036993466e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037026236e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037059006e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037091776e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037124546e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037157339e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037190109e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037222879e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037255649e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037288419e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037321189e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037353959e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037386752e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]
00037419522e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff]

at first, i think i should wait. but for a long time ,it just keeps print things like this.
and can not stop at the break point 0x100000.
i dont konw why.

could any one help me ?

[Griwes]

Post your entire code, Bochs dump of CPU state and segment registers.

[Combuster]

Knowing how to read is a very essential skill in this business. It's repeatedly telling you that EIP neared 0x10000 and that it can't do that because of the 16-bit segment limit.

Ask yourself, why would EIP be 0x10000? how did it get there? You have figured out what the debugger is so you should be able to step through it to see where it goes wrong.

[Ready4Dis]

If you're in 16-bit real mode, you cannot jump straight to 1mb... (well, you can actually get just over 1mb, but better to do it correctly). The solution is either
A.) Switch to pmode and ensure you have a 32-bit kernel
B.) Load it somewhere else under 1mb.

C.) You know how seg:offset pairs work right? Well, if you use a seg of 0xf000, that is physical address 0xf0000, so the highest point you can hit using your offset would be 0xfffff. This is just under 1mb. If you however use something like 0xffff, this is physical address 0xffff0... so, if you use an offset of say 0x10, this puts you at 0x100000 exactly. So, the maximum address you can reach using this method is 0xffff0 + 0xffff (0x10ffef), so you can actually access 65520 bytes above the 1mb area. If you're kernel is less than 64k, you could still actually use it this way, but I would recommend not using this solution as it's messy.

[ckzippo]

Post your entire code, Bochs dump of CPU state and segment registers.

There are several hundreds of codes.
the segment registers are :

Code: Select all

es:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
cs:0x1000, dh=0x00009301, dl=0x0000ffff, valid=1
	Data segment, base=0x00010000, limit=0x0000ffff, Read/Write, Accessed
ss:0x0000, dh=0x00009300, dl=0x0000ffff, valid=7
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
ds:0x0000, dh=0x00009300, dl=0x0000ffff, valid=7
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
fs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
gs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
ldtr:0x0000, dh=0x00008200, dl=0x0000ffff, valid=1
tr:0x0000, dh=0x00008b00, dl=0x0000ffff, valid=1
gdtr:base=0x000fbb67, limit=0x30
idtr:base=0x00000000, limit=0x3ff

and dump_cpu command can not use in my bochs(2.5.1).
the value of general registers are:

Code: Select all

eax: 0x00000100 256
ecx: 0x00090000 589824
edx: 0x000f0000 983040
ebx: 0x00000000 0
esp: 0x00007c00 31744
ebp: 0x00000000 0
esi: 0x000e7c1d 949277
edi: 0x0000ffac 65452
eip: 0x0000845e
eflags 0x00000202: id vip vif ac vm rf nt IOPL=0 of df IF tf sf zf af pf cf

i find the segment registers are set correct, and the segment registers are set at the end of boot to jmp to protected mode.

[ckzippo]

Knowing how to read is a very essential skill in this business. It's repeatedly telling you that EIP neared 0x10000 and that it can't do that because of the 16-bit segment limit.

Ask yourself, why would EIP be 0x10000? how did it get there? You have figured out what the debugger is so you should be able to step through it to see where it goes wrong.

But i have changed to protected mode at the end of boot, then i jump to kernel.
And it is OK in qemu.

Thank you.

[ckzippo]

If you're in 16-bit real mode, you cannot jump straight to 1mb... (well, you can actually get just over 1mb, but better to do it correctly). The solution is either
A.) Switch to pmode and ensure you have a 32-bit kernel
B.) Load it somewhere else under 1mb.

C.) You know how seg:offset pairs work right? Well, if you use a seg of 0xf000, that is physical address 0xf0000, so the highest point you can hit using your offset would be 0xfffff. This is just under 1mb. If you however use something like 0xffff, this is physical address 0xffff0... so, if you use an offset of say 0x10, this puts you at 0x100000 exactly. So, the maximum address you can reach using this method is 0xffff0 + 0xffff (0x10ffef), so you can actually access 65520 bytes above the 1mb area. If you're kernel is less than 64k, you could still actually use it this way, but I would recommend not using this solution as it's messy.

Thank you for your answer.
But i changed to pmode , ant it works fine in qemu.
I'm pretty sure i have set the GDT right.

[Griwes]

There are several hundreds of codes.

"Code" is uncountable.

I meant CPU state, that includes processor mode... but your post shows exactly what I wanted to see.

http://wiki.osdev.org/Real_mode - CS = 0x1000 limit 0xffff - you are clearly in real mode.

Post your code to prove that you are in protected mode, please.

[Combuster]

Ask yourself, why would EIP be 0x10000? how did it get there? You have figured out what the debugger is so you should be able to step through it to see where it goes wrong.

But i have changed to protected mode at the end of boot, then i jump to kernel.

Computer says no.

It only takes a monkey to see that something isn't right, but finding out what requires a good detective. Go debug it - the required knowledge rule demands that you can.

[ckzippo]

Ask yourself, why would EIP be 0x10000? how did it get there? You have figured out what the debugger is so you should be able to step through it to see where it goes wrong.

But i have changed to protected mode at the end of boot, then i jump to kernel.

Computer says no.

It only takes a monkey to see that something isn't right, but finding out what requires a good detective. Go debug it - the required knowledge rule demands that you can.

Thank you!
I find the problem.
I use MBR to load Boot,and changed to pmode in Boot.
At first, i use hard disk in qemu,it works fine.
But when i use bochs,i use floppy disk.
i find that

Code: Select all

# Load Boot from the boot device	
	movw	$ext_rw, %si    # si = extended read/write parameter packet
	movb	$BOOTLEN, 2(%si)# Fill in # blocks to transfer	
	movb	$0x42, %ah	# Extended read
	int	$0x13

can not load the Boot to the address i want.

Can INT 0x13,ah = 0x42 apply to floppy disk?

[ckzippo]

There are several hundreds of codes.

"Code" is uncountable.

I meant CPU state, that includes processor mode... but your post shows exactly what I wanted to see.

http://wiki.osdev.org/Real_mode - CS = 0x1000 limit 0xffff - you are clearly in real mode.

Post your code to prove that you are in protected mode, please.

Thank you.
I find the problem.
I use INT 0x13,ah=0x42 to load boot(as a hard disk) in qemu,it works fine.
But i find it does not work when applied to floppy disk.(i use floppy disk in bochs).

because i use MBR to load Boot,this is done in MBR with INT 13, ah = 0x42.
it does not work.

[Kazinsal]

Nope. Can't use AH=42h with floppies. You're going to need to convert an LBA number to CHS yourself and use AH=02h.

EDIT: Just to be safe, before executing AH=42h/43h/48h, you should do AH=41h to make sure that the computer you're running on actually /has/ the BIOS LBA extensions installed.

[ckzippo]

Nope. Can't use AH=42h with floppies. You're going to need to convert an LBA number to CHS yourself and use AH=02h.

EDIT: Just to be safe, before executing AH=42h/43h/48h, you should do AH=41h to make sure that the computer you're running on actually /has/ the BIOS LBA extensions installed.

Thank you very much.