OSDev.org

Apparently, my old NANO board which drive a data collection system at home, freezes after the mode set code first reprograms the keyboard controller and then goes on to reinitialize the PIT timer (after which everything dies). This once worked (about half a year ago), but I'm unsure exactly why it does this. Could either be because it has hit a fatal error and wants to reboot, or possibly I've changed the IO hooking code so I could continue even when this happened?

What would be most likely?

Another problem with the setup is that I broke something when I introduced my new physical memory manager. I discovered this bug yesterday, but no revision in between actually works.

Even if I could trace the call 7 layers in V86-mode (C000:8B3F, C000:5307, C000:51BD, C000:3F72, C000:3F90, C000:2CD0 and C000:2C90), it is still hard to understand why the code ends up where it does. I suppose one possibility might be to rebuild the source at the point before I broke it, and do the same trace into the video BIOS to see where it differs.

Edit: Managed to setup an environment with the code from last year, and it turns out exactly the same code is executed, and that the video BIOS really does these things during normal mode-switches. Not nice at all, but possible to solve with the IO-permission bitmap and the emulations in place.

Please define "NANO board" and restate your question so that your post actually reflects upon your thread topic or question, whatever it is.

NANO board: http://www.attro.com/embedded/NANO-7240.htm

You can view the thread in the context of doing mode-switches in V86 mode, and what a video BIOS might do.

Yeah, it seems that the BIOS wants back some control. I had to reprogram a few hardware devices after each BIOS call. I think the best approach is pretty much shutting most drivers down and keeping userspace cryogenically frozen, doing the BIOS call, and then try to get the drivers going again and resume userspace.

Scary stuff

It's like Han Solo knowing Luke is walking into a trap, which he solves by invoking the "Get Luke out of the trap" force call, which while works, it teleports him to the palace of some alien slug on Tatooine and he has to deal with being thrown into the Great Pit of Carkoon because that's the way the force works.

Hi,

sortie wrote:Yeah, it seems that the BIOS wants back some control. I had to reprogram a few hardware devices after each BIOS call. I think the best approach is pretty much shutting most drivers down and keeping userspace cryogenically frozen, doing the BIOS call, and then try to get the drivers going again and resume userspace.

One of the things I like is the ExitBootServices UEFI function. It marks the specific point during boot where the OS takes control of the hardware. It makes it clear that the OS can't mess with hardware before calling ExitBootServices, and that the OS can't use the firmware for device drivers after calling ExitBootServices (which makes it nearly impossible to end up with a "2 people trying to ride the same bicycle" design flaw).


Cheers,

Brendan

sortie wrote:Yeah, it seems that the BIOS wants back some control. I had to reprogram a few hardware devices after each BIOS call. I think the best approach is pretty much shutting most drivers down and keeping userspace cryogenically frozen, doing the BIOS call, and then try to get the drivers going again and resume userspace.

About half-a-year ago, when this actually worked, I used the IO permission bitmap to disallow access to certain ports. The virtual timer module sets up traps for the keyboard port and the PIT ports, and emulates accesses to them much like Bochs does for an OS, so the BIOS has no idea that it doesn't operate in real mode with real IO ports. After all, I cannot allow BIOS to reprogram the keyboard controller or PIT timer, especially not when it changes mode of PIT timer.

Seems like some update broke this code, and now the video BIOS executes with an IO permission bitmap of all 0s, and can kill the OS.

Brendan wrote: One of the things I like is the ExitBootServices UEFI function. It marks the specific point during boot where the OS takes control of the hardware. It makes it clear that the OS can't mess with hardware before calling ExitBootServices, and that the OS can't use the firmware for device drivers after calling ExitBootServices (which makes it nearly impossible to end up with a "2 people trying to ride the same bicycle" design flaw).

V86 mode was invented back in the DOS days when it was customary for applications to use direct access to hardware, and thus there is a possibility for an OS (with IO permission bitmap) to emulate IO ports. Now that DOS programs are no longer are used, it's instead the BIOS' access to shared ports that must be restricted/emulated. It's not that hard for a V86 monitor to provide emulations for the hardware that might be used by both the BIOS and the OS, which typically only is keyboard ports and PIT + the real-mode interrupt callbacks (8 and 1Ch) for an VBE implementation using LFB.

