Re: [PATCH 00/34] sunxi: clock refactoring and Allwinner A523 support

[Andre Przywara <andre.przywara@arm.com>]

On Sat, 5 Apr 2025 02:44:33 +0000
Yixun Lan <dlan@gentoo.org> wrote:

Hi,

> On 11:35 Sun 23 Mar     , Andre Przywara wrote:
> > This series introduces support for the Allwinner A523 SoC family. The
> > same die is used in different packages: the A523, A527, T527, and H728:
> > they connect a different set of peripherals to the pins, or enable extra
> > goodies like an NPU. From a U-Boot perspective those chips do not differ
> > much, all the differences are described in the board DT files.
> > These patches are not the most refined at the moment, but I hope that
> > people start reviewing them, so we can merge the ones that are ready,
> > to reduce their number.
> > 
> > To be able to share the SPL clock code, the existing H6 code gets
> > refactored in patches 01-13. This removes the C struct describing the
> > 127 clock registers, and replaces it with macros defining the register
> > offsets. For more rationale and explanation see the 01/34 commit message.
> > 
> > Patches 14-20 extend the existing Allwinner U-Boot drivers to cope with
> > some of the changed peripherals, this includes the mandatory clock and
> > pinctrl drivers, but also some clock tweaks for the MMC controller
> > driver, and support for the new watchdog and the AXP323 used.
> > 
> > Patches 21-23 update some SPL bits to be able to cope with the A523.
> > Patches 24-28 extend the FEL handling code: the A523 has a GICv3, which
> > requires saving some GICv3 system registers, plus the IRQ mode stack
> > pointer. Patches 25-27 refactor the CPU clock code, and add the new
> > clock bits required by the A523.
> > 
> > Patch 29-32 add the new SPL bits for the A523, most prominently the DRAM
> > initialisation code. Many thanks to Jernej and Mikhail for providing
> > this part, there is a great reverse engineering and testing effort behind
> > this.
> > 
> > Patch 33 copies the DT files from the proposed Linux patches. They have
> > not been merged yet, mostly due to one missing DT binding dependency in
> > the linux-next tree, but have otherwise been agreed upon, with almost
> > every used binding being already merged. Eventually we will use the copy
> > from the DT rebasing repo, but for now those files must do.
> > 
> > The final patch adds defconfig files for the three boards that seem to be
> > the most popular at the moment, they include two development boards and
> > one TV box. The most interesting bits in there are the DRAM parameters.
> > 
> > Please have a look, review, and test.
> > 
> > Thanks!
> > Andre
> >   
> 
> 
> Is there any docs about how to compile and run this patch series?
> I've got some complaint while apply to v2025.04-rc5 (not found correct base myself)

Yes, it's pretty much work in progress, I just wanted to get the
patches out on the list, to start the review process.
You should be able to base it on "sunxi-next" or U-Boot's main next
branch.

> 
> I'm following doc/board/allwinner/sunxi.rst to build and using sunxi-tools to run,
> but it seems stuck at running uboot (should pass SPL stage)
> 
> here are steps I tried
> 
> 1) build trust firmware
> $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
> $ make CROSS_COMPILE=aarch64-unknown-linux-gnu- PLAT=sun50i_a64
> is sun50i_a64 correct for a527 SoC?

No, A64 will not work, as you figured ;-)
Jernej has a WIP branch for TF-A here:
https://github.com/jernejsk/arm-trusted-firmware/commits/a523/
Please use this and the "sun55i_a523" build target.

> besides, got a oversize error if DEBUG=1 enabled

Yes, this is a known issue, the available secure SRAM on the A64 is
just too small for all the features. Should not be a problem on other
SoCs including the A523/T527, though.

> 
> 2) build SCP

SCP is highly optional, and there is no port available anyway.
I would not know of someone working on it as well.

> 
> 3) build uboot
> $ export BL31=/home/work/trusted-firmware-a/build/sun50i_a64/release/bl31.bin  
> export SCP..
> $ make ARCH=arm CROSS_COMPILE=aarch64-unknown-linux-gnu- -j30 radxa-a5e_defconfig
> $ make ARCH=arm CROSS_COMPILE=aarch64-unknown-linux-gnu- -j30

Just use .../build/sun55i_a523/debug/bl31.bin, as mentioned above.

> 
> 4) run:  sunxi-fel -v uboot u-boot-sunxi-with-spl.bin
>  4.a) serial console from a527 board
> 
> U-Boot SPL 2025.04-rc5-00048-g432f0f975187 (Apr 05 2025 - 10:21:15 +0800)
> DRAM: 4096 MiB
> Trying to boot from FEL

Yes, this is the effect when TF-A is built for the wrong target,
normally you would see TF-A messages here.
 
>  4.b) from host which run sunxi-fel
> 
>  $ sunxi-fel -v uboot u-boot-sunxi-with-spl.bin
> found DT name in SPL header: sun55i-a527-radxa-a5e
> Stack pointers: sp_irq=0x00045400, sp=0x00060300
> MMU is not enabled by BROM
> => Executing the SPL... done.  
> loading image "ARM Trusted Firmware" (37076 bytes) to 0x54000
> loading image "U-Boot" (657216 bytes) to 0x4a000000
> loading DTB "sun55i-a527-radxa-a5e" (19024 bytes)
> Starting U-Boot (0x00054000).
> Store entry point 0x00054000 to RVBAR 0x08000040, and request warm reset with RMR mode 3... done.
> 
> is ATF loading address correct, 0x54000 here? which seems override sp address?

Yes, that's the correct address. Which SP would it collide with, anyway?

So in summary you did everything right, and the SPL is returning to FEL
with DRAM initialised, which is the biggest hurdle.
Just use the correct A523 TF-A branch and build target.

Cheers,
Andre.