OSDev.org

Posted: **Tue Sep 22, 2020 3:06 pm**

What graphics parameters you set for qemu for getting such a set of resolutions?

Posted: **Tue Sep 22, 2020 6:10 pm**

zaval wrote:What graphics parameters you set for qemu for getting such a set of resolutions?

I'm not setting anything special. I am using QEMU for Windows "out of the box" and using the EDK2 firmware "out of the box". Here is the batch file I use to invoke it:

Code: Select all

qemu-system-x86_64.exe -m 256 ^
-drive file=fysos64.img,format=raw,if=ide,media=disk,index=0 ^
-drive if=pflash,format=raw,unit=0,readonly,file=OVMF-pure-efi.fd ^
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS-pure-efi.fd ^
-parallel file:paraefi.txt -serial file:serial.txt ^
-vga std -net none -monitor stdio -machine q35

The firmware is from: https://www.kraxel.org/repos/jenkins/edk2/
Direct link: https://www.kraxel.org/repos/jenkins/ed ... noarch.rpm
Extracting out the two used files.

That's it.
- Ben

Posted: **Tue Sep 22, 2020 7:17 pm**

mine is from the same source. I think, I confused it with ARM variants (only two ancient modes - 800x600 and yet one even smaller) - these are ones, I mess around with most. I'll try that with x64, but I doubt it would be any different from your experience. I thought you need a real hardware check. after all, it's safe to assume all "live" UEFI firmwares are based on tianocore.

Posted: **Wed Sep 23, 2020 9:29 am**

@BenLunt: I don't have such a huge screen...

Here are some screenshots:

: uefi1.png (9.37 KiB) Viewed 21661 times

This is shown for a long time (several seconds, 2-3 secs at least, but sometimes 5, long time for booting). It is 640 x 480.

: uefi2.png (9.44 KiB) Viewed 21661 times

Then this screen is shown for a while (again, for several seconds, which is very long for booting). It's 1024 x 768 if I'm not mistaken. With the image @BenLunt suggested, there's no text on the screen, just the logo in the centre.

Then that TianoCore logo disappears, and only then the real boot starts. I've already lost many precious seconds (sometimes ~10) before FS0:\EFI\BOOT\BOOTX64.EFI even gets loaded. The loader itself runs pretty fast, btw, less than a sec from the "Booting OS..." message to the BOOTBOOT screen.

I've tried with many different OVMF.fd images, as well as with "pflash" and "-sdl" options, all the same.
On the other hand, with the default qemu BIOS, and also with coreboot.rom, the boot is instant, happens within a blink of an eye. Definitely less than one sec from pressing Enter on the command line to the BOOTBOOT screen.

As I've said, I have an old slow machine, it could be that it just can't emulate that bloated UEFI monstrocity any faster... It definitely backs up Wirth's law

Cheers,
bzt

Posted: **Wed Sep 23, 2020 9:34 am**

bzt wrote:As I've said, I have an old slow machine, it could be that it just can't emulate that bloated UEFI monstrocity any faster...

That's still rather strange. I don't have that problem. May I ask what your CPU speed is? Mine is 2.2GHz I think.

Greetings
Peter

Posted: **Wed Sep 23, 2020 9:39 am**

PeterX wrote:
bzt wrote:As I've said, I have an old slow machine, it could be that it just can't emulate that bloated UEFI monstrocity any faster...
That's still rather strange. I don't have that problem. May I ask what your CPU speed is? Mine is 2.2GHz I think.

Greetings
Peter

I've already wrote that, 1GHz, running at about 3000 bogomips, no VT-x extensions.

Cheers,
bzt

Posted: **Wed Sep 23, 2020 9:48 am**

bzt wrote:
PeterX wrote:
bzt wrote:As I've said, I have an old slow machine, it could be that it just can't emulate that bloated UEFI monstrocity any faster...
That's still rather strange. I don't have that problem. May I ask what your CPU speed is? Mine is 2.2GHz I think.

Greetings
Peter
I've already wrote that, 1GHz, running at about 3000 bogomips, no VT-x extensions.

Cheers,
bzt

OK! I wonder why it is so slow on your PC. I think it should be roughly half as fast as on my computer. But it isn't. *puzzled*

Greetings
Peter

Posted: **Wed Sep 23, 2020 10:01 am**

PeterX wrote:OK! I wonder why it is so slow on your PC.

Well, unlike UEFI, emulating BIOS and coreboot is fast, so the only explanation left is: "What Andy giveth, Bill taketh away"

Cheers,
bzt