The UEFI really doesn't solve this problem, rather says that if you try to do anything after calling ExitBootServices, we are not responsible for the results. Which basically is the same thing as calling the real mode BIOS, since it also is not guaranteed to work after you have reprogrammed the hardware. Personally, I would never call ExitBootServices at all, just in case the UEFI BIOS trashes something so later calls to it doesn't work, or provides a mechanism to deny these calls based on calling ExitBootServices. Then I would call everything from protected mode user-mode, and with an IO permission bitmap that disallowed common hardware usage, much like in the BIOS case. If the UEFI really insists, as a last resort, I could take a memory image of UEFI prior to calling ExitBootServices, make a copy of it, call ExitBootServices in the copy, discard the copy, and later use the pre-call memory image. An OS always has some ways to circumvent such broken behavior if it can execute the unsafe code in user mode.

Besides, it is a serious design flaw if an application cannot decide for itself which video resolution or text mode it wants to use. It really looks stupid in Linux when the console runs in an emulated video mode on an UEFI BIOS.

Hi,

rdos wrote:

Brendan wrote:One of the things I like is the ExitBootServices UEFI function. It marks the specific point during boot where the OS takes control of the hardware. It makes it clear that the OS can't mess with hardware before calling ExitBootServices, and that the OS can't use the firmware for device drivers after calling ExitBootServices (which makes it nearly impossible to end up with a "2 people trying to ride the same bicycle" design flaw).

V86 mode was invented back in the DOS days when it was customary for applications to use direct access to hardware, and thus there is a possibility for an OS (with IO permission bitmap) to emulate IO ports.

