Forums - i2c13 not supported by firmware?

3 posts / 0 new
Last post
i2c13 not supported by firmware?
tulric
Join Date: 7 Jun 22
Posts: 2
Posted: Tue, 2022-06-07 17:45

I'm trying to use i2c13 and getting an error during boot which I believe is saying that I2C is not supported in the firmware for that QUP serial engine.  But, I'm guessing I'm just missing something since the device is available in the device tree.  Any suggestions on how to get this working would be welcome.

The boot errors I see are:

[ 5.560279] geni_i2c a94000.i2c: Bus frequency not specified, default to 100k
[ 5.560315] geni_i2c a94000.i2c: Invalid proto 2

 
and no /dev/i2c-13 is created.

Interestingly, i2c15 is working OK.  It still gives the warning about the bus frequency, but nothing about the protocol and /dev/i2c-15 is created.

Looking in the kernel code I see the "Invalid proto" message is coming from geni_i2c_probe in i2c-qcom-geni.c where it is expecting to read 3 (GENI_SE_I2C) from the second byte of the serial engine firmware revision register (GENI_FW_REVISION_RO at offset 0x68), but is instead getting a value of 2 (GENI_SE_UART).

I tried updating the firmware with the lastest version I found on linaro.org using "fastboot flash devcfg RB5_firmware_20210901-v6\07-devcfg\devcfg.mbn", but that made no difference.

In case it is helpful the pertenant parts of my device tree are:

#include "qrb5165-som.dtsi"
&i2c13 {
  status = "okay";
  tc358775: bridge@2d {
  [detail omitted]
  };
};

qrb5156-som.dtsi includes sm8250.dtsi where i2c13 is defined and also enables qupvv3_id_1 which contains i2c13.

 

  • Up0
  • Down0
bruce1
Join Date: 28 Oct 21
Posts: 4
Posted: Wed, 2022-07-06 12:12

Are you building the kernel from source (LE or LU builds that Qualcomm releases)?  

My device tree uses kona-qupv3.dtsi for qupv3_se13_i2c (pins GPIO_36 and GPIO_37 on the SOM).  However, the QRB5165 trustzone image on the RB5 configures SE13 as a UART (UART0), and pins GPIO_36 and 37 are UART0_CTS and UART_RTS.  

If you look through the device tree you will notice they overload the pins to provide multiple functionality with the same set of pins (i2c, i3c, uart, and spi).  However, it's the trustzone configuration that determines what functionality is actually supported on that particular build and who can access it.   If you have access to build the trustzone devcfg stuff then just modify QUPAC_Access.c to change the QUP from QUPV3_PROTOCOL_UART_2W to QUPV3_PROTOCOL_I2C, rebuild, and flash it.  In this particular case you will then lose the debug uart (or uart0 on LC1) depending on your dip switch settings.  At least that's my limited understanding.

It's unfortunate that Qualcomm doesn't really want to provide much community support.  It makes it hard to build a community when interesting questions go unanswered.

Bruce

 

 

  • Up0
  • Down0
tulric
Join Date: 7 Jun 22
Posts: 2
Posted: Fri, 2022-07-08 08:02

Bruce, thanks for the guidance!  I am building the kernel, and had similarly needed to disable UART0.  But I don't currently have source for building the devcfg and didn't know it was called the trustzone.  So, those details will be very helpful if I decide research how to make it work with my unmodified hardware.  To get something working in the short term I switched to another QUP that supported I2C in the stock devcfg I have loaded.

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.