| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Make lmb_free() return -EFAULT when the requested memory region is not
allocated, instead of the generic -1 error value.
Document the updated error code in the public API comment and change the
LMB unit test to check for the new -EFAULT errno value.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Randolph Sapp <[email protected]>
|
|
lmb_alloc_addr() is documented to return -EINVAL when the requested
memory region is not part of the LMB memory map. However, -EINVAL is
also used to e.g. indicate that a NULL pointer is passed as the addr
parameter or when the requested memory region partially overlaps an
existing region.
Change lmb_alloc_addr() to return -EFAULT when the requested memory
region is not part of the LMB memory map to make the type of error known
to callers. Also extend unit tests to validate that the return code has
stay the same when the requested memory region partially overlaps.
No caller of lmb_alloc_addr() is checking what type of error code is
returned, so this change has no intended behavior change.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Randolph Sapp <[email protected]>
|
|
decompression"
Aristo Chen <[email protected]> says:
The dm_test_cmd_zip_gzwrite sandbox test occasionally fails in CI
with:
12582912/16777216
Error: inflate() returned -5
The chunked decompression loop added in commit 58e523fedf48 ("gunzip:
Implement chunked decompression") treats Z_BUF_ERROR from inflate()
as fatal. When an input chunk is exhausted at exactly the same time
as the write buffer fills up, the next inflate() call is made with
avail_in == 0, cannot make progress, and returns Z_BUF_ERROR. Per the
zlib documentation this only means "no progress was possible" and the
call should be repeated with more input, which is what the reference
implementation in zlib examples/zpipe.c does.
The failure needs the consumed/produced byte counts to line up with
both the chunk size and the write buffer size at once, with no
buffered output on the inflate side, which is why only certain random
payloads trigger it. Note that the failure offset above is a multiple
of the 1 MiB write buffer while gzwrite_chunk was SZ_1M + 1.
Patch 1 makes gzwrite() refill the input chunk in this situation.
Patch 2 adds a deterministic regression test which builds a gzip file
from two stored deflate blocks by hand and aligns the chunk boundary
with the write buffer boundary exactly, failing reliably without
patch 1.
Verified on sandbox and sandbox64:
- dm_test_cmd_gzwrite_chunk_boundary fails with -5 in 20 out of 20
runs before the fix, passes 100 out of 100 runs after
- dm_test_cmd_zip_gzwrite fails 17 out of 2000 runs (about 1%)
before the fix, every time with the same signature as the CI
flake, and passes 2000 out of 2000 runs after
- dm_test_cmd_zip_unzip keeps passing
Link: https://lore.kernel.org/r/[email protected]
|
|
The chunked decompression loop in gzwrite() treats any inflate()
return value other than Z_OK and Z_STREAM_END as a fatal error. When
the current input chunk happens to be exhausted at exactly the same
time as the write buffer fills up, the inner loop calls inflate()
again with avail_in == 0. No forward progress is possible in that
state, so inflate() returns Z_BUF_ERROR and gzwrite() bails out:
Error: inflate() returned -5
Per the zlib documentation, Z_BUF_ERROR is not fatal and only means
that no progress was possible; the call should be repeated once more
input is available. The reference implementation in zlib
examples/zpipe.c continues in this exact situation.
The failure is data dependent: it needs a stream position where the
consumed input and produced output line up with both the chunk and
the write buffer boundary at once, and the inflate side must have no
buffered output. That is most likely with incompressible input, where
deflate emits stored blocks and inflate holds no lookahead bits. This
is how dm_test_cmd_zip_gzwrite occasionally fails in sandbox64 CI on
random data with gzwrite_chunk = SZ_1M + 1, stopping at a multiple of
the 1 MiB write buffer:
12582912/16777216
Error: inflate() returned -5
Detect this case and let the outer loop refill the input chunk
instead of failing.
On sandbox64, the random data dm_test_cmd_zip_gzwrite test failed
17 out of 2000 runs (about 1 percent) without this fix, every time
with the same signature as the CI flake, and passed 2000 out of 2000
runs with it.
Fixes: 58e523fedf48 ("gunzip: Implement chunked decompression")
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-net
Pull request net-20260813.
net:
- phy: dp83867: enable extended read / write for driver
- phy: fix duplicate eth_phy binding
- Drop unnecessary device_set_name
- dwc_eth_xgmac: Return -ENODEV when phy_connect() fails
- nfs: clean up bounds checks in nfs_readlink_reply()
- rtl8169: add support for RTL8126A and RTL8127A
- srand_mac(): fix -ENODEV crash with CONFIG_DM_RNG
net-legacy:
- Fix out-of-bounds write in IP fragment reassembly
- test: net: add regression test for IP reassembly overflow
net-lwip:
- Add tftpsrv command
- Handle chained pbufs in transmit path
- sntp: fix netif leak when ntpserverip is unset
- wget: free mbedtls x509 cert context to avoid memory leak
- Fix DHCP fine timer interval
|
|
v7.1"
Alexey Charkov <[email protected]> says:
U-Boot's <linux/math64.h> was last really synced with Linux in 2017 by
commit 0342e335ba88 ("lib: div64: sync with Linux"). Since then it has
only been patched locally twice, and both times in ways that increased
the divergence rather than tracking upstream.
The one that prompted this series is DIV64_U64_ROUND_UP(). Commit
3adc17f60bf8 ("lib: div64: Add support for round up of div64_u64") added
it inside the #if BITS_PER_LONG == 64 branch, whereas upstream defines
it unconditionally after that block, so any 32-bit user fails to build.
While auditing the header, two bugs turned up in lib/div64.c, so this
series starts with those. Both are 32-bit only:
- div64_u64() and div64_u64_rem() shifted by 1 + fls(high) instead of
fls(high), losing a bit of the divisor. Linux fixed this in 2019, while
U-Boot never picked it up.
- div64_s64() used abs() on s64 operands. U-Boot's abs() is not 64-bit
safe: its own comment says to use abs64() instead. Both operands were
silently truncated to 32 bits.
Transitive headers that affect what <linux/math64.h> offers were checked
too. <linux/math.h> and <vdso/math64.h> have no U-Boot equivalent and
are not needed; do_div() comes from U-Boot's <div64.h> in place of
<asm/div64.h>.
Deliberately left out of this resync:
- CONFIG_ARCH_SUPPORTS_INT128 is tested by <linux/math64.h> but isn't
defined anywhere in U-Boot, so the __int128 fast paths for
mul_u64_u32_shr() and mul_u64_u64_shr() are dead code on arm64,
riscv64 and x86_64 where they could have been useful. Wiring it up in
the arch Kconfigs looks like an easy win (but could result in subtle
behavior changes or code size drift, so needs to be approached
separately).
- abs() in <linux/kernel.h> diverges from Linux and is not 64-bit safe.
Patch 2 and patch 5 work around it with abs64() at the two call
sites that need it. Replacing it with Linux's __abs_choose_expr()
version would be the root fix, but changes abs()'s return type from
long to typeof(x) for every caller in the tree.
- abs_diff() lives in <linux/math64.h> here rather than upstream's
<linux/math.h>; it could move to <linux/kernel.h> alongside abs().
- mul_u64_add_u64_div_u64() and the mul_u64_u64_div_u64() macros are
not ported, as they need a u128 type and ~110 lines of
lib/math/div64.c that nothing in U-Boot calls yet.
Build tested with both gcc and clang for evb-rk3288-rk808 (32-bit LE),
generic-rk3576 (64-bit LE), malta (32-bit big-endian, which is what
actually compiles the __BIG_ENDIAN union paths), plus sandbox and
tools-only. No size change on any phase.
Link: https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/pipelines/812
Link: https://lore.kernel.org/r/[email protected]
|
|
Bring the structure of this file in line with Linux v7.1
lib/math/div64.c, so that future resyncs are a near-verbatim diff. No
functional change: the compiled lib/div64.o is byte-identical before and
after, verified by comparing objdump -d output for both
evb-rk3288-rk808_defconfig (32-bit, where these out-of-line helpers are
actually built) and generic-rk3576_defconfig (64-bit).
- Add the SPDX license identifier, as upstream did in commit
b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier
to files with no license").
- Demote the kernel-doc blocks on div64_u64_rem() and div64_u64() to
plain comments and drop the one on div64_s64() entirely, following
upstream commit d28a1de5d112 ("math64: favor kernel-doc from header
files"). The kernel-doc for these lands in <linux/math64.h> in a
later patch of this series; keeping it in both places would only let
the two copies drift apart.
- Guard iter_div_u64_rem() with #ifndef iter_div_u64_rem, matching
upstream, so an arch can override it the same way it can override
the other helpers here.
Two U-Boot-local deviations are kept deliberately and are now marked as
such so that the next resync does not silently drop them:
- __div64_32() carries a no_instrument_function attribute, needed
because CONFIG_TRACE builds with -finstrument-functions and this
function is reachable from tracing code via do_div().
- The includes stay as they are. <linux/compat.h> provides U-Boot's
no-op EXPORT_SYMBOL() in place of upstream's <linux/export.h>, and
<linux/kernel.h> provides abs()/abs64() in place of upstream's
<linux/math.h>, which U-Boot does not have.
The u32/u64 spelling is also left alone rather than converted to Linux's
uint32_t/uint64_t: U-Boot's <div64.h> already made the opposite choice,
and matching Linux here would make the two files inconsistent for no
benefit.
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
__iter_div_u64_rem() is only split out in Linux for its vDSO header, which
has no use in U-Boot. Inline the body of the helper directly into its only
user, which is the iter_div_u64_rem() wrapper in this same file, and drop
the static inline, so that a subsequent resync of include/linux/math64.h
against Linux does not have to carry an exception for it.
include/vdso/math64.h is deliberately not created: its only other resident,
mul_u64_u32_add_u64_shr(), has no U-Boot user.
No functional change: the generated code is identical, verified by
comparing objdump -d of lib/div64.o before and after for
evb-rk3288-rk808_defconfig. The compiler was already inlining the sole
call.
iter_div_u64_rem() itself has no in-tree callers either, but it is
upstream API and is left in place.
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Both operands of div64_s64() are s64, but U-Boot's abs() is not 64-bit
safe. Unlike its Linux counterpart, which dispatches on the argument
type down to long long, U-Boot's abs() evaluates its argument as int
whenever sizeof(x) != sizeof(long) and yields a long.
The header even says so: "abs() should not be used for 64-bit types
(s64, u64, long long) - use abs64() for those."
So on BITS_PER_LONG == 32 both operands are silently truncated to 32
bits before the division. Simulating the macro with long narrowed to
32 bits shows what reaches div64_u64():
x= -4294967296 abs()= 0 abs64()= 4294967296
x= -5000000000 abs()= 705032704 abs64()= 5000000000
x=-9223372036854775807 abs()= 1 abs64()= 9223372036854775807
A zero from the first case makes the subsequent division a divide by
zero rather than merely imprecise.
div64_s64() has no in-tree callers today, so this is a latent bug and
not a regression. Note that the abs() in div_s64_rem() is correct as-is
and deliberately left alone.
Fixes: 0342e335ba88 ("lib: div64: sync with Linux")
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
fls() counts bits starting from 1, so shifting the operands right by
1 + fls(high) discards one more bit of the divisor than intended. Both
functions estimate the quotient from the shifted operands and then fix
it up with a single decrement/increment, so an estimate that is off by
more than one cannot be repaired and the result comes out wrong.
This only affects BITS_PER_LONG == 32, where these are the out-of-line
implementations; on 64-bit the header provides plain C division.
The error is only reachable when the quotient is large, which needs a
divisor just above 2^32. For example:
dividend = 15559272575191414037
divisor = 4333540799
expected = 3590429465
actual = 3590429468 (off by 3)
A sweep over 6.4M random operand pairs, stratified by the width of the
divisor's high word, mismatches a __int128 reference 8260 times before
this change and never after it. All failures have a divisor with one or
two significant bits above bit 32; uniformly random 64-bit divisors are
closer to 2^63 and yield quotients of ~1, which hides the problem.
Port of Linux commit cdc94a374931 ("lib/div64.c: off by one in shift"),
which fixed the same code and cites [1].
In-tree users of div64_u64() that are built for 32-bit targets include
the Aspeed, Meson and Cadence TTC PWM drivers, the Versaclock and
wrpll-cln28hpc clock drivers, and the DWC3 USB core.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202391 [1]
Fixes: 0342e335ba88 ("lib: div64: sync with Linux")
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-snapdragon into next
* Support for building mbn files during the build with the new mkmbn
tool.
* Remove UCLASS_SMEM and the old smem driver (Qualcomm was the only
user of both), replace it with a port of the Linux SMEM driver.
* Refactor memory map parsing and support reading the memory layout from
the SMEM database.
* Set the serial# from SMEM.
* Introduce initial support for SPL in mach-snapdragon.
* Add a defconfig for sm8650 with U-Boot as the primary bootloader.
* Workaround an MMC issue by limiting the transfer size.
* Add support for SM7125/SC7180 (clock/pinctrl drivers and UFS phy).
* Add support for the QCS6490 powered Rubik Pi 3 board and document it.
|
|
Add CONFIG_SPL_OF_LIVE and if set, initialize of_live in spl.c
Signed-off-by: Michael Srba <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
On systems with FWU enabled but without the required DT changes the
boottime checks fail. The failures are only reported via log_debug()
which is compiled out by default, so the user has no idea what is going
on.
Use log_err() to make these failures visible.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
efi_bootmgr_delete_invalid_boot_option(), eficonfig_show_boot_selection(),
and eficonfig_create_change_boot_order_entry() each enumerate all EFI
variables by repeatedly calling efi_next_variable_name() in a loop,
passing the same efi_guid_t as both input and output. GetNextVariableName()
needs the vendor GUID returned by the previous call, together with the
variable name it returned, to know where to resume.
In each of these loops the efi_guid_t was declared inside the loop body,
so a new instance comes into scope on every iteration. Relying on it to
still hold the previous iteration's value depends on the compiler reusing
the same stack slot across iterations, which is undefined behavior. With
a compiler that zero-initializes locals by default (e.g. clang, or gcc
configured with -ftrivial-auto-var-init=zero), the GUID is cleared on
every iteration, so the lookup of the variable name returned by the
previous call fails and efi_init_obj_list() aborts:
Cannot initialize UEFI sub-system
** Booting bootflow ... with efi
Boot failed (err=-22)
Move the efi_guid_t declarations out of the loops so the value written
by the previous efi_next_variable_name() call is preserved across
iterations.
Fixes: 140a8959d48f ("eficonfig: use efi_get_next_variable_name_int()")
Signed-off-by: Scott Moser <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
In case of an error in efi_sigstore_parse_siglist() function
efi_sigstore_free() is called. Currently it fails to free allocated data
because siglist->sig_data_list is not set on the error path.
Always update siglist->sig_data_list when a struct efi_sig_data is
allocated.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc2
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/753
Documentation:
* sandbox: fix enum host_platform_flags description
* switch from setenv to env set and from printenv to env print
* document Renesas R-Car Gen5 RSIP Cortex-R52 start
* thead: lpi4a: detail how to enable fastboot
UEFI:
* unify and correct GUID selection for security database variables
* test: check default GUID selection of security database variables
* set correct frame buffer address
* check efi_deserialize_load_option() in get_dp_device()
|
|
get_dp_device() reads a Boot#### variable and passes its contents to
efi_deserialize_load_option() but ignores the return value. On failure
efi_deserialize_load_option() may return without having initialised the
caller's struct efi_load_option, and even on a malformed device path it
sets lo.file_path before validating it with efi_dp_check_length().
As a result get_dp_device() can proceed to walk lo.file_path with
efi_dp_split_file_path() (via efi_dp_dup()/efi_dp_size()) on a device
path that was never validated, or on an uninitialised pointer when the
variable is too short to be parsed. A device-path node with a length of
zero makes the walk loop forever, and a length below the 4-byte node
header leads to an out-of-bounds read. The Boot#### variable is
attacker-controlled in threat models where writing EFI variables does
not imply the ability to execute firmware code, so this is reachable
during capsule-on-disk processing at boot.
Check the return value and bail out, as every other caller of
efi_deserialize_load_option() already does.
Suggested-by: Hem Parekh <[email protected]>
Cc: Hem Parekh <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
If we use video copy, bit image transfers need to write to the in memory
copy of the physical frame buffer. Damage control will sync the changes
to the physical frame buffer.
Cyclic video copy will catch all changes done by EFI applications directly
accessing the frame buffer copy.
gopobj->mode.fb_base must be a valid pointer to memory and not a virtual
sandbox address.
With this change the block image transfer test works again on the sandbox.
setenv efi_selftest block image transfer
bootefi selftest
Fixes: a75cf70d23ac ("efi: Correct handling of frame buffer")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Re-sync the vendored libavb from AOSP external/avb, moving from the ~2019
snapshot (v1.1.0) to v1.3.0. v1.1.0 rejected any vbmeta whose required
libavb minor version was greater than 1 with UNSUPPORTED_VERSION; this
lifts that ceiling and picks up the accumulated upstream fixes.
Synced from commit a1fe228b8654 ("libavb: support chain partition no ab"),
which is where AVB version 1.3.0 was introduced; the vendored files match
this commit verbatim except for the -Wstrict-prototypes fixup noted below.
For more details check [1].
Functionality now parsed by the library:
- AvbVBMetaImageHeader.rollback_index_location (v1.2)
- AvbChainPartitionDescriptor flags / DO_NOT_USE_AB (v1.3)
- AvbHashtreeDescriptor FLAGS_CHECK_AT_MOST_ONCE
- AVB_HASHTREE_ERROR_MODE_PANIC
The AvbOps callback set is unchanged, so the integration layer in
common/avb_verify.c needs no changes.
U-Boot-specific adaptations are preserved rather than pulling upstream's
BoringSSL-oriented crypto restructure (sha/, boringssl/): the U-Boot port
in avb_sysdeps.h / avb_sysdeps_posix.c and the flat avb_sha.h /
avb_sha256.c / avb_sha512.c are kept as-is. The SHA API signatures are
unchanged, so the retained implementation is compatible with the updated
code.
Imported files keep U-Boot's SPDX-License-Identifier header style
and their upstream per-file licenses (avb_rsa.c stays MIT OR
BSD-3-Clause). The unused, Apache-2.0-licensed avb_crc32.c is not
imported.
The import keeps U-Boot's existing local fix from commit fbfcb614e05
("libavb: Fix a warning with clang-15"): avb_new_cmdline_subst_list() is
kept with a (void) parameter list instead of reverting to upstream's
empty () form, which clang rejects under -Werror,-Wstrict-prototypes.
[1] https://android.googlesource.com/platform/external/avb/+/a1fe228b86543a21739c51352f5ce72f134fccfa
Signed-off-by: Igor Opaniuk <[email protected]>
|
|
The legacy network stack supports tftpsrv, which listens for an
incoming TFTP write request and receives the first file into memory.
Despite the old command help wording, the command returns after
receiving the file and does not boot it automatically.
The lwIP stack already builds the lwIP TFTP application, but only wires
it up for client-side tftpboot. Add a lwIP tftpsrv command and
implement the server path with tftp_init_server(). Reuse the existing
lwIP TFTP write callback and memory copy path so LMB checks, progress
output, filesize/fileaddr updates and EFI bootdev handling stay
consistent with tftpboot.
Track receive timeout and write-failure state around the lwIP callbacks
so a stalled or rejected receive is not reported as a successful close.
Move CMD_TFTPSRV out of the legacy-only Kconfig block so it can be
enabled with either network stack. Update the command help text and add
usage documentation for the receive-only behavior.
Add pytest coverage for tftpsrv using a generated host file and curl's
TFTP upload support. Enable the command in qemu_arm64_lwip_defconfig so
the test can be run with the existing lwIP QEMU build when the boardenv
provides env__net_tftpsrv_file.
Signed-off-by: James Hilliard <[email protected]>
[Jerome Forissier: remove trailing ':' after SPDX tag]
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
This started by me wanting something like what patch 8 does. That
wasn't too hard, except we had no strcasestr(), and also our regex
engine (which I didn't really want to pull into the mix anyway)
doesn't have a flag that requests case-insensitive matching. So I
wanted to add strcasestr(), but then I stumbled on a bunch of stuff
that should be cleaned up in str-land.
Link: https://lore.kernel.org/r/[email protected]
|
|
While this is not likely needed by any "real" driver code, a later
convenience addition to the "config" command will need this. As usual,
the linker will throw it away if nothing actually uses it, so it
should have no size impact when not used.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
None of these six macros are defined by any architecture. Moreover,
the ifndef guard only exists in either string.h or string.c, making them
completely pointless.
I'm not sure whether we have an explicit coding style discouraging the
"extern" qualifier on function declarations, and string.h has a random
mix of everything, but I can't leave it on strncasecmp() now that it
will be immediately after strcasecmp() which doesn't have it.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The last use of this function with rather peculiar semantics[*] vanished
in 2021 with 0a527fda782 ("Fix IDE commands issued, fix endian issues,
fix non MMIO"). It has no tests, and should a need for something
similar ever appear, it is better done with some proper
utf16le/utf16be/utf16 abstractions rather than cluttering code with
'#ifdef __LITTLE_ENDIAN'.
[*] The byte-swapping itself is weird enough. But why is an input string
of odd length ok, while the empty string is not allowed?
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The len parameter for strnstr() concerns the maximum size of the
haystack to consider, not the length of the needle being searched for.
strstr() obviously has no len parameter, so remove the copy-pasta.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Both glibc's (where this originated as a GNU extension) and the
kernel's versions of strchrnul() return "char *", not "const
char *". That also makes it consistent with the standard strchr()
function.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
is set
PK, KEK, db, dbx etc must always be measured in PCR7.
DeployedMode and AuditMode should be measured in PCR1 if DeployedMode
is set and PCR7 otherwise.
Fix the u16_strcmp to only change the PCR value for those two variables.
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
The function defined by the TCG spec looks like:
typedef
EFI_STATUS
(EFIAPI *EFI_TCG2_GET_EVENT_LOG) (
IN EFI_TCG2_PROTOCOL *This,
IN EFI_TCG2_EVENT_LOG_FORMAT EventLogFormat,
OUT EFI_PHYSICAL_ADDRESS *EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS *EventLogLastEntry,
OUT BOOLEAN *EventLogTruncated
);
and the spec mandates that
"If no TPM is present, the function SHALL set the following values and return
EFI_SUCCESS:
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE"
However, if we set it to NULL the local assignment is discarded when the
function returns. Set it to 0, although on some platforms that's a valid
address.
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When doing a sha256_update() for the measured DT, the size arguments for
fdt_size_dt_struct() and fdt_size_dt_strings() are inversed.
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
In efi_sigstore_parse_siglist() sigdata is allocated. But instead of an
allocation matching the size of sigdata, tainted external data was used
to calculate the allocation size. This may lead to buffer overflows.
* Correct the allocation size.
* Follow the man-page. Use the structure size as second argument for
calloc.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Enhance the unit test to verify all Revision fields and all pointers of all
the EFI_BLOCK_IO_PROTOCOL structures.
As the unit test registers its own block io protocol for test purposes,
make sure to initialize its revision properly, as it will be verified as
well.
This can run on the sandbox with the following command:
./u-boot -T -c 'setenv efi_selftest block device; bootefi selftest'
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
In the block device selftest, make the handles pointer global and free it
also in teardown(), to simplify error handling.
We also need to nullify the pointer after freeing it on the normal path,
to avoid freeing it a second time during teardown().
Signed-off-by: Vincent Stehlé <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Since commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
out-of-tree builds with CONFIG_EFI_VARIABLES_PRESEED=y fail with errors
like:
../lib/efi_loader/efi_var_seed.S:14: Error: file not found:
ubootefi.var
For out-of-tree build we cannot use CONFIG_EFI_VAR_SEED_FILE in the
.incbin statement of file efi_var_seed.S.
* We have to prepend $(srctree) if the path is relative.
* We must not prepend $(srctree) if the path is absolute.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
Reported-by: Jon Mason <[email protected]>
Closes: https://lore.kernel.org/u-boot/CAPoiz9zg4OXgHo5J3WtJHKOEuWOdCDrugWfAt6Z+d71j=+q8oA@mail.gmail.com/T/#mffaca10a9e812d03eceafad59999a02e57258b9a
Tested-by: Nora Schiffer <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
We are missing a call to EFI_EXIT() when returning from
efi_disconnect_controller(), which we need after having called EFI_ENTRY().
Fix this by jumping to the common error path, which does call EFI_EXIT().
Even though the common error path may try to free child_handle_buffer, this
cannot harm in our case as it always NULL.
This is inspired by a barebox fix. [1]
Link: https://git.pengutronix.de/cgit/barebox/commit/?id=080db65e39a877b000baaf843c997a69821dfe69 [1]
Fixes: 314bed6c854e ("efi_loader: fix DisconnectController() for sole child")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
PMBus regulators differ in numeric formats and quirks, not in how they
are driven. Share that common behaviour as a regulator-uclass adapter
so chip drivers and the pmbus CLI do not each reimplement the decode
and transport, and add a catch-all driver on compatible = "pmbus" for
compliant chips that have no dedicated driver yet.
Gated by CONFIG_DM_REGULATOR_PMBUS_HELPER and
CONFIG_DM_REGULATOR_PMBUS_GENERIC.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add U-Boot's PMBus 1.x layer: the decoder/transport library, the
pmbus CLI command and a generic DT binding.
The subsequent commits provide the UCLASS_REGULATOR adapter and per-chip
drivers.
U-Boot's PMBus support is not a hwmon clone of Linux's
drivers/hwmon/pmbus/. Linux owns the runtime side (polling, sysfs,
alert IRQs, fan loops). U-Boot owns the boot-time side in order to,
- identify the PMBus regulators a board carries: MFR_ID/
MFR_MODEL/MFR_REVISION + sanity checks.
- print telemetry (VIN/VOUT/IIN/IOUT/POUT/TEMP) so an
operator can confirm rail voltages and faults before the kernel
- decode any chip alerts (STATUS_VOUT/STATUS_IOUT/STATUS_INPUT/
STATUS_TEMPERATURE/STATUS_CML) so a boot log shows why the
previous boot failed or the board had been power cycled because
of an outage (typically over temperature or under current).
Out of scope by design: no periodic polling, no sysfs, no fan-speed
control loop, no PMBUS_VIRT_* sensor virtualisation, no caching.
If a use case needs any of those, the answer should be "wait until
Linux comes up". It shall remain a thin layer.
The constants and structural shape (command codes, status bit names,
sensor-class enum, format enum, struct pmbus_driver_info) are
mirrored from Linux drivers/hwmon/pmbus/pmbus.h verbatim. The
decoders/encoders are reimplemented from the PMBus 1.3
specification because the surrounding hwmon context (struct
pmbus_data, sysfs caching, hwmon publication) does not apply.
The main benefits:
- One framework + CLI for any board carrying PMBus regulators:
no per-board PMBus implementation required anymore.
- Boards call pmbus_print_telemetry() / pmbus_print_status_word()
directly from boot init for a snapshot, sharing all decode +
format-dispatch with the CLI.
- Linux-compatible constants and DT binding so porting an existing
drivers/hwmon/pmbus/ chip is mechanical.
- Boot-time AVS/VID rail trim reuses the same decoders and
encoders as the CLI and the regulator path: no duplicate math.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
|
|
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "lib":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol [1]
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079de8c ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Alexander Graf <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Tom Rini <[email protected]> says:
As part of the resync to dtc version v1.7.2-35-g52f07dcca47c from the
Linux Kernel, we missed updating the fdt_check_full function because it
exists in its own file in upstream dtc and the kernel doesn't import it,
as reported by Anton Ivanov. This short series brings in the upstream
fdt_check.c file and then implements our size-saving option, but in the
modern way.
The size-saving portion has been upstreamed.
Link: https://lore.kernel.org/r/[email protected]
|
|
In the upstream project, the function fdt_check_full has been moved from
fdt_ro.c to its own file, fdt_check.c. This file is not included in the
Linux kernel copy and so has not been synced over. As we do need and use
the fdt_check_full function, bring that file over as of the current
upstream we are synced to. Remove our copy of this function from
fdt_ro.c and add fdt_check.o and 1-liner fdt_check.c where needed. Note
that for now, this will increase size in some cases as upstream does not
have a size reduction method here.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <[email protected]>
Reviewed-by: Jonas Karlman <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
[email protected] <[email protected]> says:
From: Randolph Sapp <[email protected]>
Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
[1]. This does a lot of general setup required for the device, but these
modifications themselves aren't device specific. For those specifically
interested in PocketBeagle2 support and don't care about these details, my
development branch is public [2].
That first patch may provoke some opinions, but honestly if that warning was
still present I wouldn't have spent a week poking holes in both the EFI and LMB
allocations systems. Please let me know if there is a specific usecase that it
breaks though.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
Link: https://lore.kernel.org/r/[email protected]
|
