Expand capsule update support to correctly identify which partition
U-Boot is flashed to (between xbl, uefi, and boot including A/B
variants).
Use qcom_boot_source to determine if we were chainloaded from ABL,
meaning U-Boot is on the boot partition, otherwise we assume uefi if
it's available, finally leaving the xbl partition.
Set a different fw_name based on the target partition to prevent GUID
collisions, since a board may support U-Boot flashed to boot or XBL we
need to differentiate them since the U-Boot binary must be built
differently.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250411-b4-qcom-capsule-update-improvements-v2-2-27f6b2fcc4a9@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Add a MAINTAINERS file for assigning maintainership of a particular
Qualcomm platform or board (if board specific files exist). It is
intended to supplement the treewide ARM SNAPDRAGON maintainers with
folks who have a more specific interest.
Add an initial entry for the QCS6490 platform which powers the RB3 Gen 2 board.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250604113452.1075503-2-casey.connolly@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
The default DIP switch configuration on RB1/2 is to enable flashing
support via USB type-c port either using QDL or fastboot. It's just
cumbersome to get the host mode working in U-Boot via DIP switch toggle
when you need the flashing capability using the type-c port.
So instead lets enable fastboot in U-Boot for RB1/2 boards which is
more useful in the default board DIP switch configuration. This let's
us to drop dr_mode DT fixup.
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250516130854.606067-1-sumit.garg@kernel.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
The value passed to dcd_skip of build_container() should be obtained by
parsing .cfg file, and should not be fixed to false. For i.MX8QXP, dcd
data needs to be skipped, in which case dcd_skip should be true.
Fixes: 5f28a6599f01("tools: imx8image: add i.MX95 support")
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reported-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
The Chameleon board is an OpenHardware devboard made by YuzukiTsuru,
featuring an Allwinner H616 SoC. The form factor resembles the Raspberry
Pi Model A boards, though it differs significantly in its features.
Apart from the usual peripherals of those kind of boards (SD card, eMMC,
WiFi, HDMI), it features four USB-C 2.0 ports.
Add a defconfig for the board, the DRAM parameters have been extracted
from the firmware shipped with the board.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Chameleon board is an OpenHardware devboard made by YuzukiTsuru.
The form factor resembles the Raspberry Pi Model A boards, though it
differs significantly in its features:
- Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache, 1.4 GHz)
- between 512MiB and 2GiB DDR3 DRAM
- up to 128 GiB eMMC flash
- AXP313a PMIC
- 100 Mbit/s Ethernet pins on a header
- XR829 WIFI+Bluetooth chip
- 4 * USB 2.0 USB-C ports
- microSD card slot
- 3.5mm A/V port
Add the devicetree describing the board's peripherals and their
connections.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250307005712.16828-16-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[ upstream commit: f4a6b0f7200f8629f4138f1094ce654ab75df41e ]
(cherry picked from commit 3a879d878553d57057ce0a7096bfbf1eb077f6dc)
The Liontron H-A133L is an industrial development board based on the
Allwinner A133 SoC. It uses LPDDR4 DRAM, eMMC, and an AXP707 PMIC.
Add a defconfig with the required DRAM settings.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The H-A133L board is an industrial development board made by Liontron.
It contains a number of dedicated JST connectors, to connect external
peripherals. It features:
- Allwinner A133 SoC (4 * Arm Cortex-A53 cores at up to 1.6 GHz)
- 1 GiB, 2 GiB or 4 GiB of LPDDR4 DRAM
- between 16 and 128 GiB eMMC flash
- AXP707 PMIC (compatible to AXP803)
- 100 Mbit/s RJ45 Ethernet socket, using an JLSemi JL1101 PHY
- XR829 WIFI+Bluetooth chip
- 2 * USB 2.0 USB-A ports, plus three sets of USB pins on connectors
(connected via a USB hub connected to USB1 on the SoC)
- microSD card slot
- 3.5mm A/V port
- 12V power supply
- connectors for an LVDS or MIPI-DSI panel
Add the devicetree describing the board's peripherals and their
connections.
Despite being a devboard, the manufacturer does not publish a schematic
(I asked), so the PMIC rail assignments were bases on BSP dumps,
educated guesses and some experimentation. Dropping the always-on
property from any of the rails carrying it will make the board hang as
soon as the kernel turns off unused regulators.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250505164729.18175-4-andre.przywara@arm.com
[wens@csie.org: fix property in &usbphy; fix comment typo in &usb_otg]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[ upstream commit: a3cd12acb7b74d9b243cd893209972fc657d0bd3 ]
(cherry picked from commit 4062957c0797752dcf8b71f99c7aa47301c70aac)
The manual for the Allwinner A133 SoC mentions that the maximum
supported MMC frequency is 150 MHz, for all of the MMC devices.
Describe that in the DT entry, to help drivers setting the right
interface frequency.
Fixes: fcfbb8d9ec58 ("arm64: allwinner: a100: Add MMC related nodes")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250505202416.23753-1-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[ upstream commit: d8f10550448b03d3c5c6d9392119205c65ebfc89 ]
(cherry picked from commit 85e37e6a8a002eb231df8209478d7ff2b134a451)
The Allwinner A100 SoC has been around for a while, mostly on cheap
tablets, but didn't generate much interest in the community so far.
There were some efforts by two Allwinner employees in 2020, which led
to basic upstream Linux support for that SoC, although this momentum
dried up pretty quickly, leaving a lot of peripherals unsupported.
The A100 was silently replaced with the seemingly identical Allwinner
A133, which is reportedly a better bin of the A100. So far we assume
that both are compatible from a software perspective. There are some
more devices with the A133 out there now, so people are working on
filling the gaps, and adding U-Boot (and TF-A) support.
Based on the just added pinctrl, clock and DRAM support, this adds the
missing bits, mostly addresses and values for the SPL.
The A133 seems to be an predecessor to the H6, so we can share a lot of
code with that (and the H616 code), and just need to adjust some details.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This adds preliminary support for the DRAM controller in the Allwinner
A100/A133 SoCs.
This is work in progress, and has rough edges, but works on at least
three different boards. It contains support for DDR4 and LPDDR4.
Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest>
[Andre: formatting fixes, adapt to mainline, drop unused parameters,
remove struct struct sunxi_mctl_com_reg, hardcode MR registers,
switch to mctl_check_pattern(), remove simple DRAM check]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Commit 6fe50e3950 ("arm: asm/system.h: mrc and mcr need .arm if
__thumb2__ is not set") is not a proper fix for the LTO link error
mentioned in its description. It causes 32-bit arm instructions to be
mixed with thumb instructions, which the Kirkwood SoCs do not support.
For example, board_init_r() is mostly generated in Thumb-1 mode as
expected since the build flags contain -mthumb -mthumb-interwork. The
MCR instruction corresponding to writefr_extra_feature_reg() is also
correcly emitted as a 32-bit ARM instruction (it cannot be encoded in
Thumb-1 anyways). The problem is, the compiler inlines the MCR without
generating the BX or BLX instruction which are needed to transition
between the ARM and the Thumb-1 states. From the objdump output:
006186a0 <board_init_r>:
board_init_r():
/home/jerome/work/u-boot/common/board_r.c:799
6186a0: b5f0 push {r4, r5, r6, r7, lr}
6186a2: b0ab sub sp, #172 @ 0xac
get_gd():
/home/jerome/work/u-boot/./arch/arm/include/asm/global_data.h:127
6186a4: 464a mov r2, r9
...
/home/jerome/work/u-boot/arch/arm/mach-kirkwood/cpu.c:242
619aae: 9b15 ldr r3, [sp, #84] @ 0x54
writefr_extra_feature_reg():
/home/jerome/work/u-boot/./arch/arm/include/asm/arch/cpu.h:100
619ab0: ee2f3f11 mcr 15, 1, r3, cr15, cr1, {0}
^^^^^^^^
32-bit ARM instruction
Further investigation is needed to understand how to fix the issue so
that the code size is minimal for all boards. In the mean time, this
fix disables LTO for the two problematic files (common/board_f.c and
common/board_r.c). This makes the Kirkwood-based boards bootable again.
The binary size is increased by 1048 bytes which is perfectly
acceptable.
Fixes: 6fe50e3950 ("arm: asm/system.h: mrc and mcr need .arm if __thumb2__ is not set")
Reported-by: Tony Dinh <mibodhi@gmail.com>
Tested-by: Tony Dinh <mibodhi@gmail.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The function definition of fit_check_sign() is guarded by
"#ifdef CONFIG_FIT_SIGNATURE" in "tools/image-host.c". If we try
to build it without CONFIG_FIT_SIGNATURE, we will get an error:
/usr/bin/ld: tools/fit_check_sign.o: in function `main':
fit_check_sign.c:(.text.startup+0x165): undefined reference to `fit_check_sign'
collect2: error: ld returned 1 exit status
Fixes: 9c79c8fe70 ("tools/fit_check_sign: make key optional")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e66 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Device bus address might not be valid for direct access when the bus
address and CPU address are not the same. Use dev_bus_to_phys() to
translate bus address back to CPU address.
Fixes: 3d98b8c504 ("net: designware: Invalidate RX buffer cache before freeing the DMA descriptor")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
As stated in 5e847f7729 ("efi_loader: call efi_init_early() earlier"):
efi_init_early() creates an event hook for block device probing.
It has to be called before any block device is probed.
Indeed, efi_bl_init() registers EVT_DM_POST_PROBE event, which calls
efi_disk_probe() whenever any block device is probed. And to make that
hook work, the initialization of all block devices was put after
efi_init_early() in initcall_run_r():
INITCALL(efi_init_early);
INITCALL(initr_nand);
INITCALL(initr_onenand);
INITCALL(initr_mmc);
Because LDFW firmware is being read from MMC, attempt to load LDFW in
board_init() causes MMC driver to be probed. And because board_init() is
executed before efi_init_early(), the hook mentioned above won't work
for MMC devices anymore. So EFI disk objects won't be created, which in
turn makes the EFI subsystem non-functional, showing next symptoms:
- 'efidebug dh' output is empty
- attempt to add boot devices in 'eficonfig' shows this message:
"No block device found!"
- 'bootefi selftest $fdtcontroladdr' shows this warning:
"Cannot persist EFI variables without system partition"
- booting GRUB with 'bootefi' runs minimal GRUB shell which doesn't
see any block devices as well, probably because EFI vars weren't
passed
Load LDFW in board_late_init() instead, as it's called after
efi_init_early(). This fixes the described problem and makes it possible
to run EFI apps like GRUB correctly, add entries in 'eficonfig', and
makes 'efivar --list' command in Linux rootfs actually show EFI
variables.
The only user of LDFW at the moment is the TRNG driver, and it's probed
later, only when it's going to be used (e.g. on "rng" command). So it's
fine to load LDFW in board_late_init(). Now the corresponding call order
will look like this:
efi_init_early()
initr_mmc()
mmc_probe()
EVT_DM_POST_PROBE -> efi_disk_probe()
board_late_init()
load_ldfw() -> fs_read(), blk_dread()
exynos_trng_probe()
Fixes: ccfd8de541 ("board: samsung: e850-96: Report LDFW loading failures")
Fixes: f04e58cc97 ("board: samsung: e850-96: Load LDFW firmware on board init")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
The note about U-Boot not being able to verify server certificates is
false now that WGET_CACERT and WGET_BUILTIN_CACERT have been added.
Remove it.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
