This adds support for the Kontron Electronics OSM-S i.MX93 SoM
and the matching baseboard BL i.MX93.
The SoM hardware complies to the Open Standard Module (OSM) 1.1
specification, size S (https://sget.org/standards/osm).
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
The arch-level implementation should be used here so that
env_get_location() can be used on board-level.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
This adds support for the Kontron Electronics OSM-S i.MX8MP SoM
and the matching baseboard BL i.MX8MP.
The SoM hardware complies to the Open Standard Module (OSM) 1.1
specification, size S (https://sget.org/standards/osm).
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
The SCMI shared memory area is no longer automatically marked as
non-cacheable after the commit a5a0134570 ("firmware: scmi: Drop
mmu_set_region_dcache_behaviour() misuse").
This change in behavior cause Rockchip RK3588 boards to fail boot with:
SoC: RK3588
DRAM: 8 GiB
scmi-over-smccc scmi: Channel unexpectedly busy
scmi_base_drv scmi-base.0: getting protocol version failed
scmi-over-smccc scmi: failed to probe base protocol
initcall_run_r(): initcall initr_dm() failed
### ERROR ### Please RESET the board ###
Update the memory mapping on RK3588 to mark the SCMI shared memory area
as non-cacheable to fix the SCMI shared memory based transport issue
that prevented RK3588 boards from booting.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/28408
This pull request enhances NAND and SPI flash support, primarily
focusing on the Airoha EN7523 platform. The Airoha SPI driver receives
a major update, adding DMA, dual/quad-wire modes, and a critical
workaround to prevent flash damage if the UART_TXD pin shorts to Ground.
New chips supported include FudanMicro FM25S01A SPI-NAND and several
Winbond SPI NOR devices. Fixes include correcting Kconfig dependencies,
updating the mtd benchmark command to use lldiv(), and addressing minor
bugs in the generic spi-mem and SPL NAND code.
The ROM code of Xilinx Zynq searches the boot flash for a "BootROM header"
at increments of 32k (0x8000), beginning with 0x0000 for a
configuration without authentication and beginning with 0x8000
for a configuration with authentication. [1]
Move the offset of the SPL partition on the brcp1 board to 0x8000
so that both cases are the same, e.g. a board that is configured
without authentication can boot an SPL partition with or without
authentication.
[1] Zynq 7000 TRM, section 6.3 "BootROM Code"
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251029092252.115582-1-wolfgang.wallner@br-automation.com
Dmitrii Sharshakov <d3dx12.xx@gmail.com> says:
Initially fix the inconsistency reported in reply to the previous
series and also make sure AArch64 images can be built with latest
Clang versions by guarding AArch32-specific options behind extra
config checks.
Tested qemu_arm_defconfig and qemu_arm64_defconfig with Clang 21,
mainline (to be 22) ce7f9f9c and also Clang 18 (for AArch64 only, as I
have not managed to build an AArch32 image with clang-18).
Link: https://lore.kernel.org/r/20251108-clang-cross-fixes-v1-0-ea6c4282844a@gmail.com
Clang is strict with respect to unknown options.
Therefore, only enable AArch32-specific options when CONFIG_ARM64
is not set.
Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>
Philippe Schenker <philippe.schenker@impulsing.ch> says:
This series fixes compilation errors when building for R5 cores and
addresses a security issue where authenticated images were not being
used correctly.
Patch 1: Cosmetic removal of duplicate code
Patches 2-3: Fix build errors caused by type mismatches between
function signatures and the types used in R5 builds.
Patches 4-5: fix a bug where ti_secure_image_post_process() relocates
images during authentication, but callers were still using the original
unverified addresses.
Patch 6: Implements is_running operation to allow querying R5F core status.
Link: https://lore.kernel.org/r/20251111071756.1257488-1-dev@pschenker.ch
The ti_secure_image_check() function may relocate the image during
authentication, updating image_addr to point to the verified location.
The caller was not updated with this new address, causing it to
reference the original unverified location.
Update p_image with the verified image address after authentication
to ensure subsequent operations use the correct location.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
The device tree contained a duplicate DT node 'main_mmc1_pins_default',
which was already defined a few lines below. This patch removes the
redundant entry.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.
Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Split the DH STM32MP13x based boards from ST STM32MP13x target,
this way the DH board specific code can be reused for STM32MP13x
DHSOM.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.
Fixes: ad3cdc677d ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.
Signed-off-by: Md Asadullah <md.asadullah@eds-india.com>
Add st,adc_usb_pd property in /config node for stm32mp135-dk-u-boot.
This needed to check board USB power delivery.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Anshul Dalal <anshuld@ti.com> says:
TI offers SoCs in various speed grades, each speed grade specifies a
certain maximum operating frequency of the clocks for each core.
In K3's boot flow, the R5 SPL starts the A53 or A72 core and configures
the correct clocks and power using the K3 ARM64 rproc driver
(compatible: ti,am654-rproc). However, the driver expects the dt node
for the ARM64 core to be set with a correct "assigned-clock-rates"
value.
Currently the dt has a value of 1.2GHz for the A53 core on AM62a, this
is incorrect for lower speed grades. Therefore this patch set adds
support for fixing this value at runtime based on the detected speed
grade from the efuse MMR.
For the speed grade table, refer to Table 6-1 of the AM62a datasheet.
Link: https://www.ti.com/lit/ds/symlink/am62a7.pdf
Link: https://lore.kernel.org/r/20251030-ti_speed_grade_fix-v1-0-703e4189640a@ti.com
Speed grades indicate the maximum operating frequency of any core on the
SoC. This patch adds support for the same to AM62a, this allows the A53
core to be started with the correct frequency by the R5 SPL.
Reference:
Device Speed Grades (Table 6-1) in AM62a7 Datasheet
https://www.ti.com/lit/ds/symlink/am62a7.pdf (Page#82)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The K3 ARM64 rproc driver uses the "assigned-clock-rates" value in the
respective "/a53@0" node to properly configure the clocks for the A53
core.
Although the clock value in the DT node might need to be fixed based on
SoC's speed grade at runtime. Certain SoCs such as AM62p and AM62x
already had this implemented, this patch moves the common code to
common.c to avoid duplication and simplify speed grade handling.
The logic to detect the correct entry in the "assigned-clock-rates"
property has also changed. Where we earlier relied on per SoC specific
device and clock IDs for the A53 core, we now use the "clock-names"
property which is device agnostic.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
fdt_fixup_cpu_freq_nodes_am62p is used to delete unsupported opp table
entries at runtime based on the SoC's speed grade.
However, the ti-cpufreq driver in kernel already has support for
rejecting unsupported entries. Therefore this fdt fixup is not necessary
and can be dropped.
Fixes: 8d05cbef73 ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
Support both old < 2.1 and new >= 2.1 protocol versions.
Update commit message based on Linux one]
Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Anshul Dalal <anshuld@ti.com> says:
This patch series adds support for AM6254atl SiP (or AM62x SiP for
short) to U-Boot.
The OPN (Orderable Part Number) 'AM6254atl' expands as follows[1]:
AM6254atl
||||
|||+-- Feature Lookup (L indicates 512MiB of integrated LPDDR4)
||+--- Device Speed Grade (T indicates 1.25GHz on A53 cores)
|+---- Silicon PG Revision (A indicates SR 1.0)
+----- Core configuration (4 indicates A53's in Quad core config)
AM62x SiP provides the existing AM62x SoC with 512MiB of DDR
integrated in a single packages. The first 4 patches in the series
are cherry-picked from the devicetree-rebasing repository at
'v6.18-rc2-dts'.
Link: https://lore.kernel.org/r/20251025-62sip_support-v3-0-b4c8314d0055@ti.com
Guillaume La Roque (TI.com) <glaroque@baylibre.com> says:
This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.
The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
from EEPROM data
Link: https://lore.kernel.org/r/20251103-am62xeeprom-v3-0-e390779c0fc5@baylibre.com
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says:
This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.
This patch series adds support for the following hardware:
* console UART
* ethernet controller/switch
* spinand flash (in non-dma mode)
The following issues may be expected:
* Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
* Linux airoha-snfi driver in some cases might damage you flash data
(see: https://lore.kernel.org/lkml/20251012121707.2296160-15-mikhail.kshevetskiy@iopsys.eu/)
* Latest linux kernel is recommended to properly support flashes
with more than one plane per lun
(see: https://lore.kernel.org/lkml/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu/)
* It's NOT recommended to use flashes working in continuous mode because
U-Boot airoha-snfi driver does not support such flashes properly.
The patches was tested on the board:
- SoC: Airoha EN7562
- RAM: 512 MB
- SPI NAND: 4 Gbit, made by Toshiba
- Linux boot: was NOT tested
The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created
1) Create u-boot.its file with the following contents:
=== cut here ===
/dts-v1/;
/ {
description = "ARM OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;
images {
u-boot-ram {
description = "OpenWrt U-Boot RAM image";
data = /incbin/("u-boot.bin.lzma");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x81e00000>;
entry = <0x81e00000>;
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
fdt-1 {
description = "OpenWrt device tree blob";
data = /incbin/("dts/upstream/src/arm/airoha/en7523-evb.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
};
configurations {
default = "config-ram-uboot";
config-ram-uboot {
description = "OpenWrt RAM U-Boot";
kernel = "u-boot-ram";
fdt = "fdt-1";
};
};
};
==================
2) Create u-boot.itb image to chain-load new u-boot from the old one
lzma_alone e u-boot.bin u-boot.bin.lzma
mkimage -f u-boot.its u-boot.itb
3) Load new u-boot from the old one
U-Boot> tftpboot u-boot.itb && bootm
Link: https://lore.kernel.org/r/20251101004503.2379529-1-mikhail.kshevetskiy@iopsys.eu
TI's AM6254atl (or AM62x SiP for short) provides the existing AM62x SoC
with 512MiB of DDR integrated in a single package.
This patch adds the necessary U-Boot devie tree files, the required
defconfigs along with the documentation for the AM62x SiP EVM.
AM62x SiP differs from the already supported AM62x in following ways:
- OP-TEE for the AM62x resides from 0x9e800000 to 0xa0000000 which needs
to be moved to 0x80080000 to free up space at end of DDR in AM62x SiP
with 512MiB of memory. This is required to allow U-Boot to relocate to
end of DDR before booting to the kernel.
- Changes to the env:
1. splashimage address updated from 0x80200000 to 0x81a00000
2. DFU addresses updated to match updated TEXT_BASE for SPL and U-Boot
Signed-off-by: Anshul Dalal <anshuld@ti.com>
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot
Use the generic do_board_detect_am6() and setup_serial_am6()
functions to avoid code duplication across AM6x family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.
To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha EN7523 SoC.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.
To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha AN7581 SoC.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Basic support for en7523/en7529/en7562 SoCs. Within a patch
only serial console will be supported.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Add DWMCI_QUIRK_DISABLE_FMP which disables Flash Memory Protector (FMP)
during driver's init. It's usually done by early bootloaders, but in
some cases (like USB boot) the FMP may be left unconfigured. The issue
was observed on Exynos850 SoC (the E850-96 board). Enabling this quirk
makes eMMC functional even in such cases.
No functional change, as this feature is only added here but not enabled
for any chips yet.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The bootargs are passed to the kernel in the chosen node, this patch
adds support for populating bootargs in the dtb if missing.
The values for kernel boot params is taken from the env, with 'boot' and
'bootpart' specifying the rootfs for the kernel similar to the
non-falcon boot flow.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch adds fdt fixups to the kernel device-tree in R5 falcon mode,
these fixups include fixing up the core-count, reserved-memory etc.
The users can opt out by disabling the respective CONFIG_OF_*_SETUP
config options.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
To simplify the boot process and prevent the R5 SPL size from growing,
this patch restricts the boot media to load the next stage payload
(tifalcon.bin and kernel FIT) to MMC only.
We select between eMMC/SD by checking "mmcdev" in env to conform with
how U-Boot proper handles loading binaries from MMC1 or MMC2.
Note that tiboot3.bin (the initial bootloader) can be loaded from any
boot mode supported by the ROM since the restriction only applies to
tifalcon.bin and fitImage.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
We use the spl_board_prepare_for_boot hook to call k3_r5_falcon_prep
which is ran after tispl is loaded but before jump_to_image.
In k3_r5_falcon_prep, we find the boot media and load the kernel FIT
just as standard secure falcon mode (since spl_start_uboot returns 0
now). Once the kernel and args are loaded.
Now when the flow goes to jump_to_image, we do the regular pre-jump
procedure and jump to TFA which jumps to the kernel directly since we
have already loaded the kernel and dtb at their respective addresses
(PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
Overall execution for the R5 SPL after this patch:
board_init_r
|-> boot_from_devices
| +-> load_image (we load tifalcon.bin here since spl_start_uboot
| returns 1)
|
+-> spl_prepare_for_boot
| +-> k3_falcon_prep
| +-> load_image (we load fitImage here since spl_start_uboot
| returns 0 now)
|
+-> jump_to_image
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch adds creation of tifalcon.bin for the AM62a, 62p and 62x.
The contents are the same as the existing tispl.bin but A53's SPL and
the FDT have been removed as they are not needed in R5 falcon mode.
This reduces boot time since the payload size is smaller compared to the
regular tispl.bin.
tispl.bin = TFA + TEE + TIFS-STUB + A53 SPL + FDT
tifalcon.bin = TFA + TEE + TIFS-STUB
Signed-off-by: Anshul Dalal <anshuld@ti.com>
