From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9C97CC531FA for ; Fri, 24 Jul 2026 10:20:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To:References: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lGFnhKXhsb1KqomsyxuM/93XQ7gxosYTE3LUiuhjlnk=; b=cTtB6C4608I2keo8bfSaPEVitz 6UKi7GLEU5MinHmrZ7sqiGn5RBwtKJCzMurEEE3lM8dP/riCUjE3eH8POHdBho0LeJVvMZw2ailt8 ycPoOZKxRRzmsl+xx/rbGLsbn77Yya1n5pkY4lOu4axQFXc9DrSKpUwxKkPNl5yo7TrfflZmHCuJ6 yXYJXzkh/ImD6nm6EwyftZ0g7lKclvVtgUhvCQ35Fz+9BDLmM4Lo4MgqPI8nPlcB0o9GIAqtAyusA PGIK39UkqhxMQq66/rXyJsaYG3j2llo1bouCwtJixRLbYNF7RVDXcRV/toEKkKkVsUteGg6qTEPZZ /MSbVeyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnD0d-0000000G3qD-3fH6; Fri, 24 Jul 2026 10:20:03 +0000 Received: from out-173.mta1.migadu.com ([95.215.58.173]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnD0a-0000000G3or-2ra7 for linux-amlogic@lists.infradead.org; Fri, 24 Jul 2026 10:20:02 +0000 Date: Fri, 24 Jul 2026 10:13:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postmarketos.org; s=key1; t=1784888396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k4jA95NvxlnIR1Hi2g9Z6FkmE9n79P+Ej5d6GEWovXQ=; b=cKwoBgnE+DhdTJU33w9R9euhKma7trvL516xwdFrdSR280gx3pYzmYPoL2PzO6zKg4lL2r dXR5nwK2R6UctttWiJOJDOtg2Sm/nRqZo1Tt5c2TZB04ZfQJ/K90Z7XDJXjzFzrsHxK+3a Z3TnFQWnO6jfg05+Gc4FrGCA8hgPGJzaYI2QSvfYRUZhKHnvUAqVMGggj7RhoTdFS9r/WS VyzzYyLKEYOy8x78w4xTGLIiq6P2Pp+aaPkDjXuZmnwxw1J8AOJDZGnW4nxsBUoDN+ns5K zI9qoPXU6n5j8jAKW20dD9+fsMcLSEuvTnFrnW7G3Lne3gCPK8cQUukJvHlCRw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ferass El Hafidi To: linux-amlogic@lists.infradead.org, zhentao.guo@amlogic.com, Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, Zhentao Guo Subject: Re: [PATCH v6 0/6] Add Amlogic stateless H.264 video decoder for S4 References: <20260724-b4-s4-vdec-upstream-v6-0-6072a7ee7428@amlogic.com> In-Reply-To: <20260724-b4-s4-vdec-upstream-v6-0-6072a7ee7428@amlogic.com> Message-ID: MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260724_032001_172684_022051A5 X-CRM114-Status: GOOD ( 11.23 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org Hi Zhentao, On Fri, 24 Jul 2026 07:04, Zhentao Guo via B4 Relay 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? >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? Best regards, Ferass _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DF7641F5CC for ; Fri, 24 Jul 2026 10:20:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784888412; cv=none; b=uvmaaGMDCSlq+EOVT0JBsZwCg8D71jnAjXbsjI+kGV0p0FXFAkccB8NwAeX2GIeVyySIef5Ic/3BykWD4mjFsCpg0upmgJAIx7L5ls1MRYuvOVDt0E4DgiLVpQnDFqRuByPbd7WRBCiv0cCv1SiY2stuYKkgwFiryxwoqQKDQsQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784888412; c=relaxed/simple; bh=43loBfQY/YMXr6zeV9pXCVAF0ZfELGRn5ItUjZRXuLQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=nzNWAENbChtCqQwO0YwHxN17mR7oHw/SlgNT8Kda+LnrVTg7oFZ2klDB/hLlLj86kFZsMX1D6Iszsi12MadjHk1Vpbh/i5JLbCMtPOms/FmUFVyHi15L4LCE7yK12n2Lru1adcUGt6th3uhNmbJKmvfxvS/ckYW5ZgbfYnc32WQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=postmarketos.org; spf=pass smtp.mailfrom=postmarketos.org; dkim=pass (2048-bit key) header.d=postmarketos.org header.i=@postmarketos.org header.b=cKwoBgnE; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=postmarketos.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=postmarketos.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=postmarketos.org header.i=@postmarketos.org header.b="cKwoBgnE" Date: Fri, 24 Jul 2026 10:13:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postmarketos.org; s=key1; t=1784888396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k4jA95NvxlnIR1Hi2g9Z6FkmE9n79P+Ej5d6GEWovXQ=; b=cKwoBgnE+DhdTJU33w9R9euhKma7trvL516xwdFrdSR280gx3pYzmYPoL2PzO6zKg4lL2r dXR5nwK2R6UctttWiJOJDOtg2Sm/nRqZo1Tt5c2TZB04ZfQJ/K90Z7XDJXjzFzrsHxK+3a Z3TnFQWnO6jfg05+Gc4FrGCA8hgPGJzaYI2QSvfYRUZhKHnvUAqVMGggj7RhoTdFS9r/WS VyzzYyLKEYOy8x78w4xTGLIiq6P2Pp+aaPkDjXuZmnwxw1J8AOJDZGnW4nxsBUoDN+ns5K zI9qoPXU6n5j8jAKW20dD9+fsMcLSEuvTnFrnW7G3Lne3gCPK8cQUukJvHlCRw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ferass El Hafidi To: linux-amlogic@lists.infradead.org, zhentao.guo@amlogic.com, Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, Zhentao Guo Subject: Re: [PATCH v6 0/6] Add Amlogic stateless H.264 video decoder for S4 References: <20260724-b4-s4-vdec-upstream-v6-0-6072a7ee7428@amlogic.com> In-Reply-To: <20260724-b4-s4-vdec-upstream-v6-0-6072a7ee7428@amlogic.com> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed X-Migadu-Flow: FLOW_OUT Hi Zhentao, On Fri, 24 Jul 2026 07:04, Zhentao Guo via B4 Relay 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? >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? Best regards, Ferass