diff options
| author | Tom Rini <[email protected]> | 2025-04-03 11:43:38 -0600 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2025-04-03 11:43:38 -0600 |
| commit | 1f2a3d066c99f57675162ce09586e9de30407f1b (patch) | |
| tree | 40bfceab01cc1c6a035eb66792638149400db1ef /doc/develop | |
| parent | 39ff722b3ee0bd569388a3b89c59899511ac1a24 (diff) | |
| parent | a3d255d996b346c527962926ff80343e02ae8f00 (diff) | |
Merge patch series "x86: Improve operation under QEMU"
Simon Glass <[email protected]> says:
U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.
With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.
With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.
We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.
With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.
Link: https://lore.kernel.org/all/[email protected]/
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/bootstd/overview.rst | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index e3ce97cc4f5..9fe5630ab16 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -235,8 +235,9 @@ means that `default_get_bootflow()` is used. This simply obtains the block device and calls a bootdev helper function to do the rest. The implementation of `bootdev_find_in_blk()` checks the partition table, and attempts to read a file from a filesystem on the partition number given by the -`@iter->part` parameter. If there are any bootable partitions in the table, -then only bootable partitions are considered. +`@iter->part` parameter. If there are any bootable partitions in the table and +the BOOTFLOWIF_ONLY_BOOTABLE flag is set in `@iter->flags`, then only bootable +partitions are considered. Each bootdev has a priority, which indicates the order in which it is used, if `boot_targets` is not used. Faster bootdevs are used first, since they are |