Now that U-Boot can boot this quickly, using kvm, add a test that the
installer starts up correctly.
Use the qemu-x86_64 board in the SJG lab.
Series-to: u-boot
Series-cc: bin
Series-version: 5
Series-links: 447304 2:445849 1:444626
Series-changes: 2
- Add more patches to support booting with kvm
- Add new patch with a test for booting Ubuntu 24.04
Series-changes: 3
- Significantly expanded to correct e820 and other issues
Series-changes: 5
- Drop timeouts patch
- Use Ctrl-N instead of down-arrow to make the test more reliable
- Add more logging into the test
Cover-letter:
x86: Improve operation under QEMU
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.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
When the ACPI tables come from an earlier bootloader it is helpful to
see whether the checksums are correct or not. Add a -c flag to the
'acpi list' command to support that.
Series-changes: 3
- Add new patch to support checking checksums with ACPI command
Signed-off-by: Simon Glass <sjg@chromium.org>
Free the memory used in tests to avoid a leak. Also unmap the addresses
for sandbox.
Series-changes: 3
- Add new patch to correct memory leaks in the ACPI test
Signed-off-by: Simon Glass <sjg@chromium.org>
This table lacks a correct checksum at present, so fix it.
Series-changes: 3
- Add new patch to add a checksum to the DMAR table
Signed-off-by: Simon Glass <sjg@chromium.org>
The values in the FADT are pointers so should not go through sandbox's
normal addr<->pointer mapping. Fix this.
Series-changes: 3
- Add new patch to correct mapping in FADT
Series-changes: 4
- Split out the command change into a separate patch
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a condition for sandbox, to match that of x86, to avoid the warning
"FADT not ACPI-hardware-reduced-compliant".
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-changes: 4
- Split out into separate patch
Update the string to take account of UARTs which are connected on I/O
ports, as on x86.
Fix a typo in an error message in the same command, while we are here.
Series-changes: 3
- Add new patch to support IO UARTs for earlycon and console
Signed-off-by: Simon Glass <sjg@chromium.org>
If only a single label is provided in the list, bootdev_next_label()
does not operate correctly and reads beyond the end of the pointer list.
Fix this by adding a new check. Also add a note to convert this array
to an alist
Series-changes: 3
- Add new patch to handle running out of labels
Signed-off-by: Simon Glass <sjg@chromium.org>
Any 'bootable' flag in a DOS partition causes boostd to only scan
bootable partitions for that media. This can mean that extlinux.conf
files on the root disk are missed.
Put this logic behind a flag and update the documentation.
For now, the flag is enabled, to preserve existing behaviour. Future
work may provide a command (or some other mechanism) to control this.
Series-changes: 4
- Rewrite the commit message
- Enable the flag by default
Series-changes: 3
- Add new patch to consider non-bootable partitions
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the size of this struct is too large on 64-bit machines.
Annotate it with __packed to fix this.
Series-changes: 3
- Add new patch to mark struct acpi_rsdp as packed
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some missing pieces to bootparams so that a 64-bit ramdisk address
can be used. Tidy up the logging while we are here.
Series-changes: 3
- Add new patch to support a 64-bit ramdisk address
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing QEMU implementation mostly ignored BLOBLIST_TABLES and
allocates the bulk of the tables with malloc(). Update it to place all
tables in the bloblist. Since QEMU declares a size of 128KB regardless
of the size of its tables, this requires a larger bloblist.
Fix up the e820 table to handle this, keeping the old code as an option
for now, to assist with any future bug-fixing.
Series-changes: 3
- Add new patch to support BLOBLIST_TABLES properly in QEMU
Signed-off-by: Simon Glass <sjg@chromium.org>
Move over to use this API before making the code even more complicated.
Series-changes: 3
- Add new patch to use the new e820 API
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing mechanism is pretty painful as it requires manual
calculations for anything but a trivial setup.
Add a new API for adding e820 entries.
Series-changes: 3
- Add new patch with an API for e820
Signed-off-by: Simon Glass <sjg@chromium.org>
There is already code for this in zimage. Move it to the e820 file so
it can be used elsewhere.
Series-changes: 3
- Add new patch with a function to dump the e820 table
Signed-off-by: Simon Glass <sjg@chromium.org>
Some test can only be run by a particular board in a lab, e.g. because
they are loaded with an OS image used by the test. Add a way to specify
this in tests.
Series-changes: 2
- Add new patch to allow tests to be filtered by role
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing run_command() method is not great for sending things other
than U-Boot commands. Add a helper for sending arbitrary strings as well
as control characters.
Series-changes: 2
- Add new patch with a helper to send characters
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At present the disks end up being 1MB shorter than they should be,
since dd truncates by default.
Move the code into a function and update it to avoid truncation.
This resolves various warnings when running sandbox tests, of the form:
mmc_bread() MMC: block number 0x9801 exceeds max(0x9800)
caused by the FAT partition being scanning.
Series-changes: 3
- Add new patch to correct sizing of created disks
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for an environment stored in the first partition of the
disk, which is assumed to hold a FAT filesystem.
Support the 'cat' command as it is useful for looking at extlinux.conf
files.
Signed-off-by: Simon Glass <sjg@chromium.org>
QEMU likes to have an MTRR set up, just like real machines. Add an MTRR
which covers the total RAM size.
This does nothing on machines without MTRRs.
Series-changes: 2
- Add new patch to set an MTRR for the RAM in QEMU
Series-changes: 3
- Support memory sizes above 3GB properly
Signed-off-by: Simon Glass <sjg@chromium.org>
At present mtrr_add_request() requires that the size is a power of two.
This is too limiting for machines with 4GB (or more) of RAM, since they
often must take account of a memory hole at 3GB.
Update the function to automatically deal with an unaligned size, using
more MTRRs as required.
Series-changes: 3
- Add new patch to allow adding non-aligned size for MTRR
The algorithm is taken from coreboot commit 60bce10750
Signed-off-by: Simon Glass <sjg@chromium.org>
The CONFIG option is no-longer correct since we can have SPL and PPL
with different bitness.
Fix this and sync up with Linux 6.13 in this area, since this is where
the code came from many years ago.
Series-changes: 3
- Add new patch to correct msr operation on amd64
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing functions work but the register clobbers are wrong, so
strange bugs results.
The original functions were taken from a very old version of Linux.
Update them from Linux 6.13
Series-changes: 3
- Add new patch to update cpuid_eax et al to work on amd64
Signed-off-by: Simon Glass <sjg@chromium.org>
The MTRR registers have 64-bit values. Update the command to use 64-bit
values so that memory larger than 4GB can be handled.
Series-changes: 3
- Add new patch to update mtrr command to support 64-bit values
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than repeating the same code in several places, add some
functions which can do the conversion.
Use the cpu_phys_address_size() function to obtain the physical-address
size, since it is more reliable with kvm, where the host CPU may have a
different value from the emulation CPU.
Series-changes: 3
- Add new patch with functions to convert between mtrr size and mask
Signed-off-by: Simon Glass <sjg@chromium.org>
At present it is not possible to find out the physical-address size in
long mode, so a predefined value is used.
Update the macros to support this properly, since it is important when
programming MTRRs.
Series-changes: 2
- Add new patch to support CPU functions in long mode
Series-changes: 3
- Always return true from flag_is_changeable_p() on amd64
Signed-off-by: Simon Glass <sjg@chromium.org>
This value happens to be used by ctype.h so chose a different name.
Series-changes: 2
- Add new patch to rename the _D dirty flag
Signed-off-by: Simon Glass <sjg@chromium.org>
With the 64-bit descriptor we can use a jump instruction, rather than
pushing things on the stack.
Since the processor is in 64-bit mode by this point, pop a 64-bit value
from the stack, containing the target address.
This simplifies the code slightly, in particular its use of the stack.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is required as part of the procedure. The existing code works
because it changes the GDT at the same time, but this makes kvm
unhappy.
Update the algorithm to disable and then re-enable paging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use a symbol to select the size of the GDT, rather than hard-coding a
value. This matches how it is done in start64
Signed-off-by: Simon Glass <sjg@chromium.org>
At present it is not possible to execution 64-bit code without
installing an entire new Global Descriptor Table. This is inconvenient
since kvm does not seem to like switching into long mode with a new
table.
It isn't actually necessary, since we can just extend the existing
table. Add some new entries to this effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot clears the display when it starts up, so there is no need to ask
the VESA driver to do this. Fix this and add a comment explaining the
flags.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is not actually defined in Kconfig anymore. Use a normal
debug print instead, which has a similar effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
BSS is placed in DRAM which is actually available early with QEMU. But
it is cleared by the init sequence, so values stored there are lost.
Move the system-type flag into a function, instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
The vesa display is widely used on hardware, but it is a bit of a pain
with QEMU. It requires executing option ROMs, which either doesn't work
with kvm, or is difficult to do in a kvm/QEMU-friendly way.
THe bochs display is probably better anyway, so switch to that. It works
fine with kvm as it doesn't need an option ROM.
Series-changes: 2
- Redo commit message
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/31
The SPL and pre-reloc malloc()-space is not large enough to start up
with a display. Expand it.
Switch the order of SPL_SYS_MALLOC_F_LEN and SPL_TEXT_BASE since this
matches what 'savedefconfig' gives us.
Signed-off-by: Simon Glass <sjg@chromium.org>
We must use the ramdisk address for the initrd_addr field, not the kernel
address. Fix this.
Series-to: u-boot
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: e05cda3004 ("boot: pxe: Refactor label_run_boot() to avoid")
Reviewed-by: Tom Rini <trini@konsulko.com>
When BLOBLIST_TABLES is used, the ACPI tables are not currently added to
the list of EFI tables. While we don't want to create a new memory
region, we do want to tell EFI about the tables.
Fix this by covering this case. At some point the non-bloblist code can
likely be removed.
Series-to: u-boot
Series-cc: Raymond Mao <raymond.mao@linaro.org>
Series-cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 3da59ee957 ("efi_loader: Avoid mapping the ACPI tables twice")
Provide a symbol script to mount the second partition on root.img as an
ext4 filesystem and write a kernel file into it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a way to share a host directory with the guest. It uses the name
hostshare so can be mounted. within the guest, using:
mount -t virtiofs hostshare /mnt
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to boot with a particular disk, either to
install an OS, or to run an existing OS. Add a -d option for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This gets the script to where it can boot with kvm:
- Use -cpu host with kvm so that the host CPU is used
- Show the full QEMU arguments
Signed-off-by: Simon Glass <sjg@chromium.org>
bloblist_find function only returns the pointer of blob data,
which is fine for those self-describing data like FDT.
But as a common scenario, an interface is needed to retrieve both
the pointer and the size of the blob data.
Add a few ut test cases for the new api.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
A bisect of Ubuntu 2022.04 boot-failure on qemu-x86_64 resulted in this
patch. I am not sure how to investigate it.
The boot hangs at some point during booting of the install image, before
the Ubuntu logo appears.
I will sent a series with a script showing how it is run.
Series-to: u-boot
Series-cc: sughosh, trini
This reverts commit a68c9ac5d8.
2025-03-15 14:21:18 +00:00
4 changed files with 18 additions and 10 deletions
"""Test the sleep command, and validate that it sleeps for approximately
the correct amount of time."""
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.