OSDev.org

Hi,

I was just reading the other post when I came across this Wiki article. Let me go through it.

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,

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

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?

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

Hi,
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

Hi,



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

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.

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!

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.

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).

Hi,



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

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.

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.

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

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.

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)