Bochs "physical memory read error"

[inflater]

Hello again...
... after solving the issue with rmode->pmode switching through macros, there seems to be another problem.

Formerly, when executing call SwitchToPmode in my thread below, after the final RET it started to corrupt opcodes and then, "physical memory read error" by Bochs. Then, it threw the exception 0x06. My error handler looks like this:

Code: Select all

invalid_instruction:
	mov cx,6
	cmp cx,3
	jne invalid_instruction

(The cmp cx,3 etc is for bochs debugging.)

From above, I stated that the "final RET" started to corrupt opcodes. And it did even with the error handler function. Instead of "mov cx,6" it threw this: mov ecx, 0xf9830006 and instead of "cmp cx,3" and "jne invalid_instruction" it threw this -single line- add esi, dword ptr ss:[ebp+0xfffffff8].

But, this same problem has awaited for me again. In my kernel.asm, I call the macro SwitchToPmode and then I call the function "StartShell", which seems to be OK.
My StartShell function looks like this:

Code: Select all

StartShell:
	call Keybirq
	WriteStr "Hello"
	cli
	hlt

The Keybirq IRQ handler is located in the file interrupts.asm, which is included after real-mode include files, BUT BEFORE including "gdt.asm" and "idt.asm". GDT.ASM and IDT.ASM are included at the end of the include section, right where kernel.asm main part starts.

When I execute the function StartShell, it works, but when I attempt to execute "call KeybIrq", Bochs welcomes me with

bx_dbg_read_linear: physical memory read error (phy=0xbe6f09cc, lin=0x00000000be
6f09cc

and the "call keybirq" looks in Bochs like

(0) [0x00081977] 0010:0000000000003957 (unk. ctxt): call .+0xbe66f050 (0xbe6f09c
c) ; e850f066be.

Now the fun begins: if I attempt to "call" anything in e.g. interrupts.asm, stdio.asm (which is included before gdt.asm and idt.asm again), etc. -> it results in "physical memory read error".
And, after that - INT 0x06 with corrupted opcodes EXACTLY like above.

I suspect the order of include files to be faulty...

I'm welcome for any ideas or hints!

[Combuster]

tip of the day: do not use your kernel area as free memory

Try to figure what's changing your code

[inflater]

Tip of the day: keep away all data/code declared in 16-bit section to the code in 32-bit section and vice versa

Now it seems to work ... The error was:

include RMODE\INCLOOD.ASM
include PMODE\INCLOOD.ASM

in the use16 section... *bangs head*

On the other side, SwitchToPmode and SwitchToRmode must be declared as macros, or else ..., you know what.

//EDIT:
After SwitchToRmode, it's possible to access data declared in 32-bit section even in real mode (!) and you can even call some functions - but calling functions that do anything pmode-related (such as memory managment or interrupt handling) can have a unexpected result. For example, executing function RealMode_Print (in real mode of course) with ESI pointing to a string in the 32-bit part of my OS will result in success, but executing RealMode_Print in pmode will result in firing INT 10h from the pmode IDT, which is simply "iret".
But still, the problem with the "physical read memory error" was because 32bit functions were declared in a 16bit section.

[pcmattman]

After SwitchToRmode, it's possible to access data declared in 32-bit section even in real mode (!)

If you don't reset segment registers after being in PMode you'll essentially be in Unreal mode (where the segment cache holds the 32-bit flat address space).