This is a feeble attempt to update the qemu script to run a selection of
UEFI tests. It copies a .seq file into the disk so it can be read by
SCT.
It doesn't seem to work and I am not sure why. I am posting it in case
someone else has ideas or wants to pic it up.
Once Ilias' CI solution is in place, I can perhaps come back to this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This collects together several v3 patches into one, to avoid any
temporary test-breakage which would make future bisecting difficult.
For efi_memory, the efi_allocate_pool() call uses a pointer to refer to
memory, but efi_allocate_pages() uses an int. This causes quite a bit of
confusion, since sandbox has a distinction between pointers and
addresses. Adjust efi_allocate/free_pages_ext() to handle the
conversions.
Update efi_add_memory_map() function and its friend to use an address
rather than a pointer cast to an integer.
For lmb, now that efi_add_memory_map_pg() uses a address rather than a
pointer cast to an int, we can simplify the code here.
For efi_reserve_memory(), use addresses rather than pointers, so that it
doesn't have to use mapmem.
In general this simplifies the code, but the main benefit is that casts
are no-longer needed in most places, so the compiler can check that we
are doing the right thing.
For efi_add_runtime_mmio(), now that efi_add_memory_map() takes an
address rather than a pointer, do the mapping in this function.
Update the memset() parameter to be a char while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This cannot work since the code is not present in the emulated memory.
In any case, sandbox cannot make use of the runtime code.
For now, just drop it from sandbox. We can always adjust things to copy
it into memory, if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
When logging pool allocations, show the address of the pointer, not the
pointer itself. This makes it easier to debug with sandbox
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is passed the address of a void * so update the argument
to match. It is better to have casts in the caller than introduce
confusion as to what is passed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
The word 'physical' suggests that there is an associated virtual address
but there is not. Use 'base' since this is the base address of a region.
Change some uint64_t and remove some brackets to keep checkpatch happy.
Signed-off-by: Simon Glass <sjg@chromium.org>
This struct is really a node in the list, not a list itself. Also it
doesn't need an efi_ prefix. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need a separate struct for the values in this node. Move
everything in together, so that there is just one struct to consider.
Add a comment about physical_start, so it is clear that it is really
a pointer.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is always the same as physical_start, so keeping track of it
separately is unnecessary and confusing. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present efi_memory uses struct efi_mem_desc for each node of its
memory list. This is convenient but is not ideal, since:
- it means that the fields are under a 'desc' sub-structure
- it includes an unused 'reserved' field
- it includes virtual_start which is confusing as it is always the same
as physical_start
- we must use u64 to store pointers, since that is how they are returned
by calls to efi_get_memory_map()
As a first step to tidying this up, create a new, private struct to hold
these fields.
Signed-off-by: Simon Glass <sjg@chromium.org>
Bring in the documentation from the efi_loader.h header file, so we can
see the API defined there.
Fix efi_alloc() to avoid a warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Exported functions should be documented in the header file, not the
implementation. We tend to make such updates on a piecemeal basis to
avoid a 'flag day'. Move some comments related to memory allocation to
follow the convention.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update efi_allocate_pool_ext() to log the pointer returned from this
call, which can be helpful when debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some functions are passing addresses instead of pointers to the
efi_add_memory_map() function. This confusion is understandable since
the function arguments indicate an address.
Make a note of the 8 places where there are problems, which would break
usage in sandbox tests.
Future work will resolve these problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is quite a bit of confusion in the EFI code as to whether a field
contains an address or a pointer. As a first step towards resolving
this, document the memory-descriptor struct, indicating that it holds
pointers, not addresses.
Dro the same for efi_add_memory_map() as it is widely used, as well as
efi_add_memory_map_pg() which is only used by lmb
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini <trini@konsulko.com> says:
Hey all,
This is picking up Simon's v5 of the above-named series and making a few
more changes so that the follow-up series I have leads to arm64 being
supported for almost all jobs. To quote Simon's cover letter:
All gitlab runners are currently amd64 machines. This series attempts to
create a docker image which can also support arm64 so that sandbox tests
can be run on it.
The TARGET_... environment variables for grub could perhaps be adjusted,
using the new variables, but I have not done that for now.
Adding to what Simon said, we now build grub for all architectures as
the reason to install it was to be able to use the binaries in QEMU.
That won't provide us with amd64 binaries on arm64 hosts so we can't use
that shortcut anymore.
Link: https://lore.kernel.org/r/20241127172247.1488685-1-trini@konsulko.com
Refactor the code to support downloading toolchains for arm64 as well as
x86_64
There doesn't seem to be an xtensa toolchain for arm64 at the same
location, so download that only on x86
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Fix a warning due to the syntax used for PYTHONPATH:
LegacyKeyValueFormat: "ENV key=value" should be used instead of
legacy "ENV key value" format (line 304)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
We no longer need to install libc6-i386 so we can drop that. Switch to
installing linux-image-generic as that will be available on all hosts,
to provide the /boot/vmlinu* file that's requires for various tools.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add instructions on how to build the file for multiple architectures.
Add a message indicating what is happening.
Update the documentation as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Instead of deleting /var/lib/apt/lists after each relevant RUN line, use
a cache mount as is the current best practices.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For consistency now, and future ease of testing with non-amd64 hosts,
build grub for all architectures rather than relying on host binaries
for i386/x86_64.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current release of grub is 2.12 and it will be good to pick this up
now so that we can update other parts of our stack.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We had a few places that were not using "make -j$(nproc)" but instead
just plain "make" and so slowing down the overall build.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add in the x86_64 toolchain, but do not enforce using it for sandbox.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since char is unsigned on arm64, this test currently fails. It seems
better to use unsigned anyway, since 0xff is written into the string at
the start. Update the terminator-assert to use a character instead of a
byte.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Changes in v6:
- Re-introduce
Changes in v2:
- Use '\0' instead of 0
test/print_ut.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
The cache-flush function is incorrect which causes a crash in the
remoteproc tests with arm64.
Fix both problems by using map_sysmem() to convert an address to a
pointer and map_to_sysmem() to convert a pointer to an address.
Also update the image-loader's cache-flushing logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 3286d223fd ("sandbox: implement invalidate_icache_all()")
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Changes in v6:
- Re-introduce
Changes in v2:
- Drop message about EFI_LOADER
arch/sandbox/cpu/cache.c | 8 +++++++-
drivers/remoteproc/rproc-elf-loader.c | 18 +++++++++++-------
lib/efi_loader/efi_image_loader.c | 3 ++-
3 files changed, 20 insertions(+), 9 deletions(-)
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Now that we can support a separate devicetree, enable this for the
EFI-app builds.
Drop the Makefile-warning exception since we don't need it anymore.
Signed-off-by: Simon Glass <sjg@chromium.org>
While this is not likely to be used these days, it seems best to keep it
in sync with the 64-bit app. Update the linker script to support a
separate devicetree.
Signed-off-by: Simon Glass <sjg@chromium.org>
While we do plan to switch to OF_SEPARATE now it is supported, it seems
worth at least showing how OF_EMBED could be used instead, just for the
record.
So make the Makefile rule conditional on OF_SEPARATE and adjust fdtdec
to avoid a build error when OF_EMBED is used.
Finally. the dtb symbol has a double underscore, so update it to avoid a
build warning.
With future patches, OF_EMBED will no-longer be used with the EFI app,
so it is expected that it will eventually stop working.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 2e7bf25f6b ("Support separate DTB files with the UEFI app")
The logic in get_details() retrieves the default source directory from
the Labgrid settings. This is convenient for interactive use, since it
allows pytests to be run from any directory and still find the source
tree.
However, it is not actually correct.
Gitlab sets the current directory to the source tree and expects that to
be used. At present it is ignored. The result is that Gitlab builds
whatever happens to be in the default source directory, ignoring the
tree it is supposed to be building.
Fix this by using the directory of the source tree, always. This is
obtained by looking at the grandparent of the conftest.py file.
Series-to: u-boot
Series-cc: trini
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
Fixes: bf89a8f1fc ("test: Introduce the concept of a role")
We may want to make things conditional on EFI variable state
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_bind_block had two issues.
1. A pointer to a the stack was inserted as plat structure and thus used
beyond its life time.
2. Only the first segment of the device path was copied into the
platfom data structure resulting in an unterminated device path.
Signed-off-by: Janis Danisevskis <jdanisevskis@aurora.tech>
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_SYS_BOOT_RAMDISK_HIGH copies the initrd out of the FIT and into
correctly aligned RAM, but the addresses used for this are then discarded
by the x86 bootm code. Fix that.
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Reviewed-by: Simon Glass <sjg@chromium.org>
The UEFI app is an actual executable with things like section headers,
so just gluing the DTB onto the end of it won't work. Add an additional
section to contain this and allocate some space, and then during build
copy the DTB into that section.
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Reviewed-by: Simon Glass <sjg@chromium.org>
