We are trying to get rid of the legacy LED API and PinePhone is one of
the last ones requiring it.
Unlike all other users of the legacy LED API, PinePhone is controlling
the GPIO LED in SPL. Unfortunately, Sunxi doesn't enable DM support in
SPL because of tight space constraints, so we cannot make use of the
modern LED framework as that is based on DM_GPIO.
Since PinePhone is the last user of this API, I'm moving the logic to
Sunxi SPL code and will let this community decide how to handle this hot
potato.
The logic is extremely simplified as only one GPIO LED is currently
controlled in SPL by PinePhone. No need for handling multiple LEDs or
inverted polarity, let's keep it simple.
This however allows us to use the modern LED framework once in U-Boot
proper since this logic won't collide with the new framework.
Since the only misc drivers that were compiled in SPL were guarded by
CONFIG_LED_STATUS and CONFIG_LED_STATUS_GPIO, we can also disable
CONFIG_SPL_DRIVERS_MISC (which does nothing anymore).
This also saves some space for PinePhone in SPL and proper.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
The exported sub_make_done variable leaks into the environment of all
child processes. When make targets like tcheck spawn independent
make-invocations with O=, those child-makes inherit sub_make_done=1,
skip the KBUILD_OUTPUT setup and try to build in the source tree.
A global 'unexport sub_make_done' cannot be used because the build
system itself re-invokes the top-level Makefile for syncconfig (via
'$(MAKE) -f $(srctree)/Makefile syncconfig'). Without sub_make_done,
that child make re-enters the KBUILD_OUTPUT block and recomputes
abs_objtree. With a relative O= path this resolves to a nested
directory (e.g. build/build/) where .config does not exist.
Instead, use 'env -u sub_make_done' in the test-target recipes so only
the test scripts see a clean environment. This allows their child make
invocations to process O= correctly without affecting internal kbuild
recursion.
This is not strictly a bugfix, but compare with:
commit 27529f1cb0 ("kbuild: skip parsing pre sub-make code for recursion")
Signed-off-by: Simon Glass <sjg@chromium.org>
Per the SCSI SPC-4 specification, the standard inquiry data length
should not be less than 36 bytes. The current implementation uses 512
bytes, which causes detection failures on some UFS devices (e.g.,
Longsys) that do not expect a transfer length exceeding the standard
inquiry size.
Align the default standard inquiry length with the Linux kernel's
implementation (see drivers/scsi/scsi_scan.c), which uses 36 bytes as
the default. Devices requiring vendor-specific inquiry lengths should
be handled through quirk settings in the future.
Signed-off-by: ht.lin <ht.lin@mediatek.com>
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Introduce a new fragment configuration in u-boot to enable support for
the snagfactory tool [1], used for factory flashing of boards. Snagfactory
tool first recovers the board via USB DFU (peripheral boot), and then
uses fastboot to flash given binaries/images to MMC or other on-board
memory via USB. The fragment config can be used to generate boot binaries
for board recovery. This fragment config needs to be added additionally,
while building a53 images for USB DFU boot.
The fragment config enables configurations to allow flashing via
fastboot, manage MMC partitions and boot partitions, customize buffer
size and memory usage for fastboot and also integrate OEM commands and
UUU compatibility. It sets CONFIG_BOOTCOMMAND to start fastboot mode
immediately on startup. It also sets BOOTDELAY to 0 to reduce snagfactory
recovery time. Since BOOTCOMMAND and BOOTDELAY configs are being
modified, these changes cannot be placed in existing DFU fragment config.
Snagfactory used mtd support for flashing both SPI NAND and SPI NOR
devices. The fragment config enables mtd in u-boot and also allows SPI
flash to be treated as an MTD device.
[1]: https://github.com/bootlin/snagboot
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Signed-off-by: Mahammed Sadik Shaik <s-sadik@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>
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>