Posted: **Wed Sep 23, 2020 10:13 am**

It takes 4 seconds on my machine. My machine has 7 CPUs at 1.65 GHz and VTx and 8GB of RAM. With KVM, it takes 4 seconds. So slower then BIOS, but not to slow. I really don't give myself a choice in the matter as I plan on dropping the BIOS version of my bootloader soon

Posted: **Wed Sep 23, 2020 11:29 am**

nexos wrote:It takes 4 seconds on my machine. My machine has 7 CPUs at 1.65 GHz and VTx and 8GB of RAM. With KVM, it takes 4 seconds.

So I think it is because of the missing VT/KVM on bzt's PC.

Greetings
Peter

Posted: **Wed Sep 23, 2020 2:22 pm**

My computer is old too, qemu isn't using any virtualization stuff and it boots into UEFI shell in a couple of seconds.

Then that TianoCore logo disappears, and only then the real boot starts. I've already lost many precious seconds (sometimes ~10) before FS0:\EFI\BOOT\BOOTX64.EFI even gets loaded.

bzt, try to create a Load Option for your loader and put it the first. Interestingly, OVMF images come preconfigured to have a Load Option for the UEFI shell, and since, as I've already pointed out, \efi\boot\bootXXXX.efi is optional for non-removable storages, it might well be not tried at all esp. given a Load Option is set. That delay, you describe might be some stupid waiting because you didn't provide Load Options, because for me, after Tianocore logo disappears, the UEFI shell does appear instantly or my Loader, - what is set first.

UEFI isn't monstrosity per se, EDK2 may be, but the standard itself is not. PI really has a lot of overdesigned stuff, but UEFI is slim. and extensible. You don't have to implement all the protocols, and oppositely - you can devise your own. The core is minimalistic and clear.

Posted: **Wed Sep 23, 2020 5:32 pm**

zaval wrote:bzt, try to create a Load Option for your loader and put it the first. Interestingly, OVMF images come preconfigured to have a Load Option for the UEFI shell, and since, as I've already pointed out, \efi\boot\bootXXXX.efi is optional for non-removable storages, it might well be not tried at all esp. given a Load Option is set.

Thanks for the tip, but \efi\boot\bootXXXX.efi is configured by default all right.

zaval wrote:That delay, you describe might be some stupid waiting because you didn't provide Load Options, because for me, after Tianocore logo disappears, the UEFI shell does appear instantly or my Loader, - what is set first.

As I've said, I have no problem after the TianoCore logo disappears. My loader is pretty fast. The long delay happens before that (most of it before the TianoCore logo shown).

zaval wrote:UEFI isn't monstrosity per se, EDK2 may be, but the standard itself is not.

Oh yes, it is. One of the worst "standards" ever. From the overall concept to the simple things. For example what "Number of partitions" mean in GPT? It is not well-defined: some interpret it as the number of active partitions, while for others it is the number of maximum usable partitions... Sadly the UEFI spec suggests both.

Then the big picture: most of the protocols are totally, completely useless after ExitBootServices. Now what kind of firmware is that, which does not provide services to the OS? UEFI should be called "Big Bloated Boot Environment" (TM), because it is definitely not usable as a "Firmware Interface" for the OS.

zaval wrote:PI really has a lot of overdesigned stuff, but UEFI is slim. and extensible.

No, it isn't. OVMF.fd is at least a Megabyte (!!!) and in run-time requires several Megabytes of RAM, I wouldn't call that "slim". BIOS, on the other hand, with it's 128K size and minimal (ca. 64k) run-time RAM requirement, now that's what slim is!

zaval wrote:You don't have to implement all the protocols, and oppositely - you can devise your own. The core is minimalistic and clear.

The core alone is completely useless. There's nothing minimalistic and clear about the must-have bytecode interpreter for example. There's no standard interface to load a disk sector by default, and there's no standard interface to switch video modes for example. Both are defined as "optional", and need LocateProtocol, which might fail (even though the video driver is clearly a requirement for ConOut, and you cannot load anything (not even the loader) without a disk driver). I really would like to see a bootloader that's capable of booting an OS using only the UEFI core (without any LocateProtocol or OpenProtocol calls)...

What's the point of being "extensible" if many protocols (like BLOCKIO, SIMPLE_FILE, GOP etc.) must be implemented anyway because you simply can't load an OS without them? And what's the purpose of all the other "extensible" optional protocols, that no boot loader ever use, and which are inaccessible after ExitBootServices anyway?

Cheers,
bzt

