Uefi 2.8

0 views

Skip to first unread message

Ambra Piszczek

unread,

Aug 3, 2024, 11:10:33 AM8/3/24

to bromlimebadc

I have an issue with the UEFI boot on my Laptop Pavilion dv7 6053er. When I looking for laptop support page, it shows me "HP BIOS Update UEFI" but I can't update my bios with the UEFI support. I wonder if my Laptop support UEFI boot. (Laptop supports UEFI Diagnostic Tool).

Thanks for your response, but it's on my laptop model support page (link). And I created USB with this tool and entering UEFI Diagnostics Tool with F2. Select Bios management and update bios option. And it says bios update failed. No updates available. And don't see my usb.

The HP BIOS UEFI tool provides the HP BIOS Update Unified Extensible Firmware Interface (UEFI) for the supported notebook models and operating systems. HP BIOS Update UEFI provides support for safe and secure BIOS updates from HP.

I'm just telling, HP Bios Update UEFI file is on my laptop model's support page. And you saying me that it's not for your model. I wanna that if it is not for my laptop, why it's on my laptop's support page. And if it is for my laptop, how can I use it. And if I cant, us there any method like Using DV7 7000+ series bios update. ItsI important, because my old laptop supported UEFI boot and I set up win10 with gpt partition uefi boot.

I can say that we have moved around 50 or so uefi boot vms from hyper v to ahv with no issues however I did experience something similar to this when the virtio drivers were installed but somehow corrupted. I had to do a manual uninstall and reinstall.

Sorry its not clear to me if you get the UEFI boot screen?
It is very clear before its trying to boot the OS if you successfully got the boot method changed.
If not maybe its not yet implemented properly in the GUI (often happens in their first try) and you still need to do the through cli.

@angeessan nope, the next thing to do is to make sure your truly do follow the uefi standard or have some odd implementation of it.
I have had to drop the vendors implementation and create it by hand myself from the UEFI documentation, then boot it from other media and recreate the system files.
But to begin with you can go into the UEFI menu and browse the disks to see if you can even find the files you need, if so try and call them by hand from the menu. If that is possible I would try and see if you could manually tell UEFI to use them or try and figure out why it does not just use them. Maybe you have more than you think when browsing through or something else will become clear in the process.
Good luck.

(U)EFI or (Unified) Extensible Firmware Interface is a specification for x86, x86-64, ARM, and Itanium platforms that defines a software interface between the operating system and the platform firmware/BIOS. The original EFI was developed in the mid-1990s by Intel for use developing firmware/BIOS for Itanium platforms. In 2005 Intel transitioned the specification to a new working group called the Unified EFI Forum, consisting of companies such as AMD, Microsoft, Apple, and Intel itself. All modern PCs ship with UEFI firmware and UEFI is widely supported by both commercial and open source operating systems. Backwards compatibility is provided for legacy operating systems.

If you choose VirtualBox for virtualization, then UEFI is already included, no need to download the image manually. You just have to enable it in the VM's preferences by clicking "Settings" / "Systems" / "Enable EFI (special OSes only)" checkbox.

A common misconception is that UEFI and BIOS are mutually exclusive. In reality, both legacy motherboards and UEFI-based motherboards both include BIOS ROMs. The differences are in where they find the bootloader/OS, how they prepare the system before executing it, and what convenience functions they provide.

On a legacy system, BIOS performs all the usual platform initialization (memory controller configuration, PCI bus configuration and BAR mapping, graphics card initialization, etc.), but then drops into a backwards-compatible real mode environment. The bootloader must enable the A20 gate, configure a GDT and an IDT, switch to protected mode, and for x86-64 CPUs, configure paging and switch to long mode.

UEFI firmware performs those same steps, but it also enables the A20 gate and prepares either protected mode environment with flat segmentation (for 32-bit x86 processors) or a long mode environment with identity-mapped paging (for x86-64 processors).

A legacy BIOS loads a 512 byte flat binary blob from the MBR of the boot device into memory at physical address 7C00 and jumps to it. The bootloader cannot return back to BIOS. UEFI firmware loads an arbitrary sized UEFI application (a relocatable PE executable file) from a FAT partition on a GPT or MBR partitioned boot device to some address selected at run-time. Then it calls that application's main entry point. The application can return control to the firmware, which will continue searching for another boot device or bring up a diagnostic menu.

