Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
This is the switch code about it.Before this code,i has done a lot of work in in the real mode.When bochs got the jmp,some error happend: Error: (0) print_guard_results: guard_found ? (stop reason 0)
However,if i delete the job which in the real mode ,it ok.
I am sorry "Love4Boobies ",what's wrong about 0x7e00,this is the adress where I load the pmode code,and rmode is in the other place.
it's not the boot file.
Ah, ok. So what is it that you do in real mode? Maybe you do something there that screwes up the rest (like writing over the EBDA or something).
EDIT: and are you sure this: jmp code_desc:protected_code is right?
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Love4Boobies wrote:Ah, ok. So what is it that you do in real mode? Maybe you do something there that screwes up the rest (like writing over the EBDA or something).
EDIT: and are you sure this: jmp code_desc:protected_code is right?
The "code_desc" has define in the second code about GDT.
Probably you are right,something may be writted,but I don't know how to check and amend.
I use bochs to debug,and I got the some info about registers just as follow. before jmp:
Love4Boobies wrote:Ah, ok. So what is it that you do in real mode? Maybe you do something there that screwes up the rest (like writing over the EBDA or something).
EDIT: and are you sure this: jmp code_desc:protected_code is right?
The "code_desc" has define in the second code about GDT.
Yes. code_desc is a constant whose value is 8. Are you sure that's what you want? Are you sure you don't mean jmp protected_code instead? The code in you file is in the same segment so there's no need for a far jump.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
um, the far jump is needed to change from 16 bit code to 32 bit code
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Combuster wrote:um, the far jump is needed to change from 16 bit code to 32 bit code
Ooops. Right, he was jumping to pmode. Still, be careful with the segment.
If I code just as "jmp protected_code", it can jmp to the 32bit.However,when I init registers,the same error has happened. "mov es,ax" can't be executd.
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
Query text wanted. Plugging the error message yields no usable results.
EDIT: Have you fixed the ORG problem? could you post an updated register dump on the state before the far jump? From what I gathered the error message looks like a reset (in your case, triple fault).
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
The problem is that CS isn't zero. The code goes from running at 0x7E00:something to 0:same something. The new GDT has a base of 0 and the old CS has a base of 0x7E00. I don't know how the NASM org instruction works exactly so I can't help you any further.
EDIT: Is the code running at 0x7E00 or 0x7E000? CS suggests the second and the ORG instruction the other.
Query text wanted. Plugging the error message yields no usable results.
I'm putting my invisible tokens on the line by saying that I bet it's a problem with the GDT.
cs 0xf000 61440
Something here looks incorrectly set up. Probably either the GDT or the jump. Probably also causing a triple fault.
OP: try, instead of using your code_desc and data_desc things, use 0x08 and 0x10 respectively.
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.