I'd go a step further. Intel knew that they couldn't break compatibility with all those DOS applications and had to provide a way for people (Microsoft's customers) to make a gradual transition from real mode to protected mode; and therefore made sure that a protected mode OS (in full control of all hardware) could run those DOS applications (via. virtual 8086 mode). I doubt they cared much about some half-baked mess than can't decide if it's an actual OS (in control of the hardware) or a "BIOS extension" thing that's too scared to take full control of hardware and be an actual OS.

rdos wrote:The UEFI really doesn't solve this problem, rather says that if you try to do anything after calling ExitBootServices, we are not responsible for the results.

Wrong. It solves the problem of cowards failing to take control of the hardware by forcing them to either take control of the hardware (exitBootServices called) or admit defeat and write a UEFI application instead (exitBootServices not called).

rdos wrote:Besides, it is a serious design flaw if an application cannot decide for itself which video resolution or text mode it wants to use. It really looks stupid in Linux when the console runs in an emulated video mode on an UEFI BIOS.

Failure to provide resolution independence is a design flaw (or in other words, if an application has a reason to care which video resolution the video driver happens to be using, then it's a design flaw).

Expecting a device to work and support everything it's capable of when there isn't a device driver is just plain silly. Without a device driver, the best you can hope for is "limp mode" - severely reduced functionality (e.g. without hardware pointers, without 2D acceleration, without 3D acceleration, without shaders, without GPGPU support, without support for multiple monitors, etc). There's no point bothering with support for video mode switches in "limp mode" as it shouldn't matter to begin with (resolution independence) and doesn't get you anywhere near the "full functionality" that the user has come to expect from devices with device drivers.

For emulating text modes (regardless of how or where or why), I agree - text modes should've been banned 20 years ago. Sadly, people still insist on copying *nix without realising that a few things have changed in the last 50 years.


Cheers,

Brendan

Brendan wrote:

rdos wrote:The UEFI really doesn't solve this problem, rather says that if you try to do anything after calling ExitBootServices, we are not responsible for the results.

Wrong. It solves the problem of cowards failing to take control of the hardware by forcing them to either take control of the hardware (exitBootServices called) or admit defeat and write a UEFI application instead (exitBootServices not called).

If exitBootServices had a parameter per hardware device type, it would be sane, but it isn't. The ideal solution would be to do exitBootServices for everything except for the video hardware. Since the designers of UEFI didn't do the design correctly, we have a standard that is useless for partial hardware support. I suppose this is mostly in the interest of Microsoft in order to hinder other OSes that might lack some driver support (like graphics hardware acceleration).

Brendan wrote: Failure to provide resolution independence is a design flaw (or in other words, if an application has a reason to care which video resolution the video driver happens to be using, then it's a design flaw).

We are not talking windowing-systems here, as RDOS makes no assumption about how an application wants to run, including which video mode (or text mode) it wants to use. If wanted, it is perfectly possible to do a generic Windowing environment, but it's not an requirement right now, and there are no plans to do this either.

Besides, there is no such thing as resolution independence when working with images (JPEG, PNG), as these always are bound to a particular resolution. Unless you want to scale them, which typically looks awful, or accept that half of the screen is unused.

Brendan wrote: Expecting a device to work and support everything it's capable of when there isn't a device driver is just plain silly. Without a device driver, the best you can hope for is "limp mode" - severely reduced functionality (e.g. without hardware pointers, without 2D acceleration, without 3D acceleration, without shaders, without GPGPU support, without support for multiple monitors, etc). There's no point bothering with support for video mode switches in "limp mode" as it shouldn't matter to begin with (resolution independence) and doesn't get you anywhere near the "full functionality" that the user has come to expect from devices with device drivers.

If a particular video device driver exist and has optimizations for acceleration, it should also support mode switch, and then the BIOS/UEFI would not need to be used in order to change resolution. However, in a typical configuration, there will be no accelerated graphics, and no specific device-driver, but instead a generic driver using LFB and BIOS to switch between modes. This will be the common case, and if it doesn't work with UEFI, it will break expected functionality.

Hi,

rdos wrote:

Brendan wrote:

rdos wrote:The UEFI really doesn't solve this problem, rather says that if you try to do anything after calling ExitBootServices, we are not responsible for the results.

Wrong. It solves the problem of cowards failing to take control of the hardware by forcing them to either take control of the hardware (exitBootServices called) or admit defeat and write a UEFI application instead (exitBootServices not called).

If exitBootServices had a parameter per hardware device type, it would be sane, but it isn't. The ideal solution would be to do exitBootServices for everything except for the video hardware. Since the designers of UEFI didn't do the design correctly, we have a standard that is useless for partial hardware support. I suppose this is mostly in the interest of Microsoft in order to hinder other OSes that might lack some driver support (like graphics hardware acceleration).

Wrong. An OS's job is to control the hardware and provide abstractions. UEFI is not designed for OS's that fail to do their job and therefore has no reason to allow partial hardware support.

rdos wrote:

Brendan wrote:Failure to provide resolution independence is a design flaw (or in other words, if an application has a reason to care which video resolution the video driver happens to be using, then it's a design flaw).

We are not talking windowing-systems here, as RDOS makes no assumption about how an application wants to run, including which video mode (or text mode) it wants to use. If wanted, it is perfectly possible to do a generic Windowing environment, but it's not an requirement right now, and there are no plans to do this either.

So, not only does RDOS fail to control the hardware it also fails to provide adequate abstractions? Nice.

rdos wrote:Besides, there is no such thing as resolution independence when working with images (JPEG, PNG), as these always are bound to a particular resolution. Unless you want to scale them, which typically looks awful, or accept that half of the screen is unused.

If you can't get acceptable results from scaling bitmap images you should stop pretending to be a programmer.

rdos wrote:

Brendan wrote:Expecting a device to work and support everything it's capable of when there isn't a device driver is just plain silly. Without a device driver, the best you can hope for is "limp mode" - severely reduced functionality (e.g. without hardware pointers, without 2D acceleration, without 3D acceleration, without shaders, without GPGPU support, without support for multiple monitors, etc). There's no point bothering with support for video mode switches in "limp mode" as it shouldn't matter to begin with (resolution independence) and doesn't get you anywhere near the "full functionality" that the user has come to expect from devices with device drivers.

If a particular video device driver exist and has optimizations for acceleration, it should also support mode switch, and then the BIOS/UEFI would not need to be used in order to change resolution.

Correct - this is how it's meant to be. Note: I realise that (especially for video) writing device drivers can be very difficult, but this does not change the fact that device drivers are expected.

rdos wrote:However, in a typical configuration, there will be no accelerated graphics, and no specific device-driver, but instead a generic driver using LFB and BIOS to switch between modes. This will be the common case, and if it doesn't work with UEFI, it will break expected functionality.

Wrong. It's not the common case, it's a design flaw due to the fact that it will never work on modern systems. It's as stupid as trying to drive you car through a lake and them attempting to blame the car's manufacturer when it doesn't work. The car was never designed to drive underwater and you would be foolish for attempting it; in the same way that (since real mode became obsolete) firmware is not intended to be used after an OS boots. The firmware is not to blame, you are foolish.


Cheers,

Brendan

Brendan wrote: Wrong. An OS's job is to control the hardware and provide abstractions. UEFI is not designed for OS's that fail to do their job and therefore has no reason to allow partial hardware support.

No, it was only designed for OSes where it is expected that every hardware device has a particular device driver. IOW, it was only designed for Windows, and only if you use an up-to-date version, forcing people to update regulary as they add new hardware.

Brendan wrote:

rdos wrote: We are not talking windowing-systems here, as RDOS makes no assumption about how an application wants to run, including which video mode (or text mode) it wants to use. If wanted, it is perfectly possible to do a generic Windowing environment, but it's not an requirement right now, and there are no plans to do this either.

So, not only does RDOS fail to control the hardware it also fails to provide adequate abstractions? Nice.

There is no rule that demands that an OS export a windowing API. I think the basics graphics API is a pure graphics API, which people can build GUIs on top on of if they wish. It was always a bad idea to mix those, quite unrelated features.

Brendan wrote:

rdos wrote:However, in a typical configuration, there will be no accelerated graphics, and no specific device-driver, but instead a generic driver using LFB and BIOS to switch between modes. This will be the common case, and if it doesn't work with UEFI, it will break expected functionality.

Wrong. It's not the common case, it's a design flaw due to the fact that it will never work on modern systems. It's as stupid as trying to drive you car through a lake and them attempting to blame the car's manufacturer when it doesn't work. The car was never designed to drive underwater and you would be foolish for attempting it; in the same way that (since real mode became obsolete) firmware is not intended to be used after an OS boots. The firmware is not to blame, you are foolish.

It is the typical case for less popular OS.

I also have no idea what you are talking about in regards to not working. It works perfectly well.

Taking this off a flame war for or against UEFI, I'm answering the op.

A good solution for the video bios modifying the pit is, emulate the pit. Disallow io access, and every so often (while needed) call the real mode irq 0 handler.

Hi,

rdos wrote:

Brendan wrote: Wrong. An OS's job is to control the hardware and provide abstractions. UEFI is not designed for OS's that fail to do their job and therefore has no reason to allow partial hardware support.

No, it was only designed for OSes where it is expected that every hardware device has a particular device driver. IOW, it was only designed for Windows, and only if you use an up-to-date version, forcing people to update regulary as they add new hardware.

It's been a long time since I found an OS that doesn't support a device (including Windows, Linux and FreeBSD). The main cause of breakage that I've seen is lack of stable interfaces (e.g. X updates that aren't compatible with ATI drivers).

rdos wrote:

Brendan wrote:

rdos wrote: We are not talking windowing-systems here, as RDOS makes no assumption about how an application wants to run, including which video mode (or text mode) it wants to use. If wanted, it is perfectly possible to do a generic Windowing environment, but it's not an requirement right now, and there are no plans to do this either.

So, not only does RDOS fail to control the hardware it also fails to provide adequate abstractions? Nice.

There is no rule that demands that an OS export a windowing API. I think the basics graphics API is a pure graphics API, which people can build GUIs on top on of if they wish. It was always a bad idea to mix those, quite unrelated features.

I'm not sure why you think anything I've said has anything to do with any windowing API. Typically the monitor says what its preferred resolution is (to avoid scaling) and the video mode should be set that exact same resolution. No other software (applications, GUI, whatever) should have any reason to care what that video mode might be - software just tells the video driver to draw lines, rectangles, textures, etc using a (virtual) coordinate system (and hopes that one day it will all be hardware accelerated).

rdos wrote:

Brendan wrote:

rdos wrote:However, in a typical configuration, there will be no accelerated graphics, and no specific device-driver, but instead a generic driver using LFB and BIOS to switch between modes. This will be the common case, and if it doesn't work with UEFI, it will break expected functionality.

Wrong. It's not the common case, it's a design flaw due to the fact that it will never work on modern systems. It's as stupid as trying to drive you car through a lake and them attempting to blame the car's manufacturer when it doesn't work. The car was never designed to drive underwater and you would be foolish for attempting it; in the same way that (since real mode became obsolete) firmware is not intended to be used after an OS boots. The firmware is not to blame, you are foolish.

It is the typical case for less popular OS.

Only for less popular OS's that are *designed* to be less popular forever. I'd be willing to bet that if someone wanted to write a native video driver for your OS (complete with all the acceleration, MPEG decoder, multi-monitor, GPGPU, etc) and asked for documentation for any/all APIs they need, you'd have no choice but to tell them those APIs don't exist and that it's a waste of time because your OS and applications can't support any of it anyway.

rdos wrote:I also have no idea what you are talking about in regards to not working. It works perfectly well.

It might work sort of in a temporary, limited/inadequate and not necessarily reliable way because you've spend far more time than it's worth emulating obsolete crud on modern systems and fixing the breakage each time new breakage is found. This is only possible because we're still in the transition from BIOS to UEFI and video cards are still supplied with legacy BIOS ROMs. It will break as soon as video card manufacturers switch to supplying drivers for UEFI instead.


Cheers,

Brendan

Brendan wrote:I'm not sure why you think anything I've said has anything to do with any windowing API. Typically the monitor says what its preferred resolution is (to avoid scaling) and the video mode should be set that exact same resolution. No other software (applications, GUI, whatever) should have any reason to care what that video mode might be - software just tells the video driver to draw lines, rectangles, textures, etc using a (virtual) coordinate system (and hopes that one day it will all be hardware accelerated).

That implies the OS can get the preferred resolution of the monitor, which might not be supported (my case), or might not be supported for the particular monitor. The OS can decide to always set the same resolution when it knows about the preferred resolution. The resolution and bit-organisation that the application asks for is only a guide.

But even disregarding that, text mode still requires switching between video modes when there are applications running in both text mode and graphics mode.

Brendan wrote:Only for less popular OS's that are *designed* to be less popular forever. I'd be willing to bet that if someone wanted to write a native video driver for your OS (complete with all the acceleration, MPEG decoder, multi-monitor, GPGPU, etc) and asked for documentation for any/all APIs they need, you'd have no choice but to tell them those APIs don't exist and that it's a waste of time because your OS and applications can't support any of it anyway.

Part of it, but not all. The graphics API was not built for games or visual design. It was built for simple embedded uses, and is modeled around PicoGUI.

Brendan wrote:It might work sort of in a temporary, limited/inadequate and not necessarily reliable way because you've spend far more time than it's worth emulating obsolete crud on modern systems and fixing the breakage each time new breakage is found. This is only possible because we're still in the transition from BIOS to UEFI and video cards are still supplied with legacy BIOS ROMs. It will break as soon as video card manufacturers switch to supplying drivers for UEFI instead.

There is a simple fix for it if the emulation stuff doesn't work. I'd have to do as Linux does, and emulate text mode in a graphics mode, which of course is easy to do and supported by the design. Then the video set mode code will be a "nop", since only a single resolution is supported.

The broken code is fixed, and now the Nano7240 board once more runs under RDOS