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

[Zhentao Guo <zhentao.guo@amlogic.com>]

Hi Feras,

>
> Hi Zhentao,
>
> On Fri, 24 Jul 2026 07:04, Zhentao Guo via B4 Relay 
> <devnull+zhentao.guo.amlogic.com@kernel.org> 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