* Read CPDL firmware version on Edgecore AS5114-48X
@ 2023-06-21 7:59 Paul Menzel
2023-06-24 11:32 ` Jean Delvare
0 siblings, 1 reply; 5+ messages in thread
From: Paul Menzel @ 2023-06-21 7:59 UTC (permalink / raw)
To: linux-i2c; +Cc: Jean Delvare
Dear I2C folks,
I am trying to read the CPDL firmware version of the switch Edgecore
AS5114-48X with dentOS (Debian based).
In U-Boot it supposedly work like below:
Marvell>> i2c dev 2
Marvell>> i2c md 0x40 01 1
0001: 01
Marvell>> i2c md 0x40 ff 1
00ff: 03
But I like to do it with GNU/Linux, but my attempts failed:
```
# i2cdetect -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- UU UU UU UU UU UU --
```
Nothing seems to be at address 0x40:
```
# i2cdump -f -y 2 0x40
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
```
Could the bus be different?
```
# i2cdetect -l
i2c-3 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-30 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-20 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-49 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-10 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-39 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-1 i2c mv64xxx_i2c adapter I2C adapter
i2c-29 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-19 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-47 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-37 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-27 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-17 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-45 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-8 i2c i2c-2-mux (chan_id 5) I2C adapter
i2c-35 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-25 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-15 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-43 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-6 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-33 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-23 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-13 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-41 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-4 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-31 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-21 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-11 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-2 i2c mv64xxx_i2c adapter I2C adapter
i2c-48 i2c i2c-2-mux (chan_id 5) I2C adapter
i2c-38 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-0 i2c mv64xxx_i2c adapter I2C adapter
i2c-28 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-18 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-46 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-9 i2c i2c-2-mux (chan_id 6) I2C adapter
i2c-36 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-26 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-16 i2c i2c-2-mux (chan_id 5) I2C adapter
i2c-44 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-7 i2c i2c-2-mux (chan_id 4) I2C adapter
i2c-34 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-24 i2c i2c-2-mux (chan_id 5) I2C adapter
i2c-14 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-42 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-5 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-32 i2c i2c-2-mux (chan_id 5) I2C adapter
i2c-22 i2c i2c-2-mux (chan_id 3) I2C adapter
i2c-50 i2c i2c-2-mux (chan_id 7) I2C adapter
i2c-12 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-40 i2c i2c-2-mux (chan_id 5) I2C adapter
# find / -iname *cpld*
/sys/bus/i2c/drivers/as4224_cpld
/sys/module/arm64_accton_as4224_cpld
/sys/module/arm64_accton_as4224_cpld/drivers/i2c:as4224_cpld
/lib/modules/5.6.16/onl/wnc/arm64-wnc-qsa72-aom-a-48p/qsa72-aom-a-48p-sys_cpld.ko
/lib/modules/5.6.16/onl/wnc/arm64-wnc-qsd61-aom-a-48/qsd61-aom-a-48-sfp_plus_cpld.ko
/lib/modules/5.6.16/onl/wnc/arm64-wnc-qsd61-aom-a-48/qsd61-aom-a-48-sys_cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn48m2/arm64-delta-tn48m-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn48m-poe/arm64-delta-tn48m-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn4810m-dn/arm64-delta-tn48m-dn-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn48m-poe-dn/arm64-delta-tn48m-dn-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn4810m/arm64-delta-tn48m-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn48m-dn/arm64-delta-tn48m-dn-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tn48m/arm64-delta-tn48m-cpld.ko
/lib/modules/5.10.4/onl/delta/arm64-delta-tx4810/arm64-delta-tx4810-cpld.ko
/lib/modules/5.10.4/onl/accton/arm64-accton-as4224-52p/arm64-accton-as4224-cpld.ko
/lib/modules/5.10.4/onl/accton/arm64-accton-as4224-52t/arm64-accton-as4224-cpld.ko
/lib/modules/5.10.4/onl/accton/arm64-accton-as5114-48x/arm64-accton-as4224-cpld.ko
# ls -l /sys/bus/i2c/drivers/as4224_cpld/
total 0
lrwxrwxrwx 1 root root 0 Jun 20 16:53 0-0040 ->
../../../../devices/platform/ap806/ap806:config-space@f0000000/f0511000.i2c/i2c-0/0-0040
--w------- 1 root root 4096 Jun 20 16:53 bind
lrwxrwxrwx 1 root root 0 Jun 20 16:53 module ->
../../../../module/arm64_accton_as4224_cpld
--w------- 1 root root 4096 May 16 10:21 uevent
--w------- 1 root root 4096 Jun 20 16:53 unbind
```
Is it bus 0?
```
# i2cdump -f -y 0 0x40
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 80 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.?????????????
10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .???????????????
20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .???????????????
30: ff ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc ....????????????
40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ????????????????
50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.????????????
60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q??????????????
70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ????????????????
80: 6c 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc liiih???????????
90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq????????????
a0: ff ff ff ff ff ff ff ff ff ff ff 7f cc cc cc cc ...........?????
b0: ff ff ff ff ff ff 00 00 00 00 00 00 cc cc cc cc ............????
c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......????
d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ????????????????
e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc cc .q??????????????
f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 05 AS5114......AWS?
```
What would be the values of `0x40 01 1` and ` 0x40 ff 1`?
Kind regards,
Paul
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Read CPDL firmware version on Edgecore AS5114-48X 2023-06-21 7:59 Read CPDL firmware version on Edgecore AS5114-48X Paul Menzel @ 2023-06-24 11:32 ` Jean Delvare 2023-07-14 10:57 ` Read CPLD " Paul Menzel 0 siblings, 1 reply; 5+ messages in thread From: Jean Delvare @ 2023-06-24 11:32 UTC (permalink / raw) To: Paul Menzel; +Cc: linux-i2c Hi Paul, On Wed, 21 Jun 2023 09:59:44 +0200, Paul Menzel wrote: > I am trying to read the CPDL firmware version of the switch Edgecore > AS5114-48X with dentOS (Debian based). > > In U-Boot it supposedly work like below: > > Marvell>> i2c dev 2 > Marvell>> i2c md 0x40 01 1 > 0001: 01 > Marvell>> i2c md 0x40 ff 1 > 00ff: 03 > > But I like to do it with GNU/Linux, but my attempts failed: > > ``` > # i2cdetect -y 2 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- > 70: -- UU UU UU UU UU UU -- > ``` > > Nothing seems to be at address 0x40: > > ``` > # i2cdump -f -y 2 0x40 > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX > (...) > f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX > ``` > > Could the bus be different? Yes, unlike the PCI bus which has a well defined topology, multiple I2C root segments can coexist in a system and their numbering is largely arbitrary. So there's no guarantee that i2c bus 2 on U-Boot is the same as i2c bus 2 on Linux. I'm not familiar with U-Boot but you may try "i2c dev" or "i2c bus" commands there, maybe it will tell you what corresponds to i2c bus 2. > (...) > # find / -iname *cpld* > /sys/bus/i2c/drivers/as4224_cpld > (...) > # ls -l /sys/bus/i2c/drivers/as4224_cpld/ > total 0 > lrwxrwxrwx 1 root root 0 Jun 20 16:53 0-0040 -> > ../../../../devices/platform/ap806/ap806:config-space@f0000000/f0511000.i2c/i2c-0/0-0040 > --w------- 1 root root 4096 Jun 20 16:53 bind > lrwxrwxrwx 1 root root 0 Jun 20 16:53 module -> > ../../../../module/arm64_accton_as4224_cpld > --w------- 1 root root 4096 May 16 10:21 uevent > --w------- 1 root root 4096 Jun 20 16:53 unbind > ``` > > Is it bus 0? Seems so, yes. > > ``` > # i2cdump -f -y 0 0x40 > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: 80 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.????????????? > 10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .??????????????? > 20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .??????????????? > 30: ff ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc ....???????????? > 40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? > 50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.???????????? > 60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q?????????????? > 70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ???????????????? > 80: 6c 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc liiih??????????? > 90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq???????????? > a0: ff ff ff ff ff ff ff ff ff ff ff 7f cc cc cc cc ...........????? > b0: ff ff ff ff ff ff 00 00 00 00 00 00 cc cc cc cc ............???? > c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......???? > d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? > e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc cc .q?????????????? > f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 05 AS5114......AWS? > ``` > > What would be the values of `0x40 01 1` and ` 0x40 ff 1`? As I understand the U-Boot i2c command syntax, 0x40 is the slave address, 01/ff is the register offset (in hexadecimal, despite no leading "0x") and 1 is the register count. So the equivalent Linux i2c-tools commands, assuming i2c bus 0, would be: # i2cget 0 0x40 0x01 b # i2cget 0 0x40 0xff b From the full register dump above, these commands will most probably return values (0x)01 and (0x)05, respectively. The former matches what you got from U-Boot, the latter doesn't. Which may or may not indicate a problem, depending on whether these values are supposed to be static or if they could change over time. Hope that helps, -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Read CPLD firmware version on Edgecore AS5114-48X 2023-06-24 11:32 ` Jean Delvare @ 2023-07-14 10:57 ` Paul Menzel 2023-07-18 7:05 ` Jean Delvare 0 siblings, 1 reply; 5+ messages in thread From: Paul Menzel @ 2023-07-14 10:57 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-i2c [Subject: Correct CPDL to CPLD.] Dear Jean, Thank you very much for y Am 24.06.23 um 13:32 schrieb Jean Delvare: > Hi Paul, > > On Wed, 21 Jun 2023 09:59:44 +0200, Paul Menzel wrote: >> I am trying to read the CPLD firmware version of the switch Edgecore >> AS5114-48X with dentOS (Debian based). >> >> In U-Boot it supposedly work like below: >> >> Marvell>> i2c dev 2 >> Marvell>> i2c md 0x40 01 1 >> 0001: 01 >> Marvell>> i2c md 0x40 ff 1 >> 00ff: 03 >> >> But I like to do it with GNU/Linux, but my attempts failed: >> >> ``` >> # i2cdetect -y 2 >> 0 1 2 3 4 5 6 7 8 9 a b c d e f >> 00: -- -- -- -- -- -- -- -- -- -- -- -- -- >> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 50: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- >> 70: -- UU UU UU UU UU UU -- >> ``` >> >> Nothing seems to be at address 0x40: >> >> ``` >> # i2cdump -f -y 2 0x40 >> No size specified (using byte-data access) >> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef >> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX >> (...) >> f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX >> ``` >> >> Could the bus be different? > > Yes, unlike the PCI bus which has a well defined topology, multiple I2C > root segments can coexist in a system and their numbering is largely > arbitrary. So there's no guarantee that i2c bus 2 on U-Boot is the same > as i2c bus 2 on Linux. > > I'm not familiar with U-Boot but you may try "i2c dev" or "i2c bus" > commands there, maybe it will tell you what corresponds to i2c bus 2. > >> (...) >> # find / -iname *cpld* >> /sys/bus/i2c/drivers/as4224_cpld >> (...) >> # ls -l /sys/bus/i2c/drivers/as4224_cpld/ >> total 0 >> lrwxrwxrwx 1 root root 0 Jun 20 16:53 0-0040 -> >> ../../../../devices/platform/ap806/ap806:config-space@f0000000/f0511000.i2c/i2c-0/0-0040 >> --w------- 1 root root 4096 Jun 20 16:53 bind >> lrwxrwxrwx 1 root root 0 Jun 20 16:53 module -> >> ../../../../module/arm64_accton_as4224_cpld >> --w------- 1 root root 4096 May 16 10:21 uevent >> --w------- 1 root root 4096 Jun 20 16:53 unbind >> ``` >> >> Is it bus 0? > > Seems so, yes. > >> ``` >> # i2cdump -f -y 0 0x40 >> No size specified (using byte-data access) >> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef >> 00: 80 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.????????????? >> 10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .??????????????? >> 20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .??????????????? >> 30: ff ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc ....???????????? >> 40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> 50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.???????????? >> 60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q?????????????? >> 70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> 80: 6c 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc liiih??????????? >> 90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq???????????? >> a0: ff ff ff ff ff ff ff ff ff ff ff 7f cc cc cc cc ...........????? >> b0: ff ff ff ff ff ff 00 00 00 00 00 00 cc cc cc cc ............???? >> c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......???? >> d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc cc .q?????????????? >> f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 05 AS5114......AWS? >> ``` >> >> What would be the values of `0x40 01 1` and ` 0x40 ff 1`? > > As I understand the U-Boot i2c command syntax, 0x40 is the slave > address, 01/ff is the register offset (in hexadecimal, despite no > leading "0x") and 1 is the register count. So the equivalent Linux > i2c-tools commands, assuming i2c bus 0, would be: > > # i2cget 0 0x40 0x01 b > # i2cget 0 0x40 0xff b > > From the full register dump above, these commands will most probably > return values (0x)01 and (0x)05, respectively. The former matches what > you got from U-Boot, the latter doesn't. Which may or may not indicate > a problem, depending on whether these values are supposed to be static > or if they could change over time. The U-Boot values were copied from the GitHub issue, so it’s not an error that they are different. I updated the CPLD firmware to version 1.09 now, and to verify tried your commands, but get an error: # i2cdump -f -y 0 0x40 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 88 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.????????????? 10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .??????????????? 20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .??????????????? 30: 03 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc ?...???????????? 40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? 50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.???????????? 60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q?????????????? 70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ???????????????? 80: 6a 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc jiiih??????????? 90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq???????????? a0: 00 00 00 00 00 00 f0 01 00 00 00 c0 cc cc cc cc ......??...????? b0: 00 00 00 00 00 00 00 00 00 00 00 00 cc cc cc cc ............???? c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......???? d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc 00 .q?????????????. f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 09 AS5114......AWS? # i2cget 0 0x40 0x01 b Error: Could not set address to 0x40: Device or resource busy # i2cget 0 0x40 0xff b Error: Could not set address to 0x40: Device or resource busy Do you know, why i2cdump is able to read the date, but i2cget is not? Kind regards, Paul ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Read CPLD firmware version on Edgecore AS5114-48X 2023-07-14 10:57 ` Read CPLD " Paul Menzel @ 2023-07-18 7:05 ` Jean Delvare 2023-07-18 7:10 ` Paul Menzel 0 siblings, 1 reply; 5+ messages in thread From: Jean Delvare @ 2023-07-18 7:05 UTC (permalink / raw) To: Paul Menzel; +Cc: linux-i2c Hi Paul, On Fri, 14 Jul 2023 12:57:33 +0200, Paul Menzel wrote: > I updated the CPLD firmware to version 1.09 now, and to verify tried > your commands, but get an error: > > # i2cdump -f -y 0 0x40 > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: 88 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.????????????? > 10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .??????????????? > 20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .??????????????? > 30: 03 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc ?...???????????? > 40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? > 50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.???????????? > 60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q?????????????? > 70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ???????????????? > 80: 6a 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc jiiih??????????? > 90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq???????????? > a0: 00 00 00 00 00 00 f0 01 00 00 00 c0 cc cc cc cc ......??...????? > b0: 00 00 00 00 00 00 00 00 00 00 00 00 cc cc cc cc ............???? > c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......???? > d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? > e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc 00 .q?????????????. > f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 09 AS5114......AWS? > # i2cget 0 0x40 0x01 b > Error: Could not set address to 0x40: Device or resource busy > # i2cget 0 0x40 0xff b > Error: Could not set address to 0x40: Device or resource busy > > Do you know, why i2cdump is able to read the date, but i2cget is not? You already have a kernel driver bound to address 0x40, so you aren't supposed to access it from user-space. You bypassed this check with option -f you passed to i2cdump, but you did not pass option -f to i2cget, which is why the former succeeded while the latter failed. So either pass -f to i2cget, or unload the kernel driver (arm64_accton_as4224_cpld) before reading the value from user-space. Whichever option is safer depends on what happens when the system runs without that driver. In theory it's better to unload the driver, however depending on how the driver is implemented and whether reading these values has any side effect on the hardware side, forcing the read may be fine. -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Read CPLD firmware version on Edgecore AS5114-48X 2023-07-18 7:05 ` Jean Delvare @ 2023-07-18 7:10 ` Paul Menzel 0 siblings, 0 replies; 5+ messages in thread From: Paul Menzel @ 2023-07-18 7:10 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-i2c Dear Jean, Am 18.07.23 um 09:05 schrieb Jean Delvare: > On Fri, 14 Jul 2023 12:57:33 +0200, Paul Menzel wrote: >> I updated the CPLD firmware to version 1.09 now, and to verify tried >> your commands, but get an error: >> >> # i2cdump -f -y 0 0x40 >> No size specified (using byte-data access) >> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef >> 00: 88 01 ff 07 0f cc cc cc cc cc cc cc cc cc cc cc ??.????????????? >> 10: ff 03 3f cc 01 cc cc cc cc cc cc cc cc cc cc cc .??????????????? >> 20: ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc .??????????????? >> 30: 03 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc ?...???????????? >> 40: cc cc cc 0e cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> 50: 0d 4a 03 00 7f cc cc cc cc cc cc cc cc cc cc cc ?J?.???????????? >> 60: 01 71 1e cc cc cc cc cc cc cc cc cc cc cc cc cc ?q?????????????? >> 70: 7f 7f 7f 7f 7f cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> 80: 6a 69 69 69 68 cc cc cc cc cc cc cc cc cc cc cc jiiih??????????? >> 90: 02 00 71 71 cc cc cc cc cc cc cc cc cc cc cc cc ?.qq???????????? >> a0: 00 00 00 00 00 00 f0 01 00 00 00 c0 cc cc cc cc ......??...????? >> b0: 00 00 00 00 00 00 00 00 00 00 00 00 cc cc cc cc ............???? >> c0: 0f fe ff ff ff 3f 00 00 00 00 00 00 cc cc cc cc ??...?......???? >> d0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ???????????????? >> e0: 00 71 cc cc cc cc cc cc cc cc cc cc cc cc cc 00 .q?????????????. >> f0: 41 53 35 31 31 34 00 00 00 00 00 00 41 57 53 09 AS5114......AWS? >> # i2cget 0 0x40 0x01 b >> Error: Could not set address to 0x40: Device or resource busy >> # i2cget 0 0x40 0xff b >> Error: Could not set address to 0x40: Device or resource busy >> >> Do you know, why i2cdump is able to read the date, but i2cget is not? > > You already have a kernel driver bound to address 0x40, so you aren't > supposed to access it from user-space. You bypassed this check with > option -f you passed to i2cdump, but you did not pass option -f to > i2cget, which is why the former succeeded while the latter failed. > > So either pass -f to i2cget, or unload the kernel driver > (arm64_accton_as4224_cpld) before reading the value from user-space. > Whichever option is safer depends on what happens when the system runs > without that driver. In theory it's better to unload the driver, > however depending on how the driver is implemented and whether reading > these values has any side effect on the hardware side, forcing the read > may be fine. Thank you again for the detailed and spot-on answer. Passing `-f` it worked (without any side-effects for now): # dpkg -l i2c-tools | grep ^ii ii i2c-tools 3.1.2-3 arm64 heterogeneous set of I2C tools for Linux root@ec-as5114-48x-03:~# i2cget -f 0 0x40 0x01 b WARNING! This program can confuse your I2C bus, cause data loss and worse! I will read from device file /dev/i2c-0, chip address 0x40, data address 0x01, using read byte data. Continue? [Y/n] Y 0x01 root@ec-as5114-48x-03:~# i2cget -f 0 0x40 0xff b WARNING! This program can confuse your I2C bus, cause data loss and worse! I will read from device file /dev/i2c-0, chip address 0x40, data address 0xff, using read byte data. Continue? [Y/n] 0x09 Kind regards, Paul ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-07-18 7:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-06-21 7:59 Read CPDL firmware version on Edgecore AS5114-48X Paul Menzel 2023-06-24 11:32 ` Jean Delvare 2023-07-14 10:57 ` Read CPLD " Paul Menzel 2023-07-18 7:05 ` Jean Delvare 2023-07-18 7:10 ` Paul Menzel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox