OSDev.org

That's right, they are not in UEFI.

The point is, contrary to many opinions here, is that you should write your own boot loader, doing everything you need to do while still having access to the firmware, whether that be the Legacy BIOS, the UEFI, or whatever firmware there is, including setting the screen mode, then move to protected/long mode and forget about the firmware. At that point, if you ever need to do something that a call to the firmware could handle (which should be rare), you will need to do it via direct hardware programming.

As for the 2020 deadline, or whatever this may be, in my humble opinion, don't worry about it. The Legacy BIOS is going to be around for a long time. Look how long support for a v86 mode was supported. How about real-mode? Look how long the A20 line was supported. How about PS/2 ports (keyboard/mouse) or at least legacy support for them. The legacy BIOS will be around for a long time to come, if not simply emulated by the modern firmware.

Anyway, my suggestion is, and again, against many opinions, skip Grub and write your own boot loader. There are many reasons for this. First and foremost, you learn how to do it. Second, you get to have full control of the machine, doing what you need to do before the kernel takes over. There are many other reasons as well.

Just my opinion,
Ben

ok then. i'll write my own bootloader. i think some links will help but i think i know how to do it

EDIT:i'm wrong.totally wrong

A simple video driver for QEMU, bochs and virtualbox is the BGA, which is relatively simple to program.

Hi,

BenLunt wrote:As for the 2020 deadline, or whatever this may be, in my humble opinion, don't worry about it. The Legacy BIOS is going to be around for a long time.

I'd take this very seriously. About 6 to 12 months ago, Intel announced official plans to phase out BIOS by 2020 and that's not something Intel are likely to do if they aren't sure. This was always inevitable (the "hybrid UEFI and BIOS for backward compatibility" transition period that began in 2005 had to end at some point, and 15 years is longer than average) and I've been predicting this since at least 2013.

Of course BIOS will still exist in emulators like VirtualBox, and it'll take a while before people upgrade existing/old computers, but at this point in time it's (still) obvious that failing to at least make it possible to support UEFI in future is a guaranteed death sentence.

BenLunt wrote:Look how long support for a v86 mode was supported. How about real-mode? Look how long the A20 line was supported. How about PS/2 ports (keyboard/mouse) or at least legacy support for them. The legacy BIOS will be around for a long time to come, if not simply emulated by the modern firmware.

Yes, all of this awful old junk had to stay because BIOS requires it; and making it possible to get rid of all the legacy hardware is the reason Intel wants to get rid of BIOS. I'm thinking it'll probably take less than 6 months between "old chipset without BIOS" and "new chipset without BIOS, A20, PS/2, PIC chips, PIT, legacy ROM areas, legacy VGA area, ..."); and by 2021 we'll finally end up with lean and mean PCs without the unnecessary baggage that no major operating system (Windows, OSX, Linux) has required for at least a decade.


Cheers,

Brendan

thomtl, thanks, but the idea for the OS is also run in real hardware.brendan, benlunt and many other people have said to me for writing my own bootloader, 'cause with it i'll can call interrupts.but if the problem is the protected mode of grub, isn't the solution leave from protected mode??

Hi,

alberinfo wrote:if i set the video mode during the boot, i wont be able to switch again.if i quit VM8086 due the intel no support for bios in 2020, then i'll can't do many other things that(for me)is necesary the bios, almost a just bios interrupt.if i quit vm8086 i'll need another way to do what i do with the bios.

Why? There is (almost) no sane reason to want to use VBE after boot.

alberinfo wrote:how i can do that??.as far as i know these interrupts arent in uefi

The simplest way is to set the best video mode during boot and then emulate worse video modes that nobody wants to use by writing a little software that reads pixel data from a fake/emulated frame buffer in RAM, scales the pixel data up and/or convert pixel formats, and then writes the resulting pixel data to the real frame buffer. This same emulation trick (with a few additions - font data lookup) can even be used to make the fake/emulated video mode so crippled and ugly that it's effectively identical to ancient monochrome text modes from before VGA existed (still without actually changing the real video mode).


Cheers,

Brendan

well, i think thats very complicated. leave from protected mode lets me use interrupts, for things that i consider that can't be done in C. also my plans are not only vbe, also vga

Brendan wrote: Yes, all of this awful old junk had to stay because BIOS requires it; and making it possible to get rid of all the legacy hardware is the reason Intel wants to get rid of BIOS. I'm thinking it'll probably take less than 6 months between "old chipset without BIOS" and "new chipset without BIOS, A20, PS/2, PIC chips, PIT, legacy ROM areas, legacy VGA area, ..."); and by 2021 we'll finally end up with lean and mean PCs without the unnecessary baggage that no major operating system (Windows, OSX, Linux) has required for at least a decade.

More than likely, they will simply eliminate real mode entirely at the 2020 mark, making the A20 line and the BIOS routines moot and making UEFI booting the only option.

Several of the other things you've mentioned are ones which that were imposed on Intel by IBM's designs for the PC, PC/AT, and PS/2 product lines, and are, for the most part, only emulated even now, IIUC. For example, the Local APIC, inside of x86 CPUs as far back as the Pentium 'refresh' of 1994, bears little if any actual resemblance to the 8253 PIT even though the former was made by Intel originally - and IIUC, the legacy behavior is in the CPU's internal firmware, not hardware.

I wouldn't be surprised if they eliminated booting into 32-bit p-mode, for that matter, and made 32-bit code a legacy support feature to be phased out over a few years, as well. Even supporting just two different operating modes is getting burdensome, and they have already stopped making CPUs without 64-bit modes for mainstream use, so this would simplify a lot.

This would be a lot less painful than the shift away from real mode has been, simply because (unlike with real mode software) most of the programs were written in high-level languages, and with less direct operations on the hardware, and most of the source code is still around and can be re-compiled with some tweaks. For that matter, the ubiquity of code compiled to .NET and JVM, or written for interpreted languages such as Python or Ruby, means most won't even need recompiling.

I'd finish by adding that recent developments - in particular, the problems Intel is having with implementing their CPUs on a 10nm process - raise the hope that we will finally be able to put that horrible x86 garbage out of our misery for good soon. I'm not sure, as we've thought that revenant was down for the count before, but maybe.

alberinfo wrote:leave from protected mode lets me use interrupts, for things that i consider that can't be done in C.

Which things?

int 33h?for example

EDIT:with int 33h i mean by set a cursor specifically a graphic cursor

Hi,

alberinfo wrote:int 33h?for example

I think "Int 0x33" is only used for mouse drivers written for MS-DOS; and for your code (using BIOS without MS-DOS) it doesn't exist.


Cheers,

Brendan

you're right. in http://www.ctyme.com/intr/int-33.htm many of it subfunctions are for ms-dos. i was going to say ahci, but ahci can be done in C.

What I think to be the best way is to have a sort of chain of things to try, so you would try native drivers so for example: if you detect QEMU bochs or virtualbox use the BGA driver. if you are running on real hardware and on BIOS try V86 VBE and if there are no options left fall back to writing VGA register dumps.

thats a good idea... but how to detect qemu, bochs or anything else?

VirtualBox can be detected with a device on the PCI bus (Vendor ID 0x80EE and Device ID 0xCAFE), I don't know how to detect Bochs Or QEMU however. I do remember something about the qemu cpu name being recognizable but i'm not sure.