summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-28cmd: Kconfig: Fix typosAristo Chen
fix the following typos - from "categorys" to "categories" - from "indivdually" to "individually" Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]>
2025-04-28cros_ec_sandbox.c: Drop spi.h includeTom Rini
As this driver needs to use the special sandbox <asm/malloc.h> header rather than normal malloc, it must be careful of the includes it brings in. It does not need <spi.h> for anything, so drop it. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2025-04-28net: ti: am65-cpsw-nuss: invoke phy_config() in driver's .start callbackSiddharth Vadapalli
Currently, the phy_config() API is invoked by the driver only once since it has been probed. While this works in general, it doesn't allow the driver to bring the PHY back to its default reset state. As a result, the driver might not be able to recover the PHY from a bad state. To address this, move phy_config() into the driver's start callback (am65_cpsw_start()). Apart from providing the means to recover the PHY in the event of failure, the implementation is in line with the idea of "reset and configure" that is already followed by am65_cpsw_start() when it comes to programming the CPSW MAC. Signed-off-by: Siddharth Vadapalli <[email protected]>
2025-04-28Merge patch series "Apple RTKit improvements"Tom Rini
Mark Kettenis <[email protected]> says: This is a collection of improvements for the Apple RTKit code that we have been carrying downstream for some time now. Link: https://lore.kernel.org/r/[email protected]
2025-04-28arm: apple: rtkit: Support allocating OSLog out of SRAM in helperHector Martin
The new OSLog region in MTP (firmware 13.3+) persists on handoff to Linux. To avoid having to come up with some weird DART handoff or DAPF tricks, let's just steal some of the coprocessor's dedicated SRAM. This keeps it happy and Linux doesn't need any special handoff then. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add endpoint field to buffersHector Martin
To be used for special-case oslog support in rtkit-helper. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add OSLog buffer supportHector Martin
This will work for u-boot itself, but needs a special workaround in the MTP driver for Linux handoff to work. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add a generic RTKit helper driverHector Martin
This driver handles the MTP ASC coprocessor, which does not need any special handling on the RTKit side and communicates out-of-band. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add default buffer handlersHector Martin
For devices without specific buffer methods, just assume we can give them raw memory pointers when they request a buffer. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add support for AP power & syslogsHector Martin
This is required for MTP to work properly Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28Merge tag 'u-boot-imx-master-20250428' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-imx CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25974 - Fix power-domain ref counting regression. - Fix i.MX8MP USB clock regression. - Fix i.MX8MM osc_32k regression in SPL. - Finish converting clock-osc-24 back to osc_24 on i.MX. - Several imx8mp capricorn updates. - Update Stefano Babic's email address. - Fix fsl_qspi bug by moving AHB read buffer config after LUT. - Fix verdin imx95 sku 0089 pid4.
2025-04-28Merge patch series "bloblist: fix the overriding of fdt from bloblist"Tom Rini
This series from Raymond Mao <[email protected]> fixes some cases of passing the device tree to U-Boot via standard passage and then ensures that we set the environment variable of the device tree correctly in this case. Link: https://lore.kernel.org/r/[email protected]
2025-04-28Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini
We have improvements to the reliability of H6 and H616 DRAM initialisation, hopefully avoiding those occasional size misdetections many people reported before. Also there is some modernisation of the USB PHY code, to use DT provided regulators and GPIOs, instead of relying on this being badly duplicated in Kconfig. This also happens to fix broken USB operations for older boards (using the A20 SoCs, for instance), which were clashing over grabbing some GPIOs, leading to a driver bailout. There is also some rework of the H6/H616 SPL clock code, to prepare it for being reused by the upcoming Allwinner A523 support. This drops the usage of C structs to model MMIO register frames, and replaces them by using an addition of the base address with a macro defined offset. Also in preparation for A523 there is one fix and one addition for the FEL code, to prepare for the GICv3 interrupt controller that the new SoC uses. And since this is a simple fix, and was ready, there is also the watchdog driver for that new SoC. Finally tossing in an easy fix to some H616 defconfig files to enable eMMC. I also use the opportunity to enable proper page table protection (observing read-only and no-execute attributes), support for which the arm64 port recently gained. I didn't spot any issues on my arm64 board tests, but it can be easily disabled or backed out again in case any issues arise. Full support for the two new SoC series (A133 and A523) we are working on is not quite ready yet, but might follow still a bit later if progress permits. CI passed, and boot-tested on at least one board with a H616, H6, A64, H3, A20, T113s.
2025-04-28sunxi: clock: H6: remove struct sunxi_prcm_regAndre Przywara
With the SPL clock code and the DRAM init routine we converted all users of the H6 class "struct sunxi_prcm_reg" over to use #define'd register offsets now. Drop the whole definition of this struct now, since it's not needed anymore, for all H6 and H616 boards. This removes the entire fragile and questionable definition, and allows new SoCs to share the code more easily. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: H6/H616: dram: remove usage of struct sunxi_prcm_regAndre Przywara
The Allwinner H6 and H616 DRAM initialisation code uses a complex C struct, modelling the PRCM clock register frame. For those SoCs, this struct contains 20 registers, but the DRAM code only uses two of them. Since we want to get rid of this struct, drop the usage of the struct in the H6 and H616 DRAM code, by using #define'd register names and their offset, and then adding those names to the base pointer. This removes one more user of the PRCM clock register struct. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: clock: H6: drop usage of struct sunxi_prcm_regAndre Przywara
U-Boot drivers often revert to using C structures for modelling hardware register frames. This creates some problems: - A "struct" is a C language construct to group several variables together. The details of the layout of this struct are partly subject to the compiler's discretion (padding and alignment). - The "packed" attribute would force a certain layout, but we are not using it. - The actual source of information from the data sheet is the register offset. Here we create an artificial struct, carefully tuning the layout (with a lot of reserved members) to match that offset. To help with correctness, we put the desired information as a *comment*, though this is purely for the human reader, and has no effect on the generated layout. This sounds all very backwards. - Using a struct suggests we can assign a pointer and then access the register content via the members. But this is not the case, instead every MMIO register access must go through specific accessor functions, to meet the ordering and access size guarantees the hardware requires. - We share those structs in code shared across multiple SoC families, though most SoCs define their own version of the struct. Members must match in their name, across every SoC, otherwise compilation will fail. We work around this with even more #ifdefs in the shared code. - Some SoCs have an *almost* identical layout, but differ in a few registers. This requires hard to maintain #ifdef's in the struct definition. - Some of the register frames are huge: the H6 CCU device defines 127 registers. We use 15 of them. Still the whole frame would need to be described, which is very tedious, but for no reason. - Adding a new SoC often forces people to decide whether to share an existing struct, or to create a new copy. For some cases (say like 80% similarity) this works out badly either way. The Linux kernel heavily frowns upon those register structs, and instead uses a much simpler solution: #define REG_NAME <offset> This easily maps to the actual information from the data sheet, and can much simpler be shared across multiple SoCs, as it allows to have all SoC versions visible, so we can use C "if" statements instead of #ifdef's. Also it requires to just define the registers we need, and we can use alternative locations for some registers much more easily. Drop the usage of "struct sunxi_prcm_reg" in the H6 SPL clock code, by defining the respective register names and their offsets, then adding them to the base pointer. We cannot drop the struct definition quite yet, as it's also used in other drivers, still. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: clock: H6: remove struct sunxi_ccm_regAndre Przywara
With the SPL clock code, the MMC driver, and the DRAM init routine we converted all users of the H6 class "struct sunxi_ccm_reg" over to use #define'd register offsets now. Drop the whole definition of this struct now, since it's not needed anymore, for all H6 and H616 boards. This removes the entire fragile and questionable definition, and allows new SoCs to share the code more easily. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: H6: dram: remove usage of struct sunxi_ccm_regAndre Przywara
The Allwinner H6 DRAM initialisation code uses a complex C struct, modelling the clock device's register frame. For this SoC, the struct contains 127 registers, but the DRAM code only uses four of them. Since we want to get rid of this struct, drop the usage of the struct in the H6 DRAM code, by using #define'd register names and their offset, and then adding those names to the base pointer. This removes one more user of the clock register struct. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: H616: dram: remove usage of struct sunxi_ccm_regAndre Przywara
The Allwinner H616 DRAM initialisation code uses a complex C struct, modelling the clock device's register frame. For this SoC, the struct contains 127 registers, but the DRAM code only uses four of them. Since we want to get rid of this struct, drop the usage of the struct in the H616 DRAM code, by using #define'd register names and their offset, and then adding those names to the base pointer. This removes one more user of the clock register struct. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: mmc: remove usage of struct sunxi_ccm_regAndre Przywara
The Allwinner MMC code uses a complex C struct, modelling the clock device's register frame. We rely on sharing the member names across all Allwinner SoCs, which is fragile. Drop the usage of the struct in the MMC code, by using #define'd register names and their offset, and then adding those names to the base pointer. This requires to define those offsets for all SoCs, but since we only use between four and six clock registers in the MMC code, this is easily done. This removes one common user of the clock register struct. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: clock: H6: drop usage of struct sunxi_ccm_regAndre Przywara
U-Boot drivers often revert to using C structures for modelling hardware register frames. This creates some problems: - A "struct" is a C language construct to group several variables together. The details of the layout of this struct are partly subject to the compiler's discretion (padding and alignment). - The "packed" attribute would force a certain layout, but we are not using it. - The actual source of information from the data sheet is the register offset. Here we create an artificial struct, carefully tuning the layout (with a lot of reserved members) to match that offset. To help with correctness, we put the desired information as a *comment*, though this is purely for the human reader, and has no effect on the generated layout. This sounds all very backwards. - Using a struct suggests we can assign a pointer and then access the register content via the members. But this is not the case, instead every MMIO register access must go through specific accessor functions, to meet the ordering and access size guarantees the hardware requires. - We share those structs in code shared across multiple SoC families, though most SoCs define their own version of the struct. Members must match in their name, across every SoC, otherwise compilation will fail. We work around this with even more #ifdefs in the shared code. - Some SoCs have an *almost* identical layout, but differ in a few registers. This requires hard to maintain #ifdef's in the struct definition. - Some of the register frames are huge: the H6 CCU device defines 127 registers. We use 15 of them. Still the whole frame would need to be described, which is very tedious, but for no reason. - Adding a new SoC often forces people to decide whether to share an existing struct, or to create a new copy. For some cases (say like 80% similarity) this works out badly either way. The Linux kernel heavily frowns upon those register structs, and instead uses a much simpler solution: #define REG_NAME <offset> This easily maps to the actual information from the data sheet, and can much simpler be shared across multiple SoCs, as it allows to have all SoC versions visible, so we can use C "if" statements instead of #ifdef's. Also it requires to just define the registers we need, and we can use alternative locations for some registers much more easily. Drop the usage of "struct sunxi_ccm_reg" in the H6 SPL clock code, by defining the respective register names and their offsets, then adding them to the base pointer. We cannot drop the struct definition quite yet, as it's also used in other drivers, still. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: armv8: FEL: save and restore SP_IRQAndre Przywara
Thanks for Jernej's JTAG debugging effort, it turns out that the BROM expects SP_IRQ to be saved and restored, when we want to enter back into FEL after the SPL's AArch64 stint. Save and restore SP_IRQ as part of the FEL state handling. The banked MRS/MSR access to SP_IRQ, without actually being in IRQ mode, was introduced with the ARMv7 virtualisation extensions. The Arm Cortex-A8 cores used in the A10/A13s or older F1C100s SoCs would not support that, but this code here is purely in the ARMv8/AArch64 code path, so it's safe to use unconditionally. Reported-by: Jernej Skrabec <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: armv8: FEL: save and restore GICv3 registersAndre Przywara
To be able to return to the BootROM FEL USB debug code, we must restore the core's state as accurately as possible after the SPL has been run. Since the BootROM runs in AArch32, but the SPL uses AArch64, this requires a core reset, which clears the core's state. So far we were saving and restoring the required registers like SCTLR and VBAR, but could ignore the interrupt controller's state (GICC), since that lives in MMIO registers, unaffected by a core reset. Newer Allwinner SoCs now feature a GICv3 interrupt controller, which keeps some GIC state in architected system registers, and those are cleared when we switch back to AArch32. To enable FEL operation on the Allwinner A523 SoC, Add AArch32 assembly code to save and restore the ICC_PMR and ICC_IGRPEN1 system registers. The other GICv3 sysregs are either not relevant for the BROM operation, or haven't been changed from their reset defaults by the BROM anyway. This enables FEL operation on the Allwinner A523 family of SoCs. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28watchdog: sunxi: add A523 supportAndre Przywara
The Allwinner A523 SoC moved the watchdog into a separate MMIO frame, and also shifted the registers a bit: the control, config, and mode register are located four bytes earlier. Add the new compatible string, and connect it to the new struct describing the new register layout. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2025-04-28sunxi: Kconfig: Remove obsolete USBx_* pin symbolsAndre Przywara
Now that the USB PHY driver uses the device tree to get the VBUS detect and USB ID GPIOs, these Kconfig symbols are unused. Remove them from their Kconfig definition, and also from all defconfig files. Signed-off-by: Andre Przywara <[email protected]> Acked-by: Jernej Skrabec <[email protected]>
2025-04-28phy: sun4i-usb: Determine USB OTG detection pin from devicetreeAndre Przywara
So far Allwinner boards controlled the USB OTG ID detection via the respective GPIO pin specified in Kconfig, as a string. All boards should have the same GPIO already specified in the devicetree, in the usb0_id_det-gpios property. Convert the usage of the Kconfig configured GPIO over to query that information from the devicetree, then use the existing DM GPIO infrastructure to request the GPIO. Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to avoid claiming it multiple times. This removes the need to name that GPIO in the defconfig file. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28phy: sun4i-usb: Determine VBUS detection pin from devicetreeAndre Przywara
So far Allwinner boards controlled the USB VBUS detection via the respective GPIO pin specified in Kconfig, as a string. All boards should have the same GPIO already specified in the devicetree, in the usb0_vbus_det-gpios property. Convert the usage of the Kconfig configured GPIO over to query that information from the devicetree, then use the existing DM GPIO infrastructure to request the GPIO. Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to avoid claiming it multiple times. This removes the need to name that GPIO in the defconfig file. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28gpio: axp: Remove virtual VBUS enable GPIOSamuel Holland
Now that this functionality is modeled using the device tree and regulator uclass, the named GPIO is not referenced anywhere. Remove it, along with the rest of the support for AXP virtual GPIOs. Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: Remove obsolete USBx_VBUS_PIN Kconfig symbolsSamuel Holland
Now that the USB PHY driver uses the device tree to get VBUS supply regulators, these Kconfig symbols are unused. Remove them. Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Acked-by: Jernej Skrabec <[email protected]>
2025-04-28phy: sun4i-usb: Control supplies via the regulator uclassSamuel Holland
The device tree binding for the PHY provides VBUS supplies as regulator references. Now that all boards have the appropriate regulator uclass drivers enabled, the PHY driver can switch to using them. This replaces direct GPIO usage, which in some cases needed a special DM-incompatible "virtual" GPIO from the PMIC. The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are missing the "usb0_vbus-supply" property in their device tree. None of them have the MUSB controller enabled in host or OTG mode, so they should see no impact: - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1 - Ampe_A76_defconfig / sun5i-a13-ampe-a76 - CHIP_pro_defconfig / sun5i-gr8-chip-pro - Cubieboard4_defconfig / sun9i-a80-cubieboard4 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus - Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99 - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078 - Yones_Toptech_BS1078_V2_defconfig / sun6i-a31s-yones-toptech-bs1078-v2 - iNet_3F_defconfig / sun4i-a10-inet-3f - iNet_3W_defconfig / sun4i-a10-inet-3w - iNet_86VS_defconfig / sun5i-a13-inet-86vs - iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2 - icnova-a20-swac_defconfig / sun7i-a20-icnova-swac - sun8i_a23_evb_defconfig / sun8i-a23-evb Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not have "usb1_vbus-supply" in their device tree. Neither of them have USB enabled at all, so again there should be no impact: - Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3) - sun8i_a23_evb_defconfig / sun8i-a23-evb The following boards use a different pin for USB1 VBUS between their defconfig and their device tree. Depending on which is correct, they may be broken: - Linksprite_pcDuino3_Nano_defconfig (PH11) / sun7i-a20-pcduino3-nano (PD2) - icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6) Finally, this board has conflicting pins given for its USB2 VBUS: - Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12) Signed-off-by: Samuel Holland <[email protected]> [Andre: use regulator_set_enable_if_allowed()] Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: Enable PMIC drivevbus regulator support for USB suppliesSamuel Holland
On many boards, the USB ports are powered by the PMIC's "drivevbus" regulator. In preparation for switching the USB PHY driver to use the regulator uclass instead of a virtual GPIO pin, ensure these boards have AXP PMIC regulator support enabled. Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Acked-by: Jernej Skrabec <[email protected]>
2025-04-28power: regulator: Add a driver for the AXP PMIC drivevbusSamuel Holland
AXP PMICs have a pin which can either report the USB VBUS state, or driving a regulator that supplies USB VBUS. Add a regulator driver for controlling this pin. The selection between input and output is done via the x-powers,drive-vbus-en pin on the PMIC (parent) node. Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: enable MMU_PGPROT proper page table protectionAndre Przywara
Select the new MMU_PGPROT Kconfig symbol for all Allwinner board builds, to use a write-protected .rodata, non-executable .data and .rodata sections, and non-writable .text sections. This might trigger runtime exceptions in misbehaving drivers, which should then be fixed. Signed-off-by: Andre Przywara <[email protected]> Acked-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: h616: defconfigs: enable eMMCAndre Przywara
Now that eMMC is working properly on H616 devices, it became apparent that some boards were missing the right defconfig bits to enable eMMC access. Add the eMMC device number to the Tanix TX1 and the X96 Mate defconfig, also the eMMC boot option to the TX1. Oddly enough the X96 Mate had just this bit already. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]>
2025-04-28sunxi: h6/h616: Reuse common DRAM infrastructureJernej Skrabec
H616 rank and size detection code is superior to the H6. Nevertheless, they are structurally the same. Split functions from H616 into new file and reuse them in H6 DRAM driver too. This should also fix some bugs for H6 too, like incorrect DRAM size detection. Signed-off-by: Jernej Skrabec <[email protected]> [Andre: back out panic if test fails to allow 2^11 columns] Reviewed-by: Andre Przywara <[email protected]> Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: h6: dram: split dram_para structJernej Skrabec
This change is same as in commit 78aa00c38e86 ("sunxi: H616: dram: split struct dram_para"), but for H6. This is needed in order to extract common code between H6 and H616 later. Signed-off-by: Jernej Skrabec <[email protected]> Reviewed-by: Andre Przywara <[email protected]>
2025-04-28sunxi: H6: DRAM: Constify function parametersJernej Skrabec
Constify parameters for two reasons: - Allow more compile time optimizations - It will allow later sharing of common code with H616 (when it will be rearranged some more) Commit does same kind of changes as commit 457e2cd665bd ("sunxi: H616: dram: const-ify DRAM function parameters") Signed-off-by: Jernej Skrabec <[email protected]> Reviewed-by: Andre Przywara <[email protected]>
2025-04-28env: point fdt address to the fdt in a bloblistRaymond Mao
Point fdt_addr to the fdt embedded in the bloblist since fdt_addr is a default address for bootefi, bootm and booti to look for the device tree when launching the kernel. Signed-off-by: Raymond Mao <[email protected]>
2025-04-28bloblist: fix the overriding of fdt from bloblistRaymond Mao
When a bloblist is valid and contains fdt, it explicitly means a previous boot stage is passing transfer list compliant with Firmware Handoff specification, thus the fdt from bloblist should not be overridden with the ones from board or env variables. Fixes: 70fe23859437 ("fdt: Allow the devicetree to come from a bloblist") Signed-off-by: Raymond Mao <[email protected]> Reviewed-by: Caleb Connolly <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2025-04-28Merge tag 'u-boot-stm32-20250428' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-stm CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25970 - Add OF_UPSTREAM flag support for STi, STM32 MCU and MPU platforms. - Add ETZPC as system bus for STM32MP1 platforms - Add RIFSC as sytem bus for STM32MP2 platforms - Update STM32MP2 board/machine support: - update cmd_stm32key. - update cmd_stm32prog. - update STM32MP25 configs. - add leds and buttons support. - add boot_mode support (USB/PXE/MMC/NOR/NAND). - add bootcmd support. - enable MMC support.
2025-04-28siemens: imx8qxp: remove unused config fileHeiko Schocher
include/configs/giedi.h is not longer used after siemens imx8qxp cleanup series, so remove it. Signed-off-by: Heiko Schocher <[email protected]>
2025-04-28arm: imx8qxp: capricorn: move env offset settingsHeiko Schocher
move the ENV_OFFSET settings from common config settings file configs/imx8qxp_capricorn.config to defconfig file for the cxg3 board, as other imx8qxp based boards from siemens has the environment on other offsets. Signed-off-by: Heiko Schocher <[email protected]>
2025-04-28siemens: capricorn: defconfig updatesWalter Schweizer
add ahab command as secure boot is used on this boards, and enable watchdog, so U-Boot triggers it. Signed-off-by: Walter Schweizer <[email protected]> for respelling commit subject and message: Signed-off-by: Heiko Schocher <[email protected]>
2025-04-28siemens: capricorn: enable text based default environmentWalter Schweizer
enable text based default U-Boot Environment by enabling CONFIG_ENV_SOURCE_FILE and adding default environment file: board/siemens/capricorn/capricorn_cxg3.env Signed-off-by: Heiko Schocher <[email protected]> Signed-off-by: Walter Schweizer <[email protected]>
2025-04-28imx8qxp: capricorn defconfig: collect common Kconfig optionsHeiko Schocher
Siemens have some defconfigs for different hardware versions, all based on mainline cxg3 board. For easier updating the downstream defconfigs, move common settings into new file. configs/imx8qxp_capricorn.config Signed-off-by: Heiko Schocher <[email protected]> Signed-off-by: Walter Schweizer <[email protected]>
2025-04-28clk: imx: Pass CCM udevice into clk_register_composite()Marek Vasut
Pass the clock controller udevice into clk_register_composite(), so it can be passed further to any registered composite clocks and used for look up of parent clock referenced in DT "clocks" and "clock-names" properties by phandle and name pair. Use the clock controller udevice in imx8m_clk_mux_set_parent() to perform accurate look up of parent clock referenced in the CCM driver by name. If the clock name that is being looked up matches one of the names listed in the clock controller DT node "clock-names" array property, then the offset of the name is looked up in the "clocks" DT property and the phandle at that offset is resolved to the parent clock udevice. The test to determine whether a particular driver instance registered with clock uclass matches the parent clock is done by comparing the OF nodes of the clock registered with clock uclass and parent clock resolved from the phandle. Example: drivers/clk/imx/clk-imx8mm.c: static const char * const imx8mm_a53_sels[] = {"osc_24m", "arm_pll_out", ... _____________| arch/arm/dts/imx8mm.dtsi: | clk: clock-controller@30380000 { v clock-names = "osc_32k", "osc_24m", ... | v clocks = <&osc_32k>, <&osc_24m>, ... }; _______________________| ... | / { v osc_24m: clock-osc-24m { compatible = "fixed-clock"; ... }; Signed-off-by: Marek Vasut <[email protected]> Reported-by: Francesco Dolcini <[email protected]> Tested-by: Fabio Estevam <[email protected]> Tested-by: Adam Ford <[email protected]> # imx8mp-beacon
2025-04-28arm64: dts: imx8mm: Make osc_32k available in SPLFabio Estevam
Since commit b4734c9c333b ("clk: imx: Convert clock-osc-* back to osc_*") SPL takes a long time to load U-Boot proper on an imx8mm-evk board. The reason for the long delay is because the osc_32k clock is not available in the SPL phase. Fix this problem by passing the 'bootph-all' and 'bootph-pre-ram' properties to make the osc_32k clock available in SPL. This also aligns with imx8mn and imx8mp-u-boot.dtsi files. Fixes: b4734c9c333b ("clk: imx: Convert clock-osc-* back to osc_*") Suggested-by: Marek Vasut <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Adam Ford <[email protected]>
2025-04-28imx: power-domain: Enable refcounting on imx8mpMiquel Raynal
Prevent enabling/disabling multiple times the same power domain to avoid breakages due to the same power domains being referenced several times by different device nodes. Signed-off-by: Miquel Raynal <[email protected]>
2025-04-28power-domain: Add support for refcounting (again)Miquel Raynal
It is very surprising that such an uclass, specifically designed to handle resources that may be shared by different devices, is not keeping the count of the number of times a power domain has been enabled/disabled to avoid shutting it down unexpectedly or disabling it several times. Doing this causes troubles on eg. i.MX8MP because disabling power domains can be done in recursive loops were the same power domain disabled up to 4 times in a row. PGCs seem to have tight FSM internal timings to respect and it is easy to produce a race condition that puts the power domains in an unstable state, leading to ADB400 errors and later crashes in Linux. Some drivers implement their own mechanism for that, but it is probably best to add this feature in the uclass and share the common code across drivers. In order to avoid breaking existing drivers, refcounting is only enabled if the number of subdomains a device node supports is explicitly set in the probe function. ->xlate() callbacks will return the power domain ID which is then being used as the array index to reach the correct refcounter. As we do not want to break existing users while stile getting interesting error codes, the implementation is split between: - a low-level helper reporting error codes if the requested transition could not be operated, - a higher-level helper ignoring the "non error" codes, like EALREADY and EBUSY. CI tests using power domains are slightly updated to make sure the count of on/off calls is even and the results match what we *now* expect. They are also extended to test the low-level functions. Signed-off-by: Miquel Raynal <[email protected]>
2025-04-27board: starfive: visionfive2: Order board detection logic to match configE Shattow
Fixup previous merge resolution of this series. Intent is to ease code readability and logic to match ordering in CONFIG_OF_LIST - Remove "starfive/" string math - Remove redundant local cache of calls to get_*_from_eeprom() - Match name before EEPROM product_id in board_fit_config_name_match() - Remove single-consumer FDTFILE_* defines - Do not set fdtfile for visionfive-2-* when unknown model revision Fixes: 5a0a93a76848 ("Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-riscv") Signed-off-by: E Shattow <[email protected]>