Emerson Power Supply vs. Arista Emerson Power Supply

[NikSG]

Hi,

Would anyone know the difference between a normal 460W Emerson power supply, and the Emerson power supply that is sold only for Arista switches?

Ordered some over e-bay and it turned out they were not recognized by the Arista switch. The switch powered up, but had some issues recognizing that all fans work properly and thus entered into a reboot loop.

Would anyone know where to look for such schemas and how to reverse-engineer a power supply, or do they actually include a different hardware to those power supplies. In the meantime I have purchased the correct ones, but it would be kind of interesting to know what is different.

Power supply for Arista switch purchased from Arista costs around 700 USD, whereas Emerson 460W power supplies are sold for 70-100 USD over Alibaba (China).

 

[fohdeesha]

I cannot speak on them being identical or not, I have no clue. Open them up and look around?

However if they are identical and it's still not working, it's most likely due to the EEPROM having different data in it. In each PSU is a little EEPROM (usually 16kbit), and the switch reads it over an I2C bus. It reads (and sometimes controls) the PSU fan speeds and temp over the same bus. In my experience the EEPROM has the PSU part number, the serial number of it, and the revision. If the arista isn't seeing any of that, or results that don't make sense, it could be refusing to run.

On top of that you mention that it said something about fan errors? It could be that the fan controller/monitor in the OEM PSU has different I2C bus/device addresses as well, which would definitely confuse the switch.

I don't have a lot of low level arista experience, but on brocade I know there's low level debug commands that allow you to scan the i2c bus for devices and their addresses, and also read/write eeprom's (in the psu's or elsewhere). If you can keep it running long enough (like in the bootloader or something), and find similar commands, you can compare the device addresses and EEPROM contents between the OEM supply and the original one (if you still have it)

Depending on the model you have it's probably just linux, in which case there's probably an I2C-TOOLS package or similar installed that you'd most likely use. Not sure what commands it exposes though

Have you checked ebay for the arista supplies? In my experience they can be had for 70 or 80 bucks, and work perfectly fine

 

[i386]

Power supply for Arista switch purchased from Arista costs around 700 USD,

Did you check ebay? There are some front-to-back arista psus available for ~100-150$

 

[NikSG]

I cannot speak on them being identical or not, I have no clue. Open them up and look around?

However if they are identical and it's still not working, it's most likely due to the EEPROM having different data in it. In each PSU is a little EEPROM (usually 16kbit), and the switch reads it over an I2C bus. It reads (and sometimes controls) the PSU fan speeds and temp over the same bus. In my experience the EEPROM has the PSU part number, the serial number of it, and the revision. If the arista isn't seeing any of that, or results that don't make sense, it could be refusing to run.

On top of that you mention that it said something about fan errors? It could be that the fan controller/monitor in the OEM PSU has different I2C bus/device addresses as well, which would definitely confuse the switch.

I don't have a lot of low level arista experience, but on brocade I know there's low level debug commands that allow you to scan the i2c bus for devices and their addresses, and also read/write eeprom's (in the psu's or elsewhere). If you can keep it running long enough (like in the bootloader or something), and find similar commands, you can compare the device addresses and EEPROM contents between the OEM supply and the original one (if you still have it)

Depending on the model you have it's probably just linux, in which case there's probably an I2C-TOOLS package or similar installed that you'd most likely use. Not sure what commands it exposes though

Have you checked ebay for the arista supplies? In my experience they can be had for 70 or 80 bucks, and work perfectly fine

I already purchased the correct PSU's and Arista switch works properly now. I was just curious to find out more about this specific power supply. I definitely learned something from your message (thank you), I was not aware that they had some kind of EEPROM, but even on its official page, it states the same:
DS460S Series

The switch has the following i2c commands : i2c-stub-from-dump i2cPresenceTest i2cdetect i2cdump i2cget i2cset.
I am not familiar with these commands and am currently trying to get something out of it? Any ideas?

Thanks,
Nik

 

[fohdeesha]

I have no way of knowing without access to the switch, but I would guess, "i2cdetect" will dump a list of all i2c devices in a table, hopefully with easy to recognize names "like psu #1" etc, so try running that, and see if it takes any arguments.

i2cdump would probably dump the contents of any i2c-connected eeprom, so figure out what arguments it'll take (probably i2c device address, eeprom offset, and amount to dump), and try to dump the contents of each psu's eeprom. to make them match you would need a write command, which would maybe be i2cset, but I have no clue - those are very strangely named commands

 

[NikSG]

