Add support for rkrng variant, used by e.g. RK3528 and RK3576.
Imported from vendor U-Boot linux-6.1-stan-rkr5 tag with minor
adjustments for mainline.
Signed-off-by: Lin Jinhan <troy.lin@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Successive Approximation ADC (SARADC) in RK3528 uses the v2
controller and support:
- 10-bit resolution
- Up to 1MS/s sampling rate
- 4 single-ended input channels
- Current consumption: 0.5mA @ 1MS/s
Add support for the 4 channels of 10-bit resolution supported by SARADC
in RK3528.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add support for the OTP controller in RK3528. The OTPC is similar to the
OTPC in RK3568 and can use the same ops for reading OTP data.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enable clock stopping to gate clock during phase code change to ensure
glitch free phase switching in auto-tuning circuit. Fixes HS200 mode
on RK3528.
POST_CHANGE_DLY
Time taken for phase switching and stable clock output.
- Less than 4-cycle latency
PRE_CHANGE_DLY
Maximum Latency specification between transmit clock and receive clock.
- Less than 4-cycle latency
TUNE_CLK_STOP_EN
Clock stopping control for Tuning and auto-tuning circuit. When enabled,
clock gate control output is pulled low before changing phase select
codes. This effectively stops the receive clock. Changing phase code
when clocks are stopped ensures glitch free phase switching.
- Clocks stopped during phase code change
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add initial support for SDHCI controller in RK3528.
Only MMC Legacy and MMC High Speed (52MHz) mode is supported after this,
more work is needed to get the faster HS200/HS400/HS400ES modes working.
Variant tap and delay num is copied from vendor Linux tag
linux-6.1-stan-rkr5.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
RK3528 and RK3576 use different tap and delay num for cmdout and strbin.
Move tap and delay num for cmdout and strbin to driver data to prepare
for adding new SoCs.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Rockchip RK3528 is a ARM-based SoC with quad-core Cortex-A53.
Add initial arch support for the RK3528 SoC.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add pinctrl driver for RK3528.
Imported from vendor U-Boot linux-6.1-stan-rkr5 tag with adjustments
to use regmap_update_bits().
Signed-off-by: Steven Liu <steven.liu@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add support for reading DRAM size information from PMUGRF os_reg18 reg.
Compared to most Rockchip SoCs the RK3528 use os_reg18 for DRAM info,
instead of os_reg2.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Linux commit 6ee0b9ad3995 ("arm64: dts: rockchip: Add rng node to
RK3588") merged for v6.15-rc1 add a proper rng node to the device tree.
The compatible used differs compared to what U-Boot is currently using.
Replace the old trngv1 compatible with the dts/upstream compatible in
the rng driver and remove the old rng node compatible override from SoC
u-boot.dtsi to keep rng working after the driver change.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Linux commit afeccc408496 ("arm64: dts: rockchip: add DT entry for RNG
to RK356x") merged for v6.12-rc1 add a proper rng node to the SoC DT.
The compatible used differs compared to what U-Boot is currently using.
Add support for the rk3568-rng used in upstream Linux. Support for the
cryptov2-rng compatible is still kept because PX30/RK3326 and RK3308 are
still using it.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
This is a huge series which promoted MIPS/Boston target into a
usable state, with fixes to drivers and general framework issues
I found in this process.
I also converted the target to OF_UPSTREAM.
This target is covered by QEMU, to test on QEMU:
```
make boston64r6el_defconfig
make
qemu-system-mips64el -M boston -cpu I6500 -bios ./u-boot.bin -nographic
```
Link: https://lore.kernel.org/r/20240517-boston-v3-0-1ea7d23f4a1d@flygoat.com
In upstream devicetree, clk_boston is a child of syscon node
and there is no "regmap" property for clk_boston node.
Try to check parent device first to look for syscon.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Remove hard dependencies to arch headers, get clock from clk
subsystem if arch clock function is not available, align
compatible strings with devicetree binding.
No functional change on existing platforms, just get it build
on other platforms.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Ensure that we are using correct physical/virtual address for
DMA buffer write and hardware register settings.
The convention is: in ahci_ioports all pointers are virtual,
that will be converted to physical address when writing to
hardware registers or into sg/cmd_tbl.
Also fixed 64bit physical address support for dwc_ahsata, ensure
higher bits are written into registers/sg properly.
Use memalign for allocating aligned buffer in dwc_ahsata so we
don't have to do our own alignment in driver.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
For MIPS we are always looking gd->dram in virtual address so
PCI_MAP_SYSTEM_MEMORY should always be enabled.
If in future we ever want to make it physical we have to set
ARCH_MAP_SYSMEM.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Boston has a very limited memory range for PCI controllers, where
1MB can't easily fit into it.
Make alignment boundary of PCI memory resource allocation a Kconfig
option and default to 0x10000 for boston.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Probe size of ecam from devicetree properly and cap accessible
bus number accorading to ecam region size to ensure we don't go
beyond hardware address space.
Also disable all interrupts to ensure errors are handled silently.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
i2c updates for v2025.07-rc1
- omap24xx_i2c: Enable Repeated Start functionality
add Repeated Start functionality for the DM_I2C xfer
API (omap_i2c_xfer()
from Aniket Limaye
- mediatek i2c driver
fixes from Martin
- add end marker for struct udevice_id mtk_i2c_ids
- remove duplicate entry in mt_i2c_regs_v1
This pull request contains updates for the SoCFPGA platform, targeting
the 2025.07 release cycle. Highlights include enhancements to Agilex5
support, improvements in DDR error handling, and bridge reset handling
for SoC64 devices.
Key updates:
Agilex5 platform enhancements:
* New MMU region mappings and memory layout updates using
LMB_ARCH_MEM_MAP.
* Fixes for bloblist configuration, kernel FIT image generation, and
VAB flow enablement.
* GPIO pin control added for SDIO selection.
* Marvell PHY driver enabled in defconfig.
Agilex5 / SoC64 DDR subsystem:
* Added ECC debug improvements for IOSSM.
* Introduced LPDDR inline ECC support.
* Resolved size calculation overflow in memory driver.
SoC64 improvements:
* Enhanced mailbox communication with the SDM to reflect various
boot stage transitions.
* Implemented F2S bridge reset support and updated related reset
manager registers.
* Expanded SoC64 CPU info reporting.
General maintenance:
* Additional peripherals released from reset for Arria10.
* Cleanup of legacy or incorrect Kconfig implications.
This patch set has been tested on Agilex 5 devkit.
Passing all pipeline tests at:
https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/25867
Add a Kconfig option to disable sending Stop conditions between multiple
i2c_msgs within a single xfer. Enable this config by default for ARCH_K3
platforms.
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Repeated Start Condition (Sr) can be used to transfer multiple i2c msgs
without sending a Stop condition (P). So far, the driver default was to
always send a Stop condition after every i2c msg.
Add support for a config option (CONFIG_SYS_I2C_OMAP24XX_REPEATED_START)
to disable sending the Stop condition by default. If this config is
enabled, Stop condition will be sent only if explicitly requested in the
msg flags OR if it is the last msg in the transfer.
Consequently, handle the Repeated Start condition (Sr) in the next msg
by not calling the wait_for_bb() check since it will simply timeout in
the absence of a stop condition (BB will be 1 until Stop is programmed)
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Remove __omap24_i2c_read/write() usage from omap_i2c_xfer() in favour of
the more flexible __omap24_i2c_xfer_msg().
Consequently, these are also no longer needed when DM_I2C is enabled.
New function __omap24_i2c_xfer_msg() will take care of individual read
OR write transfers with a target device. It goes through below sequence:
- Program the provided Target Chip address (OMAP_I2C_SA_REG)
- Program the provided Data len (OMAP_I2C_CNT_REG)
- Program the provided Control register flags (OMAP_I2C_CON_REG)
- Read from or Write to the provided Data buffer (OMAP_I2C_DATA_REG)
For a detailed programming guide, refer to the TRM[0] (12.1.3.4 I2C
Programming Guide).
This patch by itself should be a transparent change. However this is
needed for implementing a proper Repeated Start (Sr) functionality for
i2c_msgs.
Previous implementation for omap_i2c_xfer called __omap24_i2c_read/write
functions, with hardcoded addr=0 and alen=0 for each i2c_msg. Each of
these calls would program the registers always with a Stop bit set, not
allowing for a repeated start between i2c_msgs in the same xfer().
[0]: https://www.ti.com/lit/zip/spruj28 (TRM)
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Remove unused piece of code under CONFIG_I2C_REPEATED_START which does
not have any Kconfig entry at all.
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
In-line ECC support was added for LPDDR by reserving the last one-eighth
of the memory space for ECC data. Full memory initialization using the
BIST MEM INIT mailbox command, based on address and size, is required to
correctly generate ECC data and enable proper ECC logic verification.
Signed-off-by: Tingting Meng <tingting.meng@altera.com>
Current implementation releases most peripherals out of reset for
gen5, but A10 has more peripherals than gen5, hence this patch is
required to release the rest of peripherals to support old kernels.
Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Data structure, dramaddrw, is defined as u32. Compiler performs
32-bit arithmetic and logic operations on this data structure. Fix
is provided to avoid integer overflow while performing shifting
operations greater than 32-bit.
Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
This was applied prematurely by me as I missed the feedback provided at
the time.
This reverts commit c9c8df2c37.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add Airoha SPI NAND driver to permit usage of attached SNAND on the
Airoha AN7581 SoC. While SPI controller supports DMA transation, due to
U-Boot limitation we currently limit it to single command in Manual
mode.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Call SPI setup_for_spinand() if supported and defined to configure the
SPI slave for the attached NAND. This is needed to configure the SPI
with the NAND page size and spare size for correct configuration of the
device.
Call it as soon as the NAND is detected to correctly handle SPI
controller with select_op_variant detection.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Airoha new SoC implement the same Mediatek driver for MMC. Permit to
also build for Airoha arch.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add airoha Ethernet driver for Airoha AN7581 SoC. This is a majorly
rewritten and simplified version of the Linux airoha_eth.c driver.
It's has been modified to support a single RX/TX ring to reflect U-Boot
implementation with recv and send API.
The struct and the define are kept as similar as possible to upstream
one to not diverge too much.
The AN7581 SoC include an Ethernet Switch based on the Mediatek MT753x
but doesn't require any modification aside from setting the CPU port and
applying the Flood configuration hence it can be handled entirely in the
Ethernet driver.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports
100/1000/2500 Mbps with auto negotiation only.
The driver uses two firmware files, for which updated versions are added to
linux-firmware already.
Based on the Linux upstream 8811 driver code(air_en8811h.c),
I have modified the relevant process to align with the U-Boot boot sequence.
and have validated this on Banana Pi BPI-R3 Mini.
The MD32 FW is currently stored in eMMC partition 1 on Banana Pi BPI-R3 Mini,
and it is loaded from there.
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
Add support for loading the secure & non-secure pdi images and PL
bitstream on the Versal Gen2 platform. The FPGA driver is enabled
to load the bitstream in PDI format on the AMD Versal Gen2 device.
PDI is the new programmable device image format for Versal Gen2,
and the bitstream for the Versal Gen2 platform is generated exclusively
in this format.
With the enhanced SMC format in TF-A ensuring transparent payload
forwarding for Versal Gen2, the u-boot driver must now handle the
word swapping of PDI address that was previously done in TF-A for
this API. The source code for the Versal2 loadpdi command and the
CONFIG_CMD_VERSAL2 configuration has been removed. It now utilizes
the fpga load <dev> <address> <length> command to load secure &
non-secure pdi images.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250327105200.1262615-3-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Introducing additional flag to check whether an FPGA driver is able to
load a particular FPGA bitstream image.
Generally, flag variable is used to enable or disable certain features,
specify additional parameters (such as error handling), or modify how
the function operates.
Hence, in this function flags is an integer that can be used to pass
configuration options to the fpga_load function. Here, it's
initialized to 0, meaning no special options are enabled, but it could
modify the flags to influence the function's behavior.
Signed-off-by: Muhammad Hazim Izzat Zamri <muhammad.hazim.izzat.zamri@altera.com>
Link: https://lore.kernel.org/r/20250314021953.18379-3-muhammad.hazim.izzat.zamri@altera.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Enabling the capability to automatically perform FPGA configuration
when booting Linux FIT image via bootm command. The FPGA
configuration bitstream shall be packed within the FIT image.
The FPGA data (full or partial) is checked by the SDM hardware,
for Intel SDM Mailbox based devices. Hence always return full
bitstream.
Second function is to enable the HPS to FPGA bridges when FPGA load
is completed successfully. This is to ensure the FPGA is accessible
by the HPS.
Signed-off-by: Muhammad Hazim Izzat Zamri <muhammad.hazim.izzat.zamri@altera.com>
Link: https://lore.kernel.org/r/20250314021953.18379-2-muhammad.hazim.izzat.zamri@altera.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Added extended support for retrieving the PMC muti boot mode
register via the firmware interface, which is preferred when
U-Boot runs in EL2 and cannot directly access PMC registers
via raw reads. Ideally, all secure registers should be accessed
via xilinx_pm_request(). Introduced the secure
zynqmp_pm_get_pmc_multi_boot_reg() call, which uses
xilinx_pm_request() to read the PMC multi boot mode register.
BootROM increments the MultiBoot register (PMC_MULTI_BOOT) read
address offset by 32 KB and retries. For SD and eMMC boot modes,
it can search up to 8191 FAT files for the identification string.
A 13-bit mask (0x1FFF) is applied to PMC_MULTI_BOOT_MASK to obtain
the correct values in BootROM.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250305134845.3182193-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Added extended support for retrieving the boot mode register
via the firmware interface, which is preferred when U-Boot
runs in EL2 and cannot directly access CRP registers via raw
reads. Ideally, all secure registers should be accessed via
xilinx_pm_request(). Introduced the secure zynqmp_pm_get_bootmode_reg()
call, which uses xilinx_pm_request() to read the boot mode register.
When CONFIG_ZYNQMP_FIRMWARE is enabled, the secure
zynqmp_pm_get_bootmode_reg() call is used; otherwise,
direct raw reads are performed in the case of mini U-Boot.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250219115301.3661036-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
A small fix for the cr50 which is a TPM but doesn't support all
the TPM functionality. Since it deviates from our normal TIS compliant
TPMs it can't be started twice since running the selftests twice hangs.
When FIT image with multiple dtbs are involved for R5 boot process,
R5 SPL starts off with the first instance of dtb to probe the
eeprom, then once we have identified the type of board, invocation
of setup_multi_dtb_fit will replace the gd->fdt_blob with the proper
board dtb match. However, when we do this, two things happen:
a) Prior to the invocation of setup_multi_dtb_fit, as part of the eeprom
discovery process, i2c controller device is already probed and marked
as exclusive with the match of the very first tisci match (from the
original boot dtb). This list is stored in the info->dev_list of the
first probe.
b) When the second dtb is loaded, tisci is probed again (since this is a
new node) and the new info->dev_list is empty.
At this stage, the exclusive devices such as i2c instances used to
probe the board information is left in the old info->dev_list that is
no longer used actively by the system using the replaced dtb.
As a result of this, the cleanup we intend to do with
ti_sci_cmd_release_exclusive_devices is no longer complete and
leaves the instances such as i2c for eeprom marked used as we scan just
the new info->dev_list.
This creates a problem when Device Manager(DM) firmware starts up later
on in the boot process and identifies that this instance of i2c is
already marked active, so it assumes this can no longer be controlled
by software and is marked internally as reserved and HLOS can no
longer control these instances. This defeated the purpose of
ti_sci_cmd_release_exclusive_devices.
NOTE: This scheme works just fine if the FIT has just a single dtb as
the info->dev_list is upto date.
To fix this, let us make ti_sci_cmd_release_exclusive_devices scan the
all registrations of tisci instances and cleanup all exclusive devices
that have ever been registered.
As part of this, change the prototype of release_exclusive_devices to
drop the handle since that has no further meaning now.
Though this issue was identified on AM64-sk, this can be present in
other builds which use multi-fit-dtb for R5 SPL startup.
Fixes: 9566b777ae ("firmware: ti_sci: Add a command for releasing all exclusive devices")
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
The tpm_auto_start() function is used in tests and assumes that it can
open the TPM even if it is already open and a locality claimed. The cr50
driver does not use the common TPM2 TIS code so lacks a check for the
is_open field of struct tpm_chip and in fact it doesn't use that struct.
Add an equivalent check to cr50_i2c_open().
This fixes all init sequences on that TPM -- e.g 'tpm init && tpm init'
or 'tpm autostart && tpm init' used to hang
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
