pcb_revision is stored in the pcb_revision field of ATOM4. Correct it.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: aea1bd95b6 ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Directly return the DDR size instead of the field of 'DxxxExxx'.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: aea1bd95b6 ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Although the J742S2 EVM supports PCIe boot in Hardware, since it is not
enabled yet in Software, disable PCIe boot related configurations that are
not applicable.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Although the J742S2 EVM supports PCIe boot in Hardware, since it is not
enabled yet in Software, disable PCIe boot related configurations that are
not applicable.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
AM69 SK does not contain PCIe Boot in the list of supported Boot Modes.
Hence, disable PCIe Boot related configurations that are not applicable.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
AM69 SK does not contain PCIe Boot in the list of supported Boot Modes.
Hence, disable PCIe Boot related configurations that are not applicable.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
J784S4 SoC has two instances of PCIe, namely PCIe0 and PCIe1. The
PCIe1 instance is used for PCIe endpoint boot. Enable the configs
required for PCIe boot on the J784S4 platform.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
J784S4 SoC has two instances of PCIe, namely PCIe0 and PCIe1. The
PCIe1 instance is used for PCIe endpoint boot. Enable the configs
required for PCIe boot on the J784S4 platform.
Additionally, enable configs for J721E WIZ SERDES wrapper, Cadence
Torrent PHY, and MMIO multiplexer. These are required to configure
the SERDES lanes at the R5 SPL stage for PCIe endpoint operation.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Add SPL_PHY_J721E_WIZ configuration option to enable the WIZ SERDES
wrapper driver in SPL stage. This is required for PCIe boot support
where SERDES configuration must be done early in the boot sequence
before loading the bootloader image over PCIe.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Add SPL_PHY_CADENCE_TORRENT configuration option to enable the Cadence
Torrent PHY driver in SPL stage. This is required for PCIe boot support
where SERDES configuration must be done early in the boot sequence
before loading the bootloader image over PCIe.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
To enable PCIe boot on J784S4 SoC SERDES0 and PCIE1 should be enabled
and configured at the R5 stage. Add the required clk-data and dev-data
for SERDES0 and PCIE1.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Pull request efi-2026-03-14
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/29512
UEFI:
* Require at least 128 KiB of stack space to use EFI sub-system.
* Avoid buffer overrun in efi_var_restore().
* Avoid superfluous variable store writes on unchanged data
* Implement SPI Flash store for EFI variables.
* Add an efidebug ecpt sub-command to display the ECPT table
and a unit test for the command.
Others:
* Add missing include string.h to make exception command build again.
* lib: uuid: add EBBR 2.1 conformance profile GUID
u-boot-dfu-20260316
DFU:
* Make DFU_WRITE_ALT symbol available outside of DFU
* Fix PCI subclass_code warning in spl_dfu
Usb Gadget:
* Mark udc_disconnect() as static
When building qemu_arm64_defconfig with CMD_EXCEPTION a build error occurs:
In file included from cmd/arm/exception64.c:87:
include/exception.h: In function ‘exception_complete’:
include/exception.h:41:23: error: implicit declaration of
function ‘strlen’ [-Wimplicit-function-declaration]
41 | len = strlen(argv[1]);
| ^~~~~~
Add the missing include.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Currently U-Boot uses ESP as storage for EFI variables.
Devices with SPI Flash are used for storing environment with this
commit we allow EFI variables to be stored on SPI Flash.
Signed-off-by: Shantur Rathore <i@shantur.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Every SetVariable() call triggers efi_var_mem_ins() followed by
efi_var_to_storage(), even when the variable value is not actually
changing. This is unfriendly to flash-backed stores that suffer
wear from unnecessary erase/write cycles.
Add a change-detection path to efi_var_mem_ins(): when size2 == 0
(i.e. not an append) and the caller passes a non-NULL changep flag,
look up the existing variable and compare attributes, length, time
and data byte-by-byte. If everything matches, set *changep = false
and return EFI_SUCCESS without touching the variable buffer.
Both efi_set_variable_int() and efi_set_variable_runtime() now
check the flag and skip efi_var_mem_del() / efi_var_to_storage()
when nothing changed.
Introduce efi_memcmp_runtime() - a runtime-safe byte-by-byte memory
comparison helper, following the same pattern as the existing
efi_memcpy_runtime(). The standard memcmp() is not available after
ExitBootServices() and calling it from Linux will crash.
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The value of buf->length comes from outside U-Boot and may be incorrect.
We must avoid to overrun our internal buffer for excessive values.
If buf->length is shorter than the variable file header, the variable
file is invalid.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add support for printing the EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID as human
readable text.
This is compiled in only when CONFIG_CMD_EFIDEBUG and CONFIG_EFI_EPCT are
set.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI specification requires at least 128 KiB stack space. Consider this
value as a prerequisite for CONFIG_EFI_LOADER.
Mention the requirement in the CONFIG_STACK_SPACE description and decribe
that the UEFI sub-system uses CONFIG_STACK_SPACE when defining the memory
map.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Rockchip RK356x supports up to 8 GiB DRAM, however U-Boot only includes
the initial 32-bit 0-4 GiB addressable range in its memory map,
something that matches gd->ram_top and current expected memory available
for use in U-Boot.
The vendor DRAM init blobs add following ddr_mem rk atags [1]:
4 GiB: [0x0, 0xf0000000) and [0x1f0000000, 0x200000000)
8 GiB: [0x0, 0x200000000)
Add the remaining 64-bit 4-8 GiB addressable range, that already is
reported to OS, to the U-Boot memory map to more correctly describe all
available and addressable DRAM of RK356x. While at it also add the
missing UL suffix to the PCIe address range for consistency.
[1] https://gist.github.com/Kwiboo/6d983693c79365b43c330eb3191cbace
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Neha Malcom Francis <n-francis@ti.com> says:
Typically we do not enable these configs by default but would still like to
have the option to start building them in our default build flow for
testing. Also there is the added advantage of users being able to see what
is needed in case they choose to enable these features.
Link: https://lore.kernel.org/r/20260226122508.2269682-1-n-francis@ti.com
Add sections dedicated to explaining how BIST and inline ECC can be
enabled via the config fragments.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
K3 OTP bits can only be programmed 25bits at a time. Limit the value
accordingly using a 25 bit mask.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Error out if readback value doesn't match the programmed value.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Use signed int format to print error codes so that its more readable
Fixes: ed5f2e5bed ("drivers: k3_fuse: Add fuse sub-system func calls")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Sparsh Kumar <sparsh-kumar@ti.com> says:
This series updates the Resource Management (RM) configuration files
for AM62 family devices to align with the TIFS v11.02.09 firmware.
Background
----------
With the latest TIFS firmware (v11.02.09), an additional virtual
interrupt and event is reserved for MCU cores to DM usage on am62x,
am62ax, and am62px devices. This series brings the rm-cfg and
tifs-rm-cfg files in sync with these firmware changes across both
TI reference boards and vendor boards.
These changes are backward compatible with older TIFS firmware versions.
Additionally, the am62x platform was originally introduced without a
tifs-rm-cfg.yaml file, unlike other platforms in the AM62 family.
This series addresses that gap and enables tifs-rm-cfg in binman for
am625-sk and am62p-sk platforms.
Changes
-------
TI reference boards (patches 1-4):
- Update rm-cfg.yaml for am62x, am62ax, am62px
- Sync am62px tifs-rm-cfg.yaml with TIFS firmware template
- Add missing tifs-rm-cfg.yaml for am62x
- Enable tifs-rm-cfg in binman for am625-sk and am62p-sk
Vendor boards (patches 5-9):
- beagleplay (am62x-based)
- phytec phycore_am62x
- toradex verdin-am62
- phytec phycore_am62ax
- toradex verdin-am62p
with the required interrupt reservation. The tifs-rm-cfg.yaml files
cannot be updated without access to the corresponding SysConfig files,
as both rm-cfg.yaml and tifs-rm-cfg.yaml must remain in sync.
Link: https://lore.kernel.org/r/20260225132425.3096103-1-sparsh-kumar@ti.com
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62px devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62ax devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Add rcfg_yaml_tifs node override to use tifs-rm-cfg.yaml instead of
the default rm-cfg.yaml for am625-sk and am62p-sk platforms.
This enables binman to include the tifs-rm-cfg.yaml configuration
when building tiboot3 images, bringing these platforms in line with
other K3 devices like am62a-sk that already use tifs-rm-cfg.yaml.
This builds on the tifs-rm-cfg files added/updated earlier in this series.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
The am62x platform was originally introduced without a
tifs-rm-cfg.yaml file. Add the tifs-rm-cfg to bring am62x
in line with other am62 family of devices (am62px and am62a)
which all include this file.
This complements the rm-cfg update earlier in this series.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Synchronize tifs-rm-cfg file with the latest v11.02.09
TIFS firmware rm configuration:
- Update am62px tifs-rm-cfg with revised resource allocations
- Apply formatting updates to align with TIFS template
This brings tifs-rm-cfg in sync with the rm-cfg changes
earlier in this series.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x, am62ax and am62px devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Updates the polarities for the GPIOs on the sc594
EZKIT carrier board for the newest revision, Rev D.
The new carrier board revision has different polarities
for some GPIOs. This patch updates the sc594 entries
to match the sc598 entries that were updated in a previous
commit, as both SOMs can utilize the EZKIT.
Note that these updates are for the EZKIT carrier
board used by both sc598 and sc594 SOMs, not the SOMs themselves.
Fixes: be79378 ("board: adi: Add support for SC594")
Signed-off-by: Caleb Ethridge <caleb.ethridge@analog.com>
Reviewed-by: Greg Malysa <malysagreg@gmail.com>
Add NULL check after memalign() call in get_mem() to prevent
potential NULL pointer dereference (CWE-476).
The function memalign() can return NULL on allocation failure.
Dereferencing the returned pointer without checking for NULL
may cause a crash in low-memory conditions.
Changes:
- Add NULL check after memalign() allocation
- Return NULL on failure, consistent with function semantics
This fixes the static analyzer warning:
linux_compat.c:34: dereference of memalign return value without NULL check
Reported-by: static analyzer Svace
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
