[TF-A / sunxi] Allwinner A733 (sun60iw2) TF-A Support & Validation on Orange Pi 4 Pro

[TF-A / sunxi] Allwinner A733 (sun60iw2) TF-A Support & Validation on Orange Pi 4 Pro

[Alastair D'Silva]

Hi Andre, Jernej,

I have been working on upstream support for the Allwinner A733 (sun60iw2)
SoC using the Xunlong Orange Pi 4 Pro as my test vehicle.

Building on top of Jernej's in-flight A523/A733 groundwork (specifically
commit 5bc9605cb "feat(allwinner): add A733 support"), I have developed
and verified a clean 6-commit series that completes BL31 enablement for
the A733 without requiring vendor out-of-tree SMC hacks.

Summary of What Was Implemented:
1. Disable SCPI in Favor of Native PSCI:
   Explicitly sets SUNXI_PSCI_USE_SCPI := 0 in sun60i_a733/platform.mk to
   avoid compiling unused SCPI driver dependencies.
2. Generalize SUNXI_BL31_IN_DRAM and Relocate A733 BL31:
   Because U-Boot SPL on this SoC is ~136 KB due to embedded LPDDR5 PMU
   firmware, SRAM headroom is insufficient for BL31. I generalized
   SUNXI_BL31_IN_DRAM to allow platform override of BL31_BASE and
   BL31_LIMIT (placing A733 BL31 in DRAM at 0x48000000), dynamically
   named the reserved-memory DT node (tf-a@%lx), and added
   common/fdt_wrappers.c to allwinner-common.mk for SUNXI_AMEND_DTB builds.
3. Dedicated 4KB Per-Core Stack for DRAM BL31:
   Enlarged PLATFORM_STACK_SIZE to 4KB per core when SUNXI_BL31_IN_DRAM is
   enabled.
4. Cortex-A76 Silicon Errata Workarounds:
   Enabled applicable Cortex-A76 errata workarounds in platform.mk for
   the performance cores.
5. Security Controller Un-gating:
   Configured the Security Permission Controller (SPC) decode ports and
   bypass register, CCU CPU interconnect clocks and resets, DMAC0
   security gate, and dual IOMMU auto-bypass in sunxi_security_setup().
   This eliminates the need for vendor SMC fastcall backdoors
   (0xC000FF05 / 0xC000FF06) when running normal-world drivers.
6. Per-Core Security Re-arm on PSCI CPU_ON:
   Added sunxi_security_setup_core(core) to re-configure only the waking
   core's SPC decode port in sunxi_pwr_domain_on_finish(), avoiding full
   SoC peripheral security re-initialization on hotplug.

Validation on Physical Hardware:
I verified this series on actual Orange Pi 4 Pro hardware across the
entire software stack:
- 8-Core SMP Boot: Clean bring-up of 2x Cortex-A76 + 6x Cortex-A55 under
  Linux 7.x with dual-cluster cpufreq.
- PSCI Dynamic CPU Hotplug: Verified cycling secondary cores 1–7 offline
  and back online under load.
- PSCI System Reset: Clean reboot via PSCI SYSTEM_RESET.
- Hardware Qualification: Passed full automated qualification testing
  across all SoC peripherals un-gated by BL31, including PCIe Gen3 (NVMe),
  Display Engine 3.5 DRM, GMAC, SD card IDMAC, Crypto Engine V5 (HWRNG),
  NPU, THS, and PMIC.

Related Repositories & Test Environment:
For reproducibility or inspection of how this integrates end-to-end,
the corresponding branches are available here:
- TF-A (sun60i_a733):
  https://github.com/InfernoEmbedded/arm-trusted-firmware/commits/sun60i_a733
- U-Boot (v2026.07 rebase with 100% open-source SPL & freestanding C PMU
  firmware, completely replacing vendor boot0 blobs):
  https://github.com/InfernoEmbedded/u-boot/commits/feature/sunxi-a733-orangepi4pro
