Rather than having this code mixed with the tests, it seems better to
put it up one level. Move the directory and tidy up references.
Signed-off-by: Simon Glass <sjg@chromium.org>
This can indicate that something is horribly wrong. It seems better to
abort, rather than just print a message which might not be noticed.
If the mapping does not map exactly, abort.
Series-to: concept
Cover-letter:
sandbox: Fix memory corruption around 1MB
After many hours of debugging, it turns out that the PCI EA driver is
mapping itself into RAM at 1MB. This happens to be where the kernel
ends up, with the vbe_abrec_os bootmeth. Since measurement is enabled,
bootm_measure() calls map_sysmem() on the kernel in order to measure it.
easurement takes place, although of course using the wrong data. Then,
through a strange sequence of events, which I have found very hard to
narrow down, the malloc() heap is corrupted.
This series provides a fix.
To repeat this problem:
NO_LTO=1 ./test/py/test.py --bd sandbox --build -k
"(ut or vbe) and not efi and not slow and not dm"
which dies when running vbe_test_abrec_oem_norun:
...
=> echo $?
0
=> host bind 0 [...]/build-sandbox/persistent-data/vbe1.img
=> ut -f bootstd vbe_test_abrec_oem_norun
Test: bootstd_setup_for_tests: bootstd_common.c
common/dlmalloc.c:793: do_check_free_chunk:
Assertion `next->prev_size == sz' failed.
resetting ...
With this series, the above now passes.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the sizes to the expected size of the device's mapping in each
case, to avoid a warning in map_physmem() about a partial map.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the size to the expected size of the device's mapping, to avoid
a warning in map_physmem() about a partial map.
Signed-off-by: Simon Glass <sjg@chromium.org>
The address chosen for testing this feature is 1MB which is part of the
sandbox RAM. When devices access this, e.g. with map_sysmem(), the
memory is mapped to a PCI device. Any changes then apply to that device
and are not written to memory. Reads also come from the device.
It is not safe to use RAM space in this way.
A symptom that something is wrong is the log message:
map_physmem: Warning: partial map at 100000, wanted 4, got 2000
Move the memory out of the way and document it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 21ebbafde8 ("test: dm: Add a test for PCI Enhanced Allocation")
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Series-to: concept
Cover-letter:
test: Move towards using a fixture for test images
There are quite a few test images created by the test system. Most are
needed for bootstd tests.
At present these are created by a test, called test_ut_dm_init_bootstd()
which runs before the test_ut() tests.
This means that it is possible to create the images once, then iterate
on a test without the images being recreated each time.
While this is not a terrible approach, it does have some drawbacks:
- If an image is missing or corrupted for some reason, the test fails
- The relationship between the images and the tests is not obvious
- Images are often created even if the tests to be run do not need them
Overall, it seems worthwhile to explore moving to using a fixture for
the images.
Another problem is that 'make qcheck' and 'make pcheck' are not tested
in CI, so can break over time. The latter is a good way of seeing
whether each test is independent, e.g. not reliant on files created by
another test.
Overall this area of U-Boot could use some attention. This series makes
a very small start on this:
- Update test_fdt_add_pubkey() to work without test_vboot_base()
- Fix 'make qcheck' so that it passes
- Minor fixes to a few tests
- Pass separate fixtures to the image-setup functions instead of the
overall ubman fixture
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass in the two fixtures this function actually requires, rather than
ubman, which is a function-scoped fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
The normal function requires a ubman but only uses it to find the log
fixture. This is a pain since the ubman is a function-level fixture.
Provide a version that takes a log directory, so that it can be called
from a session fixture.
Signed-off-by: Simon Glass <sjg@chromium.org>
This test should create its own files rather than relying on those
created by test_vboot_base(). Copy the code in the test.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present test_fdt_add_pubkey() relies on the vboot test having already
run, since its makes use of the files that test produces.
This means that the tests cannot run in parallel (make pcheck).
As a first step to resolving this, move the required common code out to
a standalone function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that this base-class function is called, it can produce an error on
test failure, since it passes an empty list for the arguments.
Rename the reset() function to prepare_for_spawn() and use that instead.
See also: ca30385c61 ("Correct implementation of Spawn() in ConsoleBase")
Signed-off-by: Simon Glass <sjg@chromium.org>
The VBE test uses fdt_util to compile a devicetree.
Other tests log the output of the dtc tool, which can be helpful when
a test fails.
For reasons which are unclear, using fdt_util means that the path to dtc
ends up being './scripts/dtc/dtc' when run from 'make qcheck'. This
causes a failure to set up the image required for the VBE test.
Update the test to use the normal run_and_log() method instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
The bootflow contains fields which are connected to the struct. It
should be freed when it is finished with.
It isn't exactly clear why this fixes the problem, which shows up as:
=> ut -f bootstd vbe_test_abrec_oem_norun
Test: bootstd_setup_for_tests: bootstd_common.c
common/dlmalloc.c:793: do_check_free_chunk:
Assertion `next->prev_size == sz' failed.
Fix it by adding a bootflow_free() at the end, which is good practice in
any case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 07f5b96985 ("boot: test: Add a test for the VBE OS flow")
When LTO is used it seems to miss some line-number information, so the
event_dump.py tool does not fully work, thus causing test_event_dump to
fail.
Disable LTO to prevent this problem. It speeds up the build in any case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new board which can run the EFI app and boot an OS.
Series-to: concept
Series-cc: heinrich
Series-version: 2
Cover-letter:
efi: Support booting an OS with the EFI app on ARM
The ARM EFI app does not successfully boot an OS at present. This series
includes patches to allow it to boot an OS via extlinux:
The main changes are:
- Call exit-boot-services before jumping to the OS
- Write the physical-memory info to the FDT
- Tidy up some Kconfig options
- Improve keyboard compatibility
Note that QEMU 8.2 does not boot Ubuntu 24.04 with this series[1]. The
kernel dies quite early with:
ERROR:target/arm/internals.h:767:regime_is_user: code should not be reached
Bail out! ERROR:target/arm/internals.h:767:regime_is_user: code should not be reached
QEMU 9.2 resolves this problem.
[1] https://lists.opensuse.org/archives/list/bugs@lists.opensuse.org/
message/XVO4M4LDEFOORP5M4ZFINZDX36DWO3G5/
END
Signed-off-by: Simon Glass <sjg@chromium.org>
The video sync sometimes takes 8ms on this board when running under
emulation, so increase the limit to 15ms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Before booting using extlinux we must add the memory map to the FDT.
Provide a ft_system_setup() function to handle this.
To determine the memory size, scan the memory map looking for entries
that look like real memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
When booting an OS with a large ramdisk, we need enough memory to load
it. Expand the app's memory to 512M to allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
When extlinux is used, the boot partition is often 2, which is ignored.
Use the 'bootflow scan' -p flag to resolve this.
Signed-off-by: Simon Glass <sjg@chromium.org>
The conversion to using an event was not done correctly, with the
result that it has no effect. Fix it, by passing in the length and
actually using the returned address.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 207bf34de7 ("boot: efi: Use an event to relocate the OS")
When running under QEMU the FDT is available at the start of RAM. Set
fdt_addr to this address, so that the FDT can be passed onto the OS.
If the OS provides its own devicetree, that is used instead of the QEMU
one.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the app is booting a kernel without using EFI, it must first exit
the boot services provided by EFI. Add a hook for this, using
bootm_final()
Signed-off-by: Simon Glass <sjg@chromium.org>
It is common to run the EFI app without a display, e.g. for testing.
Drop the unwanted warnings about this:
EFI graphics output protocol not found (err=-524)
No video mode configured in EFI!
Signed-off-by: Simon Glass <sjg@chromium.org>
It is sometimes useful to display the memory type in logs, etc. Add a
function to convert it to a string, which is more user-friendly than a
number.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'efi mem' command dumps out the memory map. This is useful within
the app, even if commands are not enabled, so move it to a common file.
Rename it from 'print' to 'dump' since most things that dump information
use that word.
Signed-off-by: Simon Glass <sjg@chromium.org>
We can never hope to have a definitive list of GUIDs, but add four more,
discovered when booting from QEMU on ARM.
Signed-off-by: Simon Glass <sjg@chromium.org>
The declarations in efi_api.h are inconsistent. Tidy them up, so that
the final 8 bytes appear on their own line aways.
Signed-off-by: Simon Glass <sjg@chromium.org>
The EFI serial driver checks for keypresses but does not allow other
events to be processed. For devices which have a USB keyboard, the USB
message must be processed before any keys can emerge for the serial
driver to pick up.
Add a periodic timer to the list of events. This allows the keyboard to
work on Qualcomm laptops, for example.
Series-changes: 2
- Add a comment to serial_efi_get_key() about the 1ms delay
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not called from the app at present. Even if it were, it
would be called later, after stdio is working, so there is no need to
use printhex2() and the like.
Move the function into the stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
When running in CI it is better to specify the build directory rather
than provide a device. Add a --build-dir option.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases a board may wish to do some final processing before
starting the OS. An example is the EFI app, which may wish to call
exit-boot-services.
Add an event to permit this.
Series-to: concept
Cover-letter:
boot: Allow lmb-allocation of compression buffer with booti
ARM 'booti' images (as created by Linux 'make Image') typically need to
be compressed. At present the decompression buffer is described by a
pair of environment variables: kernel_comp_addr_r and kernel_comp_size
This is quite inflexible, since the buffer size and location must be
pre-set in the environment, before the OS size is known.
For the EFI app, it is quite difficult to work with a fixed buffer. It
is not in control of the memory map so it may be that the requested
buffer address is not available.
This series updates the boot implementation to allow the variables to
be omitted, with lmb allocations done in this case. This resolves the
problem in the EFI app, with kernels which come from extlinux.conf
When the EFI app loads another app, a similar problem is present, but
with the EFI bootmeth, also resolved in this series.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Unfortunately no one else has taken up this migration. For now, reword a
a comment to more correctly describe what the event uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
