Flash/Crossflash DELL H330 RAID Card to HBA330/12Gbps HBA IT Firmware
- Thread starter Sleyk
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
Hi, Many thanks to Sleyk. Followed the process and resulted in a HBA330!.
Has anyone noticed that their DELL LFM now spins the fans up to a higher speed than before? I tested this by removing the card and the system fans dropped to a slower speed than with the card in. It is still detected as a Dell card when checked using RACADM:
get system.PCIESlotLFM.4
Security Alert: Certificate is invalid - Certificate is not signed by Trusted Third Party
Continuing execution. Use -S option for racadm to stop execution on certificate-related errors.
[Key=system.Embedded.1#PCIeSlotLFM.4]
#3rdPartyCard=No
#CardType=NonRAID
CustomLFM=0
LFMMode=Automatic
#MaxLFM=380
#PCIeInletTemperature=27
#SlotState=Defined
#TargetLFM=Airflow Controlled
This was within a T440
I noticed that there is an updated firmware for the HBA330 on the Dell support site (Version 16.17.00.05, A07). Are these cross-flashed cards upgradeable using the standard Dell tools, or does a similar manual approach need to be employed? (However, the release notes don't suggest this firmware fixes my issue with Fan levels).
TIA
Has anyone noticed that their DELL LFM now spins the fans up to a higher speed than before? I tested this by removing the card and the system fans dropped to a slower speed than with the card in. It is still detected as a Dell card when checked using RACADM:
get system.PCIESlotLFM.4
Security Alert: Certificate is invalid - Certificate is not signed by Trusted Third Party
Continuing execution. Use -S option for racadm to stop execution on certificate-related errors.
[Key=system.Embedded.1#PCIeSlotLFM.4]
#3rdPartyCard=No
#CardType=NonRAID
CustomLFM=0
LFMMode=Automatic
#MaxLFM=380
#PCIeInletTemperature=27
#SlotState=Defined
#TargetLFM=Airflow Controlled
This was within a T440
I noticed that there is an updated firmware for the HBA330 on the Dell support site (Version 16.17.00.05, A07). Are these cross-flashed cards upgradeable using the standard Dell tools, or does a similar manual approach need to be employed? (However, the release notes don't suggest this firmware fixes my issue with Fan levels).
TIA
Last edited:
An update to this, after some additional reading, I found that it was not the adapter causing the Dell LFM to spin up the fans, it was the HDDs plugged into the backplane. They are not Dell drives, and I suspect they cause LFM to spin up. For now, I am not going to update the adapter firmware, however it would be good to know if it can be if the need arises in the future.
Regards,
Ah yes, thanks for that! I will go check out the updated firmware files and tinker and report back
Also, Welcome to STH my friend!
Also, if the firmware is usable, (as it should be) its just a matter of unpacking the updated firmware and bios files and flashing the firmware with sas3flsh. I will include here once done testing it out.
You could, however, use the Windows Dell tools to flash with Windows as the tools will recognize the card the same as an HBA330. I personally prefer sas3flsh for completeness though.
You could, however, use the Windows Dell tools to flash with Windows as the tools will recognize the card the same as an HBA330. I personally prefer sas3flsh for completeness though.
Last edited:
Ok, so unpacked latest firmware (16.17.00.05) and was able to successfully update with no problems.
I just downloaded the Redhat Linux bin file zip and used 7zip to unpack the "payload" folder. It has the firmware and bios files.
I just renamed it to match the same instructions: hba330.fw and mptx64.rom.
I will include a zip file here in case anyone wants to upgrade to latest HBA330 firmware and Bios as well. Same as instructions in first posts, just place on flash drive, and boot to freedos and flash using sas3flsh.
Seems like Dell made some small improvements in the latest firmware, and they fixed little errors here and there. I don't think its super urgent to upgrade, but meh, why not?
Its also very possible to upgrade in Windows using the Dell tools as well, so no harm to try it if you prefer not to use sas3flsh this time.
Also, if you use sas3flsh to upgrade from 16.17.00.03 to 16.17.00.05, you can directly upgrade. No need to save your sas address again, or clear the nvdata or anything, as it will just update the firmware and leave the sas address and mfg pages intact.
Same as in initial instructions: sas3flsh -o -f hba330.fw -b mptx64.rom
I just downloaded the Redhat Linux bin file zip and used 7zip to unpack the "payload" folder. It has the firmware and bios files.
I just renamed it to match the same instructions: hba330.fw and mptx64.rom.
I will include a zip file here in case anyone wants to upgrade to latest HBA330 firmware and Bios as well. Same as instructions in first posts, just place on flash drive, and boot to freedos and flash using sas3flsh.
Seems like Dell made some small improvements in the latest firmware, and they fixed little errors here and there. I don't think its super urgent to upgrade, but meh, why not?
Its also very possible to upgrade in Windows using the Dell tools as well, so no harm to try it if you prefer not to use sas3flsh this time.
Also, if you use sas3flsh to upgrade from 16.17.00.03 to 16.17.00.05, you can directly upgrade. No need to save your sas address again, or clear the nvdata or anything, as it will just update the firmware and leave the sas address and mfg pages intact.
Same as in initial instructions: sas3flsh -o -f hba330.fw -b mptx64.rom
Well, i honestly haven't played around with the H330 mini adapters, but in theory, the process should be the same.
If you have a dell system with a h330 mini adapter inside, and willing to flash, i would work with you to figure it out. If anything goes wrong, i can even help you replace it, since they are pretty cheap on eBay.
Steps: (please refer to same as instructions for H330 card)
0. Save the card info either with perccli in windows, or with megacli in dos using freedos (sas address, serial number etc.).
1. Load freedos and flash the smc3108 rom using megacli, then reboot.
2. Wait for bios to enumerate the mini adapter with "baseport not responding" message. Remember, this should take about 3 minutes, then it should boot to freedos.
3. When booted back in freedos, use megarec to write the sbrempty.bin file, then use megarec again to clean the flash directly after.
4. Reboot, then use sas3flsh to flash the latest hba330 MINI firmware. (Dont use the hba330 hba adapter firmware on the mini card, it must be the mini adapter firmware, as im unclear how close the 2 interweave, and could result in a brick.)
5. Program your sas address and done.
Im about 90% sure the same steps for the H330 card should work for the H330 mini. If you have that setup, give it a try! I confess i don't have a dell setup, so i don't have access to a dell h330 mini to test myself. Let me know how it goes!
Haha okie. Well just let do this. I still have warranty from dell so just play it
)
HOLD ON....
If the 13th gen mini monolithic is anything like the 12th gen that I figured out how to flash, erasing the SBR is going to brick your card. At least with 12th gen, the Dell system will disable the PCIe slot if the PCI subsystem id is not correct and you will not be able to boot your system unless you remove the "empty sbr" card.
at the very least, get yourself a EEPROM programmer and save the contents of the SBR EEPROM before you start doing this.
I definitely understand you BL. Ultimately, Dell systems can be alittle tricky. Plus i certainly trust you on your experience with them.
I wonder if you can pre-empt this issue by disabling the "pci slot" the card uses? By this, i mean disabling the option-rom in the dell bios. This is what i mentioned in a previous post regarding dell systems. Can someone confirm if this is an option in the dell bios? If so, it may very well be possible.
From my limited amount of testing these dell cards, it seems that as long as the firmware on the card is not locked to the specific pci slot the card uses, you can ultimately make the card temporarily "invisible" to the bios. This is essentially the hallmark of flashing the h330. Since the bios doesn't "see" the correct card, it ultimately gives up.
However, the characteristics of the 13th gen minis do concern me
Thus, if i had a dell setup, i would gladly test it out, but i sadly don't right now. I am willing to grab a cheap one to test if anyone can refer to a listing on eBay or something where i can pick up one that holds one of these mini adapters. I will start looking now.
Essentially, i dont mind losing a whole system to figure out something as valuable as flashing a card or adapter like this, as the beneficial use of this will help many. Far more than the cost of a single dell system.
Further, i would actually still endorse the idea to attempt to flash the mini in spite of everything if i knew it was super easy to remove the card from the system, as i would have zero problems replacing the adapter if it fails. Those bad boys are fairly cheap on eBay, but i think its kinda hard to remove from your setup? Not sure myself, as again, i dont have a dell setup to tinker yet.
However, i do agree with BL's post. Best to hold off for now. If i do get a system to test, i will do it and report back. I don't mind the dirty work
I can share with you guys my experience with the 12th gen PowerEdge stuff, but I honestly don't know about the 13th gen. However, if history is any indicator, the method Dell uses to "lock" the cards is basically the same in the 12th gen as it was in the 11th gen, so it is very likely same for 13th gen as well. I've mentioned this in several of my YouTube videos on this topic, but the short version is that Dell basically checks the PCI subsystem ids for vendor and product, call them subsystem VID and PID. This information is stored in the SBR. As long as you have acceptable values for the subsystem VID/PID, the card will be accepted - and this is *independent* of the firmware (LSI or Dell). However, the catch is that the firmware will not operate correctly if you don't have the correct SBR it needs, but fortunately, LSI firmware doesn't care that much about the subsystem VID/PID, so we can make it so that the LSI firmware will run with "custom" subsystem VID/PID. This key piece of information is at the center of getting LSI firmware to run in the 11th gen integrated storage PCIe slots, as well as the 12th gen mini monolithic slots.I definitely understand you BL. Ultimately, Dell systems can be alittle tricky. Plus i certainly trust you on your experience with them.
I wonder if you can pre-empt this issue by disabling the "pci slot" the card uses? By this, i mean disabling the option-rom in the dell bios. This is what i mentioned in a previous post regarding dell systems. Can someone confirm if this is an option in the dell bios? If so, it may very well be possible.
From my limited amount of testing these dell cards, it seems that as long as the firmware on the card is not locked to the specific pci slot the card uses, you can ultimately make the card temporarily "invisible" to the bios. This is essentially the hallmark of flashing the h330. Since the bios doesn't "see" the correct card, it ultimately gives up.
However, the characteristics of the 13th gen minis do concern me
Thus, if i had a dell setup, i would gladly test it out, but i sadly don't right now. I am willing to grab a cheap one to test if anyone can refer to a listing on eBay or something where i can pick up one that holds one of these mini adapters. I will start looking now.
Essentially, i dont mind losing a whole system to figure out something as valuable as flashing a card or adapter like this, as the beneficial use of this will help many. Far more than the cost of a single dell system.
Further, i would actually still endorse the idea to attempt to flash the mini in spite of everything if i knew it was super easy to remove the card from the system, as i would have zero problems replacing the adapter if it fails. Those bad boys are fairly cheap on eBay, but i think its kinda hard to remove from your setup? Not sure myself, as again, i dont have a dell setup to tinker yet.
However, i do agree with BL's post. Best to hold off for now. If i do get a system to test, i will do it and report back. I don't mind the dirty work
So, if anyone wants to start experimenting, I would suggest first identify the SBR EEPROM chip on the card, and save a copy of it. If history repeats itself, it's likely a 8K EEPROM that you can communicate via I2C. I would start by analyzing the SBR and decoding the structure and compare with other LSI SAS3008 SBRs. Primarily, if you know the PCI id sections, and the checksum, you can manipulate it and fix the checksum.
Some of you might be thinking, "wait, many of us have used this empty.sbr file to cross flash and that's always worked"... so here's why that works for normal PCIe cards, and not for these "mini monolithic" slots... the empty.sbr file is basically 256 bytes of 0x00. When you write this SBR, it essentially erases the SBR EEPROM. The card does not operate correctly in this way, HOWEVER, almost all the LSI firmware I've messed with have a special "recovery" routine when it boots up... if it finds the SBR to be all 0x00, it will attempt to fix it and write the necessary SBR content. This is why the first time you boot the firmware after a cross flash with an empty SBR, it usually takes a few seconds longer than the next boot, those extra seconds are for running the "SBR recovery" routine and that's why the SBR is no longer empty after the first boot. That's why the empty.sbr thing works. Now, the problem with the Dell "mini monolithic" is that Dell motherboard (BIOS firmware?) checks the SBR during POST, and if it finds something not on the whitelist, it stops the POST process with an error message on screen. So, if you write the empty.sbr, and then reboot the system, it will not boot since 0x0000 is not on the whitelist. This is how many people have "bricked" their H310 mini monolithic cards in the past. You can recover (as I've shown in a video on my YouTube channel) from this, so it's not a permanent "bricking", by basically fixing the SBR externally by writing to the EEPROM chip directly. So, that's why using the empty.sbr doesn't work for the mini monolithic cards (at least with 12th gen). And that's also why I say save the EEPROM content, because that's the way to recovery without buying tons of cards to throw away at each trial. I bricked the H710 mini cards about 2 dozen times or more before I figured out how to cross flash that... and I recovered each time by fixing the SBR EEPROM back.
Like @Sleyk , i would gladly investigate this further myself, but I need a 13th gen Dell system. but frankly, too busy at the moment, not to mention I'm still trying to understand's @Sleyk's method for the H330 in this thread. lol @Sleyk BTW, I did finally pickup a few H330 cards and will be experimenting with them thanks to your courageous thread here....
Hey BL, thanks for that excellent explanation on the SBR and programming the eeprom. Significant wisdom from a pro passed down! Truly, thanks for taking the time to explain that. Its greatly appreciated. I didn't personally have to touch the eeprom myself for the H330, but I did consider saving the SBR as a safeguard against flashing back to stock Dell rom, but then I realized no one would want to go back, but yeah, still no harm to save it.
I will definitely pay attention to the SBR and bios booting process when I do obtain a 13th gen, as I know Dell can be fickle with their servers sometimes. Will let you know how it goes. I want to test out for completeness sake and will report back as soon as complete.
Also, I'm glad you picked up a few H330's! You'll see how easy it is to flash over to an HBA330. Dell did confirm to me a while back that the firmware is basically LSI with their spin on things. The latest firmware update looks great as well.
I tried to flash a HBA330 to H330 (I need HW RAID but wrong controller was ordered...) but did not succeed.
Flashed the H330 firmware using megarec3 -m0flash FW0009i.rom. After reboot, RAID BIOS appeared, waiting forever for the controller to start.
Unfortunately, this card has no "safe mode" jumper to disable flash access. But there's a solution: look at the flash on the back side of the card (S29GL128S10TFIV2 on mine), find R1066 (not populated) and R1079 (populated) resistors near the lower right corner of the flash. Their joint is connected to flash A1 pin. Power off, ground this point through a 10 ohm resistor and power on - no BIOS should appear, boot to DOS, disconnect resistor and use sas3flsh to recover (unbrick).
Flashed the H330 firmware using megarec3 -m0flash FW0009i.rom. After reboot, RAID BIOS appeared, waiting forever for the controller to start.
Unfortunately, this card has no "safe mode" jumper to disable flash access. But there's a solution: look at the flash on the back side of the card (S29GL128S10TFIV2 on mine), find R1066 (not populated) and R1079 (populated) resistors near the lower right corner of the flash. Their joint is connected to flash A1 pin. Power off, ground this point through a 10 ohm resistor and power on - no BIOS should appear, boot to DOS, disconnect resistor and use sas3flsh to recover (unbrick).
The H330 firmware seems to be iMR, not iR. So I probably need a H330 SBR for the firmware to start. Here's a nice analysis of (older) SAS2008 SBR:
Crossflashing the Fujitsu D2607
There's a "Interface mode" byte which must be changed. Unfortunately, SAS3008 SBR structure is different (PCI IDs are at different positions) and I can't find any dump from H330.
Then there's the PCI subsystem ID problem - HBA330 has 1028:1f45 but H330 should have 1028:1f44.
I was flashing a M1015 to LSI 9220-8i before. Even after changing the SBR, PCI subsystem IDs stills showed M1015. Finally, found that MegaSCU can change the subsystem IDs: "MegaSCU -AdpFactorySettings -SetPCIData -f pci.ini -a0"
pci.ini:
Unfortunately, the old MegaSCU does not work on SAS3008. Also MegaOEM does not work for me.
Crossflashing the Fujitsu D2607
There's a "Interface mode" byte which must be changed. Unfortunately, SAS3008 SBR structure is different (PCI IDs are at different positions) and I can't find any dump from H330.
Then there's the PCI subsystem ID problem - HBA330 has 1028:1f45 but H330 should have 1028:1f44.
I was flashing a M1015 to LSI 9220-8i before. Even after changing the SBR, PCI subsystem IDs stills showed M1015. Finally, found that MegaSCU can change the subsystem IDs: "MegaSCU -AdpFactorySettings -SetPCIData -f pci.ini -a0"
pci.ini:
Code:
[GEN2_INI_FILE]
[PCIDATA]
VENDORID=1000
DEVICEID=0073
SUBVENDORID=1000
SUBDEVICEID=92a0Welcome to STH brother! We're glad to have you!
So i read your post, and i must say, you are certainly the first guy i know of, that deliberately wants to go from hba firmware to the dell proprietary firmware rom.
However, this is not a bad thing, as i know people have various reasons as to why they would need to use the dell rom instead of hba firmware, as you pointed out.
Of note, the H330 does have a "sort of" hardware raid, but not really. It's literally just the LSI/Avago SAS3008 chip that works along with the dell rom to give you a "sorta, kinda" type of raid. Honestly, the h330 is really just a "pumped up" software raid card with a "dell-ified" flare. I mean, it works, but if you needed true hardware raid, then you would need a minimum of a H730/H730p and above. Those cards come with a proper onboard raid chip and battery backed cache. I personally recommend the H730p. It has 2GB of battery backed cache as opposed to the H730's 1GB of cache. Let me know if you need one, as i have a spare one i can sell you at a discount. (Sorry for the shameless plug)
Now, with that being said, there IS a way to crossflash from a hba330 to a h330. I have done it before, as i specified this in my full writeup, but it is somewhat risky.
I have found however, that in my testing of these cards, they are easily recoverable from bricks if you happen to brick it, so the risk is somewhat mitigated. Thank goodness for Megarec3
Now, i personally dont like to mess with the physical electrical components of a card to flash it unless absolutely necessary. I try to find alternate software methods of bypassing and defeating the flash on these oem cards that they use with their proprietary firmware roms. I do acknowledge that sometimes you do need to use a physical electrical bypass though, depending on how bad the firmware/nvram is corrupted.
A simple trick you could have used was to disable the pci option-rom in your motherboard bios for the specified slot. This would have allowed the pc to boot past the corrupted firmware rom and boot straight to freedos. The dell rom halts the boot process like a liitle bitch if it cant find a stable firmware on the adapter. This is bypassed by disabling the option for the card to do that. Depends on if you have that option in your bios though. Supermicro boards usually have the option in their bios, that's why i flash all my cards with supermicro boards only. Most newer motherboards may have the option hidden. So when you turn off the option-rom for the specific slot, the pc just ignores the hell out of the slot and keeps on booting. This should allow you to boot back to freedos to flash back to a hba330 using megarec3 and sas3flsh. Once done, turn the option rom back on, and your good to go. No need to ground with a resistor or anything.
Now, if you had to make another go at it, try these few tips:
1. For the initial flash back, use megacli. It appears that megacli is more compatible with the dell rom than megarec3 is. It would seem that dell modelled their proprietary "perccli" utility off of storcli, which is just a "newer" megacli. This is why the flash process from h330 to hba330 works well. Megarec is more like a recover and "rinse clean" sort of utility. You could use megarec though, but its probably better to write the sbr and just clean the flash with megarec, then use megacli to flash back the dell proprietary rom. Then use megaoem to set the firmware to default settings and program the sas address. This method might still have some small issues, but its worth a try.
For example, try this:
1. Megarec3 -cleanflash 0 (get rid of the hba330 firmware)
2. Reboot.
3. Megarec3 -writesbr 0 h330sbr.bin (write the h330sbr.bin file to nvram)
4. Megacli -adpfwflash -f fw0005i noverchk nosigchk -a0 (flash the proprietary dell rom)
Alternatively, Megacli also lets you flash to the m0 area of the card. You could try:
Megacli -adpm0flash -f fw0005i.rom
5. Megaoem -adpfacdefset -a0 (sets the dell proprietary rom firmware settings to factory defaults)
6. Megaoem -adpsetsasa xxxxxxxxxxxxxxxx -a0 (set your sas address where the x's = your sas address)
7. Then use the Megacli utility again to see if it worked: Megacli -adpallinfo -a0
Or see if sas3flsh still recognizes the card. sas3flsh -list (It shouldn't recognize it if you were successful, as the card is now a H330 again)
2. You can also follow my instructions in the full write up to revert back, but i sometimes ended up stuck in the crossflash back to an H330. This is because you initially defeat the dell rom and erase key components of the firmware stored in the nvram on the card from the dell proprietary rom. Remember, the H330 rom was initially flashed on the card first. No biggie if you were going from an h330 to an hba330, but its the reason its kinda difficult to go back to a h330 from a hba330. Same reasons apply, as the HBA330 firmware was initially flashed into the nvram first. So now it takes a different method to flash over to a H330 from an initial factory HBA330. Hope that makes sense!
If it doesnt, here is a little side explanation from a very good dell tech, for added info: You might say then, "How does Dell and the other oems's do it? They can flash back and forth." Well, as i understand it, when these cards are initially manufactured, the flash is empty of course. On first power on, we load an "initial" megaraid firmware that determines if we want an h330 or hba330. When you get the card, it is then that you now have the issue of trying to convert from one to the other. Dell of course doesn't have that problem. We will just make whatever we want. Since you are the ones trying to modify the firmware, you have to defeat the nvram safeguards the card uses to protect itself. If Dell receives a corrupted card under warranty or something, our techs have a few more options. They can try to restore the flash with a bypass eeprom/flash method, or a software flash restore/clean with a utility like megarec or perccli or storcli or other software. Or we can simply do what most manufacturers do and just solder on a new flash chip.
3. Try the older fw0005i firmware (25.5.5.000) to flash back instead of the newer firmware. Its possible the newer firmware wont work. I was afraid of this, and it is entirely possible that dell might have changed some things in the newer fw0009i firmware they just released to make it harder to flash back and forth. If you check my included flash folder download in the earlier posts, there should be a folder with the dell rom, with a file labelled fw0005i. If not, there should be a file I relabelled as "fw19.rom" somewhere in the flash folder, which is an even older version of the dell h330 proprietary rom. Let me know if you dont see it, and i can upload it here in a zip file, or modify my google drive download folder and add it.
4. I have a modified version of the h330sbr.bin file that i was messing around with, but not a clean one, but it should still be usable. I will get a clean h330sbr.bin file and upload it once i get my hands on one again. For now, you can experiment and try to flash with the modified h330sbr.bin file i will upload. If you wanna wait a 'lil bit, i will get my hands on a clean H330 sbr.bin file again soon.
Try some of these things to see if it helps you go to a h330 from an hba330. Let us know how it goes! I had stopped testing on my cards to go back to the h330 rom, as i didn't think we would really need it, but i suppose i should keep testing and perfect the process both ways for completeness sake.
Last edited:
Just bought a card that looks like the 4Y5H1 but the DP/N number is 05H1G0, can this one be flashed? (The model number is UCSA-901 and the seller said it's a h330)
Also sadly i didn't get a low profile bracket and would like to get one, is there suitable ones available? (Searching "lsi low profile" on ebay finds some brackets for around a dollar wonder if any of them fit.)
Also sadly i didn't get a low profile bracket and would like to get one, is there suitable ones available? (Searching "lsi low profile" on ebay finds some brackets for around a dollar wonder if any of them fit.)
Hey brother, thanks for joining STH :.)
Yup, as long as the model number is ucsa-901 it should be fine to flash. Can you do me a favor? Can you take a pic and upload to imgur and post the link? I haven't come across that specific part number. I would like to see what it looks like.
For a low profile bracket, you can grab a cheap $0.99 cent one from china or you can get one from the states. Of note, any 6gb sas low profile bracket will fit as well if you don't wanna wait to get it from China.
This is where I got my low profile bracket: Low Bracket for LSI 9300-8i,9361-4i,9361-8i,LSI00344 12GB HBA SFF-8643 713752005673 | eBay
Yup, as long as the model number is ucsa-901 it should be fine to flash. Can you do me a favor? Can you take a pic and upload to imgur and post the link? I haven't come across that specific part number. I would like to see what it looks like.
For a low profile bracket, you can grab a cheap $0.99 cent one from china or you can get one from the states. Of note, any 6gb sas low profile bracket will fit as well if you don't wanna wait to get it from China.
This is where I got my low profile bracket: Low Bracket for LSI 9300-8i,9361-4i,9361-8i,LSI00344 12GB HBA SFF-8643 713752005673 | eBay