- Linux Kernel (7.x edge with A733 DT and driver support):
  https://github.com/InfernoEmbedded/linux/commits/feature/sunxi-a733-orangepi4pro

Upstream Coordination:
The TF-A commits are prepared with Gerrit Change-Id headers.

Jernej, Andre:
How would you prefer to coordinate this for review.trustedfirmware.org?
- Should I submit these 6 commits to Gerrit as dependent changes on top
  of your A523/A733 branch?
- Or would you prefer to squash/fold these fixes directly into the base
  A733 submission before pushing?

I am happy to follow whichever approach works best for you.

Cheers,

-- 
Alastair D'Silva

-- 
Alastair D'Silva
0493 18 5566

Re: [TF-A / sunxi] Allwinner A733 (sun60iw2) TF-A Support & Validation on Orange Pi 4 Pro

[Alastair D'Silva]

On Tue, 2026-10-06 at 19:42 +0200, Jernej Škrabec wrote:
> Hi!
> 
> Dne torek, 6. oktober 2026 ob 14:16:49 Srednjeevropski poletni čas je Alastair D'Silva napisal(a):
> > Hi Andre, Jernej,
> > 
> > I have been working on upstream support for the Allwinner A733 (sun60iw2)
> > SoC using the Xunlong Orange Pi 4 Pro as my test vehicle.
> > 
> > Building on top of Jernej's in-flight A523/A733 groundwork (specifically
> > commit 5bc9605cb "feat(allwinner): add A733 support"), I have developed
> > and verified a clean 6-commit series that completes BL31 enablement for
> > the A733 without requiring vendor out-of-tree SMC hacks.
> > 
> > Summary of What Was Implemented:
> > 1. Disable SCPI in Favor of Native PSCI:
> >    Explicitly sets SUNXI_PSCI_USE_SCPI := 0 in sun60i_a733/platform.mk to
> >    avoid compiling unused SCPI driver dependencies.
> 
> Don't do that. A733 (as does A523) has ARISC core, so porting Crust
> firmware is possible.
> 

Understood completely. The intention was simply that because Crust is
not yet ported to NCAT2, native PSCI is required to boot today. I will
ensure SCPI is not hard-disabled (using SUNXI_PSCI_USE_SCPI ?= 0 with
native PSCI default), so that when Crust support is developed for the
ARISC core on A523/A733, it drops in without conflict.

> > 
<snip>
> 

> > 6. Per-Core Security Re-arm on PSCI CPU_ON:
> >    Added sunxi_security_setup_core(core) to re-configure only the waking
> >    core's SPC decode port in sunxi_pwr_domain_on_finish(), avoiding full
> >    SoC peripheral security re-initialization on hotplug.
> 
> Is this something that can be done for every SoC?
> 

Yes, this applies to the whole NCAT2 family (both A523 and A733).
On NCAT2 SoCs, the Security Permission Controller (SPC) introduced
per-core CPU decode registers (SUNXI_SPC_CPU_DECPORT_SET_REG). When an
individual core transitions out of power-down via PSCI CPU_ON, hardware
resets that core's decode port to Secure-only.

Older SoCs (A64/H5/H6) only have peripheral decode ports, so they never
encountered this. Because A523 and A733 share sunxi_native_pm_ncat2.c,
calling sunxi_security_setup_core(core) in sunxi_pwr_domain_on_finish()
directly benefits both A523 and A733, while remaining an invisible
no-op for SoCs that do not define per-core decode registers.

