| Age | Commit message (Collapse) | Author |
|---|
|
Remove empty gpio.h header file and CONFIG_GPIO_EXTRA_HEADER on
ARCH_MEDIATEK. There is no reason to have these since the header
doesn't contain anything.
Signed-off-by: David Lechner <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
- Add u-boot SPL support for GX SoCs
- meson_gx_mmc: reduce maximum frequency
- Add support for EFI capsule updates on all Amlogic boards
|
|
Add a helper function based on rockchip_sdram_size() that return what
DRAM type is used on current running board.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Previously, few Amlogic devices supported EFI capsule updates.
Generally only the Libre Computer ones with SPI flash supported it,
thanks to board-specific code.
This commit commonises capsule update support across supported
Amlogic boards. Similar to Qualcomm's support for it, the dfu string
and firmware name is automatically generated at runtime depending on
which device we are booted from. Right now this supports flashing to
the eMMC/SD and SPI flash.
As usual, the capsule UUID is automatically generated. You can get it
by enabling CONFIG_CMD_EFIDEBUG and running:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=796180D4-AAB2-50F1-B16A-53DFF9CA89B2
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
Reviewed-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Supports both GXBB and GXL SoCs.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Add initial boilerplate for U-Boot SPL support on Amlogic.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Add a minimal non-DM MMC driver for use in size-constrained
environments.
Signed-off-by: Ferass El Hafidi <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Fix macros for the GPIO function for two pads (ENET1_TD3 and I2C2_SCL),
aligning them to the functions specified in the datasheet.
Fixes: a9d562daa3c3 ("imx: Add iMX91 support")
Suggested-by: Javier Viguera <[email protected]>
Signed-off-by: Francesco Valla <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.
This patch series adds support for the following hardware:
* console UART
* ethernet controller/switch
* spinand flash (in non-dma mode)
The following issues may be expected:
* Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
* Linux airoha-snfi driver in some cases might damage you flash data
(see: https://lore.kernel.org/lkml/[email protected]/)
* Latest linux kernel is recommended to properly support flashes
with more than one plane per lun
(see: https://lore.kernel.org/lkml/[email protected]/)
* It's NOT recommended to use flashes working in continuous mode because
U-Boot airoha-snfi driver does not support such flashes properly.
The patches was tested on the board:
- SoC: Airoha EN7562
- RAM: 512 MB
- SPI NAND: 4 Gbit, made by Toshiba
- Linux boot: was NOT tested
The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created
1) Create u-boot.its file with the following contents:
=== cut here ===
/dts-v1/;
/ {
description = "ARM OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;
images {
u-boot-ram {
description = "OpenWrt U-Boot RAM image";
data = /incbin/("u-boot.bin.lzma");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x81e00000>;
entry = <0x81e00000>;
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
fdt-1 {
description = "OpenWrt device tree blob";
data = /incbin/("dts/upstream/src/arm/airoha/en7523-evb.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
};
configurations {
default = "config-ram-uboot";
config-ram-uboot {
description = "OpenWrt RAM U-Boot";
kernel = "u-boot-ram";
fdt = "fdt-1";
};
};
};
==================
2) Create u-boot.itb image to chain-load new u-boot from the old one
lzma_alone e u-boot.bin u-boot.bin.lzma
mkimage -f u-boot.its u-boot.itb
3) Load new u-boot from the old one
U-Boot> tftpboot u-boot.itb && bootm
Link: https://lore.kernel.org/r/[email protected]
|
|
We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.
To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha EN7523 SoC.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.
To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha AN7581 SoC.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
OPTEE-OS on ARMv7a"
This series from Marek Vasut <[email protected]> brings some
enhancements to use cases using OPTEE-OS on ARMv7a platforms, some of
which already existed on ARMv8.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a.
This is only supported if U-Boot runs in PL1 secure. This change adds
two components, one is fitImage OPTEE-OS loadable handler, which makes
a note of OPTEE-OS being loaded and stores the load address for later
jump to it. The second part is the actual jump to Linux through OPTEE-OS.
The jump through OPTEE-OS requires set up of multiple CPU registers, r1
and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
Linux kernel entry point. This setup is done by new assembler function
boot_jump_linux_via_optee().
The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
configuration write, this cannot be moved easily, hence the ifdef.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add USB1_BASE_ADDR and USB2_BASE_ADDR for i.MX9 platform, and define
USB_BASE_ADDR as an alias to USB2_BASE_ADDR.
Signed-off-by: Alice Guo <[email protected]>
|
|
The bootsource ids reported by BootROM of RK3528 and RK3576 for e.g.
SPI NOR and USB differs slightly compared to prior SoCs:
- Booting from sfc0 (ROCK 4D) report the normal bootsource id 0x3.
- Booting from sfc1 M1 (NanoPi M5) report a new bootsource id 0x23.
- Booting from sfc1 M0 has not been tested (no board using this config).
- Booting from USB report a new bootsource id 0x81 on RK3528 and RK3576.
Add a helper function to read the bootsource id. This helper function
will be used to translate the new values to the common BROM_BOOTSOURCE
enum values on RK3528 and RK3576.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
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]>
|
|
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]>
|
|
The mmu_setup function configures the page tables based on the board
supplied mem_map struct array. It is called implicitly as part of
dcache_enable but this limits us to only be able to use APIs such as
mmu_change_region_attr only after caches are enabled.
This might lead to speculative accesses before we can unmap a region
that is marked as cacheable in the static memory map.
Therefore this patch exports the mmu_setup function in mmu.h allowing
users to have more control over when the mmu is configured.
For K3 specifically this allows for the following configuration sequence
as part of enable_caches:
static mem_map fixups (TODO) -> mmu_setup -> carveouts using
mmu_change_region_attr (TODO) -> icache/dcache enable
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]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
SoCFPGA updates for v2025.10:
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/27762
This pull request brings a set of updates across SoCFPGA platforms
covering Agilex5, Agilex7, N5X, and Stratix10. The changes include:
* Agilex5 enhancements:
- USB3.1 enablement and DWC3 host driver support
- System Manager register configuration for USB3
- Watchdog timeout increase and SDMMC clock API integration
- dcache handling improvements in SMC mailbox path
- Enable SPL_SYS_DCACHE_OFF in defconfig
* Clock driver improvements:
- Introduce dt-bindings header for Agilex clocks
- Add enable/disable API and EMAC clock selection fixes
- Replace manual shifts with FIELD_GET usage
* DDR updates:
- IOSSM mailbox compatibility check
- Correct DDR calibration status handling
* Device tree changes:
- Agilex5: disable cache allocation for reads
- Stratix10: add NAND IP node
- Enable driver model watchdog
- Enable USB3.1 node for Agilex5
* Config cleanups:
- Simplify Agilex7 VAB defconfig
- Remove obsolete SYS_BOOTM_LEN from N5X VAB config
- Enable CRC32 support for SoCFPGA
- Increase USB hub debounce timeout
Overall this set improves reliability of DDR and cache flows,
adds missing USB and MMC features for Agilex5, and refines clock
and configuration handling across platforms.
This patch set has been tested on Agilex 5 devkit, and Agilex devkit.
|
|
When the data cache (dcache) is disabled, calling related
status functions can lead to compilation errors due to
undefined references.
Adding a !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) check before
invoking dcache_status() (used in common/memsize.c:get_ram_size())
and mmu_status() (from arch/arm/include/asm/io.h).
Without this check, builds with dcache disabled will fail to compile.
Signed-off-by: Boon Khai Ng <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Add MIDR entry for Cortex-A720 core.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Due to i.MX95 has reserved first 256MB DDR, change to use the DDR
start address in u-boot as the container header buffer.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
i.MX94
- Add base addresses for WDG3, WDG4, GPIO6, and GPIO7 for i.MX94.
- Introduce common.h with macros of clock IDs, power domains, and CPU
types for platform-specific replacement (e.g., i.MX94, i.MX95).
- Extend imx_get_mac_from_fuse() to support i.MX94.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Acked-by: Peng Fan <[email protected]>
Reviewed-by: Jacky Bai <[email protected]>
|
|
reasons
System Manager provides the last booted and shutdown reasons of the
logical machines (LM) and system using the SCMI misc protocol (Protocol
ID: 0x84, Message ID: 0xA). This path adds get_reset_reason() to query
and print these reasons in SPL and U-Boot.
Signed-off-by: Peng Fan <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Ye Li <[email protected]>
|
|
Introduce support for the new i.MX94 processor, including its CPU type
and SoC-level Kconfig entry.
The i.MX94 is a new member of the i.MX9 family. It uses a System Manager
to handle system-level functions such as power, clock, sensor and pin
control. The System Manager runs on a Cortex-M processor, while the
Cortex-A processor communicates with it via the ARM SCMI protocol and a
messaging unit.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Acked-by: Peng Fan <[email protected]>
Reviewed-by: Jacky Bai <[email protected]>
|
|
Prepare v2025.10-rc5
|
|
The LPCG number on iMX93 and iMX91 is 127 not 122. The wrong
value is used in ccm_reg structure and Coverity reports several
issues as out-of-bounds write.
Signed-off-by: Ye Li <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
As there are no platforms for this SoC, remove the code.
Signed-off-by: Tom Rini <[email protected]>
|
|
Reuse and export low_drive_freq_update() function. This way global imx9
board_fix_fdt() doesn't duplicate code. While low_drive_freq_update()
can be reused on boards such as phyCORE-i.MX93 (TARGET_PHYCORE_IMX93)
which is not using the global imx9 board_fix_fdt() implementation.
While at it, make printout logic less verbose by only outputting on the
error condition and not on each successful clock fixup. Also drop now
invalid comment (low_drive_freq_update() now does fixup for internal and
kernel device-tree).
Signed-off-by: Primoz Fiser <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-nand-flash
CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/27258
This series address issues found by Andrew Goodbody and mostly drop
driver that are not used by any board
|
|
As no platforms use this driver anymore let's go ahead and remove it.
Signed-off-by: Tom Rini <[email protected]>
|
|
Configure pixel clock and data enable polarity according to panel flags.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Previously software based AES encryption was used with previously known
device specific keys (SBK), now that we have AES driver we can simply
delegate this to the engine without prior knowledge of the key (assuming
it is still loaded).
Signed-off-by: Ion Agorria <[email protected]>
|
|
Now that we have working AES engine driver we can request the warmboot code
to be encrypted and signed with SBK if the device requires so. This
unlocks LP0 support for most devices in the wild as they use ODM Production
Secure.
We are not aware of any "ODM Production Open" device nor have access to
thus this has not been tested on one, merely added for completeness.
Signed-off-by: Ion Agorria <[email protected]>
|
|
This driver allows using Tegra AES engines within BSEV and BSEA blocks to
encrypt and decrypt data using different AES algorithms.
One use case is allowing u-boot to self update by using the already loaded
AES key in the engine's SBK slot by the bootrom.
Particular care must be taken as chainloaded u-boot's may not have the SBK
slot loaded as the vendor bootloader erases it before leaving it.
Signed-off-by: Ion Agorria <[email protected]>
|
|
Move a set of helpers used in warmboot code to more appropriate AP and FUSE
locations.
Signed-off-by: Ion Agorria <[email protected]>
|
|
Fix STMicroelectronics spelling in comments.
Signed-off-by: Patrice Chotard <[email protected]>
|
|
DRAM init code, as per reverse engineering and matching against
previous SoCs. As usual no real documentation, and the DRAM controller
is the usual mixture of close-to-previous IP and new inventions.
This version supports LPDDR4 for now only, as seen on the early boards.
This needs improvements, but it can be done later.
Signed-off-by: Jernej Skrabec <[email protected]>
Signed-off-by: Andre Przywara <[email protected]>
|
|
This adds the early A523 clock setup code, for the basic peripheral PLL
and the basic bus clocks (APB/AHB). This is quite close to the existing
H6 and H616 clock code, so this shares the same file. A few bits and bobs
are different, though, so filter for the A523 in a few occasions.
Signed-off-by: Jernej Skrabec <[email protected]>
Signed-off-by: Andre Przywara <[email protected]>
|
|
The cpu_sunxi_ncat2.h header file contains addresses of some peripherals
that are needed for the SPL, for chips that belong to the "NCAT2"
generation.
The Allwinner A523 is a member of this group, but a few addresses
differ, and we need a few more addresses, for playing with the core
reset, for instance.
Add the new addresses needed for the A523 and guard existing definitions
that conflict with that new chip.
Signed-off-by: Andre Przywara <[email protected]>
|
|
The watchdog in the Allwinner A523 SoC differs a bit from the one in the
previous SoCs: it lives in a separate register frame, so no longer
inside some timer device, and it manages to shuffle around some
registers a bit. But it also conveniently adds a direct reset
functionality, so we don't need to use a dummy timeout period.
Avoid introducing a new MMIO register frame C struct, but just define
the one needed register offset as a macro. Then just trigger this new
direct reset functionality in the A523 specific reset_cpu()
implementation.
Signed-off-by: Andre Przywara <[email protected]>
|
|
The Allwinner A523 features 8 CPU cores, organised in two clusters, both
driven by separate PLLs. Also there is the DSU PLL, which clocks the
hardware that connects the cores to the rest of the system.
And while the PLL registers itself are very similar, they are located in
a separate register frame, outside the main CCU, and also the register
controlling the CPU clock source (mux) is different.
Provide a separate function that reparents the two clusters and the DSU,
while their PLLs are programmed. For the actual PLL programming, we rely
on the existing shared routine.
The selection between the new A523 routine and the existing code is made
with C if statements, but since the choice is effectively made at compile
time already, the compiler optimises away the other code paths, leaving
just the one required function in.
Signed-off-by: Andre Przywara <[email protected]>
|
|
The SPL initial clock setup code for the Allwinner H6 and H616 SoCs uses
a simple CPU PLL setup routine, which programs all register bits at once,
then waits for the LOCK bit to clear.
The manual suggests to follow a certain procedure for bringing up any
PLLs, which involves several register writes, one at a time, and some
delays. Also the H616 and the new A523 require some tiny changes in this
sequence, and the different SoCs also feature some extra bits here and
there, which we should not just clear.
So factor out the PLL setup routine, and make it follow the manual's
suggestion. This will read the PLL register at the beginning, then tweak
the bits we need to manipulate, and writes the register several times on
the way. This allows to cover the specific bits for different SoCs.
Besides improving the reliability of the PLL setup, this helps with the
A523, which requires *three* CPU PLLs to be programmed.
Signed-off-by: Andre Przywara <[email protected]>
|
|
The Allwinner PLLs share most of their control bits, they differ mostly
in the factors and dividers.
Drop the PLL specific definition of those common bits, and use one
shared macro, for all PLLs.
This requires changing the users in the SPL clock and DRAM code.
Signed-off-by: Andre Przywara <[email protected]>
|
|
Add the initial board support for the NXP i.MX93 FRDM board:
https://www.nxp.com/design/design-center/development-boards-and-designs/frdm-i-mx-93-development-board:FRDM-IMX93
Based on the NXP U-Boot code.
There were attempts to upstream the board devicetree, but it has not been
accepted upstream yet:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
Once it reaches upstream, we can switch to OF_UPSTREAM.
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
As no platforms use this driver anymore, remove it.
Signed-off-by: Tom Rini <[email protected]>
|
|
Since i.MX94, the ELE get_info structure is updated to add
OEM PQC SRK hash, so update it.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Jacky Bai <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Acked-by: Peng Fan <[email protected]>
|
|
With the removal of the last i.MX31 platform we can remove the rest of
the underlying architecture code as well.
Fixes: f247354708ec ("arm: Remove mx31pdk board")
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Peng Fan <[email protected]>
|
|
The current file defines a struct gpio_regs identical to the one in
<asm/mach-imx/gpio.h>. To eliminate code duplication and align with
the approach used for i.MX8M, include the common header instead of
redefining the struct.
Signed-off-by: Giulio Benetti <[email protected]>
|
|
Ilias Apalodimas <[email protected]> says:
Instructions that lead ito an exception in the hypervisor can't modify two
CPU registers at once for the ARM ISA.
These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending.
Link: https://lore.kernel.org/r/[email protected]
|
