UEFI Wiki updates

[nexos]

Hello,
Like it or not, UEFI has replaced BIOS. Most Wiki info is very BIOS based. I am currently in the process of adding UEFI info to the wiki. Yesterday, I added a section on the EFI memory map. I think barebones should be updated to use UEFI grub (or maybe BOOTBOOT or my boot manager) and graphics. The bootloader articles should focus more on UEFI. I don't like EFI. But the wiki should stay modern. Anyone want to pitch in and help?
Thanks,
nexos

[bzt]

I don't think removing BIOS barebones is a good idea. I think the barebones tutorials should be left as is, BIOS only. However I do support to put a sentence "Modern machines use UEFI" with a link on the UEFI to an UEFI barebone tutorial.

So

Most Wiki info is very BIOS based. I am currently in the process of adding UEFI info to the wiki.

Agreed.

The bootloader articles should focus more on UEFI.

I'd rather say we should have an UEFI bootloader section too.

My reason is, you can (and you'll be able to) use BIOS with virtual machines, regardless what real hardware supports. Running a qemu VM with TianoCore takes minutes to start, while running a qemu VM with BIOS boots instantly. Considering almost everyone starts implementing their OS on a VM, it makes sense. I for one avoid UEFI on my VMs as much as possible.

Cheers,
bzt

[nexos]

Running a qemu VM with TianoCore takes minutes to start

I use the command line

Code: Select all

qemu-system-x86_64 -cpu qemu64 -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -net none

And it starts quickly. -net none is important to prevent it from doing a PXE scan. Don't know what I am going to if my OS gets network support.

I don't think removing BIOS barebones is a good idea. I think the barebones tutorials should be left as is, BIOS only. However I do support to put a sentence "Modern machines use UEFI" with a link on the UEFI to an UEFI barebone tutorial.

Agreed, yes. Maybe we could rename the current UEFI barebones to UEFI application bare bones, and create a new UEFI barebones that shows how to make a UEFI kernel, bootable by GRUB or BOOTBOOT or my bootloader (when UEFI support is finished ).

[bzt]

And it starts quickly. -net none is important to prevent it from doing a PXE scan. Don't know what I am going to if my OS gets network support.

Yep, PXE could take a long time, but I'm not talking about that. When I start qemu with TianoCore, then it first prints "Guest has not initialized the display yet.". It takes several seconds until the TianoCore logo shows up, then several more precious seconds on the logo screen before the actual booting starts. And the PXE timeouts came only afterwards. TBH by the time the "Guest has not initialized the display yet." message disappears with UEFI, I can already boot my entire OS with BIOS or coreboot...

Maybe we could rename the current UEFI barebones to UEFI application bare bones, and create a new UEFI barebones that shows how to make a UEFI kernel, bootable by GRUB or BOOTBOOT or my bootloader (when UEFI support is finished ).

I couldn't find that "UEFI barebones" page you were talking about. But if you meant UEFI App Bare Bones, then I agree: that page talks about how to use the toolchain and how to create a bootable medium. Btw, I've also created the Bootable Disk page, maybe we should remove that latter part and link there to avoid duplication?

Cheers,
bzt

[nexos]

I renamed UEFI Bare bones to UEFI App bare bones just now, and started a UEFI bare bones with BOOTBOOT and GRUB. It can be found at https://wiki.osdev.org/User:Nexos/UEFI_Bare_Bones

[zaval]

what's "UEFI kernel" and why the wiki should use grub or bootboot or other useless cruft, whereas by all the idea, an OS provider writes their own OSL, that loads the OS, using UEFI services and protocols and everything else is just not needed? shouldn't a wiki article on UEFI, concentrate exactly on that (demonstrating how to use UEFI services in an OSL for OS loading) instead of driving people use crappy solutions?

Also. maybe for creating such articles people 1) should be a bit more experienced with the topic and 2) have a little more friendlier attitude to the topic, than this "I don't like efi, intel svck5, I made my qemu setup so sucky, that it takes ages for booting into uefi shell, but I am a smart4ss, so, tianocore is to blame, linux torvalds is my gawd etc ..."? both of you, guys, failed at least one of those checks.

[BenLunt]

When I start qemu with TianoCore, then it first prints "Guest has not initialized the display yet.". It takes several seconds until the TianoCore logo shows up, then several more precious seconds on the logo screen before the actual booting starts. And the PXE timeouts came only afterwards. TBH by the time the "Guest has not initialized the display yet." message disappears with UEFI, I can already boot my entire OS with BIOS or coreboot...

bzt,

You may need to adjust your settings. I am using QEMU for Windows and the following command line (batch file):

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 ^
-vga std -net none -monitor stdio -machine q35

It boots nearly as fast as the Legacy BIOS boot does. Granted, as you state, the Legacy BIOS boots a little faster, but with this setup, I only notice less than a second difference in my UEFI boot.

