Re: [PATCH v6 0/6] Add Amlogic stateless H.264 video decoder for S4

[Zhentao Guo]

Hi Feras,

> Hi Zhentao,
>
> On Fri, 24 Jul 2026 07:04, Zhentao Guo via B4 Relay 
> <devnull+zhentao.guo.amlogic.com@xxxxxxxxxx> wrote:
> > Introduce initial driver support for Amlogic's new video acceleration
> > hardware architecture, designed for video stream decoding.
> >
> > Compared to the current Amlogic video decoder hardware architecture,
> > this new implementation eliminates the Esparser hardware component,
> > enabling direct vb2 buffer input. The driver is designed to support
> > the V4L2 M2M stateless decoder API. The initial phase includes support
> > for H.264 decoding on Amlogic S805X2 platform.
> >
> > The driver needs to work alongside with a signed firmware. The 
> > loading process of
> > the signed fw is as follow.
>
> Is the firmware still signed on devices that do not have secure boot
> enabled? (which means none of their boot chain is signed)
> Do the signing checks take place in BL32 or elsewhere?

The firmware mentioned is not enabled in the chips without the secure 
boot . In other words, this policy is not effective for the legacy 
platform like SM1/G12.

Yes, the signing check process happens in BL32.

> > Stage1: Decypt and decompose the full firmware package when the 
> > driver is probed.
> >  +---------------------+ +---------------------+
> >  |  Decoder Driver     |                        |  TEE Shared Memory  |
> >  |  (Kernel Space)     | |                     |
> >  |  +---------------+  |                        | +---------------+  |
> >  |  | video_ucode   |  |                        |  | firmware      |  |
> >  |  |    .bin       |  |  Copy payload to SHM   |  | payload     |  |
> >  |  | (from fs)     |  | ---------------------> |  | (Secure RAM)  |  |
> >  |  +---------------+  |                        | +---------------+  |
> >  +---------------------+ +----------+----------+
> >                                                            |
> >                                                            | PTA 
> > Invocation
> >                                                            v
> > +-------------------------------+
> >                                       | BL32              |
> >                                       | +-------------------------+  |
> >                                       |  | Decrypt Firmware        |  |
> >                                       | +-----------+-------------+  |
> >                                       | |                |
> >                                       | v                |
> >                                       | +-------------------------+  |
> >                                       |  | Decompose the full      |  |
> >                                      |  | firmware pacakge        |  |
> >                                       | +-----------+-------------+  |
> >                                       | |                |
> >                                       | v                |
> >                                       | +-------------------------+  |
> >                                       |  | Store decomposed .bin   |  |
> >                                       |  | in Secure Memory        |  |
> >                                       | +-------------------------+  |
> > +-------------------------------+
>
> Is BL32 strictly needed to load that firmware? I know on at least 
> older SoCs
> (sm1 and older) BL32 is not required for booting and amlogic-based 
> SBCs are
> often used without BL32. So once this gets ported to older SoCs, would
> it have a hard-dependency on BL32? And if yes, can upstream Arm Trusted
> Firmware-A BL32 be used instead of the Amlogic blob?

At least on S4 and newer SoC platforms, loading this firmware strictly 
requires the closed-source BL32 provided by Amlogic. If this solution is 
ported to older SoCs, it will also have a dependency on BL32.
The upstream Arm Trusted Firmware-A BL32 cannot be used either, as it 
lacks the capability to verify firmware signatures.
I understand your concerns, but this is primarily for the security of 
encrypted data. Amlogic SoCs do not have a dedicated CPU for processing 
encrypted data, both encrypted and clear data eventually converge on the 
AMRISC micro-core for processing (the firmware mentioned above is what 
drives this core). Therefore, we need to encrypt the firmware to prevent 
it from being reverse-engineered, which would otherwise lead to the risk 
of encrypted data leakage.
> Best regards,
> Ferass

Best regards,

Zhentao