Page 1 of 2
Wiki: Real Mode article broken
Posted: Fri Apr 08, 2011 4:24 am
by Chandra
Hi,
I was just reading the other
post when I came across this
Wiki article. Let me go through it.
The program needs to go through the following steps:
Disable the interrupts:
Turn off maskable interrupts using CLI.
Disable NMI (optional).
Turn off paging:
Transfer control to a 1:1 page.
Ensure that the GDT and IDT are in a 1:1 page.
Clear the PG-flag in the zeroth control register.
Set the third control register to 0.
Use GDT with 16-bit tables (skip this step if one is already available):
Create a new GDT with a 16-bit data and code segment:
Limit: 0xFFFFF
Base: 0x0
16-bit
Privilege level: 0
Granularity: 0
Read and Write: 1
Load new GDT ensuring that the currently used selectors will remain the same (index in cs/ds/ss will be copy of original segment in new GDT)
Far jump to 16-bit protected mode:
Far jump to 16-bit protected mode with a 16-bit segment index.
Load data segment selectors with 16-bit indexes:
Load ds, es, fs, gs, ss with a 16-bit data segment.
Load real mode IDT:
Limit: 0x3FF
Base 0x0
Use lidt
Disable protected mode:
Set PE bit in CR0 to false.
Far jump to real mode:
Far jump to real mode with real mode segment selector (usually 0).
Reload data segment registers with real mode values:
Load ds, es, fs, gs, ss with appropriate real mode values (usually 0).
Set stack pointer to appropriate value:
Set sp to stack value that will not interfere with real mode program.
Enable interrupts:
Enable maskable interrupts with STI.
Continue on in real mode with all bios interrupts.
First of all, it is missing the most important step. And that is, to restore the hardware to the default configuration. More importantly, this includes remapping the IRQ to their default vectors (real mode).
Next,
Code: Select all
[bits 16]
idt_real:
dw 0x3ff ; 256 entries, 4b each = 1K
dd 0 ; Real Mode IVT @ 0x0000
savcr0:
dd 0 ; Storage location for pmode CR0.
Entry16:
; We are already in 16-bit mode here!
cli ; Disable interrupts.
; Need 16-bit Protected Mode GDT entries!
mov eax, DATASEL16 ; 16-bit Protected Mode data selector.
mov ds, eax
mov es, eax
mov fs, eax
mov gs, eax
; Disable paging (we need everything to be 1:1 mapped).
mov eax, cr0
mov [savcr0], eax ; save pmode CR0
and eax, 0x7FFFFFFe ; Disable paging bit & enable 16-bit pmode.
mov cr0, eax
jump 0:GoRMode ; Perform Far jump to set CS.
GoRMode:
mov sp, 0x8000 ; pick a stack pointer.
mov ax, 0 ; Reset segment registers to 0.
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
lidt [idt_real]
sti ; Restore interrupts -- be careful, unhandled int's will kill it.
This example code is broken given that it doesn't consider restoring the IRQs to their default vectors. Since the IRQs are remapped as soon as we enter protected mode, they must be restored to their default Real Mode vectors. One consequence of not doing so is, some BIOS calls(Int 0x16 ...) fail. Just reloading the real mode IVT will still make other BIOS calls available, though.
Finally,
switching from protected mode to real mode isn't that straight-forward. Most of us like to play with keyboard when we first start our OS. This shouldn't cause much problem when making
Protected Mode -> Real Mode transition. But when we gradually go on adding hardware support(which means drivers) to our OS, our hardware devices seem to behave strange when making this transition. I've succesfully resolved some of those issues by reverting the hardware to the original configuration, but still some of the drivers are causing nightmare.
I hope to see that article updated(can't do myself).
Feel free to fire compliments.
Best Regards,
Chandra
Re: Wiki: Real Mode article broken
Posted: Fri Apr 08, 2011 5:22 am
by Chandra
Did that myself.
I really didn't bother to make changes to the example code, though. I'm not sure if I'm the only one opposing this, but I'm sure it has got errors. Should I replace that example code or should I simply let it be-as it is?
Re: Wiki: Real Mode article broken
Posted: Fri Apr 08, 2011 7:39 am
by Brendan
Hi,
"Returning to real mode" isn't the same as "Restoring the BIOS state". The latter includes the former, but the former doesn't include the latter.
For an example, consider an OS that was booted from 32-bit EFI in protected mode. That OS could switch to real mode, but attempting to restore the BIOS state doesn't make any sense in this case.
Cheers,
Brendan
Re: Wiki: Real Mode article broken
Posted: Fri Apr 08, 2011 6:15 pm
by Chandra
Hi,
Brendan wrote:"Returning to real mode" isn't the same as "Restoring the BIOS state"
I was in no way talking about "Restoring the BIOS state". I was talking about "restoring the hardware configuration" (which includes bringing the A/PIC chip back to its default state). The first victim of not doing so, is the Floppy drive. If you've made data transfers (DMA or PIO) and if you make a transition to Real Mode, all of the Int 0x13 call fails.
The workaround is to issue a Reset signal to the floppy before making the transition.
Next is the mouse. When you enter real mode from protected mode and then return back to protected mode, mouse stops sending packets. Sending
Reset signal doesn't correct this problem.
The next issue is with BIOS calls Int 0x16 and Int 0x13. The former fails because the IRQs are not restored to their default Real Mode vectors, while the latter fails because the Floppy Drive state has been changed(assuming the default mode for data transfer has been changed by the OS driver).
The last one which I haven't been able to resolve yet, is the CD-ROM data transfer. As soon as I make transition to real mode, all the Int13h extension service fails.
All these bugs I've stated here, come from my own experience. I do have supporting code for each bug I've mentioned, if anyone is interested..........
Best regards,
Chandra
Re: Wiki: Real Mode article broken
Posted: Fri Apr 08, 2011 8:32 pm
by Brendan
Hi,
Chandra wrote:Brendan wrote:"Returning to real mode" isn't the same as "Restoring the BIOS state"
I was in no way talking about "Restoring the BIOS state". I was talking about "restoring the hardware configuration" (which includes bringing the A/PIC chip back to its default state).
Oh, um. In that case...
"Returning to real mode" isn't the same as "Restoring the hardware configuration". The latter includes the former, but the former doesn't include the latter.
Maybe you could create a new page in the wiki called "Restoring the hardware configuration (for BIOS)", which includes all of the things you've mentioned, and also says "
if you need to switch back to real mode, see the Wiki page about real mode". If you want to do that, then you could also create a "Restoring the hardware configuration (for EFI)", which includes similar things and also says "
if you need to switch back to protected mode or long mode, see the relevant pages about protected mode or long mode".
Of course you wouldn't want to add information on restoring the hardware configuration for EFI in the wiki pages about protected mode and long mode. In the same way, you wouldn't want to add information on restoring the hardware configuration for BIOS in the wiki pages about real mode.
Cheers,
Brendan
Re: Wiki: Real Mode article broken
Posted: Sat Apr 09, 2011 2:03 am
by Chandra
Brendan wrote:Oh, um. In that case...
"Returning to real mode" isn't the same as "Restoring the hardware configuration". The latter includes the former, but the former doesn't include the latter.
I'm not saying that "Returning to real mode" is same as "Restoring the hardware configuration".
I'm just saying that the aim for "Returning to real mode" can't be fully achieved without "Restoring the hardware configuration". I'm not sure how you saw that irrelevant.
Okay, let me get this straight. Why would an OS Developer want to return to Real Mode?
To make BIOS calls, right? Now, without "restoring the hardware configuration" to the default state, too many BIOS call fails(
see explanation in the above post). This means, the goal can't be achieved. Story doesn't simply end here. This has consequences when returning back to protected mode too. Suppose, you called Int 0x10(vesa extension) to switch resolutions then returned back to protected mode. You'd be surprised to see your mouse will stop sending packets. I've been able to track out these few issues(as mentioned above) but I'm sure there are lots of them. I know we've lots of Operating Systems over here, that make this transition, but I'm not sure how many of us have succesfully made this transition without disturbing the hardware states.
Brendan wrote:Of course you wouldn't want to add information on restoring the hardware configuration for EFI in the wiki pages about protected mode and long mode. In the same way, you wouldn't want to add information on restoring the hardware configuration for BIOS in the wiki pages about real mode.
I wouldn't want to add pages regarding "Restoring the hardware configuration (for BIOS)" either. There are lots of uncatched issues. I only mentioned some of them and that too, which appeared in my route. Unless I'm confident enough that I'm not the only guy encountering this, I don't posses right to create that page.
I also noticed that the change I made to the
Real Mode article has been reverted, probably for a good reason. But I'm sure these issues exist. And I won't bother about it again. Since I'm following it my way(and actually progressing), it is not much of concern to me. I want to end this discussion here . Sorry for wasting your time.
Ah! I realized that I shouldn't have called that page
broken either. It was actually missing a little info(
though vital), so sorry for nonsense wording. (
no negative feelings)
Cheers and have a good day!
Re: Wiki: Real Mode article broken
Posted: Sat Apr 09, 2011 2:17 am
by Combuster
Chandra wrote:Brendan wrote:Oh, um. In that case...
"Returning to real mode" isn't the same as "Restoring the hardware configuration". The latter includes the former, but the former doesn't include the latter.
I'm not saying that "Returning to real mode" is same as "Restoring the hardware configuration".
I'm just saying that the aim for "Returning to real mode" can't be fully achieved without "Restoring the hardware configuration". I'm not sure how you saw that irrelevant.
Because in most practical cases where you want to return to real mode, there is no configuration to be restored. Either you entered protected mode yourself or via grub, and both cases of their own do not change the hardware state sufficiently. By the time you do need to restore that configuration, you essentially need to shut down all other drivers, and with that, your OS essentials. At which point it is just easier to just reboot - which also happens to be the most guaranteed way to fully restore the configuration
.
Even in the case of dropping to real mode for changing video modes (which suffers from the problems mentioned above - use v8086 if you really care), you shouldn't need to change the state of other bios devices.
Re: Wiki: Real Mode article broken
Posted: Sat Apr 09, 2011 2:25 am
by Chandra
Combuster wrote:Because in most practical cases where you want to return to real mode, there is no configuration to be restored. Either you entered protected mode yourself or via grub, and both cases of their own do not change the hardware state sufficiently. By the time you do need to restore that configuration, you essentially need to shut down all other drivers, and with that, your OS essentials. At which point it is just easier to just reboot - which also happens to be the most guaranteed way to fully restore the configuration
I wish things were as simpler as you stated. Unfortunately, it turns out to be more complex when actually implemented. So I was just avoiding this discussion (
being the only one with these particular issues).
Re: Wiki: Real Mode article broken
Posted: Sat Apr 09, 2011 9:37 am
by Brendan
Hi,
Chandra wrote:I'm not saying that "Returning to real mode" is same as "Restoring the hardware configuration".
I'm just saying that the aim for "Returning to real mode" can't be fully achieved without "Restoring the hardware configuration". I'm not sure how you saw that irrelevant.
Let me try to explain it in a different way. Would you write a kernel as a single huge function? Most people would break a kernel up into multiple functions/methods/procedures/routines, because it's easier to reuse smaller pieces of code and a lot easier to implement and maintain. For example, you might have a "kputc()" routine that's only ever called by a "kprintf()" routine, but you'd still make them separate.
Would you have a single wiki page that tries to explain everything about OS development? Of course not - you'd break it up into multiple pages for different topics. For example, you might have a "TCP" page that refers to a separate "IP" page because these are different (but related) topics, even though TCP is always used on top of IP.
Basically, even if switching to real mode was always needed as part of restoring the BIOS's hardware configuration; and even if the only reason anyone ever switches to real mode is to use BIOS functions; you'd still want to have separate wiki pages for both of these things to avoid having too much on one page. However...
Someone writing a real mode OS could write their own drivers and (for e.g.) disable PICs and use IO APICs, start multiple CPUs, disable the PIT and use HPET, etc. In this case, to use the BIOS functions again they'd need to restore the BIOS's hardware configuration, but they wouldn't need to return to real mode because they never left it. The opposite is also possible - someone could have a reason to switch to real mode and *not* use the BIOS functions or restore the BIOS's hardware configuration. Maybe they're writing a Z80 emulator that boots from EFI or something - I don't know. The point is that it's possible.
What I'm saying is that they are 2 completely separate (but related) topics, in the same way that "TCP" is not "IP", putting on socks isn't the same as putting on shoes, and boiling water isn't the same as making coffee; and that there should be separate wiki pages for these separate topics.
Cheers,
Brendan
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 1:48 am
by Chandra
Brendan wrote:Basically, even if switching to real mode was always needed as part of restoring the BIOS's hardware configuration;...
That is exactly where we are differing every time.
Brendan says,
"Switching to real mode is needed as a part of restoring the BIOS's hardware configuration".
Chandra says,
"Restoring the BIOS's hardware configuration is needed as a part of switching to real mode".
Although both of these statements are actually true, the theme they carry is inverted. Hence, this is causing the problem to
highlight the actual issue.
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 5:18 am
by fronty
Chandra wrote:Brendan says, "Switching to real mode is needed as a part of restoring the BIOS's hardware configuration".
Chandra says, "Restoring the BIOS's hardware configuration is needed as a part of switching to real mode".
Although both of these statements are actually true, the theme they carry is inverted. Hence, this is causing the problem to highlight the actual issue.
In fact, they aren't actually true. As Brendan noted earlier in this thread, restoring BIOS's hardware configuration doesn't make sense in a situation where BIOS doesn't exist. Processor modes are just about the processor's state, state of other hardware and software may be related but not a part of the concept.
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 7:14 am
by Chandra
What?
What do you mean by 'BIOS doesn't exist'? If BIOS doesn't exist, how do you make BIOS calls in Real Mode? Take your time to read this thread and when you have valid argument, I'll be prepared to deal with that.
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 7:24 am
by Tyler
Chandra wrote:What?
What do you mean by 'BIOS doesn't exist'? If BIOS doesn't exist, how do you make BIOS calls in Real Mode? Take your time to read this thread and when you have valid argument, I'll be prepared to deal with that.
http://en.wikipedia.org/wiki/Extensible ... _Interface
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 7:46 am
by fronty
Chandra wrote:What?
What do you mean by 'BIOS doesn't exist'? If BIOS doesn't exist, how do you make BIOS calls in Real Mode? Take your time to read this thread and when you have valid argument, I'll be prepared to deal with that.
If e.g. EFI is used, there's no BIOS and no BIOS to call in real mode. But even in that case you can drop to real mode.
Re: Wiki: Real Mode article broken
Posted: Sun Apr 10, 2011 7:56 am
by Chandra
Tyler wrote:Chandra wrote:What?
What do you mean by 'BIOS doesn't exist'? If BIOS doesn't exist, how do you make BIOS calls in Real Mode? Take your time to read this thread and when you have valid argument, I'll be prepared to deal with that.
http://en.wikipedia.org/wiki/Extensible ... _Interface
I know that. I'm again saying take your time to read this thread.
(Brendan did made some consideration about the EFI but that is another part of story)