A few other things that might effect it is that I have my BOOTx64.EFI in the \EFI\BOOT\ directory of the primary GPT partition, as well as a STARTUP.NSH file:

Code: Select all

fs0:
; first try the 64-bit one.  If not 64-bit, it will simply return and go to the next line
EFI\BOOT\BOOTx64.EFI
; if the above failed, try the 32-bit one
EFI\BOOT\BOOTIA32.EFI

In fact, solely because of my Legacy loader, the EFI boots to the kernel much faster than my Legacy version does. Therefore, if I am solely concerned about the time I have to wait to get to the kernel, my EFI version is much faster than my Legacy version, and gets me to the kernel much quicker.

Please note that I am just stating this as fact, so that you might want to look into why yours is taking so long, not to discredit yours or anything. I have noticed that if I don't have my BOOTx64.EFI file (which must be named as such) in the \EFI\BOOT\ directory *and* if I don't have a STARTUP.NSH file, the QEMU version of the EFI does take the delays you write of. I also believe the comment made earlier of "-net none" needs to be used as well.

Hope this helps,
Ben

[bzt]

Hi BenLunt,

Thanks for the tip. I did a lot of tests with different options. I'm using the qemu shipped with my distro, and I've downloaded the OVMF from http://www.tianocore.org/ovmf/, but that page has been removed since (but see below). In all cases I was looking for the first message that indicated the boot loader (to omit PXE and other net related overhead), however without UEFI I could only observe the whole boot time, it's that fast.

First, the non-UEFI versions:
"qemu -option-rom bootboot.bin" boots the OS in less than a sec. Probably millisecs to the "Booting OS..." message
"qemu -kernel bootboot.bin" less than a sec.
"qemu -bios coreboot.rom" less than a sec.

Now the UEFI versions, first with the OVMF.fd I've downloaded, with the original, unmodified OVMF-VARS.fd:
"qemu -bios"
"qemu -drive if=pflash"
"qemu -M q35 -bios"
"qemu -M q35 -drive if=pflash"
I've also tried all combination with "-sdl", but in all cases there's a "Guest hasn't initialized the display yet." message for at least 2-3 seconds. Then at least 3-5 seconds on the "TianoCore" boot screen with the "X bytes of system memory tested OK." message. Only after that it shows "Boot Failed. EFI Floppy", "Boot Failed. EFI DVD/CDROM" etc. The entire qemu command line looked like this:

Code: Select all

qemu-system-x86_64 (varied options, see above) -m 64 -drive file=disk-x86.img,format=raw -serial stdio

Then I've tried alternative OVMF.fd bios64.bin from here, same results.

I've also tried an OVMF that I compiled using the package shipped with my distro (edk2-ovmf 202005-3). However I'm sure I've misconfigured something during compilation, because it is even slower that the two binaries I've downloaded, takes more than a minute until the first "Boot Failed. EFI Floppy" message shows up.

I've repeated all test with my OVMF-VARS.fd, where I've changed the boot order so FS0:\EFI\BOOT\BOOTX86.EFI to be the first. Same results, except there are no "Boot Failed. X" messages, it is the "Booting OS..." message that shows up as first (printed by my boot loader). I do not use STARTUP.NSH, I've just changed the boot order. (Press ESC on the TianoCore boot screen, then it will start the configuration screen. Select "Boot Maintenance Manager", then "Boot Options", then "Change Boot Order". Move "EFI Harddrive" to the top).

Finally, I've tested with VirtualBox too. There without "Enable EFI (special OSes only)" it boots in a little bit more than a sec (spends some time showing "Press F12..." message, otherwise fast). With "Enable EFI (special OSes)" option, it boots just a little bit longer, in 2 secs. A lot better than any TianoCore configuration, but still slower than the BIOS version. However this 2 secs overhead is reasonable and perfectly acceptable.

You can find the images I've used here (and option rom in ../dist/bootboot.bin), along with most of the qemu commands (see Makefile). For VirtualBox, I've used it's GUI, and I've converted the disk image to vdi with

Code: Select all

VBoxManage convertfromraw disk-x86.img disk-x86.vdi

Cheers,
bzt

[BenLunt]

Hi bzt,

I use the pre-built EFI versions from https://www.kraxel.org/repos/jenkins/edk2/, more specifically the x64 version named edk2.git-ovmf-x64-0-20200515.1452.g7faece6985.noarch.rpm.

I just replaced the link to my image with your image and ran QEMU. Your image booted within a second, straight to the demo screen with the color blocks.

Code: Select all

qemu-system-x86_64.exe -m 256 ^
-drive file=disk-x86.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 ^
-vga std -net none -monitor stdio -machine q35

I see that your image does not have a STARTUP.NSH file, so this doesn't make any difference. It could simply be the specific EFI files used.

