| Age | Commit message (Collapse) | Author |
|---|
|
area"
Aristo Chen <[email protected]> says:
vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on
a block device and then issues a follow-up blk_read() to pull in the
image, and optionally an FDT, referenced by the FIT's image node. The
source offset on the device and the read length both come from the FIT
itself, via data-position or data-offset and data-size. Those properties
live on mutable boot media and can be controlled by an attacker with
write access to the firmware area. On the TPL or VPL path, and on the
bootmeth bootflow path reached via abrec_read_bootflow_fw() and
vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any
signature or hash check on the loaded phase.
Patch 1 is a sandbox test-tree preparation. The firmware1 node in
arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but
the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT
inside it carries ~16 MiB of external data, so the FIT already extended
past the declared area. The mismatch was tolerated because no caller
bounded the external-data load against area_size. Patch 1 raises
area-size to match the binman section size so test_vbe_vpl keeps passing
once the bound is enforced. The patches are ordered so the test is never
broken in the middle of the series.
Patch 2 adds the missing range check, confining the FIT-supplied
[load_addr, load_addr + len) window to [addr, addr + area_size] before
block numbers and lengths are computed, and applying the same constraint
to fdt_load_addr and fdt_size. The check is written in subtraction-only
form against the trusted area_size so the comparison cannot itself
overflow.
Patch 3 adds two sandbox unit tests under test/boot/ that construct
synthetic FITs with out-of-range data-position and oversized data-size,
write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each
before issuing the follow-up blk_read().
Deferring the external-data blk_read() until after the phase has been
signature-verified would be a stronger structural fix and was discussed
on the v1 thread. Simon confirmed the bounded read is the right first
step and that the verify-then-load change should be a separate series,
so this v3 stays scoped to the bound.
Link: https://lore.kernel.org/r/[email protected]
|
|
The firmware1 node in test.dts declares area-size = 0xe00000 (14 MiB)
but the binman fw-update section in sandbox_vpl.dtsi is 0x2000000
(32 MiB) and the FIT inside it carries ~16 MiB of external data
(spl + u-boot subimages). The FIT therefore extends past the
declared firmware area, contradicting the documented contract of
vbe_read_fit() that the FIT must fit within @area_size.
The mismatch was tolerated because no caller actually bounded the
external-data load against area_size. Bring the devicetree in line
with the binman section size so the FIT extent stays within the
trusted firmware area, in preparation for vbe_read_fit() enforcing
that bound.
state-offset and version-offset are left as-is; they were already
inside the FIT data region and are not exercised by test_vbe_vpl.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
Paresh Bhagat <[email protected]> says:
This series adds support for DM firmware reserved memory fixup in device
tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled).
The series includes:
1. Fix for phandle corruption in FDT reserved memory fixup
2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups
3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs
4. Add DM reserved memory fixup implementation
The main issue being addressed is that the current reserved DDR carveout
for DM firmware in device tree is insufficient to accommodate the DM
firmware binary on AM62A7, and potentially other K3 SoCs in the future.
Currently, the size is only modified for AM62A7 SoC. For rest of SocS
existing values from device tree is taken.
For vendor boards, please verify boot and check for errors if any.
This series depends on dts update for effected devices. If "dm" node is
not found then the existing mechanism creates a new node with same
address, which cause memory overlap issue.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for fixing up DM firmware reserved memory in the kernel
device tree for K3 SoCs that use separate DM firmware.
The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and
CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the
reserved-memory node with the correct DM firmware carveout.
Note that the fixup needs DM reserved memory node is to be renamed in
dts. Example memory@9c900000 → dm@9c900000
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
Add Kconfig options for DM firmware reserved memory for K3 SOCs that
support DM firmware (K3_DM_FW enabled)
- K3_DM_FW_RESERVED_ADDR: DM firmware address
- K3_DM_FW_RESERVED_SIZE: DM firmware reserved size
These configs will be used to fixup the kernel device tree's reserved
memory node for DM. Currently the fixup is only done for AM62A7 SoC, as
K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from
0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to
accommodate the binary.
For other platforms, the addresses and sizes are based on the existing
device tree reserved memory. If needed for other SoCs, address and size
could be modified in Kconfig.
Signed-off-by: Paresh Bhagat <[email protected]>
|
|
Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to
the dtb before passing to kernel.
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
Fix phandle corruption in fdt_fixup_reserved_memory()
The original implementation used a delete/recreate approach:
- Find existing reserved memory node (e.g. tfa@80000000)
- Delete the entire node with fdt_del_node()
- Create new node with fdtdec_add_reserved_memory()
This worked fine for ATF and OPTEE nodes because no other device tree
nodes reference them via phandles but other nodes example DM are
referenced by R5 nodes.
If these nodes are deleted and recreated, it will not have any phandle
property but the nodes referencing it will still contain the old
phandle, causing initialization to fail.
Update nodes in-place instead of delete/recreate to update only the
"reg" property using fdt_setprop().
Fixes: 8b0fc29de0e3 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT")
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
With all AM62x family boards (TI EVMs, phytec phycore, toradex
verdin) now using per-security-state FIT configurations and selecting
the right one via board_fit_config_name_match(), the runtime filter
in board_fit_image_post_process() that zero'd out *p_size for the
wrong tifsstub variant is no longer reached. Only one tifsstub
variant is present in the selected FIT configuration, and it is
always the correct one for the current silicon.
Drop the filter so board_fit_image_post_process() simply debug-logs
the variant name and returns.
Acked-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on Verdin AM62 and AM62P
SoMs at FIT config selection time.
The k3-am625-verdin-wifi-dev-binman.dtsi and
k3-am62p5-verdin-wifi-dev-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each verdin board file forwards to
the shared K3 helper. The previous implementation returned 0
unconditionally which matched the first listed configuration
regardless of the actual silicon, which after the dtsi split would
load the wrong tifsstub variant on HS-SE parts.
Signed-off-by: Aristo Chen <[email protected]>
|
|
Use the k3_fit_config_match_security_state() helper introduced in the
earlier "arm: k3: select tifsstub via board_fit_config_name_match"
patch to pick the right tifsstub variant on phycore AM62x and AM62Ax
SoMs at FIT config selection time.
The k3-am625-phycore-som-binman.dtsi and
k3-am62a-phycore-som-binman.dtsi FIT images are split into
per-security-state configurations (conf-hs-se, conf-hs-fs), and
board_fit_config_name_match() in each phycore board file forwards to
the shared K3 helper.
Signed-off-by: Aristo Chen <[email protected]>
|
|
TI K3 AM62x/AM62Ax/AM62Px boards carry two or three mutually-exclusive
tifsstub variants in their tispl.bin FIT images, all at the same load
address. The existing approach loads every variant and then discards
the wrong ones at runtime via a *p_size = 0 hack in
board_fit_image_post_process(). Switch to selecting the appropriate
FIT configuration up front via board_fit_config_name_match() so only
the correct tifsstub is loaded in the first place.
board_fit_config_name_match() is invoked by the R5 SPL during FIT
config selection. get_device_type() is a simple register read that is
available at that point, so the security state can be determined
early. The matching logic is factored into
k3_fit_config_match_security_state() in arch/arm/mach-k3/common.c so
it can be shared by any K3 board that wants this scheme. It matches
configurations by a suffix appended to the description string:
-hs-se -> HS-SE (K3_DEVICE_TYPE_HS_SE)
-hs-fs -> HS-FS (K3_DEVICE_TYPE_HS_FS)
-gp -> GP (K3_DEVICE_TYPE_GP)
Configurations without a security-state suffix (e.g. u-boot.img) do
not match and fall through to the DTS-specified default config
naturally.
Each TI EVM board defines its board_fit_config_name_match() as a thin
wrapper around the shared helper:
- board/ti/am62x/evm.c (AM625 SK: hs-se, hs-fs, gp)
- board/ti/am62ax/evm.c (AM62A SK: hs-se, hs-fs, gp)
- board/ti/am62px/evm.c (AM62P SK: hs-se, hs-fs, gp)
FIT configurations are split per security state in:
- arch/arm/dts/k3-am625-sk-binman.dtsi
(ti-falcon, ti-spl, ti-spl_unsigned: conf-hs-se/conf-hs-fs/conf-gp)
- arch/arm/dts/k3-am62a-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62A)
- arch/arm/dts/k3-am62p-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62P)
The runtime filter in board_fit_image_post_process() is intentionally
left in place. It becomes redundant once every board using the AM62x
family dtsi files migrates to per-state configurations. The dtsi for
phytec phycore and toradex verdin boards is updated by separate
patches in this series, and the now-redundant runtime filter is
removed by the final patch in the series.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
In warm reset, the value of CTRLMMR_MCU_RST_SRC was not being reset.
This leads to a reset-loop boot failure when a warm reset is triggered
from the MAIN domain (by writing 0x2006 to MCU_RST_CTRL).
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Bryan Brattlof <[email protected]> says:
Someone figured out that we do not wait long enough for the DDR chip to
be ready during initializing. During that debug it was also discovered
we don't handle warm resets correctly. These 2 patches should fix this.
I don't have a scope fast enough to prove these patches have fixed the
reported issues but I am boot testing (cold and warm resets) with a BBB
at my desk which seems to be OK with these applied.
With how old these platforms are I doubt we will see any issue on our
current devices and probably need a different DDR part to see any
stability improvements but these should help stabilize board wakeups
with different DDR parts.
Link: https://lore.kernel.org/r/[email protected]
|
|
During a warm reset, the DDR controller will be put into a self refresh
state and will exit self refresh on reset release which will put the
controller in a ready state during bootup.
However we will reinitialize the controller regardless which will
temporarily (~6us) glitch the DDR_RESET line low
Fix this by checking if the VTP controller is already in a ready state
before we initialize the controller unnecessarily.
Fixes: 3ba65f97cbed ("am33xx: refactor emif4/ddr to support multiple EMIF instances")
Signed-off-by: Bryan Brattlof <[email protected]>
|
|
With the Beaglebone Black the delay on DDR_RESET to DDR_CKE is currently
~135us and not the >500us required by JEDEC spec.
The issue here is the REF_CTRL register performs two purposes. It is the
counter for CKE to RESET delay before the DDR controller is initialized
and used to configure the refresh rate after initialization of the
controller.
So to avoid inadvertently configuring the CKE to DDR delay, ensure we
initialize the controller before we configure the refresh rate.
Fixes: 69b918b65d11 ("am33xx,ddr3: fix ddr3 sdram configuration")
Signed-off-by: Bryan Brattlof <[email protected]>
|
|
Add a UCLASS_I2C_EMUL driver that emulates a PMBus 1.x compliant chip
behind the sandbox I2C bus, plus the test.dts wiring and sandbox
defconfig that bind it to the generic PMBus regulator
(compatible = "pmbus"). This design is a stub only: it lets the
follow-up dm unit test drive lib/pmbus.c, the generic regulator and
the pmbus CLI command with no real hardware.
The emulator models a flat per-command 16-bit register file and the
three identification block strings (MFR_ID / MFR_MODEL /
MFR_REVISION). READ_IIN and READ_POUT are deliberately left
unimplemented (the chip NAKs them) so the telemetry printer's
"(not supported)" path is exercised, mirroring a real buck that only
calibrates a subset of the sensor classes.
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Wire board/nxp/common/vid.c into the <pmbus.h> framework so the legacy
NXP AVS path stops carrying its own duplicate copy of the PMBus
protocol and instead consumes the shared constants, decoders, and
transport helpers.
vid.c is the legacy NXP AVS/pre-kernel voltage-trim path for lx2160 CPUs.
It does PMBus to whichever core-rail voltage monitor the board carries:
LTC3882 or ISL68233 are selected with
CONFIG_VOL_MONITOR_LTC3882_*/CONFIG_VOL_MONITOR_ISL68233_*.
Before this change the file kept its own local PMBUS_CMD_* command-code
defines, its own inline LINEAR16 mantissa/exponent math, and called
into I2C through the I2C_READ/I2C_WRITE NXP wrappers in
board/nxp/common/i2c_common.{c,h} which is a parallel implementation of
exactly what <pmbus.h> + lib/pmbus.c provides.
The intent is to make vid.c an consumer of the new PMBus.
Compatibility with the former support:
- CLI unchanged: vdd_override and vdd_read keep their existing
semantics, return codes, and diagnostic output.
- I2C transport unchanged on the wire: the framework's pmbus_*
helpers call dm_i2c_read/dm_i2c_write: the same DM I2C
backing that vid.c's former I2C_READ/I2C_WRITE macros already
routed through on DM_I2C.
- Numeric decode is bit-equivalent: pmbus_reg2data_linear16() and
pmbus_data2reg_linear16() implement the PMBus 1.3 Part II
mantissa/exponent.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip/-/pipelines/597
- Add new rockchip custodian,
- Remove inactive rockchip custodian,
- Preemptively fix rk3528/rk356x DTS issue that will come with 7.1
upstream DTS sync,
- Fix typo in doc,
- Fix variable used before being set in rockchip_nfc,
- Fix asm-operand-widths clang warning for RK3528, RK3576 and RK3588,
- Work around HW undefined state for NVMEs on RK3588 Jaguar,
- Added support for new devices:
- LinkEase EasePi R1
- 9Tripod X3568 v4
|
|
As it is, an NVMe's built-in PERSTN pull-up fights against the
SoC's built-in pull-down which results in an undefined logic state
on the Samsung SSD 980 and likely others.
Fix that by forcing PERSTN low as early as possible, which is SPL.
Both Linux and U-Boot (via "pci enum") set the pin high later
as needed and the NVMe is detected fine.
Oscillocope shots ("x" means undefined logic state at around 1.5V):
Before:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____xxxxxxxxxxxxxxx_|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
After:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____x_______________|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
With this change, the power-up sequence conforms to PCIe specs,
except a remaining short PERSTN glitch. The glitch is about 400ms
long. It could be shortened by moving the logic to TPL, but
completely fixing it is only possible in hardware.
Signed-off-by: Jakob Unterwurzacher <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/20260625-pub-jaguar-puma-ringneck-tiger-v2025-07_nvme-v2-1-c57bf1020d63@cherry.de
Signed-off-by: Quentin Schulz <[email protected]>
|
|
CONFIG_COUNTER_FREQUENCY is currently 24000000 for all SoCs, meaning it
fits in a 32b type. For 64b SoCs, it's an issue since the registers are
64b.
clang complains that we're trying to fit a 32b value into a 64b
register:
arch/arm/mach-rockchip/rk3528/rk3528.c:98:45: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths]
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^
include/generated/autoconf.h:372:34: note: expanded from macro 'CONFIG_COUNTER_FREQUENCY'
372 | #define CONFIG_COUNTER_FREQUENCY 24000000
| ^
/home/qschulz/work/upstream/u-boot/arch/arm/mach-rockchip/rk3528/rk3528.c:98:32: note: use constraint modifier "w"
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^~
| %w0
Even though cntfrq_el0[1] is only using the 32b LSB of its 64b, use the
'x' operand modifier[2] to force the value to be 64b and fix the
warning.
[1] https://developer.arm.com/documentation/ddi0601/2026-03/AArch64-Registers/CNTFRQ-EL0--Counter-timer-Frequency-Register?lang=en
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AArch64-Operand-Modifiers
Suggested-by: Mark Kettenis <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The <soc>-u-boot.dtsi OTP nodes for RK3528/RK356x use different names
compared to the OTP nodes that was merged in Linux v7.1. This causes
build issues when dts/upstream pulls in updated DTs, i.e.:
ERROR (duplicate_label): /soc/nvmem@ffce0000: Duplicate label 'otp'
on /soc/nvmem@ffce0000 and /soc/efuse@ffce0000
ERROR (duplicate_label): /nvmem@fe38c000: Duplicate label 'otp'
on /nvmem@fe38c000 and /efuse@fe38c000
Align the OTP node names in <soc>-u-boot.dtsi with the node names used
in upstream Linux v7.1 to avoid build issues when latest DTs are synced.
Also drop the unused RK356x id@a subnode as it has moved under a
nvmem-layout node in the merged upstream DT.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
This patch series add pin controller and gpio driver support for EN7523/
AN7581/AN7583 SoCs. The driver based on official linux airoha pinctrl
and gpio driver with Matheus Sampaio Queiroga changes.
The original Matheus Sampaio Queiroga driver can be taken from the repo:
https://sirherobrine23.com.br/airoha_en7523/kernel/src/branch/airoha_en7523_pinctrl
Additionally in the EN7523 case the patches removes existing gpio dts
nodes and replaces them with pinctrl node. It should not be very
dangerous, because:
* No official EN7523 gpio support present in U-Boot
* Legacy Linux EN7523 GPIO driver is mostly abandoned
* The same driver is planned for upstream linux/openwrt
This patchset includes bitfield.h patches created for Linux kernel by
Geert Uytterhoeven. It suits U-Boot fine. I preserve original author and
original commit messages. Please note me, if there is a better way.
The patches were tested on EN7523/AN7581/AN7583 boards.
Link: https://lore.kernel.org/r/[email protected]
|
|
This patch adds pinctrl/gpio dts nodes for airoha pinctrl driver.
It also removes legacy gpio nodes.
It should not be very dangerous, because:
* No official EN7523 gpio support present in U-Boot
* The same driver is planned for upstream linux/openwrt
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
Fix indentation issues where spaces were used instead of tabs in several
ZynqMP device tree overlay files. Device tree files should use tabs for
indentation to maintain consistency with the kernel coding style.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/0dc7b65ebd48676719ace15a505ecec2f324822a.1782726386.git.michal.simek@amd.com
|
|
Add missing newline available in Linux already.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/ab6f006ee87efb54ee17f24a12c9f31aafc2f2ae.1782726386.git.michal.simek@amd.com
|
|
ina226 IIO driver doesn't need to be enabled by default in Linux that's why
disable iio-hwmon nodes to avoid warnings about it.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/deb2e92d5030a31dbb91b36fa77de3ad2de38a71.1782726386.git.michal.simek@amd.com
|
|
Add fixed RTC clock nodes at 32.768 kHz for ZynqMP. The RTC driver uses
this clock to calculate the calibration value, replacing the deprecated
calibration device tree property.
Signed-off-by: Harini T <[email protected]>
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/8838c8c4fcd0dfe151bcee2a6c4da51df81e23cb.1782726386.git.michal.simek@amd.com
|
|
zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO
and the firmware (PM_MMIO_READ/WRITE) interface with an in-function
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch
code should not carry firmware-specific ifdefs, and with SCMI the access
method changes again.
Split the accessors like the multiboot and bootmode hooks: the weak
default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL,
at EL3 and when no firmware is present), while firmware-zynqmp.c provides
a strong definition that issues the firmware call and falls back to the
direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO
primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported
for the shared fallback, and the read-modify-write helper now uses the
raw read instead of routing through the firmware-aware accessor.
The firmware-vs-MMIO decision is selected at link time, so adding SCMI
later only requires a third strong definition with no changes to generic
code.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d532df144d2c8e34be835bad6d0de3b26befdf01.1782219202.git.michal.simek@amd.com
|
|
versal_net_get_bootmode() open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like
the Versal change, move the whole function behind an overridable hook so
generic board code stays free of firmware specifics and is ready for
SCMI.
The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the
plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3
and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/be67e9c6d0bc36840a46594413886d2003967c64.1782219202.git.michal.simek@amd.com
|
|
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal-net where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/8757111cb254543d61541fb030d51f62c3c555a8.1782219202.git.michal.simek@amd.com
|
|
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal2 where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/c332ab27f66f1c808f32a4bcb453d9e8da543331.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the system timestamp counter directly
with readl()/writel() in board code. This is SoC register setup rather
than board policy, and similar code exists across the Xilinx SoCs.
Move it into zynqmp_timer_setup() in arch/arm/mach-zynqmp so the board
hook only keeps the EL3 guard and calls the helper. The asm/arch/clk.h
include (for zynqmp_get_system_timer_freq()) moves to cpu.c along with
the code.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/2d8f2419fab314b4ff8fd53b846e1dd6151586d3.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_net_timer_setup() in arch/arm/mach-versal-net so the
board hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/10dd9f35d03be0402ce13475f20b2cd3761189a6.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal2_timer_setup() in arch/arm/mach-versal2 so the board
hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_timer_setup() in arch/arm/mach-versal so the board
hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/2234d746ab5b8240e88b1a629d51f93751ee3b60.1782219202.git.michal.simek@amd.com
|
|
versal_get_bootmode() lived in board code and open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board
code free of firmware specifics and SoC register details and ready for
SCMI, move the whole function, including the alt-shift and mask decoding,
behind an overridable hook.
The weak versal_get_bootmode() in arch/arm/mach-versal does the plain
MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and
without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com
|
|
versal_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal_multi_boot_reg() so the firmware override does not duplicate it.
versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface for the multiboot register. The firmware-vs-MMIO decision is
selected at link time, and adding SCMI later only requires a third strong
definition with no board-code changes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.1782219202.git.michal.simek@amd.com
|
|
versal2_get_bootmode() lived in board code and accessed the CRP boot
mode register with a direct readl(). To keep generic board code free of
SoC register details and ready for firmware/SCMI based access, move the
whole function, including the alt-shift and mask decoding, into
arch/arm/mach-versal2 as a __weak default.
Board code now simply calls versal2_get_bootmode(). When a firmware
based implementation is available and tested it can provide a strong
definition that overrides the weak one at link time; until then only the
weak MMIO version is built.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/f3274ec77218373bc0452f6795a3ad6016be0058.1782219202.git.michal.simek@amd.com
|
|
versal2_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal2_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal2 and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal2_multi_boot_reg() so the firmware override does not duplicate it.
versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface and the now unused zynqmp_firmware.h include is dropped. The
firmware-vs-MMIO decision is selected at link time, and adding SCMI later
only requires a third strong definition with no board-code changes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com
|
|
The Versal and Versal Gen 2 mach sys_proto.h headers lacked an include
guard. mach-versal/sys_proto.h additionally defines enum tcm_mode, so
including it twice in one translation unit fails to build with a
redeclaration error.
This is about to happen in firmware-zynqmp.c, which needs the SoC
prototypes unconditionally for the upcoming weak/strong multiboot and
bootmode accessors. Add the standard _ASM_ARCH_SYS_PROTO_H guard, as
already used by mach-zynqmp, so the header can be included more than once.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com
|
|
AM011 Versal ACAP TRM, Table 43, defines:
- 0x006_0000_0000 - 0x007_FFFF_FFFF PCIe region 1
- 0x008_0000_0000 - 0x00F_FFFF_FFFF DDR controller 0 region 1
- 0x040_0000_0000 - 0x04F_FFFF_FFFF HBM0
- 0x050_0000_0000 - 0x05F_FFFF_FFFF HBM1
- 0x060_0000_0000 - 0x06F_FFFF_FFFF HBM2
- 0x070_0000_0000 - 0x07F_FFFF_FFFF HBM3
- 0x080_0000_0000 - 0x0BF_FFFF_FFFF PCIe region 2
- 0x0C0_0000_0000 - 0x0FF_FFFF_FFFF DDR controller 0 region 2
The old static normal-memory mapping spans PCIe, while DDR coverage is
already populated later from the DRAM banks discovered by mem_map_fill().
Drop the stale static mapping so the MMU table matches the Versal address
map. Also matting was using wrong attributes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/6fad36f9e7abdfee2fd29943f3a5b63d1421eaf9.1781179823.git.michal.simek@amd.com
|
|
DDR coverage is already populated later from the DRAM banks discovered by
mem_map_fill(). Drop the stale static mappings so the MMU table matches
address map more closely.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/156e48d8228acfeba8866618038b48cd51490ea7.1781179823.git.michal.simek@amd.com
|
|
There is no reason to have non zynqmp-sc compatible string for overlays
which can be applied only with SCs.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/4192927ae769e74e4ddbc1cc9814ed0305b64a5d.1780991287.git.michal.simek@amd.com
|
|
The "label" property is not documented for the dlg,slg7xl45106. Nor is
it common to use for GPIO controllers. So drop it.
Signed-off-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/32c5b160de5b8e5ffb91366cbafac0b5fd5c834a.1780991287.git.michal.simek@amd.com
|
|
Fix descriptions that don't match their filenames:
- zynqmp-sc-vpk180-revB.dtso: described as revA instead of revB
- zynqmp-sck-kv-g-revB.dtso: described as revA instead of revB
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/456e4ff541c60355aa3d35627ec481263113349e.1780991287.git.michal.simek@amd.com
|
|
Add fixed supply regulators for the onboard USB hub (USB2744) used on
Kria platforms.
The USB hub requires two always-on power rails:
- vdd: 3.3V main supply
- vdd2: auxiliary supply
Model these rails as fixed regulators and reference them from the hub
node to accurately describe the hardware.
Signed-off-by: Shaikh Mohammed Suhan <[email protected]>
Reviewed-by: Radhey Shyam Pandey <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/541ee484c0f73fda630022528ddc56d01a481bca.1780991287.git.michal.simek@amd.com
|
|
Add CMA (Contiguous Memory Allocator) reserved-memory regions to all
Xilinx arm64 board device trees to support runtime FPGA programming.
The CMA pool uses dynamic allocation constrained to the low 2 GB DDR region
via alloc-ranges so that the kernel places it within the 32-bit addressable
space.
CMA sizes are chosen per silicon family to accommodate the maximum PL
bitstream/PDI size:
- Kria K24 SOM: 64 MB
- ZynqMP boards: 128 MB
For Kria K24 SOM the CMA inherited from K26 is overridden to 64 MB.
For Kria SOMs, the CMA node is added to the SOM DTS only, not to
carrier board overlays.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/837e21582e886f1be9f95901109745ac5a8b2a25.1780991287.git.michal.simek@amd.com
|
|
Describe flash and NAND MTD partitions using the fixed-partitions
compatible under a dedicated partitions subnode. U-Boot only creates
slave MTD devices from this binding in add_mtd_partitions_of(), so
mtd list can show named partitions.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/a9e72b2c62e1b2e5c485302a861e5bae55ec2b83.1780991287.git.michal.simek@amd.com
|
|
The #phy-cells property is meant for generic PHY providers
(Documentation/devicetree/bindings/phy/phy-bindings.txt) and is not a
valid property for ethernet-phy nodes. Its presence triggers a
dt-validate warning:
ethernet-phy@x (ethernet-phy-id001c.c816): Unevaluated properties
are not allowed ('#phy-cells' was unexpected)
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/d50e4ed12227609f3f827acde885c1d37782b8a9.1780991287.git.michal.simek@amd.com
|