A legacy bootloader scans memory for structures like the EBDA, SMBIOS, and ACPI tables. It uses PIO to talk to the root PCI controller and scan the PCI bus. It is possible that redundant tables may be present in memory (for example, the MP table in the SMBIOS contains information that's also present in the ACPI DSDT and MADT) and the bootloader can choose which to use.

When UEFI firmware calls a UEFI application's entry point function, it passes a "System Table" structure, which contains pointers to all of the system's ACPI tables, memory map, and other information relevant to an OS. Legacy tables (like MP tables) may not be present in memory.

A legacy BIOS hooks a variety of interrupts which a bootloader can trigger to access system resources like disks and the screen. These interrupts are not standardized, except by historical convention. Each interrupt uses a different register passing convention.

UEFI firmware establishes many callable functions in memory, which are grouped into sets called "protocols" and are discoverable through the System Table. The behavior of each function in each protocol is defined by specification. UEFI applications can define their own protocols and persist them in memory for other UEFI applications to use. Functions are called with a standardized, modern calling convention supported by many C compilers.

Legacy bootloaders can be developed in any environment that can generate flat binary images: NASM, GCC, etc. UEFI applications can be developed in any language that can be compiled and linked into a PE executable file and supports the calling convention used to access functions established in memory by the UEFI firmware. In practice this means one of three development environments: EDK2, GNU-EFI or POSIX-UEFI.

EDK2 is a large and complex, yet feature filled environment with its own build system. It can be configured to use GCC, LLVM, MinGW, Microsoft Visual C++, etc. as a cross-compiler. Not only can it be used to compile UEFI applications, but it can also be used to compile UEFI firmware to be flashed to a BIOS ROM.

GNU-EFI is a set of libraries and headers for compiling UEFI applications with a system's native GCC (does not work with LLVM CLang). It can't be used to compile UEFI firmware. Since it's just a couple of libraries against which a UEFI application can be linked, it is much easier to use than TianoCore ( EDK2 ).

POSIX-UEFI is very similar to GNU-EFI, but it is distributed mainly as a source, not as a binary library, has ANSI C like names and works with GCC as well as LLVM CLang. It's shipped with a Makefile that sets up the compiler flags for you.

OVMF, a popular open source UEFI firmware, has been ported to the QEMU (but not Bochs) emulated machine. Because it implements the UEFI specification, it behaves very similarly to commercial UEFI firmware on real machines. (OVMF itself is built with TianoCore, and its source ship with is as well, but pre-built images are available.)

If you are targeting legacy systems for which UEFI is not available or is not reliable, you should develop a legacy bootloader. This requires intimate knowledge of 16-bit addressing and the backwards-compatibility features of an x86 or x86-64 CPU. If you are targeting modern systems you should develop a UEFI application. Many UEFI firmwares can be configured to emulate a legacy BIOS, but there is even more variation among these emulated environments than among real legacy BIOS.

Although there is a slight learning curve to become familiar with the UEFI development environments, using the System Table, and accessing UEFI-provided protocols (functions), there are far fewer "gotchas" than trying to remain compatible with the wide variety of quickly-becoming-obsolete legacy BIOSs on real machines. UEFI is the standard for all modern PCs.

A class 1 machine is a UEFI system that runs exclusively in Compatibility Support Module (CSM) mode. CSM is a specification for how UEFI firmware can emulate a legacy BIOS. UEFI firmware in CSM mode loads legacy bootloaders. A class 1 UEFI system may not advertise UEFI support at all, since it isn't exposed to the bootloader. It's only UEFI "within" the BIOS.

A class 2 machine is a UEFI system that can launch UEFI applications but also includes the option to run in CSM mode. The majority of modern PCs are UEFI class 2 machines. Sometimes the choice to run UEFI applications vs. CSM is a one-or-the-other setting in the BIOS configuration, and other times the BIOS will decide which to use after selecting the boot device and checking whether it has a legacy bootloader or a UEFI application.

Not all UEFI firmwares support Secure Boot, although it is a requirement for Windows 8. Some UEFI firmwares support Secure Boot and there's no option to be disabled, which poses a problem for independent developers that do not have access to the PK or any of the keys in the KEK, and therefore can't install their own key or application signature or hash to the whitelist database. Independent developers should develop on systems that either do not support Secure Boot or has an option for Secure Boot to be turned off.