Add U-Boot specific device tree configuration for i.MX952 EVK board.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
i.MX952 is designed for AI-powered sensor fusion and vision sensing
applications, it features 4 Corte-A55, 1 Cortex-M33, 1 Cortex-M7 and
NXP eIQ NPU and advanced graphics, video and advanced security with
edgelock. Product info could be found at:
https://www.nxp.com/products/i.MX-952
The basic device tree includes:
- clock, pin, power header files
- device nodes: CPU[0-3], SCMI firmware, Interrupt Controller, Sys counter,
eDMA, MU, SPI, UART, I2C, USB and etc
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
[ upstream commit: b516a4dd6a1ff7ddbaf3ab30ddec88088a6ec9e6 ]
(cherry picked from commit 3546aa155a84b8af636d44c852c864845e654864)
On i.MX952, WDG3 and WDG4 are not used for system reset. PSCI is used
instead. Keep WDG3 and WDG4 in their default state rather than
explicitly disabling them.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
This patch is used to add the imx type string of i.MX952 so that the
i.MX952 CPU info can be printed.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Add basic SoC support for i.MX952:
- Add CONFIG_IMX952 Kconfig option
- Include i.MX952 clock and power headers
- Set CPU speed grade to 1.7GHz for i.MX952
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: David Zang <davidzangcs@gmail.com>
Multiple pads can drive the same module input pin, and a daisy chain
register is used to select the active input path. This patch defines
DAISY_OFFSET_IMX952 (0x460) and allows binding on i.MX952.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Change to use default board_phys_sdram_size implementation in soc.c,
which will call SM API to get DDR size.
If board has special implementation for DDR size, then board_phys_sdram_size
could be implemented in board file to override the default one in soc.c.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
System Manager(SM) has implemented the MISC protocol to retrieve DDR
information. Using this API, U-Boot can obtain the DDR size dynamically
instead of relying on static configuration macros.
This change addresses the DDR ECC enabled case, where 1/8 of the total
DDR size is reserved for ECC data. The scmi_misc_ddrinfo() returns the
DDR size with EEC overhead already deducted.
Implementation details:
- Query the DDR size via scmi_misc_ddrinfo()
- Replace direct REG_DDR_CS[0,1]_BNDS register reads with SCMI call
- Switch from PHYS_SDRAM[x]_SIZE macros to runtime detection
- For backward compatibility with older SM firmware, fall back to
static PHYS_SDRAM[x]_SIZE configuration if the SCMI call fails
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
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>
Describe build with OpenSBI fw_dynamic.bin path as OPENSBI=<path> on the
same line instead of as an export. Also remedy a typo which had the wrong
directory path before the filename.
Fixes: 8304f32267 ("doc: board: starfive: update jh7110 common description")
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Describe build with output directory as O=<dir> environment variable
and not unrelated -O <output sync> command line argument.
Fixes: 8304f32267 ("doc: board: starfive: update jh7110 common description")
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
OrangePi RV is a board that uses the same EEPROM product serial identifier
as the StarFive VisionFive 2 1.3b.
In fact it is not completely compatible with the StarFive VisionFive 2
1.3b for use with Linux Kernel however it is good enough for use with
U-Boot SPL and U-Boot Main. Describe how to set the devicetree search path
and, for advanced users, suggest that it is possible to update the EEPROM
data with an invented "XOPIRV" identifier for automatic board detection.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Add XOPIRV identifier for Orange Pi RV to dts selection callback in SPL,
and to fdtfile environment variable default value selection in payload.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Set $fdtfile to the VisionFive 2 Lite DTB if the board is matched.
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Get and enable a optional power gpio. This feature is ported
from the jh7110 pcie driver in Linux. VisionFive 2 Lite needs
this gpio to enable the PCI bus device (M.2 M-Key) power.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Add eeprom data format v3 support. Add onboard_module field in
ATOM4 and add "mac onboard_module <?>" command to modify it.
The onboard module field marks the additional modules compared
with VisionFive 2 board. Now we define
bit7-1: reserved, bit0: WIFI/BT
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
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>
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>
