[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66fb0c6d-472c-4131-bd25-83266cf497e4@linaro.org>
Date: Tue, 7 Jan 2025 12:25:17 +0100
From: Caleb Connolly <caleb.connolly@...aro.org>
To: 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_msavaliy@...cinc.com, quic_anupkulk@...cinc.com
Subject: Re: [PATCH v1 0/7] Add support to load QUP SE firmware from
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.
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.
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.
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)
Powered by blists - more mailing lists