summaryrefslogtreecommitdiff
path: root/arch/arm/cpu
AgeCommit message (Collapse)Author
2026-06-25Kconfig: arm: restyleJohan Jonker
Restyle all Kconfigs for "arm": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-06-25Kconfig: armv7: fix typoJohan Jonker
While restyling Kconfig the script checkpatch.pl gives this info: WARNING: 'suppport' may be misspelled - perhaps 'support'? Fix by changing 'suppport' to 'support'. Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-06-24treewide: move bi_dram[] from bd to gdIlias Apalodimas
Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal <[email protected]> Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385 Tested-by: Anshul Dalal <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
2026-06-22Merge tag 'v2026.07-rc5' into nextTom Rini
Prepare v2026.07-rc5
2026-06-17Merge patch series "armv8: mmu: fix region unmapping and optimise ↵Tom Rini
set_one_region()" Casey Connolly <[email protected]> says: Currently trying to unmap a region results in slow and largely broken behaviour as we unnecessarily split blocks and manually set thousands of individual 4k pages instead of higher level blocks. This series fixes the behaviour of set_one_region() so that it works properly when called to unmap regions. See patch 4 for details. Patches 1 & 2 improve the existing debug functionality, the pagetable dumper will now print most explicitly unmapped regions (since they still have their PA intact), as well as adding a new function which does a very basic software TLB lookup to help with debugging. Patch 3 de-duplicates some code by moving the loop that always surrounds set_one_region() calls into its own function, this also helps with readability in the calling functions. Link: https://lore.kernel.org/r/[email protected]
2026-06-17armv8: mmu: fix and optimise explicitly unmapping regionsCasey Connolly
As more platforms start ensuring they explicitly unmap reserved-memory regions a few issues have appeared with how the existing dynamic mapping code works. Fix these and get a small optimisation as well. 1. Teach pte_type() to actually respect the PTE_TYPE_VALID bit 2. Don't walk the TLB a second time if we call mmu_change_region_attr() with PTE_TYPE_FAULT (since it would just be a slow nop) 3. Fix how set_one_region() decides to split blocks. Today set_one_region() will always split blocks until it reaches the smallest granule size (4k) and then update all of these pages. This appears to be due to a big in how is_aligned() is implemented, since it only evaluates to true if addr and size are both multiples of the current granule size, so a mapping aligned to 2M which is 4M in size will cleanly result in 2 blocks being set, but a mapping aligned to 2M which is 4M + 8k in size will result in blocks being split and 1026 individual pages being set. While for the address it is correct to enforce that it is aligned to the current granule size, we only need to check if the region size is greater than the current granule size. This allows us to simplify our second example above to only 4 entries being updated (assuming no blocks have to be split) since we only need to update 2 blocks to map the first 4M, drastically improving the best-case performance. In the case where the address is 4k aligned rather than 2M aligned we will still be restricted to mapping 4k pages until we reach 2M alignment where we could then map a larger 2M granule which previously would never happen. Signed-off-by: Casey Connolly <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2026-06-17armv8: mmu: commonize the set_one_region() loopCasey Connolly
This loop is duplicated 3 times, put it into its own function and call it instead. This simplifies the logic in a few functions. Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Casey Connolly <[email protected]>
2026-06-17armv8: mmu: teach the pagetable dumper to show explicit FAULT mapsCasey Connolly
When a region is explicitly unmapped (like with mmu_change_region_attr(.... PTE_TYPE_FAULT)) the address translation still remains but won't be used since the region is marked invalid. Print these regions when we dump the pagetable to help with debugging. Signed-off-by: Casey Connolly <[email protected]>
2026-06-17armv8: mmu: add a function to help debug TLB lookupsCasey Connolly
Implement a super basic software TLB walk which can look up a single address in the TLB and print each stage of the translation. This is helpful for debugging TLB issues and will be compiled out if unused. Example output on QEMU aarch64: Performing software TLB lookup of address 0x50100000 va_bits: 40 PTE: 0x47fe0000. addr[47:39]: 0x000 (offset 0x00000) L0: 0x47fe0000 -> TABLE (0x47fe1000) PTE: 0x47fe1000. addr[38:30]: 0x001 (offset 0x00008) L1: 0x47fe1008 -> BLOCK (0x40000000) [0x40000000 - 0x80000000] Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Casey Connolly <[email protected]>
2026-06-15arm: mxs: Avoid passing FORCE to commandsSimon Glass
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE as a prerequisite to the if_changed rules here, but the commands use $^ so FORCE leaks in as a stray operand. The dd in cmd_mkalign_mxs fails (silently, since its stderr is discarded) and the binary is never aligned, stat in cmd_mkivt_mxs emits an error and cst receives a bogus argument. Use $< and $(real-prereqs) instead, which exclude FORCE. Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <[email protected]>
2026-06-10thermal: imx_tmu: extend with QorIQ/Layerscape TMUVincent Jardin
Add support for the on-die Thermal Monitoring Unit (TMU) of the new QorIQ/Layerscape SoCs (LX2160A, LS1028A, LS1088A, ...): examples on a lx2160: => temperature list | Device | Driver | Parent | tmu@1f80000 | imx_tmu | root_driver | cluster67-thermal | imx_tmu | tmu@1f80000 | ddr1-cluster5-thermal | imx_tmu | tmu@1f80000 | wriop-thermal | imx_tmu | tmu@1f80000 | dce-qbman-hsio2-thermal | imx_tmu | tmu@1f80000 | ccn-dpaa-tbu-thermal | imx_tmu | tmu@1f80000 | cluster4-hsio3-thermal | imx_tmu | tmu@1f80000 | cluster23-thermal | imx_tmu | tmu@1f80000 => temperature get tmu@1f80000 tmu@1f80000: 82000 mC => temperature get wriop-thermal wriop-thermal: 81000 mC The parent tmu@... node owns the MMIO and calibration; one UCLASS_THERMAL device is bound per/thermal-zones site so each shows up by its zone name: => dm tree ... thermal 2 [ + ] imx_tmu |-- tmu@1f80000 thermal 3 [ + ] imx_tmu | |-- cluster67-thermal thermal 4 [ + ] imx_tmu | |-- ddr1-cluster5-thermal thermal 5 [ + ] imx_tmu | |-- wriop-thermal thermal 6 [ + ] imx_tmu | |-- dce-qbman-hsio2-thermal thermal 7 [ + ] imx_tmu | |-- ccn-dpaa-tbu-thermal thermal 8 [ + ] imx_tmu | |-- cluster4-hsio3-thermal thermal 9 [ + ] imx_tmu | `-- cluster23-thermal ... The dtsi additions mirror the existing fsl-ls1028a.dtsi: the LX2160A SoC dtsi gains the tmu@1f80000 node plus a thermal-zones hierarchy with 7 sites: cluster67-thermal site 0 A72 clusters 6 + 7 ddr1-cluster5-thermal site 1 DDR1 + A72 cluster 5 wriop-thermal site 2 WRIOP dce-qbman-hsio2-thermal site 3 DCE + QBMAN + HSIO2 ccn-dpaa-tbu-thermal site 4 CCN508 + DPAA + TBU cluster4-hsio3-thermal site 5 A72 cluster 4 + HSIO3 cluster23-thermal site 6 A72 clusters 2 + 3 Signed-off-by: Vincent Jardin <[email protected]> Suggested-by: Tom Rini <[email protected]> Inspired-by: Peng Fan <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2026-06-03arm: ls102xa: use platform data to check Ethernet interface is not SGMIIQuentin Schulz
tsec_private should, as its name suggests, be private. In the next commit, it'll be moved from a publicly available header file to the C file that requires it. ls102xa currently does not allow us to do that because it uses the structure. The flag is actually set if the Ethernet PHY interface is SGMII in drivers/net/tsec.c, so simply replace the current check with the same check made in drivers/net/tsec.c to set the flag. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Quentin Schulz <[email protected]>
2026-05-25Merge tag 'v2026.07-rc3' into nextTom Rini
Prepare v2026.07-rc3
2026-05-25Merge patch series "Fix speculative access to firewalled regions on AM62 SoCs"Tom Rini
Anshul Dalal <[email protected]> says: This patch series fixes firewall exceptions observed on AM62 family of devices due to speculative accesses made by the A53 core to secure DDR regions. Link: https://lore.kernel.org/r/[email protected]
2026-05-25arm: armv8: mmu: move mmu enablement out of mmu_setupAnshul Dalal
Currently mmu_setup for ARMv8 performs two functions, first it sets up the page tables based the memory map provided by the board and then it enables the MMU. However for some platforms runtime fixes to the generated page tables are required before the MMU can be enabled, such as K3 family of SoCs. Therefore this patch moves the enablement of the MMU out of mmu_setup and to a standalone mmu_enable function to give more granular control to the platforms. Note that no functional changes are intended from this patch. Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Anshul Dalal <[email protected]>
2026-05-18arm: Fix typo in linker scriptMarek Vasut
Fix typo, addreses -> addresses. No functional change. Signed-off-by: Marek Vasut <[email protected]> Acked-by: Ilias Apalodimas <[email protected]>
2026-05-15board: nxp: lx2160a: without QIXIS, MC-ENET, PCI, LTC3882Vincent Jardin
The shared LX2160A board file calls helpers that only exist when their subsystem is enabled. Gate them on the matching CONFIG_*: - pci_init() under CONFIG_PCI. - fdt_fixup_mc_ddr() and fsl_rgmii_init() under CONFIG_FSL_MC_ENET. - qixis_*() and the QIXIS branch of checkboard() under CONFIG_FSL_QIXIS; cpu_name(buf) moves out so the non-QIXIS path still prints "Board: <name>". - EVENT_SPY_SIMPLE on init_func_vid moves inside the CONFIG_VOL_MONITOR_LTC3882_READ guard (was outside, dangling symbol when LTC3882 off). #if / #ifdef, not IS_ENABLED(), because the helpers are themselves conditionally compiled. While here, lx2160a_common.h: fix BOOT_TARGET_DEVICES_MMC 1 arg vs 2 args and gate the MMC target on CONFIG_CMD_MMC, not CONFIG_MMC. No functional change for NXP boards: LX2160ARDB, LX2160AQDS, or LX2162AQDS, but mainly build clean up in order to support other NXP lx2160a boards without those HW dependencies. Signed-off-by: Vincent Jardin <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2026-05-06arm: layerscape: Check zero size memory bank before lmb_addYe Li
In layerspace's lmb_arch_add_memory implementation, all memory bank are added to lmb, even some is with zero size. This will cause lmb treating it as overlap with available memory by lmb_addrs_overlap and merge with available memory. Finally causing available memory start address changed to 0. For example, on LX2160, before zero memory bank added to lmb, there are two available memory regions: - region 0, start 0x80000000, size 0x7be00000 - region 1, start 0x2080000000, size 0x700000000 After zero size memory bank added, merge to one region: - region 0, start 0, size 0x2780000000 This wrong new region causes efi_memory_init issue when allocating bounce buffer because of conflict address (with uboot reserved) is allocated. Signed-off-by: Ye Li <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2026-04-27arm: psci: Add API to check for support of specific PSCI functionVaradarajan Narayanan
Add an API to check if a specific PSCI function is supported or not. This is based on the psci_features() function present in Linux kernel (drivers/firmware/psci/psci.c). Reviewed-by: Casey Connolly <[email protected]> Reviewed-by: Sumit Garg <[email protected]> Signed-off-by: Varadarajan Narayanan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Casey Connolly <[email protected]>
2026-04-13arm: Add ARMv8-M aarch32 supportMarek Vasut
Add configuration for ARMv8-M aarch32 core, which are currently Cortex-M23/M33 cores. These cores are treated similar to ARMv7-M cores, except the code has to be compiled with matching compiler -march=armv8-m.main flag . These cores have no MMU, they have MPU, which is currently not configured. Unlike ARMv7-M, these cores have 512 interrupt vectors. While the SYS_ARM_ARCH should be set to 8, it is set to 7 because all of the initialization code is built from arch/arm/cpu/armv7m and not armv8. Furthermore, CONFIG_ARM64 must be disabled, although DTs for devices using these cores do come from arch/arm64/boot/dts. To avoid excess duplication in Makefiles, introduce one new Kconfig symbol, CPU_V7M_V8M. The CPU_V7M_V8M cover both ARMv7-M and ARMv8-M cores. Signed-off-by: Marek Vasut <[email protected]> Acked-by: Udit Kumar <[email protected]>
2026-04-07lmb: Rework the LMB_ARCH_MEM_MAP symbolTom Rini
This symbol should not be enabled by the user directly but rather selected when implemented in a given platform. This converts all of the current users of this feature and hides the symbol. Signed-off-by: Tom Rini <[email protected]>
2026-03-09Merge tag 'v2026.04-rc4' into nextTom Rini
Prepare v2026.04-rc4
2026-02-24arm: armv8: Flush TLB before enabling MMUMark Kettenis
Commit 9ebdbbc43e5f ("arm: armv8: invalidate dcache entries on dcache_enable") broke Apple Silicon machines in certain scenarios. If the MMU is currently not enabled we need to flush the TLB before we enable it to prevent stale TLB entries from becoming active again. So move the __asm_invalidate_tlb_all() back immediately before the mmu_setup() call. Fixes: 9ebdbbc43e5f ("arm: armv8: invalidate dcache entries on dcache_enable") Signed-off-by: Mark Kettenis <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2026-02-17Merge patch series "treewide: Clean up usage of DECLARE_GLOBAL_DATA_PTR"Tom Rini
Peng Fan (OSS) <[email protected]> says: This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR instances. Many files declare DECLARE_GLOBAL_DATA_PTR and include asm/global_data.h even though gd is never used. In these cases, asm/global_data.h is effectively treated as a proxy header, which is not a good practice. Following the Include What You Use principle, files should include only the headers they actually depend on, rather than relying on global_data.h indirectly. This approach is also adopted in Linux kernel [1]. The first few patches are prepartion to avoid building break after remove the including of global_data.h. A script is for filtering the files: list=`find . -name "*.[ch]"` for source in ${list} do result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}` if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then echo "Found in ${source}" result=`sed -n '/\<gd\>/p' ${source}` result2=`sed -n '/\<gd_/p' ${source}` result3=`sed -n '/\<gd->/p' ${source}` if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then echo "Cleanup ${source}" sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source} sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source} sed -i '/global_data.h/d' ${source} git add ${source} fi fi done [1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf CI: https://github.com/u-boot/u-boot/pull/865 Link: https://lore.kernel.org/r/[email protected]
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <[email protected]> #TI boards Acked-by: Yao Zi <[email protected]> #TH1520 Signed-off-by: Peng Fan <[email protected]>
2026-02-09arm: spl: Ensure 8 byte alignment of appended DTB without separate BSSTom Rini
Historically, when we have an appended device tree and also our resulting binary will contain the BSS section, we have ensured that everything will be where it's expected to be by declaring that the BSS is overlayed with a symbol matches the end of the port of the ELF binary that is objcopy'd to the binary we concatenate with. This in turn means that the logic to generate a "pad" file, which is the size found in the __bss_size symbol, will be correct and then we can concatenate the device tree and it will begin at __bss_size at run time. With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts") we removed this overlay as part of trying to ensure that we met both the requirements of the device tree to be 8 byte aligned as well as that our logic to generate the -pad file would match what ended up in the resulting binary. While it was correct to remove an unused section it did not solve ultimately solve the problem for all cases. To really fix the problem, we need to do two things. First, our final section prior to _image_binary_end must be 8 byte aligned (for the case of having a separate BSS and so our appended DTB exists at this location). This cannot be '.binman_sym_table' as it may be empty, and in turn the ELF type would be NOBITS and so not copied with objcopy. The __u_boot_list section will never be empty, so it is our final section, and ends with a '. = ALIGN(8)' statement. Second, as this is the end of our copied data it is safe to declare that the BSS starts here, so use the OVERLAY keyword to place the BSS here. Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts") Reported-by: Brian Sune <[email protected]> Reported-by: Phil Phil Sutter <[email protected]> Tested-by: Brian Sune <[email protected]> Tested-by: Phil Sutter <[email protected]> Tested-by: Greg Malysa <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2026-01-28armv8: u-boot-spl.lds: Place binman symbols at end of binaryJonas Karlman
It can be useful in xPL to access symbols from binman, such as the offset/position and size of a binman entry. Place these binman symbols together at the end of the xPL binary for ARMv8, similar to ARM and RISC-V. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2026-01-28arm: Remove rel.dyn from SPL linker scriptsTom Rini
As of v2026.01, no platforms contain any rel.dyn sections in their xPL phase images. Their inclusion in linker scripts initially was an oversight as part of taking the full U-Boot linker scripts and modifying them down. Then in commit 8b0ebe054bb3 ("arm: Update linker scripts to ensure appended device tree is aligned") these sections were used to force correct alignment for the device tree. This however, lead to a different problem. That problem is that when we do not have a separate BSS section in SPL we instead would overlay the BSS with the rel.dyn section, in the common linker script case. This in turn lead to creating an incorrectly sized BSS "pad" file sometimes (depending on arbitrary changes within the rest of the binary itself). This in turn lead to the dtb being in the wrong location in the binary and not found at run time. This commit fixes a few things: - Remove the rel.dyn section from all ARM SPL linker scripts. - In turn, this moves the dtb alignment statement in to another section. - For ast2600 which uses CONFIG_POSITION_INDEPENDENT we need to keep the symbols however. Tested-by: Fabio Estevam <[email protected]> Reported-by: Fabio Estevam <[email protected]> Co-developed-by: Ilias Apalodimas <[email protected]> Reviewed-by: Chia-Wei, Wang <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2026-01-28board: nxp: Rename board directory from board/freescale to board/nxpAlice Guo
This patch renames the board directory from board/freescale to board/nxp because NXP now provides Board Support Packages (BSPs) and tools for the former Freescale i.MX and other i.MX products. All relevant references have been updated accordingly. This change does not affect functionality. Signed-off-by: Alice Guo <[email protected]> Reviewed-by: Fabio Estevam <[email protected]>
2026-01-26Revert "arm: spl: Correct alignment of .rel.dyn section"Tom Rini
This reverts commit 380ddb473c6bdf87e66c0fb93e256d1e233c6f5b. Signed-off-by: Tom Rini <[email protected]>
2026-01-26arm: spl: Correct alignment of .rel.dyn sectionTom Rini
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c") we now require the correct, 8 byte alignment of a device tree in order to work with it ourselves. This has exposed a number of issues. In the case of using arch/arm/cpu/u-boot-spl.lds for an xPL phase and having the BSS be overlayed with the dynamic relocations sections (here, .rel.dyn) we had missed adding the comment about our asm memset requirements. Then, when adjusting ALIGN statements we later missed this one. In turn, when we use objcopy to create our binary image we end up in the situation where where the BSS must start out 8 byte aligned as well as end 8 byte aligned because for appended device tree the requirement is that the whole BSS (which we add as padding to the binary) must be 8 byte aligned. Otherwise we end up with the situation where __bss_end (where we look for the device tree at run time) is aligned but the size of the BSS we add Fixes: 7828a1eeb2a1 ("arm: remove redundant section alignments") Fixes: 52caad0d14a3 ("ARM: Align image end to 8 bytes to fit DT alignment") Reported-by: Fabio Estevam <[email protected]> Tested-by: Fabio Estevam <[email protected]> Signed-off-by: Tom Rini <[email protected]> --- Cc: Ilias Apalodimas <[email protected]> Cc: Marek Vasut <[email protected]>
2026-01-20arm: Update linker scripts to ensure appended device tree is alignedTom Rini
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains that we must have ALIGN(x) statements inside of a section to ensure that padding is included and not simply that the linker address counter is incremented. To that end, this patch: - Expands some linker sections to be more readable when adding a second statement to the section. - Aligns the final section before _end (for U-Boot) or _image_binary_end or __bss_end (for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to the final section before the symbol. - Ensure that we do have alignment by adding an ASSERT so that when not aligned we fail to link (and explain why). - Remove now-spurious '. = ALIGN(x);' statements that were intended to provide the above alignments. Tested-by: Michal Simek <[email protected]> # Zynq Reviewed-by: Ilias Apalodimas <[email protected]> [trini: Also update arch/arm/cpu/armv8/u-boot.lds as Ilas requested] Signed-off-by: Tom Rini <[email protected]>
2026-01-02kbuild: Bump the build system to 6.1Sughosh Ganu
Our last sync with the kernel was 5.1. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefiles to 6.1. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call for the bump to 5.1, so we are following the same guidelines here. Signed-off-by: Sughosh Ganu <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]>a #rebased on -next
2025-12-11armv8/fsl-layerscape: fdt: Remove offline cores from cooling device mapsAnthony Pighin (Nokia)
Some processor families use a generic device tree, and rely on u-boot fixups to massage that for lower core count personalities (i.e. NXP LX2* family). For example, the LX2160A device tree will be used and then modified to offline non-existent cores when running on an 8-core LX2080A. However, the cooling maps still contain references to the non-existent core phandles, resulting in: OF: /thermal-zones/cluster6-7-thermal/cooling-maps/map0: could not find phandle 15 Rebuild the cooling maps as non-existent cores are deleted. Signed-off-by: Anthony Pighin <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2025-11-11ARM: Fix HAS_ARMV7_SECURE_BASE help textMarek Vasut
Drop the 'a' from 'ahardware', no functional change. Signed-off-by: Marek Vasut <[email protected]>
2025-11-06armv8: implement workaround for broken CNTFRQ_EL0 valueKaustabh Chakraborty
In devices where the U-Boot is used as a secondary bootloader, we rely on the device's primary bootloader to implement CNTFRQ_EL0. However, this reliance may lead to a non-functional timer in broken firmware. For instance, some versions of Samsung's S-Boot don't implement it. It's also not possible to set it in the U-Boot, because it's booted in a lower exception level. CNTFRQ_EL0 is reported to be 0. Use gd->arch.timer_rate_hz to override the queried value if set. This setting needs to be done in the board file, preferrably in timer_init(). This feature is present only when the CONFIG_ARMV8_CNTFRQ_BROKEN is enabled. Signed-off-by: Kaustabh Chakraborty <[email protected]>
2025-11-04arm: armv8: mmu: fix mem_map_from_dram_banksAnshul Dalal
mem_map_from_dram_banks calls fdtdec_setup_memory_banksize to setup the dram banks though that is expected to be done by dram_init_banksize as part of board_r sequence. This has the side effect of modifying gd->bd->bi_dram as well, therefore this patch removes the call and updates spl_enable_cache for K3 to call dram_init_banksize. Signed-off-by: Anshul Dalal <[email protected]> Reported-by: Francesco Dolcini <[email protected]> Closes: https://lore.kernel.org/u-boot/20251027165225.GA71553@francesco-nb/ Fixes: fe2647f2a0d4 ("arm: armv8: mmu: add mem_map_from_dram_banks") Tested-by: Emanuele Ghidoli <[email protected]>
2025-10-24arm: armv8: Make save_boot_params simplerIlias Apalodimas
The idiom used in save_boot_params is common for armv7. In armv8 is much easier to do the same thing with adr/adrp. So let's simplify the code a bit. Signed-off-by: Ilias Apalodimas <[email protected]>
2025-10-22spl: split spl_board_fixups to arch/board specificAnshul Dalal
The current spl_board_fixups API allows for modification of spl_image before the SPL jumps to it. This can be used to modify the DT for the next boot stage, however the current API only allows either the machine arch or the board to use it. This limits the utility of the API as there might be certain fixups that should be applied to all boards sharing the same machine architecture with others being board specific. For TI's K3 specifically, this prevents us from performing architecture level fixups since a lot of TI boards are already making use of the spl_board_fixups API. Therefore this patch splits the API into two to allow both board and the architecture specific fixups. The order is kept as arch then board to give board specific fixups the precedence. Reviewed-by: Dhruva Gole <[email protected]> Signed-off-by: Anshul Dalal <[email protected]> Tested-by: Wadim Egorov <[email protected]>
2025-10-22arm: armv8: mmu: add mmu_unmap_reserved_memAnshul Dalal
For armv8, U-Boot uses a static map defined as 'mem_map' for configuring the MMU's page tables, done by mmu_setup. Though this works well for simpler platforms, it makes creating runtime carveouts by modifying the static array at runtime exceedingly complex like in mach-snapdragon/board.c. Creation of such carveouts are much better handled by APIs such as mmu_change_region_attr once the page tables are configured. Usually such carveouts are configured via the device-tree's reserved-memory node which provides the address and size for the carveout. Therefore this patch adds mmu_unmap_reserved_mem which acts as a wrapper over mmu_change_region_attr, helping unmap a reserved-memory region. Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Anshul Dalal <[email protected]> Tested-by: Wadim Egorov <[email protected]>
2025-10-22arm: armv8: mmu: add mem_map_from_dram_banksAnshul Dalal
For armv8, U-Boot uses a static map defined as 'mem_map' for configuring the MMU as part of mmu_setup. But since the exact configuration of memory banks might not be known at build time, many platforms such as imx9, versal2 etc. utilize gd->bd->bi_dram to configure the static map at runtime. Therefore this patch adds a new API mem_map_from_dram_banks that modifies the static map in a similar way. Allowing the caller to map all dram banks by just passing the index to last entry in their mem_map and it's length. Reviewed-by: Dhruva Gole <[email protected]> Signed-off-by: Anshul Dalal <[email protected]> Tested-by: Wadim Egorov <[email protected]>
2025-10-22arm: armv8: invalidate dcache entries on dcache_enableAnshul Dalal
In dcache_enable, currently the dcache entries are only invalidated when the MMU is not enabled. This causes issues when dcache_enable is called with the MMU already configured, in such cases the existing dcache entries are not flushed which might result in un-expected behavior. This patch invalidates the cache entries on every call of dcache_enable before enabling dcache (by setting CR_C). This makes dcache_enable behave similar to icache_enable as well. Reviewed-by: Dhruva Gole <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Anshul Dalal <[email protected]> Tested-by: Wadim Egorov <[email protected]>
2025-10-03arm: armv8: remove redundant definition of mmu_statusAnshul Dalal
mmu_status is used in io memcpy functions to prevent accesses to non 8-byte aligned addresses when the mmu is disabled. Though there is a redundant definition enabled when icaches is turned off by setting SYS_ICACHE_OFF. This patch removes the redundant definition, allowing mmu_status to properly report the status regardless of config settings. This shouldn't be a problem since access to non 8-byte aligned data can be done irrespective of icache state. Fixes: 268f6ac1f95c ("arm64: Update memcpy_{from, to}io() helpers") Signed-off-by: Anshul Dalal <[email protected]> Reviewed-by: Patrice Chotard <[email protected]> Reviewed-by: Dhruva Gole <[email protected]> Acked-by: Ilias Apalodimas <[email protected]>
2025-09-23Merge tag 'v2025.10-rc5' into nextTom Rini
Prepare v2025.10-rc5
2025-09-13arm: armv8: Fix spl recover data section brokenYe Li
SPL recover data section is broken which causes reboot failure on some i.MX platforms (iMX8QM/iMX95). The global variable cold_reboot_flag is assigned to weak reset_flag function which always return 1, so restore never been executed in warm reboot. Fixes: 1c37e59bfbba ("arm: armv8: Improve SPL data save and restore implementation") Signed-off-by: Ye Li <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2025-08-11arm: bcm235xx: Remove this SoCTom Rini
As there are no platforms for this SoC, remove the code. Signed-off-by: Tom Rini <[email protected]>
2025-08-01arm: bcm281xx: Remove ethernet driverTom Rini
As no platforms enable the ethernet driver, remove it. Signed-off-by: Tom Rini <[email protected]>
2025-07-27sunxi: add basic A523 supportAndre Przywara
Add the basic Kconfig options, addresses and other values for the existing Kconfig settings for the new Allwinner A523/T527/H728 SoC. Signed-off-by: Andre Przywara <[email protected]>
2025-07-17armv8: ls1043a: make some erratas dependent from USBHolger Brunck
These erratas are only useful if USB is enabled. If it is disabled these erratas might cause issues. Signed-off-by: Holger Brunck <[email protected]>
2025-07-11global: Make ARCH_MISC_INIT a selected symbolTom Rini
This symbol is not something that the user should be enabling or disabling but rather the developer for a particular board should select it when required. This is mostly size neutral, however a few places do have changes. In the case of i.MX6ULL systems, it is always the case that arch_misc_init() could call setup_serial_number() and do useful work, but was not enabled widely, but now is. In the case of i.MX23/28 systems, we should be able to call mx28_fixup_vt() again here, so do so. Finally, some platforms were calling arch_misc_init() and then not doing anything and this results in removing the option. Acked-by: Peng Fan <[email protected]> Signed-off-by: Tom Rini <[email protected]>