Fun with an MD1200/MD1220 & SC200/SC220

[fohdeesha]

just finished testing and indeed every slot works perfectly fine with an sc200 controller in an md1200 chassis, drive LEDs and everything, so I'd wager the reverse is true too (md1200 firmware in an SC200), just gotta make sure the controller is set to the appropriate 12 or 24 drive mode

 

[fohdeesha]

another quick note on fan control, if you're plugged into the second controller in a 2 controller shelf and send a fan command, fans will ramp back up as the main controller is in control. also if you go lower than 20%, it'll ramp back up. if you want to actually go lower than 20% (not really recommended if you have drives in the thing), you need to fake the temp with set_temp - but I wouldn't go that low with functioning drives in the thing unless you wanna cook them. 20% is already a massive sound improvement

 

[fohdeesha]

was able to update the firmware with the sg3-utils package over SAS so no serial required:

apt-get install lsscsi sg3-utils

##get the enclosure address
root@r620tester:~# lsscsi -g
[1:0:2:0]    enclosu DELL     MD1200           1.06  -          /dev/sg0
[1:0:3:0]    disk    ATA      Samsung SSD 860  3B6Q  /dev/sda   /dev/sg1
[6:0:0:0]    disk    ATA      KINGSTON SV300S3 BBF0  /dev/sdb   /dev/sg2

##use that address
sg_write_buffer -b 4k -m dmc_offs_save -I MD12_106.bin /dev/sg0

