unreal mode tutorial protected mode parts (in SMP)

[Geri]

i succesfully awaken the multiple SMP cores in the system, and i have to switch the cores to unreal mode.
i am using smallerc and inline assembly. the awaken cores jumping into inline assembly code around ~3k, and the threads are working perfectly now.

parts of this process is not pre-deterministic as its going with a C compiler, and i dont have full control on code origins, cs, and ip.

so basically i jump into assembly code which is works (it does what i want), and i try to enable unreal mode with the Big Unreal Mode trick ( http://wiki.osdev.org/Unreal_Mode ) by using the given code snippet (except using different sp to not grind code down).

mov ds, bx crash. (even if i try to execute this code snippet from the bootstrap core, it is crashing, so its broken)

what could be the reason?

i suspect that i must set gdtinfo base into something.

a tryed the folowing:
i attempted to grind down cs to 0 if the case its not 0, in the hope that is maybe required for simplier handling

Code: Select all

  "xor ax, ax\n"
    "mov ds, ax\n"
    "mov ss, ax\n"
    "mov ebx, 0\n"
    "mov ecx, 0\n"
    "mov edx, 0\n"
    "mov fs, ax\n"
    "mov gs, ax\n"
    "mov es, ax\n"
    "mov sp, 57344\n"
    "mov ax, cs\n"
    "cmp ax, 0\n"
    "je nincsmarcx\n"
    "mov cx, 16\n"
    "mul cx\n"
    "add ax, 16\n"
    "push    0\n"
    "push    ax\n"
    "retf\n"
    "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"      "nop\n"    "nop\n"     "nop\n"    "nop\n"   "nop\n"      "nop\n"      "nop\n"      "nop\n"      
    "nincsmarcx:\n"

this does not making any difference, the crash is still at mov ds, bx of the unreal mode switcher (so maybe not working at all)

i tried to mov several values with mov [gdt+2], ax, where i tried to set ax to cs*16 for example, not sure if made it properly, since the crash at mov ds, bx still stayed.

Code: Select all

    "mov ax, cs\n"
    "mov cx, 16\n"
    "mul cx\n"
    "mov [gdtinfo+2], ax\n"

and again, since i am using c compiler, i dont have control over orgs, and cant pre-determinate most of the things. what is the solution in case like this? (if this is the problem and i dont overlook something else)



EDIT 1:
possibly i am assuming the reason (wrong data in gdtinfo) of the problem to be wrong, and itself the pointer of gdtinfo is bad.

EDIT 2:
what the hell? i got a20 unlocked and 32 bit width at DEFAULT from the AP-s alreday? isnt they supposed to be in 16 bit real mode?

[alexfru]

Why don't you just make your AP's far call into ___setup_unreal from c0du.asm?

[Geri]

Why don't you just make your AP's far call into ___setup_unreal from c0du.asm?

hi, i got symbol error if i attempt to do so (symbol `___setup_unreal' undefined)

[Geri]

...btw i guess i missing the point with the base, maybe the pointer of gdt is overally wrong, and thats why its not working.

[alexfru]

Why don't you just make your AP's far call into ___setup_unreal from c0du.asm?

hi, i got symbol error if i attempt to do so (symbol `___setup_unreal' undefined)

Drop one underscore.

[Geri]

symbol `___setup_unreal' undefined
symbol `__setup_unreal' undefined
symbol `_setup_unreal' undefined

(i tried to add _-s to the end too)

or am i supposed to explicitly include something?

edit:
this seems to compile

"db 0x9A\n"
"extern ___setup_unreal\n"
"dd ___setup_unreal\n"

[alexfru]

symbol `___setup_unreal' undefined
symbol `__setup_unreal' undefined
symbol `_setup_unreal' undefined

(i tried to add _-s to the end too)

or am i supposed to explicitly include something?

Did you by any chance remove "global ___setup_unreal" from c0du.asm?

It works for me (see srclib/system.c):

Code: Select all

#ifdef __HUGE_OR_UNREAL__
static
int DosExec(char* comspec, struct execparams* p, unsigned* error)
{
...
#ifdef __UNREAL__
  asm("push    dword 0\n"
      "pop     es\n"
      "pop     ds");
  // Just in case set up unreal mode again, don't depend on #GP handler to do it.
  extern void __setup_unreal(void);
  __setup_unreal();
#endif
}
#endif // __HUGE_OR_UNREAL__

[alexfru]

edit:
this seems to compile

"db 0x9A\n"
"extern ___setup_unreal\n"
"dd ___setup_unreal\n"

If you're doing that from assembly, remember to patch (convert to far pointer) the address in the same way as in c0du.asm:

Code: Select all

__start:

...

    ; Call __setup_unreal()
    db      0x9A
;    db      0x66, 0xB8 ; mov eax, const
.patch_setup_unreal_addr:
    dd      ___setup_unreal

...

section .relot ; .relot must exist for __start__relot and __stop__relot to also exist
   ...
    dd      __start.patch_setup_unreal_addr ; patch the far call to __setup_unreal()

[Geri]

something is terribly wrong with something

i commented out everything (including the attempts to set unreal mode), except this
so this is what the cores are starting up to execute:

"xor ax, ax\n"
"mov ds, ax\n"
"mov ss, ax\n"
"mov ebx, 0\n"
"mov ecx, 0\n"
"mov edx, 0\n"
"mov fs, ax\n"
"mov gs, ax\n"
"mov es, ax\n"
"mov sp, 57344\n"
"mov dword ebx,12582912\n"
"mov dword [ebx],72\n"
"cicc:\n"
"jmp cicc\n"


its suprisingly WORKS.
but why?
the cpu uses 32 bit memory addressing with the mov to ebx, and even the a20 is unlocked (the data goes to the real address),

the cores seems to interhit the settings from the bootstrap core. but how so? isnt the cores supposed to start in 16 bit real mode?

[Icee]

Oh wow.

something is terribly wrong with something

Yes indeed.

its suprisingly WORKS.
but why?
the cpu uses 32 bit memory addressing with the mov to ebx, and even the a20 is unlocked (the data goes to the real address),

Because why shouldn't it? When you use [EBX] as the memory operand the assembler generates an address size override prefix, byte 67h (as well as an operand size override, 66h, in this case). Because of that the address is calculated as a 32-bit value. A20 has effect only on bit 20 of the address, which is not set in 0xC00000. So what's your problem?

[Geri]

should not [eax] throw a fault in real mode, if the value is above 64k aniways, when you are not in unreal mode?

[Icee]

should not [eax] throw a fault in real mode, if the value is above 64k aniways, when you are not in unreal mode?

Ouch, I totally missed that, sorry. How are you verifying that the value has been stored to the right address? Does this snippet run in an emulator or on real hardware?

[Geri]

this is running in qemu, in SMP

on the 0.th core i have a running unreal mode kernel, and i am printing the information from that memory location, to see what is there. so its really there, in that memory location.

i am totally happy with this situation by the way. but i am a bit concerned, why the AP-s are coming up in such a strange mode, maybe the real hardware will act differently, and this thing must be run in real world.

[Icee]

QEMU supports dumping segment register state through the monitor (Ctrl+Alt+2), using the info registers command. To select the AP, use the cpu command. Maybe the dump will give some clues.

EDIT: it would also be a good idea to double-check memory contents at 0xC00000, again using the QEMU monitor (the command you need for this is xp).

[Geri]

cpu0

EAX=00000003 EBX=00000401 ECX=00000001 EDX=00000062
ESI=fee00300 EDI=00001350 EBP=00007f5c ESP=00007f58
EIP=00000029 EFL=00000206 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 ffffffff 00cf9300
CS =02c1 00002c10 0000ffff 00009a00
SS =0b5e 0000b5e0 0000ffff 00009300
DS =0000 00000000 ffffffff 00cf9300
FS =0000 00000000 ffffffff 00cf9300
GS =0000 00000000 ffffffff 00cf9300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 000135b0 00000017
IDT= 00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000


cpu1
EAX=00000000 EBX=00c00000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000e000
EIP=0000198d EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =0100 00001000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000