I would be curious to see what happens if you toss a Raven with the quad core processor and better ASIC's. If you were to do that you could jump to 32GB of ram.
I don't have my switch yet, but it seems the management CPU is on the rear card (the amd chip to the right of the USB DOM in the pic I posted), and the ASIC is on the front (asic and management cpu are not on the same card). Either way, started a deep dive into EOS fw earlier tonight, came across something you might be interested in. In the EOS filesystem, navigate to \usr\share\NorCal
all these fdl files define the chassis data, just cat one to view.
Contents of ClearlakeCrowS1.fdl (our 7050qx-32S):
Code:
# This file describes everything specific to the switch that consists of
# a Clearlake switch card and a Crow CPU card
description = "32 QSFP+ + 4 SFP+ 1RU"
baseSku = "DCS-7050QX-32S"
numSfpPorts = 4
numTenGigFortyGigPorts = 24
numFortyGigOnlyPorts = 8
numQsfpPorts = numTenGigFortyGigPorts + numFortyGigOnlyPorts
numPortsWithMacAddr = numTenGigFortyGigPorts * 4 + numFortyGigOnlyPorts + numSfpPorts
# this file stitches the Crow cpu card together with a Clearlake switch card
# the cards share a connector that connects PCIE busses, an Smbus and gpios between
# the two cards
# the Crow.fin file provides the following variables to allow components on the
# switch card to be plumbed into the system.
# SwitchPciRoot -- a dict of invPciBridge objects that hook up to the pci topology
# on the switch card. the number of items is based on the
# Sw2CpuPcieBridgeNums dict below.
# _configCpuSmbusDevices( smbus ) -- a function in the cpu card called when the
# smbus object for the smbus is created on the switch card, this
# should be used to initialize all smbus devices on the cpu card
# the pcie topology between the switch and CPU card, first bridge is connected to the
# Trident, the second to the scd
# configure how the CPU card creates the pcie links to the swtich card
# configure how the switch card looks up the pci root for the pcie components
Sw2CpuPcieBridgeNums = { 0 : ( 0x2, 1 ), 1 : ( 0x2, 2 ) }
backToFrontCoolingSupported = True
frontToBackCoolingSupported = True
# XXX_THEBE: These are cloverdale values
forwardInletTempToCoolingLevel ={25.0: 2, 33.33: 3, 37.5: 4, 40.0: 5}
reverseInletTempToCoolingLevel ={20.0: 2, 30.0: 3, 35.0: 4, 40.0: 5}
You can see it's quite modular/flexible, it even states "#this file stitches the Crow cpu card together with a Clearlake switch card" implying arbitrary stitching is possible (given physical limitations of course).
And, indeed, it seems a descriptor file for exactly what you wanted to do (combine a raven management plane with the 7050qx-32S ASIC board "codename clearlake") already exists!
ClearlakeRavenS1.fdl -
Code:
# This file describes everything specific to the switch that consists of
# a Clearlake switch card and a Raven CPU card
description = "32 QSFP+ + 4 SFP+ 1RU"
baseSku = "DCS-7050QX-32S"
numSfpPorts = 4
numTenGigFortyGigPorts = 24
numFortyGigOnlyPorts = 8
numQsfpPorts = numTenGigFortyGigPorts + numFortyGigOnlyPorts
numPortsWithMacAddr = numTenGigFortyGigPorts * 4 + numFortyGigOnlyPorts + numSfpPorts
# this file stitches the raven cpu card together with a Clearlake switch card
# the cards share a connector that connects PCIE busses, an Smbus and gpios between
# the two cards
# the Raven.fin file provides the following variables to allow components on the
# switch card to be plumbed into the system.
# SwitchPciRoot -- a dict of invPciBridge objects that hook up to the pci topology
# on the switch card. the number of items is based on the
# Sw2CpuPcieBridgeNums dict below.
# _configCpuSmbusDevices( smbus ) -- a function in the cpu card called when the
# smbus object for the smbus is created on the switch card, this
# should be used to initialize all smbus devices on the cpu card
# the pcie topology between the switch and CPU card, first bridge is connected to the
# Trident, the second to the scd
# configure how the CPU card creates the pcie links to the swtich card
# configure how the switch card looks up the pci root for the pcie components
Sw2CpuPcieBridgeNums = { 0 : ( 0x4, 0 ), 1 : ( 0x9, 0 ) }
backToFrontCoolingSupported = True
frontToBackCoolingSupported = True
# XXX_THEBE: These are cloverdale values
forwardInletTempToCoolingLevel ={25.0: 2, 33.33: 3, 37.5: 4, 40.0: 5}
reverseInletTempToCoolingLevel ={20.0: 2, 30.0: 3, 35.0: 4, 40.0: 5}
The only values differing between the two (other than comments) are Sw2CpuPcieBridgeNum, which I would assume are the pci-e lane/bridge identifiers of where the MGMT CPU should expect to talk to the switch ASIC.
I wouldn't count on the switch being smart enough to load this correct profile when mixing in a new mgmt board automatically, I have some more digging to do but it seems the config that gets loaded is based on FDL identifier data stored on the switch nonvolatile storage. Separate from all the usb/sata/etc flash storage there's an MXIC SPI flash chip soldered to the board, this contains aboot, fdl chassis ident data, serials, the burned in MAC, etc:
Code:
'norcal4' : {
'total' : { 'start' : 0x000000, 'length' : 0x0800000 },
'prefdl' : { 'start' : 0x010000, 'length' : 0x000f000 },
'mfgdata' : { 'start' : 0x01f000, 'length' : 0x0001000 },
'fdl' : { 'start' : 0x020000, 'length' : 0x0010000 },
'fallback' : { 'start' : 0x030000, 'length' : 0x03f0000 },
'image' : { 'start' : 0x420000, 'length' : 0x03db000 },
The contents of the script \usr\bin\flashUtil details some of the contents and addresses of said SPI flash, and seems to fully support dumping said data sections to files, and also the reverse (writing a file you provide to said flash chip). I would not run the script yet though, even with just a help arg passed, if something goes wrong or behaves not like we'd expect, wiping out the aboot section of SPI flash would brick the switch. I have tools for SPI flash raw reading/writing (and arista was nice enough to break out the chip to a SPI header), so when my switch arrives I'll see what I can get the script to do. I'd imagine worst case, to change the chassis ident to a different mgmt cpu/asic combo it would just be something like "flashutil -w fdl customfdl.bin"
for someone who enjoys reverse engineering things until they break,. the openness of EOS has been quite enjoyable, even if I only have it running in a VM currently