> > 
> > Validation on Physical Hardware:
> > I verified this series on actual Orange Pi 4 Pro hardware across the
> > entire software stack:
> > - 8-Core SMP Boot: Clean bring-up of 2x Cortex-A76 + 6x Cortex-A55 under
> >   Linux 7.x with dual-cluster cpufreq.
> > - PSCI Dynamic CPU Hotplug: Verified cycling secondary cores 1–7 offline
> >   and back online under load.
> > - PSCI System Reset: Clean reboot via PSCI SYSTEM_RESET.
> > - Hardware Qualification: Passed full automated qualification testing
> >   across all SoC peripherals un-gated by BL31, including PCIe Gen3 (NVMe),
> >   Display Engine 3.5 DRM, GMAC, SD card IDMAC, Crypto Engine V5 (HWRNG),
> >   NPU, THS, and PMIC.
> > 
> > Related Repositories & Test Environment:
> > For reproducibility or inspection of how this integrates end-to-end,
> > the corresponding branches are available here:
> > - TF-A (sun60i_a733):
> >   https://github.com/InfernoEmbedded/arm-trusted-firmware/commits/sun60i_a733
> > - U-Boot (v2026.07 rebase with 100% open-source SPL & freestanding C PMU
> >   firmware, completely replacing vendor boot0 blobs):
> >   https://github.com/InfernoEmbedded/u-boot/commits/feature/sunxi-a733-orangepi4pro
> > - Linux Kernel (7.x edge with A733 DT and driver support):
> >   https://github.com/InfernoEmbedded/linux/commits/feature/sunxi-a733-orangepi4pro
> > 
> > Upstream Coordination:
> > The TF-A commits are prepared with Gerrit Change-Id headers.
> > 
> > Jernej, Andre:
> > How would you prefer to coordinate this for review.trustedfirmware.org?
> > - Should I submit these 6 commits to Gerrit as dependent changes on top
> >   of your A523/A733 branch?
> > - Or would you prefer to squash/fold these fixes directly into the base
> >   A733 submission before pushing?
> 
> What fixes?
s/fixes/patches/

> 
> > 
> > I am happy to follow whichever approach works best for you.
> 
> I'm fine if you or someone else takes over upstreaming A523 and A733.
> This would need fixing comments which are already on Gerrit.
> 

I am happy to take ownership of reviving and upstreaming the combined
A523 and A733 series on Gerrit. I will rebase the base A523 patches,
address the open review comments (such as the standalone watchdog #if
syntax and GIC driver feedback), and stack the A733 enablement on top.
One note on testing: I only have physical A733 hardware on hand
(Orange Pi 4 Pro), where I have verified the full stack (SMP, hotplug,
PSCI reboot, and peripherals). For A523, I will ensure it compile-tests
cleanly across all sunxi configs, and then ask you or others on the list
with A523 hardware for a quick Tested-by verification on boot.


-- 
Alastair D'Silva
0493 18 5566

Re: [TF-A / sunxi] Allwinner A733 (sun60iw2) TF-A Support & Validation on Orange Pi 4 Pro

[Alvin Sun]

Hi Alastair,

We have an open-source firmware stack for A733 - EDK2 (UEFI) plus TF-A
BL31 - and our Cubie A7A boards boot from it:

  https://github.com/alvinsun039/arm-trusted-firmware   (branch a733-bl31)
  https://github.com/alvinsun039/edk2-a733               (branch main)

Which part of the upstream work would be most useful for us to take on?

Regards,
Alvin Sun

Re: [TF-A / sunxi] Allwinner A733 (sun60iw2) TF-A Support & Validation on Orange Pi 4 Pro

[Alastair D'Silva]

On Wed, 2026-11-11 at 09:10 +0800, Alvin Sun wrote:
> Hi Alastair,
> 
> We have an open-source firmware stack for A733 - EDK2 (UEFI) plus TF-A
> BL31 - and our Cubie A7A boards boot from it:
> 
>   https://github.com/alvinsun039/arm-trusted-firmware   (branch a733-bl31)
>   https://github.com/alvinsun039/edk2-a733               (branch main)
> 
> Which part of the upstream work would be most useful for us to take on?


Hi Alvin,

Thanks! I'm just about to submit UBoot patches for SPL (replacing vendor boot0)
and the PMU that trains memory.

I only have LPDDR5 support in it at the moment, if you have other Cubie boards on
hand that support LPDDR4, adding LPDDR4 support to that would be of huge value
(I don't have the relevant hardware to test).

Cheers,

-- 
Alastair D'Silva