Linux I2C development
 help / color / mirror / Atom feed
From: Caleb Connolly <caleb.connolly@linaro.org>
To: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>,
	Viken Dadhaniya <quic_vdadhani@quicinc.com>,
	andi.shyti@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, gregkh@linuxfoundation.org,
	jirislaby@kernel.org, broonie@kernel.or, andersson@kernel.org,
	konradybcio@kernel.org, johan+linaro@kernel.org,
	dianders@chromium.org, agross@kernel.org,
	linux-arm-msm@vger.kernel.org, linux-i2c@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-spi@vger.kernel.org
Cc: quic_msavaliy@quicinc.com, quic_anupkulk@quicinc.com
Subject: Re: [PATCH v1 0/7] Add support to load QUP SE firmware from
Date: Wed, 22 Jan 2025 16:23:11 +0100	[thread overview]
Message-ID: <56ef1276-9d58-4a94-ae89-5faf5870c10c@linaro.org> (raw)
In-Reply-To: <17138798-b72b-4e78-8fad-419e1a63fa5b@quicinc.com>

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

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

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.

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

-- 
// Caleb (they/them)


  reply	other threads:[~2025-01-22 15:23 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04 15:03 [PATCH v1 0/7] Add support to load QUP SE firmware from Viken Dadhaniya
2024-12-04 15:03 ` [PATCH v1 1/7] dt-bindings: i2c: qcom,i2c-geni: Document DT properties for QUP firmware loading Viken Dadhaniya
2024-12-04 15:06   ` Krzysztof Kozlowski
2024-12-10  4:43     ` Viken Dadhaniya
2024-12-10  7:23       ` Krzysztof Kozlowski
2024-12-04 15:25   ` neil.armstrong
2024-12-10  4:44     ` Viken Dadhaniya
2024-12-04 17:25   ` Doug Anderson
2024-12-10  5:28     ` Viken Dadhaniya
2024-12-10 17:42       ` Doug Anderson
2024-12-11  5:27         ` Viken Dadhaniya
2024-12-11 22:27           ` Doug Anderson
2024-12-04 22:36   ` Dmitry Baryshkov
2024-12-10  4:48     ` Viken Dadhaniya
2024-12-04 15:03 ` [PATCH v1 2/7] spi: dt-bindings: " Viken Dadhaniya
2024-12-04 15:07   ` Krzysztof Kozlowski
2024-12-04 15:03 ` [PATCH v1 3/7] dt-bindings: serial: " Viken Dadhaniya
2024-12-04 15:07   ` Krzysztof Kozlowski
2024-12-04 15:03 ` [PATCH v1 4/7] soc: qcom: geni-se:: Add support to load QUP SE Firmware via Linux subsystem Viken Dadhaniya
2024-12-04 15:24   ` neil.armstrong
2024-12-10  4:53     ` Viken Dadhaniya
2024-12-04 20:19   ` kernel test robot
2024-12-04 22:37     ` Dmitry Baryshkov
2024-12-10  4:54       ` Viken Dadhaniya
2024-12-04 21:22   ` kernel test robot
2024-12-05  1:23   ` kernel test robot
2024-12-04 15:03 ` [PATCH v1 5/7] i2c: qcom-geni: Load i2c qup Firmware from linux side Viken Dadhaniya
2024-12-04 15:03 ` [PATCH v1 6/7] spi: geni-qcom: Load spi " Viken Dadhaniya
2024-12-04 15:03 ` [PATCH v1 7/7] serial: qcom-geni: Load UART " Viken Dadhaniya
2024-12-05 15:59 ` [PATCH v1 0/7] Add support to load QUP SE firmware from Konrad Dybcio
2024-12-09 14:45   ` neil.armstrong
2024-12-10  5:22     ` Viken Dadhaniya
2024-12-12 15:56     ` Konrad Dybcio
2024-12-10  5:06   ` Viken Dadhaniya
2024-12-12 15:58     ` Konrad Dybcio
2025-01-07 11:25 ` Caleb Connolly
2025-01-10  6:56   ` Mukesh Kumar Savaliya
2025-01-22 15:23     ` Caleb Connolly [this message]
2025-01-22 17:52       ` Mukesh Kumar Savaliya

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=56ef1276-9d58-4a94-ae89-5faf5870c10c@linaro.org \
    --to=caleb.connolly@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andi.shyti@kernel.org \
    --cc=broonie@kernel.or \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=quic_anupkulk@quicinc.com \
    --cc=quic_msavaliy@quicinc.com \
    --cc=quic_vdadhani@quicinc.com \
    --cc=robh@kernel.org \
    /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