Recently, I was working on the boot system of mobile hard disks and discovered many benefits of UEFI, but also discovered some problems that were not paid attention to before.
Legacy is traditional BIOS, UEFI is new BIOS
1, no UEFI+MBR hard disk legacy
2, no UEFI+GPT hard disk bios has its own processing method UEFI support, linux uses bios-grub partition (about 1M) to solve
3, UEFI+MBR hard disk
4, UEFI+GPT Hard Disk
Today's computers basically support UEFI, but the support methods are not the same. You can also choose in bios.
Generally speaking, it is the combination of Legacy+MBR and UEFI+GPT. But Legacy+GPT, UEFI+MBR can also be realized.
CSM (Compatibility support Module) stands for compatibility module. This option is designed for compatibility with devices that can only work in legacy mode and operating systems that do not support or cannot fully support UEFI. Therefore, to install the win7 system, you also need to set the Launch CSM to Enable, indicating that it supports the Legacy boot method.
For some motherboards, only when the Secure Boot Control is set to Disable, can the Launch CSM option be set to Legacy
. Two steps of the method of changing win7:
(1) Set the BIOS to support Legacy boot. The specific goal is Set the secure boot control to Disable, the compatible function CSM option to Enable, and the boot mode Boot Mode [UEFI/Legacy] to Legacy mode.
(2) Change the partition table type of the hard disk from GUID to MBR mode.
Let’s not talk about regular booting. Legacy uses 8086 assembly. More than 99% of UEFI uses C. UEFI APP and Drives can use C/C++.
The 64-bit UEFI firmware is a 64-bit operating system (the 32-bit UEFI firmware for a few 2-in-1 tablets can be ignored), and the Legacy is 16-bit.
Legacy is directly aimed at the details of the underlying hardware. UEFI shields the details of the underlying hardware for the operating system and the boot device through Firmware-OS Interface, Boot Services, and Runtime Services.
UEFI can be expanded. Most hardware can be initialized by loading the UEFI driver module. The driver module can be placed in the firmware or on the device, such as the GOP of the graphics card, and it will be automatically loaded when the system starts. Each Table and Protocol in UEFI has a version number, which can be upgraded smoothly. Developers can develop UEFI applications and drivers according to the specifications.
UEFI time-based asynchronous operation improves the efficiency of the CPU and reduces the waiting time.
UEFI abandons the external device operation mode of interrupt, and only retains the clock interrupt. The operation of the external device adopts the event + asynchronous operation, and the external device is loaded on demand when it is started.
UEFI has a secure boot function, which will only be executed when the program's certificate is trusted.
When booting in UEFI mode, EFI drivers and applications are booted, and as long as the system is booted, it is directly 64-bit. (The 32-bit UEFI firmware of a few 2-in-1 tablets is ignored.)
Then if you choose to boot in UEFI mode, all 16-bit MS-DOS utilities, DOS toolkits and other maintenance tools, and 32-bit applications are not available. Loaded and started. UEFI must be installed using a 64-bit system!
So in UEFI mode, we cannot boot a 32-bit system.
The GPT partition table is located in the logical sector No. 2-33 of the disk. It occupies a total of 32 sectors and can accommodate 128 (4*32) partition table entries. The size of each partition table entry is 128 bytes, so the Windows system allows GPT disks to create 128 primary partitions.
The partition table entry records the start and end addresses of the partition, the GUID of the partition type, the name of the partition, the partition attribute, and the partition GUID.
GPT also has something similar to MBR, except that the boot record is empty, the windows disk signature is available, and there is also a partition table, but the partition format is defined as EE, because this format does not exist, so the old disk partitioning tool is opened The disk will find that the format of the disk cannot be recognized, and the disk will not be partitioned.
Seeing this, we already understand, so in fact, the partition table is the same thing. GPT and MBR are just two ways to allocate hard disk data.
Sector 0 of the GPT partition can be written into the master boot record or the partition table, but it needs to be converted manually.
Therefore, it is completely feasible for the traditional Legacy BIOS to start the GPT partition.
And UEFI itself reads the \efi\boot\bootx64.efi file of the first FAT32 partition of the hard disk to boot the system, so no matter whether the partition format is MBR or GPT, it will not affect the normal boot of UEFI.
This is the theoretical basis for us to successfully make the traditional BIOS boot the operating system of the GPT disk; let UEFI boot the operating system of the MBR disk.
UEFI starts MBR. First of all, the MBR partition table must have a FAT32 partition. It does not matter whether it is an active partition or not, because UEFI does not have an active partition.
Just manually repair the BCD file of the FAT32 partition, and edit it with the BOOTICE tool to
start the GPT with the traditional Legacy BIOS. This is a bit complicated, indeed a bit complicated...
In fact, there are several technical routes to choose from.
First of all, we need a large hard disk with traditional Legacy that can start the gpt partition table. This is very cumbersome and there are several technical routes. First of all, Legacy can read the 440 bytes of the master boot record, but after reading it, it cannot recognize the partition format, so it is necessary to make a mirror file that contains the information that needs to be used. At present, some sector editing is done directly, jmp to a specific sector, and using the information of this sector to guide to the target is very cumbersome, and this technique is too complicated to be popularized.
Another technical route is to simulate uefi, which is common in chameleon, clover, clover, and duet. This technical route is relatively simple. If you have two hard disks, one mbr and the other gpt, this is very simple. Boot from the mbr disk, load the simulated uefi, and then boot the system with the gpt disk.
But if it is a single gpt disk, it is still inevitable to do sector editing, leave a space in front, and then write the image in hexadecimal, load it into the memory, and then run the program that simulates uefi. This is a bit complicated. For example, if you are doing a circuit, you can convert AC to DC, then rectify and reduce the voltage and then filter. It takes a lot of effort for a seemingly simple result.
An "EFI system partition" is any partition formatted with a FAT variant (one of the variants defined by the UEFI specification). The partition is assigned a specific GPT partition type to help the firmware identify the partition. The purpose of this partition is as described above: the firmware layer can indeed read the data in the "normal" disk partition. The
UEFI specification tries to adopt a more intuitive and strict method-it rarely prohibits the firmware from performing other operations. The UEFI specification does not object to writing firmware, which is used to execute code written in other formats, read other types of partition tables, and read partitions formatted with UEFI variant file systems (non-FAT). But UEFI compatible firmware must at least be able to execute EFI executable files, read GPT partition table, and read ESP, so if you are writing an operating system or other things and want to run on UEFI compatible firmware, you also have to Following the UEFI specification, this is why the concept of the EFI system partition is very important: it allows (at least in theory) to put EFI executable files on a partition formatted with UEFI FAT and the GPT partition type is correct. In addition, the system firmware requires The partition can be read. This mechanism is very rigorous, and is equivalent to the "firmware executable" in the BIOS. The UEFI specification provides us with three important foundations. These important foundations are the foundation for the normal operation of the upper-layer architecture:
读取分区表
访问某些特定文件系统中的文件
执行特定格式的代码
Compared with the functions provided by BIOS firmware, UEFI has much richer functions. However, in order to complete the vision that the firmware layer can handle multiple targets (not just disk) booting, we need other foundations: we need to establish a mechanism through which the firmware can find various possible boot targets and provide corresponding The configuration method. Boot loader code in MBR space".
If you have booted Linux via UEFI, you can use the efibootmgr tool to complete all these operations. Windows also has corresponding tools, but I am very unfamiliar with the tools under Windows. Let’s look at some typical The output of efibootmgr, which I transferred from the Fedora forum, slightly adjusted:
[root @system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVDDrive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00 )
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G.
[Root @system directory]#This
example is very clear. We can observe the details from it.
The first line indicates which item of the "boot menu" you have started from. The second line is very obvious (if the firmware UEFI boot manager displays an interface similar to the boot menu, then this line indicates the timeout before continuing to boot the default items). BootOrder is the order in which the startup items in the list are tried. The remaining output shows the actual startup items. We will explain the specific role of each startup item later.
If the UEFI firmware is fully booted normally without any adjustments (we will discuss later), the UEFI firmware will try to boot from each "item" in the "Boot Menu" in the order listed in the BootOrder. Therefore, on this computer, the UEFI firmware will try to start the item named "opensuse". If the startup fails, then try to start the item named "Fedora", then "CD/DVD Drive", then the first Two items "Hard Drive".
"Fallback path" UEFI native boot item
The UEFI specification defines a "Fallback path" for starting this type of boot manager item, which works like a BIOS drive boot: it looks for some boot loader code in a standard location. But the details are different from the BIOS.
When trying to boot in this way, what the firmware actually performs is fairly simple. The firmware traverses every EFI system partition on the disk (in accordance with the order of the partitions on the disk). Within the ESP, the firmware will look for a file with a specific name in a specific location. On x86-64 PCs, the firmware will look for the file \EFI\BOOT\BOOTx64.EFI. The firmware actually looks for \EFI\BOOT\BOOT{computer type abbreviation}.EFI, where "x64" is the "computer type abbreviation" of x86-64 PC. The file name may also be BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Itanium), BOOTARM.EFI (AArch32, 32-bit ARM), and BOOTAA64.EFI (AArch64, 64-bit ARM). Then, the firmware will execute the first valid file found (of course, the file needs to conform to the executable format defined in the UEFI specification).
This mechanism is not designed to start the operating system that is used daily. Its design purpose is more like to start hot-pluggable, device-independent media (such as Live images and operating system media). This is also a common use of this mechanism. If you check the UEFI-compatible Live or installation media of Linux or other operating systems, you will find that it contains GPT and a FAT partition located at (or near) the starting position of the device. The GPT partition type of this partition is identified as the EFI system partition. In that partition, there will be a \EFI\BOOT directory, which contains at least one of the above-mentioned specially named files. This mechanism is used when starting Fedora Live or the installation media in native UEFI mode. The BOOTx64.EFI (or other) file will handle the rest of the boot process to boot the real operating system contained on the media.
The Linux distribution uses the efibootmgr tool to handle the UEFI boot manager. When performing native UEFI installation, the actual operation of the Linux distribution regarding boot loading is quite simple: it will create an EFI system partition (if this partition does not exist), and use the corresponding configuration to install the EFI boot loader (usually grub2-efi , But there are exceptions) Install to the correct path in the EFI system partition, and then call efibootmgr to add the corresponding UEFI boot manager item (pointing to its boot loader). If an EFI system partition already exists, most distributions will use the existing partition (although it is entirely possible to create a new EFI system partition and use this new partition): We have already mentioned that UEFI is a loose specification, as long as it is logically Following its design, it does not matter how many EFI system partitions there are.
The startup configuration interface of many firmwares is more intuitive. An excellent firmware design will at least display the startup sequence and each startup item in it, allowing users to add/delete items, change the startup sequence, or ignore the original startup sequence in a particular startup (only valid for that startup, or let the firmware directly Boot a specific menu item, you can even choose to let the firmware "boot this disk" in BIOS compatibility mode or UEFI "Fallback" mode, my firmware can do that). This type of interface can usually display complete native UEFI boot items by name only (such as the Fedora and OpenSUSE examples we mentioned above); you need to check the output of efibootmgr -v to understand in detail what they will What to try and perform.
Some firmware will try to abstract and simplify the configuration, but the end result is mixed. For example, if you can select "Enable or Disable" BIOS compatibility mode, the firmware is likely to add or remove BIOS compatibility items for the UEFI boot manager configuration of the connected drive. If you can choose to "enable or disable" native UEFI boot, when the user "disables" native UEFI boot, the firmware is likely to change the UEFI boot manager configuration and delete all native UEFI boot items from BootOrder.
Native UEFI boot and BIOS compatible boot
Users sometimes overlook the following:
如果以“原生 UEFI”模式启动安装介质，安装介质将以原生 UEFI 模式安装操作系统：它将尝试向 EFI 系统分区写入 EFI 格式的启动装载程序，并尝试向 UEFI 启动管理器的“启动菜单”中添加启动项，用于启动该启动装载程序。
如果以“BIOS 兼容”模式启动安装介质，安装介质将以 BIOS 兼容模式安装操作系统：它将尝试向磁盘上的 MBR 空间写入 MBR 类型的启动装载程序。
Windows boot process under
UEFI UEFI BIOS→EFI system partition→\efi\boot\bootmgfw.efi→efi\Microsoft\Boot\BCD→\Windows\system32\winload.efi
EFI partition stores the files needed for system startup (bootmgfw .efi, BCD, etc.)
Start linux under uefi
-
There are two ways
1.1 Start the linux kernel directly from the uefi shell
1.2 Start grub from the uefi shell, and then start the linux kernel from grub -
What do I need?
2.1 linux kernel
2.2 initrd mirror
2.3 .nsh suffixed startup script (optional, you can manually enter the command)
The content of a .nsh is as follows:
Image initrd=\initrd.gz root=/dev/ram0 earlycon =uart
2.4 BOOTAA64.EFI (this is the EFI firmware of arm64, optional)
Note: These things need to be placed in the fat file system -
The operation process of uefi shell to start the linux kernel
3.1 Enter the target partition
Shell> fs0:
FS0:>
3.2 Start the linux kernel
FS0:>boot.nsh -
Start grub from the uefi shell, and then start the linux kernel
4.1 Enter the target partition
Shell> fs0:
FS0:>
4.2. Enter grub
FS0:>BOOTAA64.EFI
4.3 Set the root node for temporary access in
grub grub> root=(hd0,msdos1) (There are linux kernel mirroring and initrd mirroring in hd0, msdos1)
4.4 Start linux kernel
grub> linux /Image initrd=/initrd.gz earlycon=uart root=(hd0,msdos1) rw rootwait