Posted: **Wed Sep 23, 2020 5:52 pm**

nexos wrote:It takes 4 seconds on my machine. My machine has 7 CPUs at 1.65 GHz and VTx and 8GB of RAM. With KVM, it takes 4 seconds.

That's extremely slow all things considered. If I were you, I'd implement the UEFI loader, but I would keep using the BIOS loader during compile - test development cycles.

PeterX wrote:So I think it is because of the missing VT/KVM on bzt's PC.

I do have kvm, just no VT. At least according to /proc/cpuinfo there are no VT extensions, but lsmod lists the kvm kernel module. If I add "-enable-kvm" to the command line, it considerably speeds up almost everything, but not UEFI boot (still takes 6-8 secs, most of the time spent before loaders are loaded). I actually use this command for testing my OS with UEFI, and this one for testing with BIOS. (Note these commands are for running OS/Z, and not for the BOOTBOOT loader tests.)

Cheers,
bzt

PS: If anybody wondering what "-device isa-debug-exit,iobase=0x8900,iosize=4" does, it allows you to shut down the VM without ACPI using this two liner:

Code: Select all

char *s = "Shutdown";
while (*s) __asm__ __volatile__("movw $0x8900, %%dx; outb %0, %%dx" : : "a"(*s++));

Extremely handy for automated tests

Posted: **Wed Sep 23, 2020 7:33 pm**

bzt wrote:If I were you, I'd implement the UEFI loader, but I would keep using the BIOS loader during compile - test development cycles.

I know you don't like UEFI @bzt, but I am starting to grow more fond of UEFI. My BIOS loader's ELF64 loader is all out kludgy in how it switches to long mode. UEFI seems to be a blessing in disguise, as it handles switching to long mode and makes my code much cleaner. My EFI loader took me a week to make, and my BIOS took me two

. To be fair, I reused some code, but still the UEFI one was shorter. As for startup speed, it fluctuates. 4 seconds is about average. I am fine with it, and have gotten used to it. So I will get rid of my BIOS loader soon.

Posted: **Thu Sep 24, 2020 6:31 am**

nexos wrote:I know you don't like UEFI @bzt, but I am starting to grow more fond of UEFI.

It's not a question of whether I like it or not. An EFI app is like a ticking bomb. It will work for months, or even years perhaps, but you'll never know when will it blow in your face. And that's because firmware manufacturers and UEFI driver writers can start to interpret the UEFI spec differently any time. (Just take a look at MP Services. It was working for more than a year, with TianoCore, VB EFI, and on all real hardware, all laptops, all desktops, up until the point when one user tried it on a certain AMD tower, where without any meaningful error message ExitBootServices just froze. Good luck debugging such issues!)

nexos wrote:My BIOS loader's ELF64 loader is all out kludgy in how it switches to long mode. UEFI seems to be a blessing in disguise, as it handles switching to long mode and makes my code much cleaner.

Once you're in long mode, it shouldn't matter to your kernel how you got there. And just for the records, UEFI using long mode is more of a problem than a blessing, you'll see for yourself later. You don't know what GDT it has set up, and at the end of the day you'll have to use your own no matter what. Likewise, you can't use its paging tables, so you'll have to use your own. When you got to the point to finally implement user space and user mode, you'll realize that you had to rewrite everything that UEFI has given to you, so it was a total waste of resources on UEFI's part... Just wait and you'll see!

Besides, if you want to do SMP, you'll have to care about real mode and prot mode code, you can't get away with long mode only. UEFI will not initialize the APs into long mode, only the BSP. You'll still need to care about those "ancient" modes.

nexos wrote:My EFI loader took me a week to make, and my BIOS took me two

Which is irrelevant

A software is written once, and executed many many times.

nexos wrote:To be fair, I reused some code, but still the UEFI one was shorter.

And how big your loader binaries are? I bet that your EFI loader is considerably bigger than the BIOS version.

Here is one of my boot records. It reads the kernel over serial line, then it sets up long mode. All of that in 512 bytes! Now implement a similar loader in UEFI, I seriously doubt you can do that in 512 bytes...

nexos wrote:As for startup speed, it fluctuates. 4 seconds is about average. I am fine with it, and have gotten used to it. So I will get rid of my BIOS loader soon.

You must be still young to have time to waste

My time is lot more precious than wasting it on waiting for VMs to boot. When I actively do development, I test my OS very often, and those seconds accumulate. They build up to minutes and even hours pretty quickly. But do as you please!

Cheers,
bzt

OSDev.org

UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates

Re: UEFI Wiki updates