The boundary checks in airoha_clk_enable(), airoha_clk_get_rate(), and
airoha_clk_set_rate() use "id > data->num_clocks" which allows id equal
to num_clocks to pass. Since data->descs[] has exactly num_clocks entries
(indices 0 to num_clocks-1), id=num_clocks results in an out-of-bounds
array access.
This is currently not triggered because the device tree clock IDs are
within bounds, but the check should be defensive. Fix by changing the
comparison from ">" to ">=".
Fixes: d0b81afb5e ("clk: airoha: Add support for Airoha AN7581 SoC clock")
Signed-off-by: Wayen Yan <win847@gmail.com>
Now that we have made bloblist have distinct "find" and "create"
functions, the global data tag "GD_FLG_BLOBLIST_READY" doesn't quite
make sense anymore. Rename it to GD_FLG_BLOBLIST_HANDOFF.
Suggested-by: Raymond Mao <raymondmaoca@gmail.com>
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
I had missed that this series was no longer ready to merge as there are
other issues to resolve.
This reverts commit a5ef184939, reversing
changes made to 4e7a9bb088.
Signed-off-by: Tom Rini <trini@konsulko.com>
On STM32MP157C-DK2, when using the "ums" command, in sleep_thread(),
ctrlc() is called every ~640ms which doesn't allows high reactivity when
user press CTRL+C in U-Boot console.
In sleep_thread() loop, ctrlc() is called every 200000 iterations.
But schedule is called on each loop iteration.
Optimize cyclic_run() in order to not call get_timer_us() on each entry.
This allow to save computation time :
_ before : ctrlc() is called every ~640ms
_ after : ctrlc() is called every ~230ms
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Vasut <marek.vasut@mailbox.org>
For new patch, b4 is suggested to replace type 'uint64_t' by 'u64' :
CHECK: Prefer kernel type 'u64' over 'uint64_t'
Update cyclic.c accordingly in order to be coherent with following commit.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Aristo Chen <aristo.chen@canonical.com> says:
vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on
a block device and then issues a follow-up blk_read() to pull in the
image, and optionally an FDT, referenced by the FIT's image node. The
source offset on the device and the read length both come from the FIT
itself, via data-position or data-offset and data-size. Those properties
live on mutable boot media and can be controlled by an attacker with
write access to the firmware area. On the TPL or VPL path, and on the
bootmeth bootflow path reached via abrec_read_bootflow_fw() and
vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any
signature or hash check on the loaded phase.
Patch 1 is a sandbox test-tree preparation. The firmware1 node in
arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but
the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT
inside it carries ~16 MiB of external data, so the FIT already extended
past the declared area. The mismatch was tolerated because no caller
bounded the external-data load against area_size. Patch 1 raises
area-size to match the binman section size so test_vbe_vpl keeps passing
once the bound is enforced. The patches are ordered so the test is never
broken in the middle of the series.
Patch 2 adds the missing range check, confining the FIT-supplied
[load_addr, load_addr + len) window to [addr, addr + area_size] before
block numbers and lengths are computed, and applying the same constraint
to fdt_load_addr and fdt_size. The check is written in subtraction-only
form against the trusted area_size so the comparison cannot itself
overflow.
Patch 3 adds two sandbox unit tests under test/boot/ that construct
synthetic FITs with out-of-range data-position and oversized data-size,
write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each
before issuing the follow-up blk_read().
Deferring the external-data blk_read() until after the phase has been
signature-verified would be a stronger structural fix and was discussed
on the v1 thread. Simon confirmed the bounded read is the right first
step and that the verify-then-load change should be a separate series,
so this v3 stays scoped to the bound.
Link: https://lore.kernel.org/r/20260705034414.2247-1-aristo.chen@canonical.com
vbe_read_fit() rejects FITs whose external-data window extends past the
trusted firmware area on disk by returning -E2BIG. Add two sandbox unit
tests that construct synthetic FITs with attacker-controlled
data-position and data-size values, write them to mmc1, and assert
vbe_read_fit() catches each one before issuing the follow-up
blk_read().
vbe_read_fit_oob_position uses a data-position past area_size, which
trips the load_addr - addr > area_size clause. vbe_read_fit_oversize_data
keeps data-position inside the area but picks a data-size that overruns
area_size - (load_addr - addr), tripping the third clause.
The two remaining bound clauses stay unreachable from a sandbox test.
The load_addr < addr guard trivially holds when addr comes from
CONFIG_VAL(TEXT_BASE), which is 0 on sandbox, and the FDT-region bound
sits behind a !CONFIG_SANDBOX guard in vbe_read_fit(), so fdt_size stays
0 and that block is skipped in this test environment.
The new file follows the existing bootstd VBE test layout and writes
the FIT at block 16, past the version and nvdata blocks already used by
bootstd_setup_for_tests().
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
vbe_read_fit() loads a firmware-phase FIT from the trusted firmware area
and then issues a blk_read() to pull in the image, and optionally an
FDT, referenced by the FIT image node. The source offset on the device
and the read length both come from the FIT's data-position or data-offset
property and its data-size property, which live on mutable boot media
and can be controlled by an attacker with prior write access to the
firmware area.
Without a range check the resulting blk_read() can read past the
firmware area on the device and, on the non-SPL path, write an
attacker-chosen number of blocks past the malloc(aligned_size) FIT
buffer into adjacent memory. Only the SPL branch routes through
spl_load_simple_fit(), which hashes the data. The external-data block
reached from TPL or VPL, and from the bootflow path via
abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), runs before
any signature or hash check on the loaded phase.
Confine the FIT-supplied [load_addr, load_addr + len) window to
[addr, addr + area_size] before computing block numbers and lengths,
and apply the same constraint to fdt_load_addr and fdt_size. The checks
are written in subtraction-only form against the trusted area_size so
the comparison itself cannot overflow.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
The firmware1 node in test.dts declares area-size = 0xe00000 (14 MiB)
but the binman fw-update section in sandbox_vpl.dtsi is 0x2000000
(32 MiB) and the FIT inside it carries ~16 MiB of external data
(spl + u-boot subimages). The FIT therefore extends past the
declared firmware area, contradicting the documented contract of
vbe_read_fit() that the FIT must fit within @area_size.
The mismatch was tolerated because no caller actually bounded the
external-data load against area_size. Bring the devicetree in line
with the binman section size so the FIT extent stays within the
trusted firmware area, in preparation for vbe_read_fit() enforcing
that bound.
state-offset and version-offset are left as-is; they were already
inside the FIT data region and are not exercised by test_vbe_vpl.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Paresh Bhagat <p-bhagat@ti.com> says:
This series adds support for DM firmware reserved memory fixup in device
tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled).
The series includes:
1. Fix for phandle corruption in FDT reserved memory fixup
2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups
3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs
4. Add DM reserved memory fixup implementation
The main issue being addressed is that the current reserved DDR carveout
for DM firmware in device tree is insufficient to accommodate the DM
firmware binary on AM62A7, and potentially other K3 SoCs in the future.
Currently, the size is only modified for AM62A7 SoC. For rest of SocS
existing values from device tree is taken.
For vendor boards, please verify boot and check for errors if any.
This series depends on dts update for effected devices. If "dm" node is
not found then the existing mechanism creates a new node with same
address, which cause memory overlap issue.
Link: https://lore.kernel.org/r/20260701075021.3626094-1-p-bhagat@ti.com
Add support for fixing up DM firmware reserved memory in the kernel
device tree for K3 SoCs that use separate DM firmware.
The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and
CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the
reserved-memory node with the correct DM firmware carveout.
Note that the fixup needs DM reserved memory node is to be renamed in
dts. Example memory@9c900000 → dm@9c900000
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Add Kconfig options for DM firmware reserved memory for K3 SOCs that
support DM firmware (K3_DM_FW enabled)
- K3_DM_FW_RESERVED_ADDR: DM firmware address
- K3_DM_FW_RESERVED_SIZE: DM firmware reserved size
These configs will be used to fixup the kernel device tree's reserved
memory node for DM. Currently the fixup is only done for AM62A7 SoC, as
K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from
0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to
accommodate the binary.
For other platforms, the addresses and sizes are based on the existing
device tree reserved memory. If needed for other SoCs, address and size
could be modified in Kconfig.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to
the dtb before passing to kernel.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Fix phandle corruption in fdt_fixup_reserved_memory()
The original implementation used a delete/recreate approach:
- Find existing reserved memory node (e.g. tfa@80000000)
- Delete the entire node with fdt_del_node()
- Create new node with fdtdec_add_reserved_memory()
This worked fine for ATF and OPTEE nodes because no other device tree
nodes reference them via phandles but other nodes example DM are
referenced by R5 nodes.
If these nodes are deleted and recreated, it will not have any phandle
property but the nodes referencing it will still contain the old
phandle, causing initialization to fail.
Update nodes in-place instead of delete/recreate to update only the
"reg" property using fdt_setprop().
Fixes: 8b0fc29de0 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT")
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Aristo Chen <aristo.chen@canonical.com> says:
The AM62x family (TI EVMs, phytec phycore, toradex verdin) ships
two or three mutually-exclusive tifsstub variants per tispl.bin FIT
image (tifsstub-hs, tifsstub-fs, tifsstub-gp), all assigned the same
load address 0x9dc00000. The current platform code loads every
variant and discards the wrong ones at runtime by zeroing *p_size in
board_fit_image_post_process() (arch/arm/mach-k3/r5/common.c).
This runtime-filter approach has become a friction point. An earlier
attempt to add FIT-image load-address overlap detection to mkimage
flagged the shared 0x9dc00000 as an apparent conflict, and the
workaround in that series was to shift each tifsstub by 64KB
increments. Bryan Brattlof reviewed that change at the time [1] and
pointed out that the real semantics are "load one of three at
runtime", and that moving the binaries was not necessarily safe given
downstream IPC assumptions about the fixed load address. The series
was ultimately reverted upstream, which leaves the underlying
question open: any future static FIT validator needs a way to
understand that these three images do not actually collide. The same
point is being discussed at the spec level in flat-image-tree issue
#32 [2], where a "mutually-exclusive-group" property has been floated
to express runtime-resolved overlaps to static tooling.
This series fixes the problem structurally without moving any
binaries and without a spec extension. Each board's binman dtsi is
updated so the tispl.bin FIT carries one configuration per security
state (conf-hs-se, conf-hs-fs, conf-gp), each containing only the
matching tifsstub. board_fit_config_name_match() in each affected
board reads the SoC security state via get_device_type() and selects
the correct configuration up front, via a shared helper
k3_fit_config_match_security_state() added in arch/arm/mach-k3/
common.c. Each FIT configuration ends up with exactly one tifsstub at
0x9dc00000, so the overlap goes away from any static validator's
perspective and no platform-specific runtime knowledge is needed to
pick the right firmware.
Series ordering is intentional and bisectable. Patch 1 introduces
the helper, migrates the TI EVMs, and leaves the runtime filter in
place. Phytec phycore and toradex verdin boards still use their old
single-config dtsi at this point, and the runtime filter continues
to do the right thing for them in the meantime. Patch 2 migrates the
phytec phycore-am62 SoMs. Patch 3 migrates the toradex Verdin AM62
modules; their previous board_fit_config_name_match() returned 0
unconditionally, which after the dtsi split would have selected the
first listed configuration regardless of silicon and broken HS-SE
parts, so this patch is also a latent-bug fix on top of the migration.
Patch 4 drops the now-dead runtime filter.
Changes since v1, all addressing review feedback from Anshul Dalal:
1. Patch 1: use strncmp() in k3_fit_config_match_security_state()
instead of strcmp() with a redundant ternary, since the suffix
length is already known.
2. Patches 1, 2 and 3: drop the CONFIG_SPL_LOAD_FIT #if guard
around board_fit_config_name_match() on the TI EVM, phycore
and verdin boards. SPL_LOAD_FIT is always selected on ARCH_K3
and LTO drops the function in any build that does not use it.
3. The move of enum k3_device_type and get_device_type() from
arch/arm/mach-k3/common.h to arch/arm/mach-k3/include/mach/
hardware.h in patch 1 is kept as-is. common.h is currently
mach-k3-internal and is not in the include search path for
board files; making it public would be a larger refactor that
Anshul has offered to take on separately [3].
Patch 4 is unchanged from v1; Acked-by from Neha Malcom Francis and
Reviewed-by from Anshul Dalal collected on v1 are carried forward.
Patch 1 has small non-behavioral changes vs v1, so v1 tags from
Alexander Sverdlin (Reviewed-by), Neha Malcom Francis (Acked-by),
and Akashdeep Kaur (Tested-by) are not carried forward and are
pending re-confirmation against v2.
Boot tested on AM625 SK GP silicon end-to-end through TFA, OP-TEE,
A53 SPL, U-Boot proper, and Linux 6.5. The two "Skipping
authentication on GP device" messages in the SPL banner confirm only
the GP tifsstub variant is present in the selected FIT
configuration; loading any HS variant on GP silicon would fail TIFS
authentication before reaching that point. Building (R5 SPL + A53
SPL + U-Boot proper) was verified clean against v2 on am62x_evm,
phycore_am62x, and verdin-am62 defconfigs.
Akashdeep Kaur tested v1 on AM62PX HS-FS and AM62X HS-SE devices,
including deep-sleep suspend/resume. v2 changes are non-behavioral
so the same code paths exercise as v1, but explicit re-test on v2
would be welcome.
[1] https://lore.kernel.org/u-boot/20250916122244.a7rda2ouhou47hp7@bryanbrattlof.com/
[2] https://github.com/open-source-firmware/flat-image-tree/issues/32
[3] https://lore.kernel.org/u-boot/DJG933DITHOO.G8ER04I2UPWX@ti.com/
Link: https://lore.kernel.org/r/20260623141540.618272-1-aristo.chen@canonical.com
With all AM62x family boards (TI EVMs, phytec phycore, toradex
verdin) now using per-security-state FIT configurations and selecting
the right one via board_fit_config_name_match(), the runtime filter
in board_fit_image_post_process() that zero'd out *p_size for the
wrong tifsstub variant is no longer reached. Only one tifsstub
variant is present in the selected FIT configuration, and it is
always the correct one for the current silicon.
Drop the filter so board_fit_image_post_process() simply debug-logs
the variant name and returns.
Acked-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on Verdin AM62 and AM62P
SoMs at FIT config selection time.
The k3-am625-verdin-wifi-dev-binman.dtsi and
k3-am62p5-verdin-wifi-dev-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each verdin board file forwards to
the shared K3 helper. The previous implementation returned 0
unconditionally which matched the first listed configuration
regardless of the actual silicon, which after the dtsi split would
load the wrong tifsstub variant on HS-SE parts.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on phycore AM62x and AM62Ax
SoMs at FIT config selection time.
The k3-am625-phycore-som-binman.dtsi and
k3-am62a-phycore-som-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each phycore board file forwards to
the shared K3 helper.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
TI K3 AM62x/AM62Ax/AM62Px boards carry two or three mutually-exclusive
tifsstub variants in their tispl.bin FIT images, all at the same load
address. The existing approach loads every variant and then discards
the wrong ones at runtime via a *p_size = 0 hack in
board_fit_image_post_process(). Switch to selecting the appropriate
FIT configuration up front via board_fit_config_name_match() so only
the correct tifsstub is loaded in the first place.
board_fit_config_name_match() is invoked by the R5 SPL during FIT
config selection. get_device_type() is a simple register read that is
available at that point, so the security state can be determined
early. The matching logic is factored into
k3_fit_config_match_security_state() in arch/arm/mach-k3/common.c so
it can be shared by any K3 board that wants this scheme. It matches
configurations by a suffix appended to the description string:
-hs-se -> HS-SE (K3_DEVICE_TYPE_HS_SE)
-hs-fs -> HS-FS (K3_DEVICE_TYPE_HS_FS)
-gp -> GP (K3_DEVICE_TYPE_GP)
Configurations without a security-state suffix (e.g. u-boot.img) do
not match and fall through to the DTS-specified default config
naturally.
Each TI EVM board defines its board_fit_config_name_match() as a thin
wrapper around the shared helper:
- board/ti/am62x/evm.c (AM625 SK: hs-se, hs-fs, gp)
- board/ti/am62ax/evm.c (AM62A SK: hs-se, hs-fs, gp)
- board/ti/am62px/evm.c (AM62P SK: hs-se, hs-fs, gp)
FIT configurations are split per security state in:
- arch/arm/dts/k3-am625-sk-binman.dtsi
(ti-falcon, ti-spl, ti-spl_unsigned: conf-hs-se/conf-hs-fs/conf-gp)
- arch/arm/dts/k3-am62a-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62A)
- arch/arm/dts/k3-am62p-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62P)
The runtime filter in board_fit_image_post_process() is intentionally
left in place. It becomes redundant once every board using the AM62x
family dtsi files migrates to per-state configurations. The dtsi for
phytec phycore and toradex verdin boards is updated by separate
patches in this series, and the now-redundant runtime filter is
removed by the final patch in the series.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Peng Fan (OSS) <peng.fan@oss.nxp.com> says:
A few misc fixes to dm core. More information could be found in each
commit. Patch list:
dm: core: free old name in device_set_name to prevent leak
dm: core: Correct calloc arguments
dm: core: fix wrong strlen check in of_add_subnode
dm: core: free fdt when fdt_create_empty_tree failure
Link: https://lore.kernel.org/r/20260703-dm-core-v1-0-076d395bded4@nxp.com
If device_set_name is called on a device that already has
DM_FLAG_NAME_ALLOCED set, the old dynamically-allocated name is leaked.
Free it before assigning the new name.
See: drivers/net/mdio_gpio.c:mdio_gpio_bind(). There is
device_set_name() here, however dm_mdio_post_bind() will also call
device_set_name() if "device-name" exists.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every other calloc in drivers/core uses calloc(count, size) with count
first. Fix the two reversed calloc(sizeof, 1) calls for consistency.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The duplicate-name check uses strlen on the search name instead of the
child name, so a child named "trevor" would falsely match a search
for "trev". Fix by checking strlen of child->name.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If fdt_create_empty_tree fails, the malloc-ed fdt buffer is never freed.
Add free before the error return.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In warm reset, the value of CTRLMMR_MCU_RST_SRC was not being reset.
This leads to a reset-loop boot failure when a warm reset is triggered
from the MAIN domain (by writing 0x2006 to MCU_RST_CTRL).
Signed-off-by: Anshul Dalal <anshuld@ti.com>
We don't have too many people looking at those at the moment, so having
people getting into the project by adding tests or documentation is I
believe a good thing so let's encourage those specific contributions.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We are "a bit" struggling with reviewing things and it's most of the
time maintainers or long time contributors reviewing patches on the
mailing list.
Hint that reviewing is also contributing to the project and that even if
you don't feel you're an expert, your review is still welcome and can
help us catch bugs before they are merged.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This way we don't need to make sure this link still points to something
that exists, as Sphinx will enforce it at build time. It also has the
added benefit that if someone builds the docs they will point at their
docs (though that is debatable whether that's useful, but at least you
stay on the same website).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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 <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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é <vincent.stehle@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The list-table layout does not allow grouping columns together,
convert the table into grid-table layout instead and rework it
such that SoC families, generations, architectures and SoCs are
grouped together. Include SoC column to group SoCs together, and
Core column which is useful on SoC like the R-Car X5H where U-Boot
can run on multiple cores in the SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update the Build section and note that it is only applicable
in case the table above does not contain any board specific
instructions. Include information that the Architecture column
now contains toolchain setup instruction links.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen5 X5H Ironhide board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Retronix R-Car Gen4 V4H Sparrow Hawk board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 D3 Draak board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 E3 Ebisu board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 M3Le Geist board.
Include Renesas R-Car Gen3 SPI NOR installation procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board.
Include generic and HyperFlash Renesas R-Car Gen3 installation
procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add documents which briefly outline how to set up the SH4/Aarch32/Aarch64
toolchains, for future use in Renesas documentation. Reference all these
documents in the renesas list of boards "Arch" column.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
