There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This concludes support for the Allwinner A133 SoC, the biggest chunk of
which is the DRAM init code. Also includes support for a devboard using
this SoC, the DT of which got added to the kernel only recently. The
same is true for another H618 devboard, so add the respective devconfig
as well.
Gitlab CI passed, and I booted that briefly on those two boards.
Observing the crash when we add the i2c-arbitrator node in the device
tree as per the DT bindings. The issue is with the child node of
i2c-arbitrator@72 i.e., i2c@f1950000->i2c-arbitrator@72->i2c-arb, as the
arbitrator uses the uclass of mux(UCLASS_I2C_MUX) and the mux uclass driver
checks for the "reg" property using the i2c_mux_child_post_bind() function,
if it won't find the "reg" property it will return -EINVAL which is leading
to the crash.
So, add the logic to check whether the child node has the "reg" property,
if the "reg" property exists then read the "reg" and update the channel.
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-arb.txt
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
This PR introduces 3 new platforms, two from the new Dragonwing IQx
series (QCS615 and QCS8300) as well as the IPQ5424.
Additionally:
* Support for booting downstream Android boot images on some phones is
added
* Capsule update support is expanded to be more generic, determining
which partition U-Boot was flashed to automatically and supporting
many more boards.
* Minor capsule update bugs are fixed
* A watchdog driver is added and gets timeout support
* Autoboot now requires pressing "space" specifically to stop booting as
a workaround for some boards getting rogue key presses which would
cause autoboot to fail
* Documentation is added for the Dragonwing boards
* The RB1/2 now use USB gadget mode rather than host
* A bug is fixed where GPIO reads could return incorrect values
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>
