[PATCH v2 00/10] crypto: allwinner: enable sun8i-ce FIT crypto

[James Hilliard]

On Sat, Jul 4, 2026 at 4:38 AM Peter Robinson <pbrobinson at gmail.com> wrote:
>
> Hey James,
>
> > This series enables Allwinner Crypto Engine backed FIT decryption and
> > FIT signature/hash validation for secure-boot flows on H6/H616-class
> > boards, covering both SPL and U-Boot proper.
> >
> > The purpose is to use CE-backed AES for encrypted FIT payloads on H6/H616
> > and CE-backed ECDSA validation where the CE ECC engine is available,
> > currently H616, instead of relying only on software crypto paths.
>
> Out of interest do you have details of the speed up?

I don't have direct comparisons for everything being added since
there doesn't appear to be a software ECDSA pathway in uboot for
example.

AES-256 CBC when I tested was generally going at least 25 MiB/s.

Hash algos were generally fairly similar.

I think ecdsa signatures were generally around 30ms per signature
validated but that was just measured via UART timing mostly.

Note that these are very rough numbers.

>
> > At a high level this adds:
> >
> >   - SPL driver-model crypto plumbing for AES and hash providers.
> >   - FIT decrypt-to-buffer support and SPL FIT cipher support, so SPL can
> >     decrypt an encrypted U-Boot proper FIT without allocating another full
> >     payload buffer.
> >   - A shared sun8i-ce parent driver with AES and hash children for H6/H616.
> >   - An H616 ECDSA child for CE-backed FIT signature validation, plus common
> >     ECDSA curve-size and key-encoding fixes for secp224r1, prime256v1,
> >     secp384r1 and secp521r1.
> >
> > The AES child supports software-provided AES-128/192/256 keys in ECB and
> > CBC modes. The hash child supports the CE one-shot MD5/SHA1/SHA256/SHA384/
> > SHA512 methods used by FIT verification. The ECDSA child exposes the H616
> > CE ECC verifier through UCLASS_ECDSA.
>
> This is me purely thinking out loud. I did some very basic testing on
> a Allwinner A64 device of the HW crypto engine and the arm native
> crypto extensions and while there was some difference I wonder whether
> it makes more sense to looks at implementing the later, upstream Linux
> seems to be going more in that route rather than device specific
> engines as the performance is compatible and it's more widely deployed
> and hence we'd have one code path that can benefit the majority of
> devices rather that a bunch of specific drivers that need maintenance.
> Had you considered that option?

Well I think it's probably good to have both as options either way as a
HW crypto engine may have various benefits beyond just performance.

For example some HW crypto engines can use efuse based keys
directly via special CE slots.