From: Baochen Qiang <quic_bqiang@quicinc.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Qiang Yu <qiang.yu@oss.qualcomm.com>
Cc: <jeff.hugo@oss.qualcomm.com>, <mhi@lists.linux.dev>,
<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<can.guo@oss.qualcomm.com>,
Mayank Rana <mayank.rana@oss.qualcomm.com>
Subject: Re: [PATCH v2] mhi: host: Add standard elf image download functionality
Date: Fri, 6 Jun 2025 09:58:06 +0800 [thread overview]
Message-ID: <9ab8e8f8-e176-44ab-b8e5-0c27e5eff30b@quicinc.com> (raw)
In-Reply-To: <sdhop6vyvt4y63tbbtorqfd5xa4ckbiwxdad5g6zzwlljqvd6q@eoaqmairdeey>
On 6/6/2025 1:04 AM, Manivannan Sadhasivam wrote:
> On Tue, Jun 03, 2025 at 02:05:44AM -0700, 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, RDDM, and AMSS. Some devices are
>> unable to process this non-standard ELF format and therefore require
>> special handling during image loading.
>>
>
> What are those "some devices"? Why are they not able to process this format
> which is used across the rest of the Qcom devices?
>
>> Add standard_elf_image flag to determine whether the device can process
>> the non-standard ELF format. If this flag is set, a standard ELF image
>> must be loaded, meaning the first 512 KB of the FBC image should be
>> skipped when loading the AMSS image over the BHIe interface.
>
> Please explain what is present in the first 512KiB and why skipping that is
> required.
>
>> Note that
>> this flag does not affect the SBL image download process.
>>
>> 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 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 efa3b6dddf4d2f937535243bd8e8ed32109150a4..f1686a8e0681d49f778838820b44f4c845ddbd1f 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"));
>
> This print is just a noise even for debug.
>
>> + if (mhi_cntrl->standard_elf_image) {
>> + fw_data += mhi_cntrl->sbl_size;
>> + fw_sz -= mhi_cntrl->sbl_size;
>
> Is it possible to detect the image type during runtime instead of using a flag?
> Also, the flag is currently unused. So it should come along an user.
The flag would be used when a new WLAN device getting upstream. So either we merge this
patch alone, or we get it grouped within the WLAN patches. Kindly share your thoughts?
>
> - Mani
>
next prev parent reply other threads:[~2025-06-06 1:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 9:05 Qiang Yu
2025-06-03 9:10 ` Baochen Qiang
2025-06-05 17:04 ` Manivannan Sadhasivam
2025-06-06 1:58 ` Baochen Qiang [this message]
2025-06-17 9:23 ` Manivannan Sadhasivam
2025-06-19 7:42 ` Qiang Yu
2025-06-06 7:53 ` Qiang Yu
2025-06-17 9:19 ` Manivannan Sadhasivam
2025-06-19 3:44 ` Qiang Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ab8e8f8-e176-44ab-b8e5-0c27e5eff30b@quicinc.com \
--to=quic_bqiang@quicinc.com \
--cc=can.guo@oss.qualcomm.com \
--cc=jeff.hugo@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mayank.rana@oss.qualcomm.com \
--cc=mhi@lists.linux.dev \
--cc=qiang.yu@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®