| #
11f03c2e |
| 17-Nov-2025 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "fix(allwinner): avoid crash when running without DTB" into integration
|
| #
69b4a591 |
| 15-Oct-2025 |
Andre Przywara <andre.przywara@arm.com> |
fix(allwinner): avoid crash when running without DTB
For determining the PMIC type and the bus its connected to, we use the DTB that is appended to the U-Boot binary, by looking for it in DRAM. And
fix(allwinner): avoid crash when running without DTB
For determining the PMIC type and the bus its connected to, we use the DTB that is appended to the U-Boot binary, by looking for it in DRAM. And while we bail out correctly if we don't find it there, we later try to use the DTB pointer - without checking.
Add a check in sunxi_pmic_setup(), to only proceed if we have found a DTB before, and exit early otherwise.
This fixes more experimental setups, where TF-A is run without U-Boot.
Change-Id: I9a7677be057a84fe6bee093d098be758970eec81 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| #
d359a6d7 |
| 11-Jun-2025 |
André Przywara <andre.przywara@arm.com> |
Merge "fix(allwinner): fix variable may be used uninitialized error" into integration
|
| #
ce750f16 |
| 15-May-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(allwinner): fix variable may be used uninitialized error
When building with LTO, the compiler observes that i2c_read() can return without writing val, declaring the variable may be used unnitial
fix(allwinner): fix variable may be used uninitialized error
When building with LTO, the compiler observes that i2c_read() can return without writing val, declaring the variable may be used unnitialized. However, there is a sufficient error check that will prevent an actual use. So calm the compiler by giving a safe default.
Change-Id: I558618467ae324a6b5b495ec9d204935135f226d Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
55b4c5ce |
| 29-Jul-2024 |
Manish Pandey <manish.pandey2@arm.com> |
Merge changes from topic "h616_pmics" into integration
* changes: feat(allwinner): adjust H616 L2 cache size in DTB feat(allwinner): h616: add support for AXP717 PMIC feat(allwinner): h616: ad
Merge changes from topic "h616_pmics" into integration
* changes: feat(allwinner): adjust H616 L2 cache size in DTB feat(allwinner): h616: add support for AXP717 PMIC feat(allwinner): h616: add support for AXP313 PMIC feat(allwinner): h616: add I2C PMIC support refactor(allwinner): h616: prepare for more than one PMIC model
show more ...
|
| #
646d06b2 |
| 21-Mar-2024 |
Andre Przywara <andre.przywara@arm.com> |
feat(allwinner): h616: add support for AXP717 PMIC
On at least one new device we see an Allwinner H700 SoC paired with the X-Powers AXP717 PMIC. In contrast to the small AXP313, this is a quite comp
feat(allwinner): h616: add support for AXP717 PMIC
On at least one new device we see an Allwinner H700 SoC paired with the X-Powers AXP717 PMIC. In contrast to the small AXP313, this is a quite complete PMIC, with many voltage rails, battery and USB-C charging support. It supports both RSB and I2C control options.
Add the compatible string to the list of checked devices. The AXP717 apparently does not feature a version ID register, but we read 0xff from that address 0x3, so use this as an indication of its presence, since this value differs from what we read from the other PMICs. The register offset and bit position for the power off functionality is again different, but easy to put into our switch/case.
Setting up regulators in TF-A is now somewhat obsolete, since U-Boot does a much better job in this now, and can figure out which regulators are actually needed. So we don't add the regulator setup code, and just use the PMIC for the power-off functionality.
Change-Id: Ie6b4c91517014adcc79d9a3459c75545fa3a63e6 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| #
03851367 |
| 21-Mar-2024 |
Andre Przywara <andre.przywara@arm.com> |
feat(allwinner): h616: add support for AXP313 PMIC
Many newer boards with the H616 and its sibling H618 are now paired with the X-Powers AXP313 PMIC. This is a simpler PMIC, with only a few voltage
feat(allwinner): h616: add support for AXP313 PMIC
Many newer boards with the H616 and its sibling H618 are now paired with the X-Powers AXP313 PMIC. This is a simpler PMIC, with only a few voltage rails and no extra functionality except the power key support. In contrast to the AXP305 it can only be controlled via I2C.
Add a check to look for the AXP313 compatible string in the devicetree, and set the PMIC type and I2C address accordingly, if one is found. With only very few voltage rails available, all of them are mostly in use and are thus enabled at reset already, so we can skip the regulator setup entirely.
Change-Id: I01962854109e43793b4f56553c1ca9e1f752e30d Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| #
04445898 |
| 21-Mar-2024 |
Andre Przywara <andre.przywara@arm.com> |
feat(allwinner): h616: add I2C PMIC support
The X-Powers AXP305 PMIC can be controlled via both I2C or RSB (an Allwinner specific bus similar to I2C), but we chose to use only RSB, because that's ea
feat(allwinner): h616: add I2C PMIC support
The X-Powers AXP305 PMIC can be controlled via both I2C or RSB (an Allwinner specific bus similar to I2C), but we chose to use only RSB, because that's easier to program and also used by Linux. The AXP313a PMIC however supports only I2C, so we need to support both buses, and need to decide which to use at runtime.
Prepare the PMIC code to add (back) I2C support. We initially used I2C on the H6/AXP805 combination, but replaced that later with RSB. So this patch is bringing some of that older code back.
The decision whether to use I2C or RSB is made by the devicetree, since on some boards even RSB capable PMICs are controlled via I2C, since they share the bus with only I2C capable devices, for instance RTCs.
At the moment this will still use RSB to drive the AXP305, but the (dynamic) I2C code will be used shortly to support the AXP313.
This increases the code size by one 4K page, but with 80K out of the reserved 256K we are still very far away from our limit.
Change-Id: I65c1e7df93dbd2dcd171b3fc486533a2948cc75b Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| #
a0597ba2 |
| 21-Mar-2024 |
Andre Przywara <andre.przywara@arm.com> |
refactor(allwinner): h616: prepare for more than one PMIC model
Most devices based on Allwinner SoCs come with a certain fixed combination of Power Management ICs (PMICs) and SoC, for instance the A
refactor(allwinner): h616: prepare for more than one PMIC model
Most devices based on Allwinner SoCs come with a certain fixed combination of Power Management ICs (PMICs) and SoC, for instance the A64 with the AXP803, or the H6 with the AXP805. This allowed us to include the respective PMIC support code into each build target at build time.
Similarly on H616 devices we initially saw only the AXP305, but for a while now the simpler (and cheaper) AXP313a is a popular companion to the H616 on many new boards. On at least one new device the AXP717 is used as well. With some rudimentary AXP version check in place we at least detected the case of an unsupported SoC, but threw an error message, and lost support for powering off the device.
Refactor the existing PMIC code to be able to support more than one PMIC model, detected at runtime. For this we use a variable for the RSB runtime address instead of hardcoding the address used on the AXP305, and read the hardware bus address from the devicetree. Also we look up the used PMIC in the devicetree, and set the PMIC model accordingly. To be on the safe side, we also confirm the real PMIC used by checking its version register and comparing that with the expected value. Finally the register offset and value to power off the PMIC is moved direclty into the platform code, as those values differ between the different PMICs.
This is just refactoring and better error report, we still only support the AXP305 on RSB at the moment.
Change-Id: I00b26ce4d30bb570ee1cd4979d0cdc9d6c020729 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| #
8078b5c5 |
| 30-Mar-2021 |
André Przywara <andre.przywara@arm.com> |
Merge changes from topic "allwinner_h616" into integration
* changes: allwinner: H616: Add reserved-memory node to DT allwinner: Add Allwinner H616 SoC support allwinner: Add H616 SoC ID all
Merge changes from topic "allwinner_h616" into integration
* changes: allwinner: H616: Add reserved-memory node to DT allwinner: Add Allwinner H616 SoC support allwinner: Add H616 SoC ID allwinner: Express memmap more dynamically allwinner: Move sunxi_cpu_power_off_self() into platforms allwinner: Move SEPARATE_NOBITS_REGION to platforms doc: allwinner: Reorder sections, document memory mapping
show more ...
|
| #
26123ca3 |
| 28-Nov-2020 |
Andre Przywara <andre.przywara@arm.com> |
allwinner: Add Allwinner H616 SoC support
The new Allwinner H616 SoC lacks the management controller and the secure SRAM A2, so we need to tweak the memory map quite substantially: We run BL31 in DR
allwinner: Add Allwinner H616 SoC support
The new Allwinner H616 SoC lacks the management controller and the secure SRAM A2, so we need to tweak the memory map quite substantially: We run BL31 in DRAM. Since the DRAM starts at 1GB, we cannot use our compressed virtual address space (max 256MB) anymore, so we revert to the full 32bit VA space and use a flat mapping throughout all of it.
The missing controller also means we need to always use the native PSCI ops, using the CPUIDLE hardware, as SCPI and suspend depend on the ARISC.
Change-Id: I77169b452cb7f5dc2ef734f3fc6e5d931749141d Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|