It seems to write it to whichever image partition isn't active (eg if the unit is booted from image 1, it flashes to image 2). Then you have to repower the unit to get it to boot off the new firmware. It wouldn't let me crossflash this way (flash sc200 firmware), it would only take about 80% of the firmware - it seems to know what kind of image it should be getting over SES (a check it obviously doesn't make via xmodem).

Can dump a ton of info (voltages, fan speeds etc) with "sg_ses --join /dev/sg0". It accepts fan speed commands over SES too, but sadly ignores them (sc200 firmware might not):

#there's 4 fans, 0-3. 2 per PSU
#set fan 0 speed to 7 (highest)
root@r620tester:~# sg_ses --index=coo,0 --set=3:2:3=7 /dev/sg0

#check, it ignored it and is still on speed 1
root@r620tester:~# sg_ses --index=coo,0 --get=3:2:3 /dev/sg0
1

there's probably some custom "vendor" SES registers that allow overtaking the fan control, but I'm not super familiar with SES (yet) so finding those indexes/registers might be a pain

 

[j_h_o]

Slightly off topic... but at 20%, what's the a) idle pull of an empty chassis, and b) dB from say, 1m away?

 

[redeamon]

I replaced the double stacked fans with some nocturas back in the day for both of my md1200's P/S's. I wish I had known there was a way to control the fans.

Thanks! I'm going to update my md1200's and change some fan settings now.

 

[frameshift18]

Slightly off topic... but at 20%, what's the a) idle pull of an empty chassis, and b) dB from say, 1m away?

Quick tests with a kill-a-watt.. stock fans speed seemed to be around 38%. Idle chassis no drives or drive bays.

2 psus, 1 psu powered, 1 contr, stock = ~34w
2 psus, 1 psu powered, 2 contr, stock = ~43w
2 psus, 2 psu powered, 1 contr, stock = ~49w
2 psus, 2 psu powered, 2 contr, stock = ~57w

2 psus, 1 psu powered, 1 contr, 20% = ~26w
2 psus, 1 psu powered, 2 contr, 20% = ~35w
2 psus, 2 psu powered, 1 contr, 20% = ~37w
2 psus, 2 psu powered, 2 contr, 20% = ~50w

2 psus, 1 psu powered, 1 contr 25% = ~27w
2 psus, 1 psu powered, 2 contr 25% = ~36w
2 psus, 2 psu powered, 1 contr 25% = ~39w
2 psus, 2 psu powered, 2 contr 25% = ~51w

Stock is on par with my ICX 6610-24. 20% isn't silent but its muuch quieter.

 

[frameshift18]

another quick note on fan control, if you're plugged into the second controller in a 2 controller shelf and send a fan command, fans will ramp back up as the main controller is in control. also if you go lower than 20%, it'll ramp back up. if you want to actually go lower than 20% (not really recommended if you have drives in the thing), you need to fake the temp with set_temp - but I wouldn't go that low with functioning drives in the thing unless you wanna cook them. 20% is already a massive sound improvement

When I plugged the second controller into a chassis at 25% it ramped back up to stock. Also had a couple times where i set 25% and it ramped back up to stock after a few seconds. Still haven't messed with set_temp though.

Also when I flashed 1.03 to anything other than the currently active region using _download it would flash fine but the active region wouldn't change to the higher version. I suspect using _boot would work in one go as it states it flashes boot and erases the other two regions. Quick and easy to flash my other controllers though using _flashpeer.

 

[fohdeesha]

When I plugged the second controller into a chassis at 25% it ramped back up to stock. Also had a couple times where i set 25% and it ramped back up to stock after a few seconds. Still haven't messed with set_temp though.

Also when I flashed 1.03 to anything other than the currently active region using _download it would flash fine but the active region wouldn't change to the higher version. I suspect using _boot would work in one go as it states it flashes boot and erases the other two regions. Quick and easy to flash my other controllers though using _flashpeer.

yeah that's exactly the weird fan-reverting behavior I was getting earlier. It wasn't until I used set_temp that it stopped it. The help info for it is pretty extensive, it gives you the list and numbers for what to spoof:

BlueDress.106.000 >set_temp
 usage: set_temp <sensor 0-4><temp>( -55 to 125 degrees C)
                         0 - SIM0 max6544 internal sensor, top shelf
                         1 - SIM1 max6654 intenal sensot, bottom shelf
                         2 - BP_1 lm75 left most looking from front
                         3 - BP_2 lm75 right most looking from front
                         4 - EXP0 max6654 external sense diode hooked to lSI expander, top shelf
                         5 - EXP1 max6654 external sense diode hooked to lSI expander, bottom shelf

I had the best luck with just spoofing the controller temps (sim0 and sim1). so you just stick their numbers in the command and then the temp after, so to set them to 0c:

set_temp 0 0
set_temp 1 0

Confirm they're set:

BlueDress.106.000 >_temp_rd

  BP_1[2] = 22c
  BP_2[3] = 22c
  SIM0[0] = 0c
  SIM1[1] = 0c
  EXP0[4] = 40c
  EXP1[5] = 42c

  AVG = 21c

It's worth noting even after this I've still had them ramp back up when trying to set them lower than 20% - I believe this is because of the fan control threshold logic. The proper way to alter the fan speeds I think would be using:

_fan_ctrl_thrd Write fan control parameters in C: fan_ctrl_thrd <M> <H> <SIM offset> <hysteresis>

Instead of forcing the existing logic to do stuff by faking temps, but I haven't had time to play around with _fan_ctrl_thrd

That's weird about it not booting later versions, on the MD1200 FW it'll boot from any slot I put stuff in as long as the ver is highest. I also noticed _boot doesn't actually format or even touch image 1 and 2, it just flashes to the first slot (the "boot" slot)

 

[fohdeesha]

welp nevermind on that one:

BlueDress.106.000 >_fan_ctrl_thrd
*****************************************************************************************
This command has not been implemented yet.
If you REALLY need this feature cont(r)act the Devil's firmware team for help.
CAUTION: It may not be wise to make cont(r)act with any of the Devil's team members.
*****************************************************************************************

 

[dmehaffy]

If any of you want something to mess with, I currently have an md3200 in the mail (after I realized the md3200 controllers only accept dell drives listed on their matrix *facepalm*) From what I've read they use the same backplane but only swap some CID which is why I'm guessing there is even a password. Once I get the thing (already ordered some md1200 emms) gonna try and swap them out and see if I need to mess with the backplane or if it will just work.

If it doesn't I'll post up anything I can find, but another spot to tinker. I hear you can also covert an md1200 into an md3200 if you wanted the extra features. In my case I just need a disk shelf to throw onto a server for storage.

Linky to where I may have a password that will work for the vx shell: How to connect to the console on a Dell MD storage array

Will have to wait til it gets here to know what I need to do to get into that shell...

 

[unclebacon]

So I wanted to throw my hat in to this ring. Don't quite remember how I stumbled on this thread but sure glad I did.

I spent the better part of an hour splicing an old PS/2 mouse mini-DIN connector to an old serial port cable. If I didn't have a brain fart and forget to cross the RX/TX lines over, it probably would have gone a lot faster. I digress, got connected and while stumbling around with different commands I pressed up once in a blank command line and it populated the command string with "devils", hit return and it output this:

asset_tag   Set or Display the Asset Tag: asset_tag {setvalue}
asd_offset  Set or Display the Auto-Shudown Offset value: asd_offset {setvalue}
broadcast   Send Broadcast SES Message: broadcast
chassistype Display and or Set Chassis Type: chassistype <0 = Blue Devil !0 = Red Devil>
clear_eel   Clear Event Error Log: clear_eel
clear_temp  Remove override of Temperature: clear_temp <sensor>
dbs         Database Read  : dbs  <page>
devils      Print the Help Screen
drive_led   Write drive led: <logicaldrive> <data>
eepromdump  EEprom Dump: eepromdump <port><addr><size in K(1,2,4,8,..512>
eepromfill  EEprom Fill: eepromfill <port><addr><size in K(1,2,4,8,..512><pattern>
eepromwrite EEprom Write: eepromwrite <port><addr><size in K(1,2,4,8,..512><offset><length><pattern>
fanlog      Fan fault count for each power supply fan [8 per unit]
fpgadisable Put FPGA in Slave Mode: fpgadisable>
fpgaenable  Put FPGA in Master Mode: fpgaenable>
fpga_rd     FPGA Access: fpga_rd <Register> <#bytes>
fpga_wr     FPGA Access: fpga_wr <Register> <data>[<Register> <data> ...]
fru_display Display FRU Status: fru_display
fru_clear   Clear Fru: fru_clear [0-SIM0, 1-SIM1, 2-PBP, 3-PS0, 4-PS1 5-SBP]
fru_download Download Fru: fru_download [0-SIM0, 1-SIM1, 2-PBP, 3-PS0, 4-PS1 5-SBP]
fru_read    Read Fru: fru_read [0-SIM0, 1-SIM1, 2-PBP, 3-PS0, 4-PS1 5-SBP]]
get_time    get encl time: get_time
gpio_rd     Read a GPIO: gpio_rd <number>
heart_beat  SIM Heartbeat Control: heart_beat [0=off !0=on] <timeout>
isim_debug  Change or view isim stats: <data> <0 - Disable; 1 - Enable>
l4_test     L4 integration manufacturing diag: l4_test
lm75        LM75 Read Access: lm75 <Slave Address>
lm75_rd     LM75 Read Access: lm75_rd <Slave Address> <Register>
lm75_wr     LM75 Write Access: lm75_wr <Slave Address> <Register> <1 byte>
log_ipmi    Log an IPMI Event:log_ipmi<Code><Type><Sensor><EV0><EV1><EV2><EV3>
max6654     Display MAX6654 Registers: max6654 <i2c port><slave addr>
noise       Write audible alarm: <data>
nvramread8  Read NVram 32bit area: nvramread <address> <length>
nvramread   Read NVram 32bit area: nvramread <32bit address> <length>
nvramwrite8 Write NVram 32bit area: nvramwrite <address> <data> [<32bit address> <data> ...]
nvramwrite  Write NVram 32bit area: nvramwrite <32bit address> <data> [<32bit address> <data> ...]
page_a      Display drive SAS Address: page_a
ps_status   Get P/S Module Status: ps_status <l(eft)/r(ight)>
ps_cap      Get P/S Module capability: ps_cap <l(eft)/r(ight)>
ps_clear    Clear P/S Module Status: ps_clr <l(eft)/r(ight)>
ps_page     Get P/S Module Status: ps_status <l(eft)/r(ight)>
ppid        Set or Display PPID: ppid {fruNumber}{setvalue}
prompt      Prompt on/off
rd_8        8-bit Read: rd_8   <address> <# of 8 bit words>
rd_16       16-bit Read: rd_16  <address> <# of 16 bit words>
rd_32       32-bit Read: rd_32  <address> <# of 32 bit words>
reset_peer  Reset other SIM using GPIO <1-reset peer>
reset       Reset ARM using Watch Dog timer
rev         SIM Firmware and Diagnogstic Revision
sas_address Display SAS Address from Phys: (option for magic addr <1>)
sbb_status  Set SBB status: sbb_set <default-print status, 0-set good, 1-set failed>
scratchpad  Display Location of Memory Test Area: scratchpad
service_tag Set or Display the Service Tag: service_tag {setvalue}
ses_page    Display SES Page: ses_page <page><buffer size>
set_speed   Sets Fan Speeds: set_speed <0-100%> 20 default
set_temp    set encl temp: set_temp <sensor><temp>( -55 to 125 degrees C)
set_thres   Set P/S Module Fan Speed Threshold: set_thres <l(eft)/r(ight)><speed code 0..15>
shelf_led   Write shelf led: <data> <0 - Disable; 1 - Enable>
twi_dis     TWI device discovery: twi_dis
twi_rd      TWI device byte read: twi_rd <port ID> <address> <# of bytes - 0xff max>
twi_stats   Dump twi statistics: twi_stats [clear]
twi_wr      TWI device byte write: twi_wr <port ID> <address> {0xff bytes max}
twi_wr_rd   TWI device wr/rd: twi_wr_rd <port ID> <address> <#read bytes> <write data>
wr_8        8-bit Write: wr_8  <address> <data> [<address> <data> ...]
wr_16       16-bit Write: wr_16 <address> <data> [<address> <data> ...]
wr_32       32-bit Write: wr_32 <address> <data> [<address> <data> ...]

Don't know if anyone mentioned it already but I don't remember seeing anything. This is awesome and now I'll be setting it up to automatically drop fan speeds on my turbine engine. Thanks to everyone!

Edit: Nevermind, first post.

 

[uberlinuxguy]

FWIW: If you are having an issue where the fans are ramping back up after you set them to 20, you have to make sure that if you have both EMM modules installed, that they are both up to the same FW version. If not, it will fault and ramp to full speed. If you remove one of them and only use one EMM, you will not run into this problem and can still get temperature data from the enclosure.

Also, If anyone else lands on this thread and is looking to replace the fans with Noctua fans, I would highly suggest against it.

The fans shipped in the unit are these: https://www.delta-fan.com/Download/Spec/PFC0812DE-SP04.pdf

Important information from that spec sheet:
Airflow: 132.6CFM (3.754 M3/min)
Air Pressure: 2.030 inH20 (51.57 mmh20)

And they are stacked, meaning the static pressure goes up. So to replace these fans, you would need one that matches those specs, or one that can do 132.6CFM at 4 inH20.... Noctua doesn't have anything close. The Air Pressure is particularly important because that's how it gets over the resistance of all those big drives being in the way.

Now, if you are not mounting this in a rack, the case might act as a bit of a heat sink and MAYBE you could get away with it, but at this point, I'll stop my digression.

 

[me7alm1k3666]

How'd you dump the flash, just used the _flashdump command to dump it to the serial terminal and then format it into a hex bin? If so and it sounds like it's not flashing right, I'd imagine something went wrong in the display > conversion process, it should indeed match the size "_ver" shows exactly

It turns out the "boot" section is a bit of a misnomer, it's just another flash slot like image 1 and 2, so it's better to think about it like image 0, image 1, image 2 - the really simple bootloader seemingly just chooses whichever has the largest version number and boots from that slot. So even if you flash my 1.01 to "boot" (slot 0), it'll just see the more recent version in image slot 1 and boot from that, so if you wanna downgrade you gotta flash the older image to all 3 slots

The bootloader is REALLY simple, seemingly only a command to display and modify raw memory (or maybe FPGA config registers, can't tell which):

help    d [loc]
        p  loc  value

        DesignWare (TM)
        DW_debugger

Instead of running at 38400-8-N-1, the bootloader also runs at 38400-7-N-1, which I've never seen before - that's why you get garbled/weird ASCII over serial on boot, for a few lines the card is sending 38400-7-N-1 bootloader output to your 38400-8-N-1 terminal session


Also got bored and flashed the SC200 image to my MD1200, and it indeed had no issue and became an SC200 controller:

**** Surly Startup Complete (Based on vendor Phase 9 drop 00.09.00.00) ****

12Pack.Slot0.101.0 >set_speed 10
12Pack.Slot0.101.1 >

Of course like I said earlier the backplanes are slightly different, so I'd imagine if I put actually drives in it, it would have odd behavior or not be able to see all the drives, being SC200 code talking to an MD1200 backplane. But I guess at least if you ever have an SC200 controller and need an MD1200 controller or vice versa, you can just flash them over to be whatever you need

If someone can get me a compellent / dell SCOS image from the last couple years it'll take like 20 seconds to pull out a clean SC200/SC220 v1.06 firmware image

Hey fohdeesha,

Do you know how to set which image to boot from in the bootloader? I tried updating the firmware via ExtraPutty and the transfer failed midway through so now the controller won't boot properly and the EMM light is orange. If this truly is like a "Image 0", "Image 1", "Image 2", I would think you should be able to tell the controller to boot using a specified image. I guess I'm thinking of this controller like a Cisco IOS device where you can specify which image to boot to using their bootloader or recover a failed upgrade by transferring a new image to flash. Maybe this isn't the same concept but one can hope! Have you played around at all with that? I'm planning on buying a new controller since they are pretty cheap but I'd like to see if I can somehow recover this broken one.

Also, for the craps and giggles, I plugged my MD1220 into a PERC 5/e (I know, its an old 3Gbps SAS controller and it required a special cable to go between the different SAS connectors but it worked for this) and was able to update the second controller in my chassis to 1.06 without any issues using Dell's firmware update utility. Maybe this will help some others who are trying to update their controllers...

Thank you

 

[fohdeesha]

Hey fohdeesha,

Do you know how to set which image to boot from in the bootloader? I tried updating the firmware via ExtraPutty and the transfer failed midway through so now the controller won't boot properly and the EMM light is orange. If this truly is like a "Image 0", "Image 1", "Image 2", I would think you should be able to tell the controller to boot using a specified image. I guess I'm thinking of this controller like a Cisco IOS device where you can specify which image to boot to using their bootloader or recover a failed upgrade by transferring a new image to flash. Maybe this isn't the same concept but one can hope! Have you played around at all with that? I'm planning on buying a new controller since they are pretty cheap but I'd like to see if I can somehow recover this broken one.

Also, for the craps and giggles, I plugged my MD1220 into a PERC 5/e (I know, its an old 3Gbps SAS controller and it required a special cable to go between the different SAS connectors but it worked for this) and was able to update the second controller in my chassis to 1.06 without any issues using Dell's firmware update utility. Maybe this will help some others who are trying to update their controllers...

Thank you

no clue, I poked around the bootloader but only found two commands with no explanation, they seemed to be for poking at/modifying very low level cpu registers. It does indeed decide which slot to boot from (I've seen it change), but I have no idea based on what. How did extraputty transfer fail, was it a bad/loose serial connection? I also bricked a controller, using teraterm with a known xmodem bug that crapped out in the middle of it. Thankfully replacement modules are $15 shipped

Somewhere back on page 2 or 3 I posted the linux command that will flash new firmware to them no problem over the normal sas connection using common sas tools

 

[me7alm1k3666]

no clue, I poked around the bootloader but only found two commands with no explanation, they seemed to be for poking at/modifying very low level cpu registers. It does indeed decide which slot to boot from (I've seen it change), but I have no idea based on what. How did extraputty transfer fail, was it a bad/loose serial connection? I also bricked a controller, using teraterm with a known xmodem bug that crapped out in the middle of it. Thankfully replacement modules are $15 shipped

Somewhere back on page 2 or 3 I posted the linux command that will flash new firmware to them no problem over the normal sas connection using common sas tools

I think the update failed because I didn't have the correct cable to plug in so I had stripped the wires from an old serial cable and shoved them in the holes to get communication. I knew I had to be careful not to bump the wires so they wouldn't come loose but I think somehow one of them disconnected temporarily and caused the connection to fail. The error I got in ExtraPutty had something to do with the VC redistributables but I think that was just a side effect of a wire coming loose. Luckily, I found out that I was able to update the firmware using Dell's updater in Windows when I had the chassis plugged into a PERC 5/e so I was able to successfully update my other controller. I'm getting ready to buy two controllers for $30 shipped on eBay AND I got myself one of those "password reset" cables so no more shoving tiny wires in holes and hoping for the best.

 

[tokugero]

I also managed to brick the 2 EMMs I had that came with my unit, had 2 more units come in and had the first attempt at _boot take ~15 hours to eventually show me 2093/2091... I restarted the process and the firmware came up properly on both modules, as well as showing only one boot image, looks like the other 2 were also wiped out.

BlueDress.106.000 >_ver
_ver
********************* Bench Build **********************
Build Owner   : GitHub
Build Number  : 000
Build Version : 106
Build Date    : Mon Aug 24 12:28:59 2015
FPGA Revision  : A9
Board Revision : 8
CPLD Revision  : 7
**************Firmware Image Information****************
Active--->Image Region 0 (Always Boot)
             Revision         : 0.0.63.0
             Dell Version     : 1.06
             Total Image Size : 000414fc [267516]
             Fast Boot        : Yes
             Image Address    : 0x14000000
             RegionOffset     : 0x00000000
             RegionSize       : 0x00080000
             RegionType       : 0x00000000
          Image Region 1
             Revision         : 255.255.255.255
             Dell Version     : ▒▒▒▒
             Total Image Size : ffffffff [-1]
             Fast Boot        : No
             Image Address    : 0x14080000
             RegionOffset     : 0x00080000
             RegionSize       : 0x00080000
             RegionType       : 0x00000001
          Image Region 2
             Revision         : 255.255.255.255
             Dell Version     : ▒▒▒▒
             Total Image Size : ffffffff [-1]
             Fast Boot        : No
             Image Address    : 0x14100000
             RegionOffset     : 0x00100000
             RegionSize       : 0x00080000
             RegionType       : 0x00000002
********************************************************

This all being said, I tried setting the temp spoof and the set_speed to 20% but the EMMs will eventually auto-restart and take away any configs along with it.

BlueDress.106.000 >

**** Devil Startup Complete (Based on vendor drop 00.00.63.00) ****

Any way found yet to write the changes to memory or otherwise make the fan speed limit permanent?

 

[tokugero]

I got some more time to work on this today and found that the fans stay spun down until I install disks; I have some Intel SSDs installed and I guess this is the cause for the spin-up.

 

[StevenOnTheRocks]

Just chiming in here: I've dumped the strings off of the MD1000 FW binary as well, and it seems like the relevant commands should be available on that one too.

Set P/S Module Fan Speed: set_speed <l(eft)/r(ight)><speed code 1..15>
   set encl temp: set_temp <sensor><temp>( -55 to 125 degrees C)
  Set P/S Module Fan Speed Threshold: set_thres <l(eft)/r(ight)><speed code 0..15>

 

[StevenOnTheRocks]

Reporting some more: I had a go at the MD1000 physically, and the pinout seems to be the same, though it uses 9600 baud 8-N-1 instead of the MD1200's 38.4k. Additionally, the magic keyword isn't 'devils', but rather 'pompano'.

A.03_WD.0:0010>
broadcast   Send Broadcast SES Message: broadcast
clear_eel   Clear Event Error Log: clear_eel
dbs         Database Read  : dbs  <page>
eeprom_dump EEprom Dump: eeprom_dump <port ID> <twi address><size in K(1,2,4,8,..512>
eeprom_zero EEprom Zero: eeprom_zero <port ID> <twi address><size in K(1,2,4,8,..512>
exp_rd8     Expander 8 Bit Read Access: exp_rd8 <Expander #> <Register>
exp_rd32    Expander 32 Bit Read Access: exp_rd32 <Expander #> <Register>
exp_wr8     Expander 8 Bit Write Access: exp_wr <Expander #> <Register> <1 byte>
exp_wr32    Expander 32 Bit Write Access: exp_wr <Expander #> <Register> <32bit word>
exp_debug   exp_debug [w|r] Debug the expander by corrupting the next CRC
fpga_rd     FPGA Access: fpga_rd <Register> <#bytes>
fpga_wr     FPGA Access: fpga_wr <Register> <data>[<Register> <data> ...]
fru_display Display data in FRU structure: fru_display [0-SIM0, 1-SIM1, 2-PB, 3-PS0, 4-PS1]
fru_init    Load Default Fru: fru_init [0-SIM0, 1-SIM1, 2-PB, 3-PS0, 4-PS1]
fru_fix     Fix the Cross Check: fru_fix
fru_read    Read Fru: fru_read [0-SIM0, 1-SIM1, 2-PB, 3-PS0, 4-PS1]
get_time    get encl time: get_time
gpio_rd     Read a GPIO: gpio_rd <number>
heart_beat  SIM Heartbeat Control: heart_beat [on/off] <timeout in seconds>
l4_test     L4 integration manufacturing diag: l4_test
lm75_rd     LM75 Read Access: lm75_rd <Slave Address> <Register>
lm75_wr     LM75 Write Access: lm75_wr <Slave Address> <Register> <1 byte>
log_ipmi    Log an IPMI Event:log_ipmi<Code><Type><Sensor><EV0><EV1><EV2><EV3>
ne1617      NE1617 Read: ne1617 <l(eft)/r(ight)>
pompano     Menu of commands
page_a      Display drive SAS Address: page_a
ps_status   Get P/S Module Status: ps_status <l(eft)/r(ight)>
prompt      Prompt on/off
quick_test  Quick Board Test: quick_test
rd_8        8-bit Read: rd_8   <address> <# of 8 bit words>
rd_16       16-bit Read: rd_16  <address> <# of 16 bit words>
rd_32       32-bit Read: rd_32  <address> <# of 32 bit words>
reset       Reset MIPS
reset_other_sim Reset other SIM using GPIO
rev         SIM Firmware and Diagnogstic Revision
save_log    Force the saving of NV Log: save_log
scratch_pad Display Location of Memory Test Area: scratch_pad
serial#     Set or Display Serial Number: serial# {setvalue}
ses_page    Display SES Page: ses_page <page><buffer size>
set_boot    Set boot partition r/w flag
set_loop    Global Loop Counter: set_loop {gLoopCount}
set_speed   Set P/S Module Fan Speed: set_speed <l(eft)/r(ight)><speed code 1..15>
set_temp    set encl temp: set_temp <sensor><temp>( -55 to 125 degrees C)
set_thres   Set P/S Module Fan Speed Threshold: set_thres <l(eft)/r(ight)><speed code 0..15>
smcl_rd     SMC Access: smcl_rd <Register> <#32 bit words>
smcl_wr     SMC Access: smcl_wr <Register> <data>[<Register> <data> ...]
twi_dis     TWI device discovery: twi_dis
twi_rd      TWI device byte read: twi_rd <port ID> <address> <# of bytes - 8 max>
twi_stats   Dump twi statistics: twi_stats [clear]
twi_wr      TWI device byte write: twi_wr <port ID> <address> {8 bytes max}
twi_wr_rd   TWI device wr/rd: twi_wr_rd <port ID> <address> <#read bytes> <write data>
wd_test     Test Watchdog: wd_test - This will throw an assert and never return!!!
wr_8        8-bit Write: wr_8  <address> <data> [<address> <data> ...]
wr_16       16-bit Write: wr_16 <address> <data> [<address> <data> ...]
wr_32       32-bit Write: wr_32 <address> <data> [<address> <data> ...]
heart_beat_high   Write HB value: <0 - Emulation; 1 - Test Failover>
drive_led   Write drive led: <logicaldrive> <data>
shelf_led   Write shelf led: <data> <0 - Disable; 1 - Enable>
noise       Write audible alarm: <data>
isim_debug   Change or view isim stats: <data> <0 - Disable; 1 - Enable>
A.03_WD.0:0011>

Edit: Not sure if this is intended behaviour, but set_speed only works for maybe 10 seconds, after that the fans revert to whatever speed the EMM thinks they should be at (ps_status reports "fan speed invalid") . I'm wondering if the solution here would be a little dongle with an MCU that sends `set_speed l 2\nset_speed r 2\n` every so often... Or a script server-side that does it over a USB-serial adapter.

 

[StraFFeR]

Hello guys, little off-topic - week ago i became happy owner of sc200 - also i bought 2 lsi 9200-8e based IT flashed cards for it. Initialy i thought that its possible to use it in High availability mode 1 controller goes down second one takes over.
Thats what i found on SC8000 manual:



based on this i still believe HA mode is possible - but maybe my 2 port cards could be a problem.
Thinking other way second SC200 controller is only used with SAS drives maybe i could use 1 port each controller to connect to 1st SC200 controller and other controller ports to connect each other to be as close to dell design as possible?

Or maybe theres some sort of command to send to 2 controller to take over.

Does anyone here have any sort of experience doing such configuration?