[PATCH v3] mhi: host: Add standard elf image download functionality

[PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

From: Mayank Rana <mayank.rana@oss.qualcomm.com>

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.

Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Changes in v3:
- Reword commit message.
- Reword comments of standard_elf_image flag
- Add reviewed-by tag.
- Link to v2: https://lore.kernel.org/mhi/20250603-standard_elf_image_load_support-v2-1-cce97644e99e@oss.qualcomm.com/

Changes in v2:
- V1 patch is paused because of no user. WLAN team plan to add support for
  new WLAN chip that requires this patch, so send v2.
- Change author and SOB with new mail address.
- Reword commit message.
- Place standard_elf_image flag after wake_set in struct mhi_controller
- Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
---
 drivers/bus/mhi/host/boot.c | 7 +++++++
 include/linux/mhi.h         | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
index 205d83ac069f15a19ab2d66a63692e5d60334d4c..64fb7a257d3529167eddf1153d34cc6b25735809 100644
--- a/drivers/bus/mhi/host/boot.c
+++ b/drivers/bus/mhi/host/boot.c
@@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
 	 * device transitioning into MHI READY state
 	 */
 	if (fw_load_type == MHI_FW_LOAD_FBC) {
+		dev_dbg(dev, "standard_elf_image:%s\n",
+			(mhi_cntrl->standard_elf_image ? "True" : "False"));
+		if (mhi_cntrl->standard_elf_image) {
+			fw_data += mhi_cntrl->sbl_size;
+			fw_sz -= mhi_cntrl->sbl_size;
+		}
+
 		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, fw_sz);
 		if (ret) {
 			release_firmware(firmware);
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index dd372b0123a6da5107b807ff8fe940c567eb2030..a13106bb234d22e3876dff3c0d46f3dee1d9e05c 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -360,6 +360,9 @@ struct mhi_controller_config {
  * @bounce_buf: Use of bounce buffer
  * @fbc_download: MHI host needs to do complete image transfer (optional)
  * @wake_set: Device wakeup set flag
+ * @standard_elf_image: Flag to determine whether the first 512 KB of the FBC
+ *                      image need to be skipped when loading WLAN FW over
+ *                      BHIe interface (optional)
  * @irq_flags: irq flags passed to request_irq (optional)
  * @mru: the default MRU for the MHI device
  *
@@ -445,6 +448,7 @@ struct mhi_controller {
 	bool bounce_buf;
 	bool fbc_download;
 	bool wake_set;
+	bool standard_elf_image;
 	unsigned long irq_flags;
 	u32 mru;
 };

---
base-commit: ac35e04f8000aaaf98635792464647e7a6f3422e
change-id: 20251129-wlan_image_load_skip_512k-ddcfe49db8e3

Best regards,
-- 
Qiang Yu <qiang.yu@oss.qualcomm.com>

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

On Mon, Dec 01, 2025 at 06:33:15PM -0800, Qiang Yu wrote:
> From: Mayank Rana <mayank.rana@oss.qualcomm.com>
> 
> 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?

> 
> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
> Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
> Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> Changes in v3:
> - Reword commit message.
> - Reword comments of standard_elf_image flag
> - Add reviewed-by tag.
> - Link to v2: https://lore.kernel.org/mhi/20250603-standard_elf_image_load_support-v2-1-cce97644e99e@oss.qualcomm.com/
> 
> Changes in v2:
> - V1 patch is paused because of no user. WLAN team plan to add support for
>   new WLAN chip that requires this patch, so send v2.
> - Change author and SOB with new mail address.
> - Reword commit message.
> - Place standard_elf_image flag after wake_set in struct mhi_controller
> - Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
> ---
>  drivers/bus/mhi/host/boot.c | 7 +++++++
>  include/linux/mhi.h         | 4 ++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> index 205d83ac069f15a19ab2d66a63692e5d60334d4c..64fb7a257d3529167eddf1153d34cc6b25735809 100644
> --- a/drivers/bus/mhi/host/boot.c
> +++ b/drivers/bus/mhi/host/boot.c
> @@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>  	 * device transitioning into MHI READY state
>  	 */
>  	if (fw_load_type == MHI_FW_LOAD_FBC) {
> +		dev_dbg(dev, "standard_elf_image:%s\n",
> +			(mhi_cntrl->standard_elf_image ? "True" : "False"));
> +		if (mhi_cntrl->standard_elf_image) {
> +			fw_data += mhi_cntrl->sbl_size;
> +			fw_sz -= mhi_cntrl->sbl_size;
> +		}
> +
>  		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, fw_sz);
>  		if (ret) {
>  			release_firmware(firmware);
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index dd372b0123a6da5107b807ff8fe940c567eb2030..a13106bb234d22e3876dff3c0d46f3dee1d9e05c 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -360,6 +360,9 @@ struct mhi_controller_config {
>   * @bounce_buf: Use of bounce buffer
>   * @fbc_download: MHI host needs to do complete image transfer (optional)
>   * @wake_set: Device wakeup set flag
> + * @standard_elf_image: Flag to determine whether the first 512 KB of the FBC
> + *                      image need to be skipped when loading WLAN FW over
> + *                      BHIe interface (optional)

How does the description correlate to the name of the flag?

>   * @irq_flags: irq flags passed to request_irq (optional)
>   * @mru: the default MRU for the MHI device
>   *
> @@ -445,6 +448,7 @@ struct mhi_controller {
>  	bool bounce_buf;
>  	bool fbc_download;
>  	bool wake_set;
> +	bool standard_elf_image;

This flag is never set, making it a dead API. If there are other patches
setting up the flag, please include them into them in the same series.

>  	unsigned long irq_flags;
>  	u32 mru;
>  };
> 
> ---
> base-commit: ac35e04f8000aaaf98635792464647e7a6f3422e
> change-id: 20251129-wlan_image_load_skip_512k-ddcfe49db8e3
> 
> Best regards,
> -- 
> Qiang Yu <qiang.yu@oss.qualcomm.com>
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

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 <mayank.rana@oss.qualcomm.com>
> > 
> > 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?

> 
> > 
> > Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
> > Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
> > Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > Changes in v3:
> > - Reword commit message.
> > - Reword comments of standard_elf_image flag
> > - Add reviewed-by tag.
> > - Link to v2: https://lore.kernel.org/mhi/20250603-standard_elf_image_load_support-v2-1-cce97644e99e@oss.qualcomm.com/
> > 
> > Changes in v2:
> > - V1 patch is paused because of no user. WLAN team plan to add support for
> >   new WLAN chip that requires this patch, so send v2.
> > - Change author and SOB with new mail address.
> > - Reword commit message.
> > - Place standard_elf_image flag after wake_set in struct mhi_controller
> > - Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
> > ---
> >  drivers/bus/mhi/host/boot.c | 7 +++++++
> >  include/linux/mhi.h         | 4 ++++
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> > index 205d83ac069f15a19ab2d66a63692e5d60334d4c..64fb7a257d3529167eddf1153d34cc6b25735809 100644
> > --- a/drivers/bus/mhi/host/boot.c
> > +++ b/drivers/bus/mhi/host/boot.c
> > @@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
> >  	 * device transitioning into MHI READY state
> >  	 */
> >  	if (fw_load_type == MHI_FW_LOAD_FBC) {
> > +		dev_dbg(dev, "standard_elf_image:%s\n",
> > +			(mhi_cntrl->standard_elf_image ? "True" : "False"));
> > +		if (mhi_cntrl->standard_elf_image) {
> > +			fw_data += mhi_cntrl->sbl_size;
> > +			fw_sz -= mhi_cntrl->sbl_size;
> > +		}
> > +
> >  		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, fw_sz);
> >  		if (ret) {
> >  			release_firmware(firmware);
> > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> > index dd372b0123a6da5107b807ff8fe940c567eb2030..a13106bb234d22e3876dff3c0d46f3dee1d9e05c 100644
> > --- a/include/linux/mhi.h
> > +++ b/include/linux/mhi.h
> > @@ -360,6 +360,9 @@ struct mhi_controller_config {
> >   * @bounce_buf: Use of bounce buffer
> >   * @fbc_download: MHI host needs to do complete image transfer (optional)
> >   * @wake_set: Device wakeup set flag
> > + * @standard_elf_image: Flag to determine whether the first 512 KB of the FBC
> > + *                      image need to be skipped when loading WLAN FW over
> > + *                      BHIe interface (optional)
> 
> How does the description correlate to the name of the flag?

The description can be updated as:

 * @tme_supported_image: Flag indicating FBC image format supports TME-L
 *                      (Trust Management Engine Lite) authentication.
 *                      When set, skip first 512KB when loading WLAN FW
 *                      over BHIe interface (optional)
> 
> >   * @irq_flags: irq flags passed to request_irq (optional)
> >   * @mru: the default MRU for the MHI device
> >   *
> > @@ -445,6 +448,7 @@ struct mhi_controller {
> >  	bool bounce_buf;
> >  	bool fbc_download;
> >  	bool wake_set;
> > +	bool standard_elf_image;
> 
> This flag is never set, making it a dead API. If there are other patches
> setting up the flag, please include them into them in the same series.

Let me discuss with Baochen about whether he can include the patch in his
series that actually sets this flag for QCC2072 device.

- Qiang Yu
> 
> >  	unsigned long irq_flags;
> >  	u32 mru;
> >  };
> > 
> > ---
> > base-commit: ac35e04f8000aaaf98635792464647e7a6f3422e
> > change-id: 20251129-wlan_image_load_skip_512k-ddcfe49db8e3
> > 
> > Best regards,
> > -- 
> > Qiang Yu <qiang.yu@oss.qualcomm.com>
> > 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

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 <mayank.rana@oss.qualcomm.com>
> > > 
> > > 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?

> 
> > 
> > > 
> > > Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
> > > Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
> > > Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > ---
> > > Changes in v3:
> > > - Reword commit message.
> > > - Reword comments of standard_elf_image flag
> > > - Add reviewed-by tag.
> > > - Link to v2: https://lore.kernel.org/mhi/20250603-standard_elf_image_load_support-v2-1-cce97644e99e@oss.qualcomm.com/
> > > 
> > > Changes in v2:
> > > - V1 patch is paused because of no user. WLAN team plan to add support for
> > >   new WLAN chip that requires this patch, so send v2.
> > > - Change author and SOB with new mail address.
> > > - Reword commit message.
> > > - Place standard_elf_image flag after wake_set in struct mhi_controller
> > > - Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
> > > ---
> > >  drivers/bus/mhi/host/boot.c | 7 +++++++
> > >  include/linux/mhi.h         | 4 ++++
> > >  2 files changed, 11 insertions(+)
> > > 
> > > diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> > > index 205d83ac069f15a19ab2d66a63692e5d60334d4c..64fb7a257d3529167eddf1153d34cc6b25735809 100644
> > > --- a/drivers/bus/mhi/host/boot.c
> > > +++ b/drivers/bus/mhi/host/boot.c
> > > @@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
> > >  	 * device transitioning into MHI READY state
> > >  	 */
> > >  	if (fw_load_type == MHI_FW_LOAD_FBC) {
> > > +		dev_dbg(dev, "standard_elf_image:%s\n",
> > > +			(mhi_cntrl->standard_elf_image ? "True" : "False"));
> > > +		if (mhi_cntrl->standard_elf_image) {
> > > +			fw_data += mhi_cntrl->sbl_size;
> > > +			fw_sz -= mhi_cntrl->sbl_size;
> > > +		}
> > > +
> > >  		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, fw_sz);
> > >  		if (ret) {
> > >  			release_firmware(firmware);
> > > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> > > index dd372b0123a6da5107b807ff8fe940c567eb2030..a13106bb234d22e3876dff3c0d46f3dee1d9e05c 100644
> > > --- a/include/linux/mhi.h
> > > +++ b/include/linux/mhi.h
> > > @@ -360,6 +360,9 @@ struct mhi_controller_config {
> > >   * @bounce_buf: Use of bounce buffer
> > >   * @fbc_download: MHI host needs to do complete image transfer (optional)
> > >   * @wake_set: Device wakeup set flag
> > > + * @standard_elf_image: Flag to determine whether the first 512 KB of the FBC
> > > + *                      image need to be skipped when loading WLAN FW over
> > > + *                      BHIe interface (optional)
> > 
> > How does the description correlate to the name of the flag?
> 
> The description can be updated as:
> 
>  * @tme_supported_image: Flag indicating FBC image format supports TME-L
>  *                      (Trust Management Engine Lite) authentication.
>  *                      When set, skip first 512KB when loading WLAN FW
>  *                      over BHIe interface (optional)
> > 
> > >   * @irq_flags: irq flags passed to request_irq (optional)
> > >   * @mru: the default MRU for the MHI device
> > >   *
> > > @@ -445,6 +448,7 @@ struct mhi_controller {
> > >  	bool bounce_buf;
> > >  	bool fbc_download;
> > >  	bool wake_set;
> > > +	bool standard_elf_image;
> > 
> > This flag is never set, making it a dead API. If there are other patches
> > setting up the flag, please include them into them in the same series.
> 
> Let me discuss with Baochen about whether he can include the patch in his
> series that actually sets this flag for QCC2072 device.

Otherwise it's a dead API which is generally not allowed.

> 
> - Qiang Yu
> > 
> > >  	unsigned long irq_flags;
> > >  	u32 mru;
> > >  };
> > > 
> > > ---
> > > base-commit: ac35e04f8000aaaf98635792464647e7a6f3422e
> > > change-id: 20251129-wlan_image_load_skip_512k-ddcfe49db8e3
> > > 
> > > Best regards,
> > > -- 
> > > Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > 
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

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 <mayank.rana@oss.qualcomm.com>
> > > > 
> > > > 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.

- Qiang Yu
> 
> > 
> > > 
> > > > 
> > > > Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
> > > > Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
> > > > Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > ---
> > > > Changes in v3:
> > > > - Reword commit message.
> > > > - Reword comments of standard_elf_image flag
> > > > - Add reviewed-by tag.
> > > > - Link to v2: https://lore.kernel.org/mhi/20250603-standard_elf_image_load_support-v2-1-cce97644e99e@oss.qualcomm.com/
> > > > 
> > > > Changes in v2:
> > > > - V1 patch is paused because of no user. WLAN team plan to add support for
> > > >   new WLAN chip that requires this patch, so send v2.
> > > > - Change author and SOB with new mail address.
> > > > - Reword commit message.
> > > > - Place standard_elf_image flag after wake_set in struct mhi_controller
> > > > - Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
> > > > ---
> > > >  drivers/bus/mhi/host/boot.c | 7 +++++++
> > > >  include/linux/mhi.h         | 4 ++++
> > > >  2 files changed, 11 insertions(+)
> > > > 
> > > > diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> > > > index 205d83ac069f15a19ab2d66a63692e5d60334d4c..64fb7a257d3529167eddf1153d34cc6b25735809 100644
> > > > --- a/drivers/bus/mhi/host/boot.c
> > > > +++ b/drivers/bus/mhi/host/boot.c
> > > > @@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
> > > >  	 * device transitioning into MHI READY state
> > > >  	 */
> > > >  	if (fw_load_type == MHI_FW_LOAD_FBC) {
> > > > +		dev_dbg(dev, "standard_elf_image:%s\n",
> > > > +			(mhi_cntrl->standard_elf_image ? "True" : "False"));
> > > > +		if (mhi_cntrl->standard_elf_image) {
> > > > +			fw_data += mhi_cntrl->sbl_size;
> > > > +			fw_sz -= mhi_cntrl->sbl_size;
> > > > +		}
> > > > +
> > > >  		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, fw_sz);
> > > >  		if (ret) {
> > > >  			release_firmware(firmware);
> > > > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> > > > index dd372b0123a6da5107b807ff8fe940c567eb2030..a13106bb234d22e3876dff3c0d46f3dee1d9e05c 100644
> > > > --- a/include/linux/mhi.h
> > > > +++ b/include/linux/mhi.h
> > > > @@ -360,6 +360,9 @@ struct mhi_controller_config {
> > > >   * @bounce_buf: Use of bounce buffer
> > > >   * @fbc_download: MHI host needs to do complete image transfer (optional)
> > > >   * @wake_set: Device wakeup set flag
> > > > + * @standard_elf_image: Flag to determine whether the first 512 KB of the FBC
> > > > + *                      image need to be skipped when loading WLAN FW over
> > > > + *                      BHIe interface (optional)
> > > 
> > > How does the description correlate to the name of the flag?
> > 
> > The description can be updated as:
> > 
> >  * @tme_supported_image: Flag indicating FBC image format supports TME-L
> >  *                      (Trust Management Engine Lite) authentication.
> >  *                      When set, skip first 512KB when loading WLAN FW
> >  *                      over BHIe interface (optional)
> > > 
> > > >   * @irq_flags: irq flags passed to request_irq (optional)
> > > >   * @mru: the default MRU for the MHI device
> > > >   *
> > > > @@ -445,6 +448,7 @@ struct mhi_controller {
> > > >  	bool bounce_buf;
> > > >  	bool fbc_download;
> > > >  	bool wake_set;
> > > > +	bool standard_elf_image;
> > > 
> > > This flag is never set, making it a dead API. If there are other patches
> > > setting up the flag, please include them into them in the same series.
> > 
> > Let me discuss with Baochen about whether he can include the patch in his
> > series that actually sets this flag for QCC2072 device.
> 
> Otherwise it's a dead API which is generally not allowed.
> 
> > 
> > - Qiang Yu
> > > 
> > > >  	unsigned long irq_flags;
> > > >  	u32 mru;
> > > >  };
> > > > 
> > > > ---
> > > > base-commit: ac35e04f8000aaaf98635792464647e7a6f3422e
> > > > change-id: 20251129-wlan_image_load_skip_512k-ddcfe49db8e3
> > > > 
> > > > Best regards,
> > > > -- 
> > > > Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > 
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

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 <mayank.rana@oss.qualcomm.com>
> > > > > 
> > > > > 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?

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Manivannan Sadhasivam]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > 
> > > > > > 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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > 
> > > > > > > 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?

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Manivannan Sadhasivam]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > 
> > > > > > > > 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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > 
> > > > > > > > > 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

As per 'TIS and ELF' spec v1.2 Mani mentioned, the previous image format
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.

- Qiang Yu

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > 
> > > > > > > > > > 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.

> 
> As per 'TIS and ELF' spec v1.2 Mani mentioned, the previous image format

pointer?

> 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.

> 
> - Qiang Yu

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > > 
> > > > > > > > > > > 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.

- Qiang Yu
> 
> > 
> > - Qiang Yu
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Dmitry Baryshkov]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > > > 
> > > > > > > > > > > > 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            │   │
> │  └─────────────────────────────┘   │
> └─────────────────────────────────────┘

okay. This should have been at the beginning of the thread.

So, if I understand correclty, beforehand WLAN was a raw data and now
it's wrapped in ELF file. If I'm correct, then this might be a
definitive name - .raw_wlan_data or .elf_wrapped_wlan_data (up to you).

Or is it that previously you were skipping the ELF header and just
sending the subset of the contents of the included ELF file?


> > 
> > > 
> > > 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.
> 
> - Qiang Yu
> > 
> > > 
> > > - Qiang Yu
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

On Thu, Dec 18, 2025 at 03:12:23AM +0200, Dmitry Baryshkov 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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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            │   │
> > │  └─────────────────────────────┘   │
> > └─────────────────────────────────────┘
> 
> okay. This should have been at the beginning of the thread.
> 
> So, if I understand correclty, beforehand WLAN was a raw data and now
> it's wrapped in ELF file. If I'm correct, then this might be a
> definitive name - .raw_wlan_data or .elf_wrapped_wlan_data (up to you).
> 
> Or is it that previously you were skipping the ELF header and just
> sending the subset of the contents of the included ELF file?

In previous fbc image, SBL is also a raw data. The ELF header is for the
whole binaries including SBL + WLAN FW. So, elf_wrapped_wlan_data or
.raw_wlan_data are still not accurate. So I still prefer
tme_supported_image, or can we avoid describing the image but describe the
behavoir like skip_sbl_on_wlan_load?
> 
> 
> > > 
> > > > 
> > > > 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.
> > 
> > - Qiang Yu
> > > 
> > > > 
> > > > - Qiang Yu
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Manivannan Sadhasivam]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > > > 
> > > > > > > > > > > > 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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

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 <mayank.rana@oss.qualcomm.com>
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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?

- Qiang Yu

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Baochen Qiang]

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 <mayank.rana@oss.qualcomm.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Baochen Qiang]

On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> 
> 
> 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 <mayank.rana@oss.qualcomm.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 :(

I mean I don't know the reason behind the design choice.

> 
>>
>> - Qiang Yu
> 

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Manivannan Sadhasivam]

On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> 
> 
> On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > 
> > 
> > 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 <mayank.rana@oss.qualcomm.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 :(
> 
> I mean I don't know the reason behind the design choice.
> 

Ok, then I guess we should try to get rid of the flag and just check for the
WLAN FW ELF header during runtime:

	/*
	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
	 * file. Hence, check for the existence of the second ELF header after
	 * SBL. If present, load the second image separately.
	 */
	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
		fw_data += mhi_cntrl->sbl_size
		fw_sz -= mhi_cntrl->sbl_size;
	}

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

On Thu, Dec 18, 2025 at 04:51:18PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> > 
> > 
> > On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > > 
> > > 
> > > 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 <mayank.rana@oss.qualcomm.com>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 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 :(
> > 
> > I mean I don't know the reason behind the design choice.
> > 
> 
> Ok, then I guess we should try to get rid of the flag and just check for the
> WLAN FW ELF header during runtime:
> 
> 	/*
> 	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
> 	 * file. Hence, check for the existence of the second ELF header after
> 	 * SBL. If present, load the second image separately.
> 	 */
> 	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
> 		fw_data += mhi_cntrl->sbl_size
> 		fw_sz -= mhi_cntrl->sbl_size;
> 	}
>
Hmmm, for the old format image, since the data at `fw_data + mhi_cntrl->sbl_size`
is raw WLAN FW data, there's a possibility that the raw binary data could
accidentally contain the ELF magic number at that offset, even though it's
not actually an ELF file. This could lead to false positive detection and
incorrect parsing.

Maybe we can caculate the image size by using the info in ELF header? The
old format image size should larger than 512K.

- Qiang Yu

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Manivannan Sadhasivam]

On Thu, Dec 18, 2025 at 04:36:28AM -0800, Qiang Yu wrote:
> On Thu, Dec 18, 2025 at 04:51:18PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> > > 
> > > 
> > > On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > > > 
> > > > 
> > > > 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 <mayank.rana@oss.qualcomm.com>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 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 :(
> > > 
> > > I mean I don't know the reason behind the design choice.
> > > 
> > 
> > Ok, then I guess we should try to get rid of the flag and just check for the
> > WLAN FW ELF header during runtime:
> > 
> > 	/*
> > 	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
> > 	 * file. Hence, check for the existence of the second ELF header after
> > 	 * SBL. If present, load the second image separately.
> > 	 */
> > 	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
> > 		fw_data += mhi_cntrl->sbl_size
> > 		fw_sz -= mhi_cntrl->sbl_size;
> > 	}
> >
> Hmmm, for the old format image, since the data at `fw_data + mhi_cntrl->sbl_size`
> is raw WLAN FW data, there's a possibility that the raw binary data could
> accidentally contain the ELF magic number at that offset, even though it's
> not actually an ELF file. This could lead to false positive detection and
> incorrect parsing.
> 

Really? How can the WLAN FW segment have the ELF magic at the start of the
segment? Then it becomes a separate ELF file.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Bjorn Andersson]

On Thu, Dec 18, 2025 at 06:12:37PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 18, 2025 at 04:36:28AM -0800, Qiang Yu wrote:
> > On Thu, Dec 18, 2025 at 04:51:18PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> > > > 
> > > > 
> > > > On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > > > > 
> > > > > 
> > > > > 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 <mayank.rana@oss.qualcomm.com>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 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 :(
> > > > 
> > > > I mean I don't know the reason behind the design choice.
> > > > 
> > > 
> > > Ok, then I guess we should try to get rid of the flag and just check for the
> > > WLAN FW ELF header during runtime:
> > > 
> > > 	/*
> > > 	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
> > > 	 * file. Hence, check for the existence of the second ELF header after
> > > 	 * SBL. If present, load the second image separately.
> > > 	 */
> > > 	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
> > > 		fw_data += mhi_cntrl->sbl_size
> > > 		fw_sz -= mhi_cntrl->sbl_size;
> > > 	}
> > >
> > Hmmm, for the old format image, since the data at `fw_data + mhi_cntrl->sbl_size`
> > is raw WLAN FW data, there's a possibility that the raw binary data could
> > accidentally contain the ELF magic number at that offset, even though it's
> > not actually an ELF file. This could lead to false positive detection and
> > incorrect parsing.
> > 
> 
> Really? How can the WLAN FW segment have the ELF magic at the start of the
> segment? Then it becomes a separate ELF file.
> 

But isn't this new format 2 concatenated ELF files? If so there
shouldn't be any data at this position? It should be the end of the
"file"?

The only way I can see that there would accidentally be a ELF header
here would be if we're still in the middle of the first ELF - but that
doesn't seem like the place to look for the second ELF.

Regards,
Bjorn

> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்
> 

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

On Thu, Dec 18, 2025 at 07:18:00AM -0600, Bjorn Andersson wrote:
> On Thu, Dec 18, 2025 at 06:12:37PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Dec 18, 2025 at 04:36:28AM -0800, Qiang Yu wrote:
> > > On Thu, Dec 18, 2025 at 04:51:18PM +0530, Manivannan Sadhasivam wrote:
> > > > On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> > > > > 
> > > > > 
> > > > > On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > > > > > 
> > > > > > 
> > > > > > 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 <mayank.rana@oss.qualcomm.com>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 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 :(
> > > > > 
> > > > > I mean I don't know the reason behind the design choice.
> > > > > 
> > > > 
> > > > Ok, then I guess we should try to get rid of the flag and just check for the
> > > > WLAN FW ELF header during runtime:
> > > > 
> > > > 	/*
> > > > 	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
> > > > 	 * file. Hence, check for the existence of the second ELF header after
> > > > 	 * SBL. If present, load the second image separately.
> > > > 	 */
> > > > 	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
> > > > 		fw_data += mhi_cntrl->sbl_size
> > > > 		fw_sz -= mhi_cntrl->sbl_size;
> > > > 	}
> > > >
> > > Hmmm, for the old format image, since the data at `fw_data + mhi_cntrl->sbl_size`
> > > is raw WLAN FW data, there's a possibility that the raw binary data could
> > > accidentally contain the ELF magic number at that offset, even though it's
> > > not actually an ELF file. This could lead to false positive detection and
> > > incorrect parsing.
> > > 
> > 
> > Really? How can the WLAN FW segment have the ELF magic at the start of the
> > segment? Then it becomes a separate ELF file.
> > 
> 
> But isn't this new format 2 concatenated ELF files? If so there
> shouldn't be any data at this position? It should be the end of the
> "file"?
> 
> The only way I can see that there would accidentally be a ELF header
> here would be if we're still in the middle of the first ELF - but that
> doesn't seem like the place to look for the second ELF.
>
For old format image, we're in the middle of the ELF. Look at the data at
offset 0x80000(512 KB), it is raw data of WLAN FW.

Old format image(WCN7850):
00000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 2800 0100 0000 0073 7a01 3400 0000  ..(......sz.4...
00000020: 0000 0000 0000 0000 3400 2000 1a00 0000  ........4. .....
...
0007fff0: 240d 0000 380d 0000 3c0d 0000 500d 0000  $...8...<...P...
00080000: 540d 0000 a80f 0000 ac0f 0000 b00f 0000  T...............
00080010: b40f 0000 b80f 0000 bc0f 0000 c00f 0000  ................

For new format image, there is an ELF header at offset 0x80000(512 KB).

New format image(QCC2072):
00000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 2800 0100 0000 00b0 8101 3400 0000  ..(.........4...
00000020: 0000 0000 0000 0000 3400 2000 0700 0000  ........4. .....
...
0007fff0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00080000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00080010: 0200 a400 0100 0000 50f7 4f01 3400 0000  ........P.O.4...

If we know that it is an ELF image, then it must have ELF MAGIC at offset
512 KB. But we can't say if we find ELF MAGIC, it must be an ELF image,
although the possibility is very high that it is.

- Qiang Yu
> Regards,
> Bjorn
> 
> > - Mani
> > 
> > -- 
> > மணிவண்ணன் சதாசிவம்
> > 

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

On Thu, Dec 18, 2025 at 06:12:37PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 18, 2025 at 04:36:28AM -0800, Qiang Yu wrote:
> > On Thu, Dec 18, 2025 at 04:51:18PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Dec 18, 2025 at 05:21:54PM +0800, Baochen Qiang wrote:
> > > > 
> > > > 
> > > > On 12/18/2025 5:13 PM, Baochen Qiang wrote:
> > > > > 
> > > > > 
> > > > > 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 <mayank.rana@oss.qualcomm.com>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 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 :(
> > > > 
> > > > I mean I don't know the reason behind the design choice.
> > > > 
> > > 
> > > Ok, then I guess we should try to get rid of the flag and just check for the
> > > WLAN FW ELF header during runtime:
> > > 
> > > 	/*
> > > 	 * Some FW combine two separate ELF images (SBL + WLAN FW) in a single
> > > 	 * file. Hence, check for the existence of the second ELF header after
> > > 	 * SBL. If present, load the second image separately.
> > > 	 */
> > > 	if (!memcmp(fw_data + mhi_cntrl->sbl_size, ELFMAG, SELFMAG)) {
> > > 		fw_data += mhi_cntrl->sbl_size
> > > 		fw_sz -= mhi_cntrl->sbl_size;
> > > 	}
> > >
> > Hmmm, for the old format image, since the data at `fw_data + mhi_cntrl->sbl_size`
> > is raw WLAN FW data, there's a possibility that the raw binary data could
> > accidentally contain the ELF magic number at that offset, even though it's
> > not actually an ELF file. This could lead to false positive detection and
> > incorrect parsing.
> > 
> 
> Really? How can the WLAN FW segment have the ELF magic at the start of the
> segment? Then it becomes a separate ELF file.

I confirmed with WLAN FW team. It is extremely rare scenario that the old
format image contains ELF magic number at offset 512KB. It is practically
not possible.

- Qiang Yu
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Jeff Johnson]

On 12/7/2025 10:35 PM, 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 <mayank.rana@oss.qualcomm.com>
...
>>> @@ -445,6 +448,7 @@ struct mhi_controller {
>>>  	bool bounce_buf;
>>>  	bool fbc_download;
>>>  	bool wake_set;
>>> +	bool standard_elf_image;
>>
>> This flag is never set, making it a dead API. If there are other patches
>> setting up the flag, please include them into them in the same series.
> 
> Let me discuss with Baochen about whether he can include the patch in his
> series that actually sets this flag for QCC2072 device.

The QCC2072 patchset under internal review is already 19 patches, all of which
are specific to the ath12k driver and hence would go through ath.git.

I'd prefer to not bury this patch in that series.

Would you be happy with a commit text note that indicates this functionality
will be used in an upcoming series that adds support for QCC2072 to the ath12k
driver?

/jeff

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Qiang Yu]

n Mon, Dec 15, 2025 at 10:21:58AM -0800, Jeff Johnson wrote:
> On 12/7/2025 10:35 PM, 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 <mayank.rana@oss.qualcomm.com>
> ...
> >>> @@ -445,6 +448,7 @@ struct mhi_controller {
> >>>  	bool bounce_buf;
> >>>  	bool fbc_download;
> >>>  	bool wake_set;
> >>> +	bool standard_elf_image;
> >>
> >> This flag is never set, making it a dead API. If there are other patches
> >> setting up the flag, please include them into them in the same series.
> > 
> > Let me discuss with Baochen about whether he can include the patch in his
> > series that actually sets this flag for QCC2072 device.
> 
> The QCC2072 patchset under internal review is already 19 patches, all of which
> are specific to the ath12k driver and hence would go through ath.git.
> 
> I'd prefer to not bury this patch in that series.
> 
> Would you be happy with a commit text note that indicates this functionality
> will be used in an upcoming series that adds support for QCC2072 to the ath12k
> driver?
>
It's fine to me.

- Qiang Yu

Re: [PATCH v3] mhi: host: Add standard elf image download functionality

[Jeff Johnson]

On 12/1/2025 6:33 PM, Qiang Yu wrote:
> From: Mayank Rana <mayank.rana@oss.qualcomm.com>
> 
> 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.

FYI the consumer of this functionality is now available:

series:
https://lore.kernel.org/all/20251218-ath12k-support-qcc2072-v1-0-87928cf8e547@oss.qualcomm.com

specific patch:
https://lore.kernel.org/all/20251218-ath12k-support-qcc2072-v1-11-87928cf8e547@oss.qualcomm.com/