Protected Mode:

Post your exact code, if possible. This isn't the kind of thing that usually can be adduced from "very similar to" code.

Also, have you carefully examined your own code and compared what it does (exactly, not approximately) to what Intel specifies in their section on switching modes from real to protected? Do you flush the instruction queue, for example, as you are supposed to? Do you reload _all_ of the selector/segment registers _after_ you set up the GDT in order to be sure that the internal cache is properly set up? There is a special JMP that you need that I always code with DB in assembly, as the MASM/ML assembler doesn't (I don't think so, anyway) have the ability to properly code it? Etc. Do you fully understand the whys and wherefores for each and every step?

Also, and finally, there are some opcodes that are interpreted differently when present in 32-bit segments than when in 16-bit segments. And I don't just mean _slightly_ differently. I mean, entirely different registers, etc. Does your c compiler actually generate the 32-bit opcodes, as designed for 32-bit segments?

Jon

Also keep in mind that not all ICE's deal with the transition perfectly. Have you tried other OSes that transition between real and protected mode (like Windows or NetBSD) with this ICE? Hopefully your ICE handles the transition properly, but it's possible that it doesn't. What processor are you using? Which ICE?

Is there anything odd about your hardware? Or is it "standard PC hardware"?

Patrick ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

============================================================================

You did follow with a far jump to the CS selector where your C code resides in right?

Without that far jump to flush to IP queue ... youll still be executing

16 bit code

Either that or your ICE is preventing you from switching modes ...

here are the relavant portions of code, please let me know if you need more details

lgdt cs:[0x435] lidt cs:[0x451]

mov eax,cr0 or al,0x1 mov cr0,eax

jmp 0x188

mov ax,0x8 mov ds,ax mov ss,ax mov es,ax

xor ax,ax mov fs,ax mov gs,ax

call 0x1178 ; C-FUNCTION

; When Ice is switched to interpret the code as protected 32, the disassembly is

push ebp

mov eax,0xFF mov ebp,esp mov byte ptr [0x20010],0x34

(the above instruction has no effect, further when looking at the ICE's wr-mem)

AD:00000114 wr-mem 77

for the above instruction.

If the ICE is not toggled to Protected 32-bit, the dissassembly is add [bx,si],al push bp mov ax,0xFF add [bx,si],al mov bp,sp mov byte ptr [di],0x10 add [bp+si],al

the C- Code being tested is: char* p=(char*)0x020010;

*p='4';

there is a loop after that which gets properly translated and executed, it is just the memory write that fails badly.

gdt has null,code,data segments with the following data:

null: 0,0,0,0,0,0,0,0 code: 0xFFFF,0,0,0x92,0xCF,0 data/linear: 0xFFFF,0,0,0x9A,0xCF,0

Chris

Lauterbach ICE for 386DX

The Hardware is a custom board, whose memory map was built for real-mode. There is hole in the RAM. The OPCODE being generated seem valid and even the disassembler interprets the instructions accurately it is the actual memory write that fails.

If I hand write 32-bit assembly instruction into RAM through the ICE, replace the C-generated instruction the CPU executes and writes to the correct location.

I'm quite sure this needs to be a FAR jump including the new Protected Mode CS. Here's how I coded it: (your syntax may vary)

Db 0EAH ;Flush the pre-fetch queue Dw 00188H ;Target offset Dw 00008H ;Target code segment

Shouldn't this be 0x10? According to your GDT, 0x0 is NULL, 0x8 is code, and 0x10 is data/linear.

Does the previous code (after the 'jmp') decode properly when the Ice is switched to interpret the code as protected 32??

Maybe it's as simple as DS not being set up right?

Good luck!

Patrick ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

============================================================================

Mmm... six years ago I spent a lot of time time trying to set up a Lauterbach ICE for 386-EX. We had a board made by ourselves that worked fine with VxWorks. We just wanted to be more efficient debugging the software. After several days struggling with the transition from real to protected mode, I finally gave up. The support from our local distributors (Spain) was very kind, but useless; the support from Germany was non-existent.

I agree the Lauterbach support is not great, maybe due to 386DX not being widely used for new development.

I have been able to work with the ICE now, I had to make a couple of changes:

1) copy the code that does the switch to RAM at 0x0. mov eax,cr0 or al,0x1 mov cr0,eax jmp 2) Just before you do the lidt, the IDT table needs to specified to the ICE 3) Just before "mov cr0,eax", the ICE needs to switched to protected mode. However if you are working in FLASH the IP after the switch is broken and hence I had to copy it to RAM at 0x0 to make it seem like the next instruction after the switch.

Thanks for all the help,

Chris