From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 E0AF5266B67 for ; Thu, 18 Dec 2025 09:13:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766049227; cv=none; b=gjTIuBOb2aS2TjDfL6NXWRBtbPY6CCod6th8FtE+HM9suzQLMt/1yDMwPg1CaQVtXSpYQ6oAXjyp+BGKJ+b2T0KDGaFC8AAejHH2IOZ6tFr8Mu/I+WgkkMY46neTKEK0V+hQoLsu8I4A1ktnobo2iVhDnRNGy2TMMafBJEVp0dg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766049227; c=relaxed/simple; bh=RUkd02xc5BOUW19p8diEZ2/mqwHXrltNPK8JeJBsbOs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DuL7aJfWLEPhSY7BWuFGEIt8QrC15Ej5yEkgsRjX2QsaGRTICbDvN7Lf9VgBboXUoTY1Z4TN76f5w0TNEF/0LJ5nTTSmUqoCx+qqPj4mCl/ONl1POwNQD9/xKo9E+llFhh0+Wcse2DDyQS2eZh6XqkhNQZhpDYjn/Lzy6vNOwoM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=XdURXzDR; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Yfr3hp4L; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="XdURXzDR"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Yfr3hp4L" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5BI9ASOK174246 for ; Thu, 18 Dec 2025 09:13:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= y1QlAWq/1L/JYAWZf7dMKVQMYHxUNIgbfZhGbeGCJX4=; b=XdURXzDRLF8yN9Ld sRWwDiYDIMwSUVWYukyGygheFuc1XerfH6DTMwbf6EEViwJUIPdxc+zxWJgs1+UE zwS6dnHohtOzombKcn/Pqt95CjbnUJ2FO94U8aCHTUy/nGIdLSPClzKCpwkcySh5 MIdgwKrkm/SqSmVx7XWWK7Y+RDsz9qqM2+fM5RDBvCALBnIFwEca9J+QAxe5T17U 53/iKsw35WGCQ6FiVCzEejPwSa3lBH3t6QdY5qYDwxYhibjoUiKWlLD6qBvYuK/d wFT3pmjan+alDgqmDgJ14wEL8FQslCsWzIWB9UFLWbYjxY6V+ujenyB4TjzKuein f0K8zw== Received: from mail-dl1-f71.google.com (mail-dl1-f71.google.com [74.125.82.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4b43nmsww6-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 18 Dec 2025 09:13:40 +0000 (GMT) Received: by mail-dl1-f71.google.com with SMTP id a92af1059eb24-11bd7a827fdso2401084c88.1 for ; Thu, 18 Dec 2025 01:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1766049220; x=1766654020; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=y1QlAWq/1L/JYAWZf7dMKVQMYHxUNIgbfZhGbeGCJX4=; b=Yfr3hp4Llc3fvrUGvvGTiplWRHcfzqoOCzmmynoEKnOSFiapcnpCInQTkk+k1+K9CI 0SH+655aBhx7Jnb3SVpsinSpAzP0PUrTK5f7Arz6/9aiu1VhA2Og5ZSuIUDYB6zzdOX6 nnAMJarHGkMjtuHIVTWp6sUG7HqnOb33wFFnLdH8qkdatixT2hdmtiaIlrtmwUJmyYWR pPgf6Nn+45NFos3dl8c39iAMlfDNRnxKDZYStVaMolDmTMfiBqgW6c1rawx9LyzVAw6k +Yv3SIhcDzWD5Bkt4FNriwKW6/l/AJ1DEiI5J0ACXvnbdwSweOxs4bOxKVi/3pcu4oKU hinQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766049220; x=1766654020; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y1QlAWq/1L/JYAWZf7dMKVQMYHxUNIgbfZhGbeGCJX4=; b=nCClSExHsk3tq5GDls7eZO/ylJQFaPt0djekq35AvGGTTeE8cCFXsLt7BGqYdwLpwX 6DYsencyj++McONAuzqf0RBKRUhlgGPuUyZyh1cRv7BGYq8zo18igMH82y7vr98FrCKM Lqi/XomB1DhWQf1MyOdTq6aE7QadyXjUtQ+/MSWi7k6JpJJHSrTBYODo2YMmM4Wy5Mm1 E5miql5jmzXo1FEdy1KpXIvuxlpc1u+vSi9GB1EybYVurU9T0J8qdp35+Uw3PMy+oUm3 cXWzOIGt6h4f4eriZzwdi+6Zr5MxY3OqES7K1lGH3mkK/LLpWPi7li3oVW0M0H+/7Jf0 hZPQ== X-Forwarded-Encrypted: i=1; AJvYcCUqPS4BLFXXKM6uf+1kHv8IjFY0EEFS2Go34jILSm9YW+ThXRhlhKBGdds9hCQUs/JAyn2sm3MN+iDJR8s=@vger.kernel.org X-Gm-Message-State: AOJu0YxErT298S+X7PeL+pFp+SvosZ+epJjOIpMs0xLmjnUke1DzNJBB gzxhV0LYzPUPzAI64L3+jKmtAO96JAebG1kHBYTg92MHPe96BQWLogQad59PMHI8TydJOhGq9qv qQBKQRrdqjEsd2ydvBzXhAowcKSr9kgrpjxrd0HqyTuNVyGbEiYjrPwdtRfqAtV0tSBSrb+5daj AzGw== X-Gm-Gg: AY/fxX4q0ZKsGyhr5cLMjx140kiicGrPVBmW+Hnw0Q2P24A1C5y084+1O2ze7Nc0OUD 0U0uJeaOpwiZUVrQwOUOrvhxhiUUEpULnNXkrTL/R3UC5H/jdtXiv6/J/rvSpt6I6f6JM25iBxi 4/i7jV8QgXRSM7req3nUDYYQAz1PGY3wDg2J9W4ONB3Znh9annctc0NrXhWQDoBbndkTvmjMS40 mkMNgacOC09xpFPPLSUUza6HFXh4lr0I47uZnxm+beKb74pMW8GocTvJxtQcuzvwnA1i56C1C6h MkqVzziP5uovZHIMR6eTkrhUpM4z7K1Be/qfjwiSqYnAKKL2cCHPssBRCkk5szc7JGr2fJx8fN8 FeGHQLPVf3IMUbITg+iuINcCxwflePk5SEx6tKONvch2nWgLWeUxquEUdJlhb7+aGY7nP X-Received: by 2002:a05:7022:388e:b0:11a:4ffb:984f with SMTP id a92af1059eb24-12061947ed8mr1884233c88.11.1766049219617; Thu, 18 Dec 2025 01:13:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IFAEsCwcPyMuP9K+u/+3JsvygiB0U6hbn/p/DBo06Ln9R2cby7DY+dReAKoE6mu+VUMIaNOyg== X-Received: by 2002:a05:7022:388e:b0:11a:4ffb:984f with SMTP id a92af1059eb24-12061947ed8mr1884188c88.11.1766049218910; Thu, 18 Dec 2025 01:13:38 -0800 (PST) Received: from [10.110.90.237] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12061fdb350sm5080971c88.17.2025.12.18.01.13.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Dec 2025 01:13:38 -0800 (PST) Message-ID: <84b14cdf-8549-4a00-8dcc-bb5bd1918cfe@oss.qualcomm.com> Date: Thu, 18 Dec 2025 17:13:34 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mhi: host: Add standard elf image download functionality To: Qiang Yu , Manivannan Sadhasivam Cc: Dmitry Baryshkov , mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Mayank Rana References: <7nhlxp6gxk2tkuzh2rogywp6ko4n5nkh6ih2uly3zsskmi7wpp@7weahfg6gksm> From: Baochen Qiang Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: hcb1vHnVO_iaDGPVEjwFnpLzRwNnI40_ X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjE4MDA3NCBTYWx0ZWRfXzVmsHjFM8uHn oia0GWzj+HAIQtqWaI8f9tled3Q8A8AjNZJaifpwLcAGBL5XygFbfiNw19D0IkinuxvPyaSQsQz y6n1XsYJBhBO8mIVDzsvaUGvNc5+bi3eGgU82clhJ9prurOhMbkKcBFGdho0MK889juzVthj2WE ng6yda7atBn67bY0fqS/mL1Umb2lNZ2X02EyEhBunyp0SuQjis/xyMvYzF0vrqL3Lrt1R4Hcn1a iy815PJjd+BjplpV7VPArU44rhu+AtjjEmLW2S5vpa1kRKJRm1LgF+kYKDme92BTizNXOci1BsZ vI17rKpX0tBY38e3cx7KaIwsBINKdw9r8htaUt9NV7c8ufCXJZ2mptgvf6bATXudR0vub7yC9/6 loNm2EbVZyyJEbnqFZyXTv44NGUbeQ== X-Proofpoint-ORIG-GUID: hcb1vHnVO_iaDGPVEjwFnpLzRwNnI40_ X-Authority-Analysis: v=2.4 cv=A6Zh/qWG c=1 sm=1 tr=0 ts=6943c5c4 cx=c_pps a=JYo30EpNSr/tUYqK9jHPoA==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=EUspDBNiAAAA:8 a=OkXkiglkZYEH1FjLT2YA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=Fk4IpSoW4aLDllm1B1p-:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-18_01,2025-12-17_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1015 impostorscore=0 priorityscore=1501 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2512180074 On 12/18/2025 4:04 PM, Qiang Yu wrote: > On Thu, Dec 18, 2025 at 10:25:08AM +0530, Manivannan Sadhasivam wrote: >> On Tue, Dec 16, 2025 at 12:26:41AM -0800, Qiang Yu wrote: >>> On Mon, Dec 15, 2025 at 08:41:32PM +0200, Dmitry Baryshkov wrote: >>>> On Sun, Dec 14, 2025 at 11:09:58PM -0800, Qiang Yu wrote: >>>>> On Sat, Dec 13, 2025 at 11:21:11AM +0900, Manivannan Sadhasivam wrote: >>>>>> On Fri, Dec 12, 2025 at 09:24:06PM +0200, Dmitry Baryshkov wrote: >>>>>>> On Fri, Dec 12, 2025 at 10:07:01AM +0900, Manivannan Sadhasivam wrote: >>>>>>>> On Thu, Dec 11, 2025 at 03:57:54PM +0200, Dmitry Baryshkov wrote: >>>>>>>>> On Thu, Dec 11, 2025 at 01:37:12AM -0800, Qiang Yu wrote: >>>>>>>>>> On Wed, Dec 10, 2025 at 12:57:11AM +0200, Dmitry Baryshkov wrote: >>>>>>>>>>> On Sun, Dec 07, 2025 at 10:35:26PM -0800, Qiang Yu wrote: >>>>>>>>>>>> On Sat, Dec 06, 2025 at 01:25:34PM +0200, Dmitry Baryshkov wrote: >>>>>>>>>>>>> On Mon, Dec 01, 2025 at 06:33:15PM -0800, Qiang Yu wrote: >>>>>>>>>>>>>> From: Mayank Rana >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently, the FBC image is a non-standard ELF file that contains a single >>>>>>>>>>>>>> ELF header, followed by segments for SBL, and WLAN FW. However, TME-L >>>>>>>>>>>>>> (Trust Management Engine Lite) supported devices (eg. QCC2072) requires >>>>>>>>>>>>>> separate ELF headers for SBL and WLAN FW segments due to TME-L image >>>>>>>>>>>>>> authentication requirement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current image format contains two sections in a single binary: >>>>>>>>>>>>>> - First 512KB: ELF header + SBL segments >>>>>>>>>>>>>> - Remaining: WLAN FW segments >>>>>>>>>>>>>> >>>>>>>>>>>>>> The TME-L supported image format contains two sections with two elf >>>>>>>>>>>>>> headers in a single binary: >>>>>>>>>>>>>> - First 512KB: First ELF header + SBL segments >>>>>>>>>>>>>> - Remaining: Second ELF header + WLAN FW segments >>>>>>>>>>>>>> >>>>>>>>>>>>>> Download behavior: >>>>>>>>>>>>>> - Legacy: 1. First 512KB via BHI (ELF header + SBL) >>>>>>>>>>>>>> 2. Full image via BHIe >>>>>>>>>>>>>> >>>>>>>>>>>>>> - TME-L: 1. First 512KB via BHI (First ELF header + SBL) >>>>>>>>>>>>>> 2. Remaining via BHIe (Second ELF header + WLAN FW segments) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Add standard_elf_image flag to mhi_controller_config to indicate TME-L >>>>>>>>>>>>>> supported image format. When set, MHI skips the first 512KB during WLAN FW >>>>>>>>>>>>>> download over BHIe as it is loaded in BHI phase. >>>>>>>>>>>>> >>>>>>>>>>>>> What is standard about it? >>>>>>>>>>>> >>>>>>>>>>>> The TME-L requires standard elf image format which includes single EFL >>>>>>>>>>>> header and WLAN FW segment. >>>>>>>>>>>> >>>>>>>>>>>> The "standard_elf_image" seems misleading. Since the new image format is >>>>>>>>>>>> required for TME-L image authentication, how about using >>>>>>>>>>>> tme_supported_image? >>>>>>>>>>> >>>>>>>>>>> Just elf_image? >>>>>>>>>> >>>>>>>>>> Is it too generic for this specific use case. Current image format also >>>>>>>>>> contains elf header. >>>>>>>>> >>>>>>>>> upload_elf_image? >>>>>>>>> >>>>>>>> >>>>>>>> Nope. What does 'upload' even mean here? The 'TIS and ELF' spec v1.2 clearly >>>>>>>> defines that an ELF executable can have only one ELF header. So I'd prefer >>>>>>>> 'standard_elf_image' to differentiate it from the non-spec-conformant ELF image >>>>>>>> used previously. >>>>>>> >>>>>>> What kind of ELF image was used previously? Could you please explain >>>>>>> what do 'First ELF header' vs 'Second ELF header' mean here? >>>>>>> >>>>>> >>>>>> I don't have the details of it, but Qiang should be able to explain. But AFAIC, >>>>>> that was a non-standard ELF image and the new one is going to be spec >>>>>> conformant. >>>>>> >>>>> Previous image format: >>>>> ELF header + SBL segments + WLAN FW segments >>>>> >>>>> The TME-L supported image format: >>>>> First ELF header + SBL segments + Second ELF header + WLAN FW segments >>>> >>>> What is the Second ELF header in this context? ELF files usually have >>>> only one header. Are we repeating the same ELF header or is some kind of >>>> an embedded ELF-in-ELF. >>> >>> The "Second ELF header" refers to a separate, complete ELF file embedded >>> within the FBC image, not a duplicate header. The TME-L supported format >>> contains: >>> >>> FBC Image Structure: >>> ┌─────────────────────────────────────┐ >>> │ Complete ELF File #1 (SBL) │ >>> │ ┌─────────────────────────────┐ │ >>> │ │ ELF Header │ │ ← First ELF header >>> │ │ Program Headers │ │ >>> │ │ SBL Segments │ │ >>> │ └─────────────────────────────┘ │ >>> ├─────────────────────────────────────┤ >>> │ Complete ELF File #2 (WLAN FW) │ >>> │ ┌─────────────────────────────┐ │ >>> │ │ ELF Header │ │ ← Second ELF header >>> │ │ Program Headers │ │ >>> │ │ WLAN FW Segments │ │ >>> │ └─────────────────────────────┘ │ >>> └─────────────────────────────────────┘ >>>> >>>>> >>>>> As per 'TIS and ELF' spec v1.2 Mani mentioned, the previous image format >>>> >>>> pointer? >>> >>> The entire 'TIS and ELF' spec v1.2 document descibes the structure of the >>> ELF excutable file, I can not point out a specfic sentence or phase that >>> tell us the previous image format is standard. But at least there is an >>> example we can refer to: Figure A-4. Executable File Example. And I can >>> also use readelf cmd to parse the image. >>> >>>> >>>>> is also standard elf image. But it doesn't meet the requirement of TME-L >>>>> because we need separate elf header for SBL and WL FW for TME-L >>>>> authentication. >>>>> >>>>> So the commit message stating "Currently, the FBC image is a non-standard >>>>> ELF file that contains a single ELF header, followed by segments for SBL, >>>>> and WLAN FW" is not correct and standard_elf_image is not accurate. >>>>> >>>>> Can we avoid saying anything about standard in commit message? Flags eg. >>>>> separate_elf_header and tme_supported_image are more accurate. >>>> >>>> Please define, what is the supported image. >>> >>> The supported image refers to an image format that TME-L can authenticate. >>> Both SBL and WLAN FW should be in ELF format. After powering on, SBL (ELF >>> format, ELF header + SBL segment, first 512 KB) is loaded over BHI and >>> authenticated by TME-L. After entering SBL, WLAN FW (ELF format, skip >>> first 512KB of fbc image) is loaded over BHIe and also authenticated by >>> TME-L. >>> >> >> So what makes it different here is that you are now sending the two FWs >> separately as standalone ELF image to the device for authentication by TME-L, >> but those are combined in a single image file in the host. But what makes you to >> combine two images in the first place? Why can't they be separate ELF files? >> >> I think you can avoid the hassle if you could just have separate ELF images for >> SBL and WLAN FW and say that the TME-L just expects individual ELF image. >> > Yes, they are two separate images combined into a single file. I'm not > sure of the specific reasons for this design choice, so I can't comment > on it. The WLAN team provides a single file for both SBL and WLAN FW, and > I don't know whether they're willing to change. > > Baochen, do you have any comment on this? Hmm, sorry, no idea :( > > - Qiang Yu