* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.