是否有 64 位 UEFI ELF 引导程序? [英] Is there a 64 bit UEFI ELF bootloader?

问题描述

我有 ELF 内核.所以我需要一个引导加载程序来加载我的 64 位 ELF 文件.我不需要过时的 Legacy BIOS 引导加载程序，我需要带/不带 GUI 的 UEFI 引导加载程序.

I have ELF kernel. So I need a bootloader that will load my 64 bit ELF file. I don't need obsolete Legacy BIOS bootloaders, I need UEFI bootloader with/without GUI.

推荐答案

我有 ELF 内核.所以我需要一个引导加载程序来加载我的 64 位 ELF 文件.

I have ELF kernel. So I need a bootloader that will load my 64 bit ELF file.

你有一个 ELF 内核；所以你可能需要一个引导加载程序:

You have an ELF kernel; so you probably need a boot loader that will:

• 加载内核的 ELF 文件

• load the kernel's ELF file

告诉内核内存映射

告诉内核有关硬件的各种信息(扁平设备树"或 ACPI 表或...)，可能包括帧缓冲区的详细信息.

tell the kernel various things about the hardware ("flattened device tree" or ACPI tables or ...), likely including frame buffer details.

还加载其他文件(例如初始 RAM 磁盘)；因为(即使对于模块化单体"内核)当内核尚未从磁盘加载磁盘驱动程序时，它也无法从磁盘加载磁盘驱动程序.

also load other files (e.g. initial RAM disk); because (even for a "modular monolithic" kernel) the kernel can't load a disk driver from disk when it hasn't loaded a disk driver from disk yet.

告诉内核某种内核配置(可能是另一个文件，可能是内核命令行参数").

tell the kernel some kind of kernel configuration (could be another file, could be "kernel command line args").

谁知道还有什么(例如，我希望我的引导加载程序在其最终虚拟地址上设置分页和映射内核；当磁盘 IO 速度较慢时，值得考虑解压以改善引导时间；进行健全性检查以查看是否内核的文件在相信它有意义之前已被篡改，...).

who knows what else (e.g. I expect my boot loaders to set up paging and map kernel at its final virtual address; decompression is worth considering to improve boot times when disk IO is slow; doing sanity checks to see if kernel's file has been tampered with before trusting it makes sense, ...).

换句话说；您需要关于任何/所有这些事情如何发生的完整详细规范(例如，内核如何从引导加载程序中检索内存映射，它采用哪种格式，如果有像内存映射中的 2 个或更多条目将不会描述相同的"这样的保证)/重叠内存区域"等)；其中引导加载程序(或所有引导加载程序)和内核(或所有内核)都符合详细规范.

In other words; you need a full detailed specification about how any/all of these things happen (e.g. how kernel retrieves memory map from boot loader, which format it's in, if there's guarantees like "2 or more entries in the memory map will not describe the same/overlapping area of memory", etc); where both the boot loader (or all boot loaders) and the kernel (or all kernels) comply with the detailed specification.

内核是 ELF"只是详细规范的一小部分.

"The kernel is ELF" is just a small piece of that detailed specification.

这让您有两个选择:

• 找到其他人设计的详细规范，其中包含内核是 ELF"；(或至少引导加载程序必须支持 ELF")，并采用他们的规范，然后忍受他们的所有设计决定，无论它们是否对您的操作系统有意义.这里唯一的选择(据我所知)是多引导规范.

• find a detailed specification designed by someone else that happens to include "the kernel is ELF" (or at least "the boot loader must support ELF"), and adopt their specification, and then put up with all of their design decisions whether they make sense for your OS or not. The only choice here (that I know of) is the multi-boot specification.

为您的操作系统创建您自己的详细规范；然后要么编写自己的引导加载程序，要么让其他人根据您的规范编写它们.这几乎是所有知名内核(Windows、Linux、FreeBSD 等)所做的.

create your own detailed specification designed for your OS; then either write your own boot loader/s or let other people write them from your specification. This is what almost every well known kernel (Windows, Linux, FreeBSD, ...) does.

注意 1:通常它不是一个引导加载程序"，而更像是一组它们(一个用于从GPT 分区硬盘"启动，一个用于从网络启动，另一个用于从可移动媒体启动，....).可以通过拆分引导加载程序"来解决这个问题.分成两半(许多不同的第一阶段"处理差异，加上一个共同的第二阶段"处理相似之处).

Note 1: typically it's not "one boot loader", but more like a set of them (one for booting from "GPT partitioned hard disk", one for booting from network, another for booting from removable media, ...). It's possible to work around this by splitting "boot loader" into halves (many different "1st stages" that handle the differences, plus a common "2nd stage" that handles the similarities).

注意 2:对于 UEFI，您可以将 UEFI 用作其他人设计的详细规范"；并且不用费心拥有引导加载程序.在这种情况下，您必须将 ELF 转换为 PE 格式；或按原样"插入您的 ELF 文件在 PE 文件中作为数据(其中 PE 文件有一些代码可以解压其中包含的 ELF).

Note 2: For UEFI, you could just use UEFI as the "detailed specification designed by someone else" and not bother having a boot loader. In that case you'd have to either convert your ELF into PE format; or insert your ELF file "as is" inside a PE file as data (where the PE file has some code to unpack the ELF contained inside it).

注 3:理论上它实际上是关于环境的；其中引导加载程序"从一个环境(例如从 UEFI)更改为另一个环境(例如到您的内核期望的环境")；以及这些改变环境的代码片段"可以分层(例如，也许BIOS -> 多重引导 -> UEFI 模拟器 -> 其他东西 -> 你的内核期望什么").

Note 3: In theory it's really about environments; where "boot loader" changes from one environment (e.g. from UEFI) to another environment (e.g. to "the environment your kernel expects"); and these "pieces of code that change environments" can be layered (e.g. maybe "BIOS -> multi-boot -> UEFI emulator -> something else -> what your kernel expects").

注 4:对于最终的您的内核期望的环境"；可能值得考虑诸如kexec()"之类的东西.其中内核的前一个实例用于启动内核的下一个实例.这有其自身的实际好处(例如更快的内核更新)，但考虑它的主要原因是改进内核期望的环境"的设计.(帮助确定内核真正想要什么，并避免从其他环境提供的、并非您的内核真正想要的东西中引入包袱).

Note 4: For the final "environment your kernel expects"; it may be worthwhile considering things like "kexec()" where a previous instance of your kernel is used to start the next instance of your kernel. This has practical benefits of its own (e.g. faster kernel updates), but the main reason to think about it is to refine the design of the "environment your kernel expects" (to help determine what the kernel actually wants and avoid introducing baggage from what other environments provide that aren't quite what your kernel really wanted).

TLDR:您可能最终会使用 Multiboot2(和 GRUB).您可以在此处找到 Multiboot2 的规范:https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html

TLDR: You'll probably end up using Multiboot2 (and GRUB). You can find the specification for Multiboot2 here: https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html

这篇关于是否有 64 位 UEFI ELF 引导程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！