Anyway, as noted, I booted with the above batch file under Windows 10, using the two "pure-efi" files from the link above, and your image booted to the (demo) kernel within a second.

Hope that helps,
Ben

[bzt]

Hi Ben,

Hi bzt,

I use the pre-built EFI versions from https://www.kraxel.org/repos/jenkins/edk2/, more specifically the x64 version named edk2.git-ovmf-x64-0-20200515.1452.g7faece6985.noarch.rpm.

Thanks, I've tried this image, the same. Several seconds with "Guest hasn't initialized the display yet.". Then the Tianocore logo shows up without the "system memory tested OK" message, just the logo.

I just replaced the link to my image with your image and ran QEMU. Your image booted within a second, straight to the demo screen with the color blocks.

Thanks, good to know it works as expected on your computer!

Anyway, as noted, I booted with the above batch file under Windows 10, using the two "pure-efi" files from the link above, and your image booted to the (demo) kernel within a second.

It could be that my rather old computer just simply can't emulate UEFI that fast... (1GHz, ca. 3000 bogomips, no VT-x). After all, UEFI runs a magnitude more code than BIOS, but for a fast computer with properly hardware accelerated VMs that just isn't noticeable.

Cheers,
bzt

[BenLunt]

On a side note--and we can move this to another thread if needed--when you list the available video modes, do you have a mode that shows a horizontal res of 1366?

i.e.: I have list all modes and halfway through the listing, I get:

Code: Select all

Found Video Mode:  XRES x YRES  (Px) Pixels_per_scanline
---------------------------------------------------
...
Found Video Mode:  1280 x 1024  (1)   1280
Found Video Mode:  1360 x  768  (1)   1360
Found Video Mode:  1366 x  768  (1)   1366
Found Video Mode:  1400 x 1050  (1)   1400
Found Video Mode:  1440 x  900  (1)   1440
...
(Px = Pixel Format)

Notice the 1366 x 768 entry.

This horizontal value is not only odd (in the "not normal" sense of the word), but when selected, doesn't display correctly. (Maybe this res isn't odd at all)

If I assume that the actual horizontal pixel value is 1360 and the pixels per line is 1360 as well, then the mode works as expected. However, if I take the value as is, 1366, I indeed get a 6 pixel offset within my display driver.

I went looking through the EDK2 code and couldn't find much of where this is initialized.

I am just wondering if someone else gets these same results or if I am missing something.

Thanks,
Ben

[kzinti]

1366x768 is a resolution used on some (older) TVs. I do own such a TV and the behaviour is rather intereresting. What ends up happening is the width is actually set to 1368 pixels, but only 1366 pixels are displayed. If you try to use this mode on a panel that is not 1366 pixels wide, you get to see the extra pixels. But not on a native 1366 pixels wide panel.

- Video card is set to 1368 pixels wide
- Display is actually 1366 pixels wide
- The graphics stack needs to know that only 1366 pixels are visible

So if you select the 1366 mode and your panel is not 1366 pixels wide, you end up actually setting up 1368 pixels and your graphics stack is ignoring 2 columns of pixels. If you are lucky they are (set to) black, but otherwise you see garbage.

Anyways that is how things appear to work on my TV.

[BenLunt]

That sounds just like I would expect it to be.

However, my "graphics stack", as you call it, sets the width to 1360 and more importantly, the bytes per scan line to 1360 * sizeof(PIXEL) and it worked as expected.

I think the EDK2 might be in error with this mode. However, I don't have anything to confirm that it is in error.

Thanks,
Ben

[zaval]

That resolution (1366 x 768) is not that odd, my only UEFI capable home laptop has it as native (HP Probook 4530s). What exactly you want to check? I would be glad to play with it, but it's not a testing machine, so it could be not too soon, just need to catch the next reboot, which is rare.

[BenLunt]

No I think it is a problem with ID2K's emulation, not my code or the computer, so there is nothing to check for your laptop. Besides, if it is your flagship, I wouldn't expect you to test anything with it. I don't on mine.

Since after switching to that mode (1366x768) via the EFI's GOP, then moving to my OS and using my graphics driver, if I set the pixels per scanline and the actual horizontal res to 1360, everything works just fine, as if it was a 1360x768 mode. However, if I do not, everything is 6 pixels off. i.e. If I use the pixels per scan line and horz res value given by the firmware, the display is skewed by 6 pixels to the right.

I believe the firmware has told QEMU that the display is only 1360 pixels wide. However, since the firmware told my kernel/display driver that the display is 1366 pixels wide, every line is moved 6 pixels to the right (6 pixels/24 bytes down the Frame Buffer).

The actual (host) window displayed occupies the exact same space on the host screen. I would expect the host window to be 6 pixels wider when choosing the wider mode setting. It isn't.

Ben
- http://www.fysnet.net/osdesign_book_series.htm