I2C device(s) on I2C5 (0x031a0000)

Hi!

I am wondering about the various devices on I2C5 (0x031a0000).

Especially the address 0x50 - what is it and how do I find information about it/dts nodes etc?

The reason I am wondering is because on some of our devices (AGX Xavier Industrial on custom carrier board) we “see it” when running “i2cdetect -y -r 4” and on some devices we don’t.

Example output from “i2cdetect -y -r 4”:

i2cdetect -y -r 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
40: 40 -- -- -- -- -- -- -- 48 -- -- -- UU -- -- -- 
50: -- -- -- -- -- -- -- -- 58 -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

During investigation - we found that 0x28, 0x48 and 0x58 seem to be linked to the RTC battery being used/plugged in or not.

Thanks.

Maybe you can dump the device tree to check the device under the i2c@31a0000

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

Thanks for the response.

However, there is no node “i2c@31a0000” in the dump - but, there is an “bpmp_i2c” that seems to match some of it (thanks to: Jetson/AGX Xavier Misc Interfaces - eLinux.org)

i2cdetect -y -r 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
40: 40 -- -- -- -- -- -- -- 48 -- -- -- UU -- -- -- 
50: -- -- -- -- -- -- -- -- 58 -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

From the dumped device tree:

...
i2c4 = "/bpmp_i2c";
...
spmic@3c (rtc0 = "/bpmp_i2c/spmic@3c";)
temp-sensor@4c (tegra_tmp451 = "/bpmp_i2c/temp-sensor@4c";)
...

This explains the 0x3C and 0x4C.

Maybe I should rephrase the question/issue:
In what document/resource can I find what “devices” should be/are located on the I2C bus 0x031a0000? Since we are finding that different Xavier AGX Industrial units either expose 0x50 on the bus or not, and are worried they might be faulty/we would like to know what is happening.

In the same way as 0x28, 0x48 and 0x58 disappears when booting the device without an RTC battery connected and appears when be boot the device with the battery connected.

0x50 would not show up in any dts/device tree - since when it does show up, it is not used by any driver (i.e. no “UU” in i2cdetect) etc.

Thanks.

Maybe check the HW design guide.

Thanks

Hello again.

I did, before reaching out to you for assistance.

However, I could share my findings. But I still need some guidance.


(DG-09840-001_v2.6)

First off - the bus is exposed on L44/L45 (on JAXi). We are not using those pins for anything on our carrier board/not routed from the contact.


(DG-09840-001_v2.6)

The “Mux JAXi Only” routes to “Voltage Monitors”. “On-Module Control” also seems to be on the bus.


(DG-09840-001_v2.6)

“Voltage Monitor” seems to be exposed on L47 - which is not used for anything on the carrier board.

There must be a list of the addresses exposed on the bus somewhere - but I cannot find it in the documents.

So, if you could help with supplying one (or the information in any other way), I would appreciate it.

Thanks.

Hi, 0x50 is address of a phase buck controller used on module. The address list of I2C5 is not public as it is on-module only.

Hi.
Thank you for the response.

Understood. But just to clear all things up and close this issue then hopefully:

0x50 seems to be present/not present on the bus rather at random, and not as I stated before about the “0x28, 0x48 and 0x58 seem to be linked to the RTC battery being used/plugged in or not

I have failed to see anything coherent in the same way for 0x50.

Bottom line: Should 0x50 be or not be present on the bus during “normal function”/“AGX is healthy”, or can we disregard it completely?

Thank you.

Do you mean run below command sometimes 0x50 shows but sometimes don’t?

How about the failed rate?

i2cdetect -y -r 4

Please use command line “tegrastats” to read the voltage value of VDD_GPU which is from 0x50 device.

Thanks guys for getting back to me.


First @ShaneCCC :
Yes that is exactly the case. I would have a hard time estimating the fail rate, but I can explain a bit more at least.

Since we noticed this behaviour, we have tested approx 50 units. Out of those we have only seen 0x50 on two of those.
However, it does seem to differ from boot to boot as well - since 0x50 have “always dissapeared after the initial/first boot in the test rig”.

So what I am saying is that I cannot say with confidence that “we have only seen 0x50 on two out of 50 units”, since we might just have been “un-/lucky” that specific boot, or the timings have not been identical.

So that is why I am wondering if it is a cause for concern, or not.


And, for @Trumany :
Thanks!
I’ll paste two different tegrastats - ran at different uptimes.

RAM 416/31930MB (lfb 7786x4MB) SWAP 0/15965MB (cached 0MB) CPU [17%@2035,14%@2035,11%@2035,10%@2035,18%@2035,19%@2035,25%@2035,20%@2035] EMC_FREQ 0% GR3D_FREQ 0% AO@23C GPU@23C thermal@23.65C Tdiode@24.5C PMIC@50C AUX@24C CPU@24.5C slv@24.562C bme280_1@25.79C Tboard@23C

RAM 413/31930MB (lfb 7758x4MB) SWAP 0/15965MB (cached 0MB) CPU [1%@115,0%@115,0%@115,0%@115,0%@115,0%@192,0%@192,0%@192] EMC_FREQ 0% GR3D_FREQ 0% AO@31C GPU@33C thermal@32.1C Tdiode@33.5C PMIC@50C AUX@31.5C CPU@33C slv@32.742C bme280_1@32.73C Tboard@32C

From what I can read, there is no “VDD_GPU”. There does not seem to be any voltage/power-related reading at all.

I will try some more, and keep it in mind and run tegrastats if I manage to “see 0x50” on the bus, and try to get back to you by monday.