[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <04bee338-2828-44e2-9ee8-8a94b4433ca9@quicinc.com>
Date: Wed, 22 Jan 2025 23:22:57 +0530
From: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>
To: Caleb Connolly <caleb.connolly@...aro.org>,
Viken Dadhaniya
<quic_vdadhani@...cinc.com>, <andi.shyti@...nel.org>,
<robh@...nel.org>, <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
<gregkh@...uxfoundation.org>, <jirislaby@...nel.org>,
<broonie@...nel.or>, <andersson@...nel.org>, <konradybcio@...nel.org>,
<johan+linaro@...nel.org>, <dianders@...omium.org>,
<agross@...nel.org>, <linux-arm-msm@...r.kernel.org>,
<linux-i2c@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>,
<linux-spi@...r.kernel.org>
CC: <quic_anupkulk@...cinc.com>
Subject: Re: [PATCH v1 0/7] Add support to load QUP SE firmware from
Hi Caleb, we shall update for latest ask and will check how to enable
validation on required board.
On 1/22/2025 8:53 PM, Caleb Connolly wrote:
> Hi Mukesh,
>
> On 10/01/2025 07:56, Mukesh Kumar Savaliya wrote:
>> Thanks Caleb for your testing and sharing results. Since Viken is on
>> leave, i am following on this.
>>
>> On 1/7/2025 4:55 PM, Caleb Connolly wrote:
>>> Hi Viken,
>>>
>>> On 04/12/2024 16:03, Viken Dadhaniya wrote:
>>>> In Qualcomm SoCs, firmware loading for Serial Engines (SE) in the QUP
>>>> hardware has traditionally been managed by TrustZone (TZ). This setup
>>>> handled Serial Engines(SE) assignments and access control permissions,
>>>> ensuring a high level of security but limiting flexibility and
>>>> accessibility.
>>>> This limitation poses a significant challenge for developers who
>>>> need more
>>>> flexibility to enable any protocol on any of the SEs within the QUP
>>>> hardware.
>>>> To address this, we are introducing a change that opens the firmware
>>>> loading mechanism to the Linux environment. This enhancement increases
>>>> flexibility and allows for more streamlined and efficient management. We
>>>> can now handle SE assignments and access control permissions directly
>>>> within Linux, eliminating the dependency on TZ.
>>>> We propose an alternative method for firmware loading and SE
>>>> ownership/transfer mode configuration based on device tree
>>>> configuration.
>>>> This method does not rely on other execution environments, making it
>>>> accessible to all developers.
>>>> For SEs used prior to the kernel, their firmware will be loaded by the
>>>> respective image drivers (e.g., Debug UART, Secure or trusted SE).
>>>> Additionally, the GSI firmware, which is common to all SEs per QUPV3
>>>> core,
>>>> will not be loaded by Linux driver but TZ only. At the kernel level,
>>>> only
>>>> the SE protocol driver should load the respective protocol firmware.
>>>
>>> I gave this series a spin on the RB3 Gen 2 with U-Boot.
>>>
>> Is it possible to try on RB8 board ? Because that's where this support
>> is enabled. It also needs respective TZ configuration to allow FW
>> loading from Linux.
>
> I don't have access to RB8, so no... This support will also be useful on
> RB3 Gen 2 for U-Boot support, can the next tz release for this platform
> include the necessary changes?
Let us evaluate and review TZ configs and changes. This was meant for
only development boards. I will check internally and review for RB3 Gen2
and update.
>>
>>
>>> After fixing the compilation errors, it seems like there is a consistent
>>> hard crash (the board freezes and resets) at some point during i2c
>>> controller init with this series.
>>>
>> Can you please share exact repro steps ? We can try locally and check
>> what's wrong and also review in future how we make it working for U-boot
>> combination.
>
> If it's true that tz changes are needed that would certainly explain the
> crash.
>
yes
> Unfortunately it isn't currently possible to boot QC Linux via U-Boot
> since the ESP uses a 512 byte sector size on 4k block size UFS which is
> not supported.
>
> If you build an image with a correct ESP (mkfs.vfat -S 4096) then you
> can boot U-Boot from upstream by following the RB3 Gen 2 documentation
>
We need to check this and update back.
> https://docs.u-boot.org/en/latest/board/qualcomm/rb3gen2.html
>
> You'll also need to apply this patch to fix a boot regression
> https://lore.kernel.org/u-boot/20250122-qcom-parse-memory-updates-v2-0-98dfcac821d7@samcday.com/
>
> On the Linux/DTS side, apply this series, add the appropriate properties
> to enable fw loading as-per the dt-bindings added by this series and
> place the qupv3fw.elf file.
>
Sure, got it.
> Kind regards,
>>> I noticed a similar issue with this same logic implemented in U-Boot.
>>>
>>> Could you clarify which xfer mode is appropriate for the i2c controllers
>>> on the RB3 Gen 2 and maybe give this a try yourself, or let me know what
>>> other info you'd need to debug this.
>>>
>> Yes, please share the procedure , we will try internally.
>> is there any DTSI change done as part of your testing ?
>>> Thanks and kind regards,
>>>>
>>>> Viken Dadhaniya (7):
>>>> dt-bindings: i2c: qcom,i2c-geni: Document DT properties for QUP
>>>> firmware loading
>>>> spi: dt-bindings: Document DT properties for QUP firmware loading
>>>> dt-bindings: serial: Document DT properties for QUP firmware loading
>>>> soc: qcom: geni-se:: Add support to load QUP SE Firmware via Linux
>>>> subsystem
>>>> i2c: qcom-geni: Load i2c qup Firmware from linux side
>>>> spi: geni-qcom: Load spi qup Firmware from linux side
>>>> serial: qcom-geni: Load UART qup Firmware from linux side
>>>>
>>>> .../bindings/i2c/qcom,i2c-geni-qcom.yaml | 11 +
>>>> .../serial/qcom,serial-geni-qcom.yaml | 12 +
>>>> .../bindings/spi/qcom,spi-geni-qcom.yaml | 11 +
>>>> drivers/i2c/busses/i2c-qcom-geni.c | 11 +-
>>>> drivers/soc/qcom/qcom-geni-se.c | 445 ++++++++++++++++++
>>>> drivers/spi/spi-geni-qcom.c | 7 +-
>>>> drivers/tty/serial/qcom_geni_serial.c | 7 +-
>>>> include/linux/soc/qcom/geni-se.h | 17 +
>>>> include/linux/soc/qcom/qup-fw-load.h | 179 +++++++
>>>> 9 files changed, 692 insertions(+), 8 deletions(-)
>>>> create mode 100644 include/linux/soc/qcom/qup-fw-load.h
>>>>
>>>
>>
>
Powered by blists - more mailing lists