U-Boot provides multiple EFI applications. The entry point is called
efi_main(). Provide a definition for this function. This avoids
build warnings like
lib/efi_loader/initrddump.c:468:21: warning:
no previous prototype for ‘efi_main’ [-Wmissing-prototypes]
468 | efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
| ^~~~~~~~
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The UEFI specification defines filed UnicodeChar as CHAR16. We use
u16 for CHAR16 throughout our code. The change fixes the following errors:
lib/efi_loader/initrddump.c: In function ‘efi_input’:
lib/efi_loader/initrddump.c:218:38: warning:
comparison is always false due to limited range of data type
[-Wtype-limits]
218 | if (key.unicode_char >= 0xD800 && key.unicode_char <= 0xDBFF)
| ^~
lib/efi_loader/initrddump.c:218:68: warning:
comparison is always true due to limited range of data type
[-Wtype-limits]
218 | if (key.unicode_char >= 0xD800 && key.unicode_char <= 0xDBFF)
| ^~
Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Reported-by: Marek Vasut <marex@denx.de> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masahisa Kojima [Thu, 2 Feb 2023 13:53:35 +0000 (22:53 +0900)]
efi_loader: update attribute check for QueryVariableInfo()
Current U-Boot supports two EFI variable service, U-Boot own
implementation and op-tee based StMM variable service.
With ACS Security Interface Extension(SIE) v22.10_SIE_REL1.1.0,
there are several failure items of QueryVariableInfo().
Current attribute check for QueryVariableInfo() was implemented
based on the Self Certification Test (SCT) II Case Specification,
June 2017, chapter 4.1.4 QueryVariableInfo().
This test case specification is outdated and don't align at all
with the SCT test case code, and UEFI specification v2.10 does
not clearly define the priority of the attribute check.
For U-Boot standard case that EFI variables are stored in a file
in the ESP, this commit modifies the attribute check to get align
to the EDK2 implementation.
For latter case(op-tee based StMM variable service), parameter check
should be delegated to StMM.
Now all ACS SIE QueryVariableInfo() test cases passed both EFI variable
storage implementations.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masahisa Kojima [Thu, 2 Feb 2023 09:24:45 +0000 (18:24 +0900)]
eficonfig: set EFICONFIG_ENTRY_NUM_MAX to INT_MAX - 1
eficonfig_append_menu_entryi() accepts the number of entries
less than or equal to EFICONFIG_ENTRY_NUM_MAX.
EFICONFIG_ENTRY_NUM_MAX is currently set as INT_MAX, so
the invalid menu count check(efi_menu->count > EFICONFIG_ENTRY_NUM_MAX)
in eficonfig_process_common() is always false.
This commit sets EFICONFIG_ENTRY_NUM_MAX to (INT_MAX - 1).
Reported-by: Coverity (CID 435659) Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masahisa Kojima [Sat, 28 Jan 2023 04:56:14 +0000 (13:56 +0900)]
efi: use 32-bit alignment for efi_guid_t
Current U-Boot implements 64-bit boundary for efi_guid_t structure.
It follows the UEFI specification, page 21 of the UEFI Specification v2.10
says about EFI_GUID:
128-bit buffer containing a unique identifier value. Unless
otherwise specified, aligned on a 64-bit boundary.
On the other hand, page 163 of the UEFI specification v2.10 and
EDK2 reference implementation both define EFI_GUID as
struct { u32 a; u16; b; u16 c; u8 d[8]; }; and so the implied
alignment is 32-bit not 64-bit like U-Boot efi_guid_t.
Due to this alignment difference, EDK2 application "CapsuleApp.efi -P"
does not work as expected.
This calls EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo()
and dump the EFI_FIRMWARE_IMAGE_DESCRIPTOR structure,
offsetof(EFI_FIRMWARE_IMAGE_DESCRIPTOR, ImageTypeId) is different,
8 in U-Boot and 4 in EDK2(CapsuleApp.efi).
Here is the wrong EFI_GUID dump.
wrong dump : ImageTypeId - 00000000-7D83-058B-D550-474CA19560D8
expected : ImageTypeId - 058B7D83-50D5-4C47-A195-60D86AD341C4
EFI_FIRMWARE_IMAGE_DESCRIPTOR structure is defined in UEFI specification:
typedef struct {
UINT8 ImageIndex;
EFI_GUID ImageTypeId;
UINT64 ImageId
<snip>
} EFI_FIRMWARE_IMAGE_DESCRIPTOR;
There was the relevant patch for linux kernel to use 32-bit alignment
for efi_guid_t [1].
U-Boot should get aligned to EDK2 reference implementation and
linux kernel.
Due to this alignment change, efi_hii_ref structure in include/efi_api.h
is affected, but it is not used in the current U-Boot code.
Device name are typically longer than 8 characters. This leads to ragged
output.
Only the I and O bit of the device flags are of interest for the user.
Writing a hexadecimal number is just confusing.
- Correct my mistake with defaulting to not setting LMB_USE_MAX_REGIONS,
and fix the lmb test to scale with more than 8 regions before setting
the new default to 16 regions. This doesn't strictly fix all issues,
but puts us ahead of where we were.
Sjoerd Simons [Thu, 19 Jan 2023 08:38:17 +0000 (09:38 +0100)]
Bump LMB_MAX_REGIONS default to 16
Since commit 06d514d77c37 ("lmb: consider EFI memory map") the EFI regions
are also pushed into the lmb if EFI_LOADER is enabled (which is by
default on most system). Which can cause the number of entries to go
over the maximum as it's default is only 8.
Specifically i ran into this case on an TI am62 which has an fdt with
4 reserved regions (in practice 3 lmb entries due to adjecent ranges).
As this is likely to impact more devices bump the default max
regions to 16 so there is a bit more slack.
Fixes: 06d514d77c ("lmb: consider EFI memory map") Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562 Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
[trini: collect tags from the other equivalent patch]
Tom Rini [Wed, 8 Feb 2023 18:39:18 +0000 (13:39 -0500)]
test: lmb: Rework lib_test_lmb_max_regions test to scale
First, this test depends on CONFIG_LMB_USE_MAX_REGIONS, so add that as a
test before building. Second, instead of using a hard-coded value of 8,
which is the default of CONFIG_LMB_USE_MAX_REGIONS previously, use that
directly and update the comments. The only trick here is that one part
of the test itself also was written with the value of 8 itself in mind.
Rework the size of the lmb region we allocate to scale with the value of
CONFIG_LMB_USE_MAX_REGIONS.
Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Wed, 8 Feb 2023 15:18:26 +0000 (10:18 -0500)]
Revert "lmb: Default to not-LMB_USE_MAX_REGIONS"
As explained by Philippe Schenker, I was misinterpreting what happened
in the case where we do not set LMB_USE_MAX_REGIONS and so had
re-introduced the problem I was attempting to more widely resolve.
To quote the author:
This series adds source scanning to moveconfig.py so that it can look
for Kconfig options mentioned in the source which do not appear in
Kconfig, and vice versa.
This tool is then used to clean up the unused or obsolete options
mentioned in Makefiles, along with any attached source code.
Simon Glass [Wed, 1 Feb 2023 20:19:12 +0000 (13:19 -0700)]
moveconfig: Add an option to compare Kconfig against source
Sometimes the Makefile rules or source code refers to Kconfig options
which don't exist. Update the moveconfig tool to check this and produce
a series of reports about inconsistencies.
This can then be used to generate patches to correct the problems.
Tom Rini [Tue, 7 Feb 2023 16:42:26 +0000 (11:42 -0500)]
Merge branch '2023-02-07-assorted-updates'
- Default to dynamic LMB allocation, and fix an issue with the EFI one,
assorted TI platform updates, socrates platform updates, switch
qemu-arm to using bootstd, imagetool fixes, macOS host build fixes,
keymile platform upates, spl FPGA load fix, MMC env bugfix, add seama
command, usb bootdev test bugfix.
Linus Walleij [Tue, 31 Jan 2023 23:16:13 +0000 (00:16 +0100)]
cmd: Add a SEAMA image load command
Add a command to load SEAMA (Seattle Image), a NAND flash
on-flash storage format.
This type of flash image is found in some D-Link routers such
as DIR-645, DIR-842, DIR-859, DIR-860L, DIR-885L, DIR890L and
DCH-M225, as well as in WD and NEC routers on the ath79
(MIPS), Broadcom BCM53xx, and RAMIPS platforms.
This U-Boot command will read and decode a SEAMA image from
raw NAND flash on any platform. As it is always using big endian
format for the data decoding is always necessary on platforms
such as ARM.
The command is needed to read a SEAMA-encoded boot image on the
D-Link DIR-890L router for boot from NAND flash in an upcoming
port of U-Boot to the Broadcom Northstar (BCM4709, BCM53xx)
architecture.
A basic test and documentation is added as well. The test must
be run on a target with NAND flash support and at least one
resident SEAMA image in flash.
Ye Li [Tue, 31 Jan 2023 06:41:58 +0000 (14:41 +0800)]
env: mmc: Fix offset issue for env save
Fix the issue in commit 46c9016 ("env: mcc: Drop unnecessary #ifdefs")
If CONFIG_SYS_REDUNDAND_ENVIRONMENT is not defined, the offset value
becomes undetermined, so write env to unexpected offset.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Pali Rohár [Sun, 29 Jan 2023 16:44:11 +0000 (17:44 +0100)]
tools: default_image: Accept images with padding
If image file is stored on flash partition then it contains padding, which
is not part of the image itself. Image data size is stored in the image
header. So use image size from the header instead of expecting that total
image file size is size of the header plus size of the image data. This
allows dumpimage to parse image files with padding (e.g. dumped from flash
partition).
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log