I have no way of knowing without access to the switch, but I would guess, "i2cdetect" will dump a list of all i2c devices in a table, hopefully with easy to recognize names "like psu #1" etc, so try running that, and see if it takes any arguments.

i2cdump would probably dump the contents of any i2c-connected eeprom, so figure out what arguments it'll take (probably i2c device address, eeprom offset, and amount to dump), and try to dump the contents of each psu's eeprom. to make them match you would need a write command, which would maybe be i2cset, but I have no clue - those are very strangely named commands

[admin@arista ~]$ i2cdetect -l
i2c-0 unknown SMBus PIIX4 adapter at 6000 N/A
i2c-1 unknown SMBus PIIX4 adapter at 6000 N/A
i2c-2 unknown SMBus PIIX4 adapter at 6000 N/A
i2c-3 unknown SMBus PIIX4 adapter at 6000 N/A

[admin@arista ~]$ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 24 -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

As seen from the above, the output is very user unfriendly.

 

[fohdeesha]

are both power supplies installed?

According to the second output, there's two devices (address 23 and 24) on bus 20. I would think those are the psu's

try:
i2cdump 20 23
for second psu:
i2cdump 20 24

that should just dump the i2c device registers, probably not eeprom contents. to read and write eeprom contents you'd need a utility aware of EEPROM structure (how to read and write them). see if there's any commands available with the word eeprom in them (maybe syseeprom or something)

 

[NikSG]

It appears that Arista has their own Python script called "idseeprom" designed to read EEPROM's.
The syntax is "idseeprom -d <bus address> read. Since I could not find the right synax for the bus address I used the following "sudo idseeprom -d all read" and received some binary mess including a few strings. I don't think that will be of much use. I really appreciate your effort for helping to figure this out. Thanks, Nik

 

[fohdeesha]

no problem. however, now you've got me curious. I'm assuming it means bus, then address. The table output you got earlier is the bus on the vertical left hand column, and the address of the devices on that bus on the top/horizontal column.

try "idseeprom -d 20 23 read" or "idseeprom -d 20 24 read"

or if you have a minute, try "idseeprom -d 50 50 read" through to "idseeprom -d 50 57 read" (increment the second number). One of those should produce readable PSU-like string (like serial number/part number/revision etc)

if that script also has a "write" argument, it could be as easy as one or two commands to make the PSU's match

 

[NikSG]

no problem. however, now you've got me curious. I'm assuming it means bus, then address. The table output you got earlier is the bus on the vertical left hand column, and the address of the devices on that bus on the top/horizontal column.

try "idseeprom -d 20 23 read" or "idseeprom -d 20 24 read"

or if you have a minute, try "idseeprom -d 50 50 read" through to "idseeprom -d 50 57 read" (increment the second number). One of those should produce readable PSU-like string (like serial number/part number/revision etc)

if that script also has a "write" argument, it could be as easy as one or two commands to make the PSU's match

The command asks for an input something like x.y. I always get an error:

[admin@arista ~]$ sudo idseeprom -d 1.23 read
=============== Exception raised in 'python /usr/bin/idseeprom -d 1.23 read ' (PID 3589; PPI D 3587) ===============
Traceback (most recent call last):
File "/usr/bin/idseeprom", line 198, in <module>
sys.stdout.write( seeprom.doRead( busId, seepromId, offset, length ) )
File "/usr/lib/python2.7/site-packages/seeprom.py", line 119, in doRead
val = dev.word[ offset + i ]
File "/usr/lib/python2.7/site-packages/Tac.py", line 751, in __getitem__
MemoryError: I2c:evice.word: error in accessor : Tac::MemoryException("Error reading bus 1 device 0x17 address 0x0")
> /usr/lib/python2.7/site-packages/Tac.py(751)__getitem__()
(Pdb) ^C

From the script:

deviceList = []
if options.device == ["all"]:
for bank in xrange(80, 88):
deviceList = deviceList + [ ( 1, bank ) ]
else:
for device in options.device:
(busId, seepromId) = device.split(".")
deviceList = deviceList + [ ( seeprom.strToInt( busId ),
seeprom.strToInt( seepromId ) ) ]

Reverse engineering the script, found out that the following works:

sudo idseeprom -v -d 0.81 read
or
sudo idseeprom -v -d 1.81 read

This output:
[admin@arista ~]$ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 24 -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


23 in that output corresponds to the following:
$ sudo idseeprom -v -d 1.35 read

Not sure what's the theory behind the conversion, but I figured that one out.
The output is unfortunately just a bunch of binary mess.