Page 1 of 1
need help switching back to real mode
Posted: Thu Feb 07, 2008 2:22 pm
by packet50071
I spent enough time in kernel programming i am getting bored now
so i want work on eye candy for a fun
but i cannot seem to get back to real mode
when i run it vmware says
*** VMware Server internal monitor error ***
vcpu-0:SyncCB failure: 6f76665 (bug #4938)
There is a problem in this version of VMware Server.
We rely on your feedback to improve the quality of our product. Please submit a support request that describes the problem at our Web page "http://www.vmware.com/info?id=8". Do not forget to attach the log file (C:\djgpp\bin\vm\vmware.log) and the core file (c:\djgpp\bin\vm\vmware-core.gz).
To collect files to submit to VMware support, run vm-support.vbs.
We appreciate your feedback,
-- the VMware Server team.
obviously its not their problem. It must be my code
my code :
Code: Select all
[BITS 32]
;part of this code is base on http://www.osdever.net/bkerndev/
global _etry, _multi_b, _halt, _kernel_stack
extern _Gptr,_link_text, _link_data, _link_bss,_PTRidt,_EX_handler ,__irq_handler,_kernal
MULTIBOOT_PAGE_ALIGN equ 1<<0
MULTIBOOT_AOUT_KLUDGE equ 1<<16
MULTIBOOT_HEADER_MAGIC equ 0x1BADB002
MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_AOUT_KLUDGE
MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
STACKSZ equ 0x4000
SECTION .text
_etry:
jmp short _startup
align 4
_multi_b:
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_CHECKSUM
dd _multi_b
dd _link_text
dd _link_data
dd _link_bss
dd _etry
_startup:
mov esp, _kernel_stack+STACKSZ
push eax
push ebx
;call _kernal
mov eax, cr0
xor eax, eax
mov cr0, eax
[BITS 16]
mov al,65
int 0x10
_halt:
hlt
SECTION .bss
resb STACKSZ
_kernel_stack:
as you can see grub loads my kernel
any help would be great pls
thx in advance
I did a search and googled but nothing help all returned same result
[btw the search function in this site need some repairing (no offense) cause the results were totally unrelated ]
Posted: Thu Feb 07, 2008 4:01 pm
by Masterkiller
Well I see you clear the whole cr0 register (only the PE needs to be cleared), but I don't believe that to be problem. After changing value of cr0, espesially PE bit, only next ONE instruction is loaded to processor and it is recommended (even it must be) far JMP instruction to preload CS register or the real mode will use the 16-bit value of visible part of CS, multiply by 16, add IP and hop, you are going too far from the next instruction
Posted: Thu Feb 07, 2008 6:05 pm
by Combuster
Clearing all of CR0 is bad practice. You will kill some bits now that will later cause you trouble. Maybe that's exactly why VMware crashes because you tried to clear the NE (and ET) bits, both of which should be set.
Also, you will need to be in a 16-bit code segment to allow PE to be disabled safely. I think that that is the real culprit at the moment, but please fix the other one too if you don't want to screw up your floating point unit.
Posted: Thu Feb 07, 2008 6:51 pm
by packet50071
Code: Select all
[BIT 32]
cli
mov eax,cr0
or al,0x1
mov cr0,eax
jmp 0x0009:_16bitc
[BITS 16]
_16bitc:
mov al,65
I hope i am not clearing the cr0 now
Also, you will need to be in a 16-bit code segment to allow PE
HUH! which other part should be in 16 bit
Forgive my ignorance
[edit] btw it still doesn't work. I know some thinging is missing but quite cannot get my head around it
Posted: Fri Feb 08, 2008 2:34 am
by AJ
Hi,
In your code snippet above, you are actually setting the PE bit. You need to AND CR0 with the inverse (NOT) of the bit you want to clear.
Cheers,
Adam
Posted: Fri Feb 08, 2008 7:45 am
by Dex
Here is a demo
http://www.dex4u.com/demos/DemoVesa.zip
that i wrote many moons ago, it goes to realmode from pmode to switch between vesa mode and text mode.
It should help you.
Note: I was called "ASHLEY4" when i wrote it.
Posted: Fri Feb 08, 2008 3:39 pm
by packet50071
that example was Seriously good
Well commented
I will ask if I still have problems
my linker doesn't like it
Posted: Fri Feb 08, 2008 4:45 pm
by packet50071
my linker doesn't like it now - I have no clue why
My code now ( i just copy paste ur code to mine For testing )
Code: Select all
[BITS 32]
;part of this code is base on http://www.osdever.net/bkerndev/ &
;http://www.dex4u.com/demos/DemoVesa.zip [ temporarily ]
global _etry, _multi_b, _halt, _kernel_stack,_do_16v,_RealModeCS,_do_rm
extern _linkd,_linkb, _linkt,kernel
MULTIBOOT_PAGE_ALIGN equ 1<<0
MULTIBOOT_AOUT_KLUDGE equ 1<<16
MULTIBOOT_HEADER_MAGIC equ 0x1BADB002
MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_AOUT_KLUDGE
MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
STACKSZ equ 0x4000
[SECTION .text]
_RealModeCS:
dw 0
_etry:
jmp short _startup
align 4
_multi_b:
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_CHECKSUM
dd _multi_b
dd _etry
dd _linkd
dd _linkb
dd _linkt
_startup:
mov esp, _kernel_stack+STACKSZ
push eax
push ebx
;call _kernel
pushad
jmp 20h:_do_16v
[BITS 16]
_do_16v:
mov ax,28h
mov ds,ax
mov ss,ax
nop
mov bx,[_RealModeCS] ; push real-mode CS:IP
push bx
lea bx,[_do_rm]
push bx ; clear PE [protected mode enable] bit and return to real mode
mov eax,cr0
and al,0xFE
mov cr0,eax
retf
_do_rm: ; jumps to do_rm
mov al,65
int 0x10
_halt:
hlt
[SECTION .bss]
resb STACKSZ
_kernel_stack:
but my linker doesn't like these lines
Code: Select all
mov bx,[_RealModeCS]
lea bx,[_do_rm]
error :
[LINK] kernel.bin
boot.o:boot.o:(.text+0x3d): relocation truncated to fit: 16 against `.text'
boot.o:boot.o:(.text+0x42): relocation truncated to fit: 16 against `.text'
make.exe: *** [kernel.bin] Error 1
My .ld file
Code: Select all
OUTPUT_FORMAT("coff-go32")
ENTRY(_etry)
SECTIONS
{
_linkt = 0x00100000;
.text 0x00100000 :
{
*(.text)
. = ALIGN(4096);
}
.data . :
{
*(.data)
. = ALIGN(4096);
}
_linkd = .;
.bss . :
{
*(.bss)
. = ALIGN(4096);
}
_linkb = .;
}
Thx in advance For ur hrlp
EDIT : Cannot I ask grub to just leave it in real mode ??
Posted: Fri Feb 08, 2008 6:10 pm
by Combuster
The first one needs some help (force an address size prefix)
I'm more concerned about do_pm being inside the kernel, and thus above 1MB. Hence, it won't ever fit into a 16-bit register (limited to 64k). Either you must relocate the code to below 1MB, or you have to push some bits to the segment part of CS (and use 0xFFFF:do_rm-0xffff0 as the cs:ip pair and hope that the address is low enough)
Posted: Fri Feb 08, 2008 6:30 pm
by packet50071
Combuster wrote:The first one needs some help (force an address size prefix)
I'm more concerned about do_pm being inside the kernel, and thus above 1MB. Hence, it won't ever fit into a 16-bit register (limited to 64k). Either you must relocate the code to below 1MB, or you have to push some bits to the segment part of CS (and use 0xFFFF:do_rm-0xffff0 as the cs:ip pair and hope that the address is low enough)
sry But i don't get a thing U said
I think you must have mistyped do_rm to do_pm
This is what i understood . "The do_rm's address is above 1mb so it needs to relocated ( I have no clue how to do that ) ." the second part I don't get it at all . but my guess would be that you want me to do a far jmp to that addr ?
I am soo clue less
Posted: Sat Feb 09, 2008 8:09 am
by Dex
I think you may find it hard to convert this code to grubs, as it does a lot of stuff in realmode before moving to pmode.
Eg: The code make addressing identical in real mode and protected mode, by setting the base of the code and data descriptors to DS * 16, this is computed at run-time.
We also save the contents of the CS register. To simplify the return to real mode, we also store the return-to-real-mode address, do_rm.
This also meens it need to be loaded below 1 MB as pointed out by Combuster.
Your best bet is to use bootprog to load your kernel
http://alexfru.chat.ru/epm.html#bootprog
As the demo does.
Posted: Sat Feb 09, 2008 3:05 pm
by packet50071
Screw real mode and GUI [sry for wasting your time
).
what manuals has this kind of information [i.e. switching modes, Implementing Paging , ETC)
thx in advance.
[btw Isn't there a way to change the vmode from PM mode!. ] Feel free to ignore this question