reading SBR from 2208 shows the data to be offset by a few bytes

[ezonakiusagi]

I know this lsirec tool was not intended to be used with LSI SAS2208 chipset, but since there are lots of similarities between 2008/2108 and the 2208/2308, i tried using lsirec to read the SBR off a 2208 card. The tool complained that there were 2 different copies and it chose to use the 1st one. When I used your 'sbrtool parse' command to read the SBR, all the segments looked wrong. But when I looked closer, I found that everything was offset by a few bytes, .e.g, i found the 0x0107 for PCI device type, but it was not where it should be located.

I haven't read your code to see how you are reading the SBR, but do you know what might cause this?

[marcan]

So two things. One, you should make sure to ./lsirec 0000:01:00.0 halt before reading the SBR, as I found that the MegaRAID firmware will try to use the I2C bus and mess things up. If that's not the issue though, it's entirely possible that these cards use a slightly different SBR format.

[ezonakiusagi]

just as follow up on this. i have now discovered that LSI 2208 and 2308 chipsets can both have either 256B or 512B SBRs, often depending on the chip revision and whether the chip supports PCIe 2.0 vs 3.0. the formats are similar, but different and have completely different offsets for the various PCI id values.

to support writing 512B SBR should be simple, since you just get the size of the SBR file and adjust the buffer and write the size of the buffer. reading SBRs might be a little tricky. you could choose to always read 512B, then check bytes 0x100-0x1FF to see if they are just padding. but I've found both 0x00 and 0xFF padding patterns, not sure why that is. if interested, i can contribute this kind of change.

[strongholdmedia]

Those are not "padding bytes" but the presumed place of the SAS address. 0xFF means uninitialized. But it seems not all firmware use them. If one doesn't, the area is filled with 0x00. You should keep in mind that other firmware, however, may use it if you plan crossflashing. If so, you will need the address checksum to match (or set them to 0xFF, that is, uninitialized).

[strongholdmedia]

To add further to the confusion, I have dumps that have second copy at 0x80, others at 0xe0..

[Fohdeesha]

@marcan How can I help to solve this so lsirec will work with 2208 cards? namely the Dell H710, there is lately a lot of demand to flash these to IT mode, and someone on ebay is making a lot of money selling them flashed over to IT mode and keeping his method a secret (probably just using an EEPROM reader/writer, or a patched version of lsirec). Would dumps of the H710 eeprom (a 2208 based card) help? Perhaps a cash donation?

[Fohdeesha]

I could also provide a dump of a stock dell H710, and an H710 from ebay that has been cross flashed to IT mode, so we could diff them and see which offsets have been modified to result in the new PCI vendor data

[strongholdmedia]

2208 - yes, H710 - no. Dell cards have two eeproms on it plus the flash. These eeproms have write protect ability on them. You cannot just power the chip as the bootloader starts and blocks it from being written, by driving pin 7 high, when there is firmware (any) on it (including bootloader).

You can erase the firmware but then it won't be flashable by the sasflash, only lsi_rec, and that is bad, as there is no lsi_rec format firmware available. Also, Dell servers won't boot in this state.

There could be a method if one could patch the kernel driver to recognize and bootstrap recovery mode devices during boot. All my attempts failed to do this after the system booted.

Plus you have to calculate Dell-specific CRC. If you can do this, you may be able to use linux/solaris sas2flash utility, or may reverse the EFI utility (but EFI reversing is quite annoying with radare2, so YMMV). Because these look for the official CRC, not the Dell one. If any of these are done, you anyhow need two working cards at the same time for this. You will need to reboot into EFI after erasing the flash, something you cannot do with mismatched (non-Dell) ID.

Basically, you need to power both cards, then hot-swap them back and forth while keeping the power attached to both of them. I managed to put one card into "degraded 4x" mode with this sadly.

Since then, though, I do not have any servers nor cards to work with these ATM.

[strongholdmedia]

This took over a week of my time for two items, and in all seriousness, I did contemplate creating a PCIE adapter for the socket, were I to find the pinout.

[Fohdeesha]

Looks like it should be the same as our Dell h310 crossflash guide, the Dell crcs were not an issue there, the only issue is the new offsets. An sth forum member has already figured those out, we are going to do some testing tonight, but in general we've already been using lsirec to crossflash Dell mini cards, the only difference with the h710 is the changed offsets (double sbr size) https://forums.servethehome.com/index.php?threads/perc-h710-mini-to-it-mode.25448/#post-249878

The person that originally opened this ticket also fixed the new offsets in lsirec, kept them a secret (did not contribute back to the project) and has been using it to make money crossflashing h710s and selling them on eBay (you can see if you search eBay for H710 IT). There's also at least one other person (in Bulgaria) using lsirec with patched offsets to sell crossflashed H710s on ebay

[Fohdeesha]

Our H310 guide, for reference: https://doku.phoxden.net/plugins/servlet/mobile?contentId=7208964#content/view/7208964

[strongholdmedia]

I don't remember fixing offsets in the lsirec though. I only remember hacking the flash utility. I went with the EFI one because I did not have the patience for consecutive boot times (much slower when no SBR). I am, however, sure that I could not make the DOS one to do what I wanted.

[strongholdmedia]

Had to write my thesis, and will have grad exam tomorrow; as such, this whole ordeal has been forgotten, thanks for remindig me anyway.

[Fohdeesha]

For starters, it looks like lsirec isn't even dumping the whole SBR for D1 revision cards (I realize this was covered above a long time ago, but just writing out my thought process) (9207-8i, SAS2308, Dell H710 Mini (5CT6D), etc), so that's the first issue. These cards SBR is 512 bytes instead of 256. Thankfully MegaRec properly dumps the whole thing. You can see the two attached dumps of a stock Dell 5CT6D, and how lsirec is missing half of it.

For pre-D1 revision cards (like B0) (eg the PCIe 2.0 variants, 9205-8E, SAS2208, Dell H710 Mini (MCR5X & FRH64)) the SBR is still 256 bytes, so lsirec at least dumps the whole thing

D1 dumps.zip

[Fohdeesha]

looking at the source it's quite obvious why it's reading/writing 256 bytes, this should be easy to fix (at least in a D1-specific repo, adding autodetection logic to support both card types in one will be more work):

static int do_readsbr(lsi_dev_t *d, const char *filename)
{
    uint8_t sbr[256];
    int ret;

[strongholdmedia]

That's not how I2C works. :) If reading another 0x100 bytes above the default 0x100 bytes yields 0xFFs, it is quite probable you have a 2Kbit eeprom, otherwise it is probably 4Kbit. I skipped that part for I have like 16384 different i2c EEPROM readers, and again, you cannot write EEPROM with anything firmware side without deprotecting the EEPROM first (after booting the card in non-recovery mode, that is).

The real issue, however, is not this. You cannot boot a Dell firmware with the non-Dell SBR, and the system doesn't boot with a non-Dell firmware. If the card does not have any firmware at boot, the PCIE subsystem and the driver won't initialize it so lsirec will not recognize it (neither) (creates no device node in /sys/bus/pci/blah).

Also, the signed firmware may only be written in regular mode (not recovery). You also have to ensure that the type value in the SBR is matching the module type, it won't work with a PCIE slot type.

[Fohdeesha]

I'm quite aware how i2c works, and I can now read/write the newer 512 byte SBRs with the above modification.

I 'm not sure why you keep saying it can't be written to, we have already done it using lsirec. I can paste the dumps of the sbr when I return home if you like. As I mentioned, two different people are doing it on eBay as well, for nearly a year now. There's no Dell signing on the sbr's, just the standard checksum, again we have already modified them and dell boots them just fine, you just have to maintain the sub vendor and product IDs. Check the h310 crossflashing guide I linked above for details. The system boots with the non-dell firmware (lsi IT mode firmware) perfectly fine, all it looks for is that the subvendor IDs in the sbr point to Dell. This post is literally being routed through an R720 with an h310 in the mini slot that was crossflashed with non Dell firmware. Boots great

[strongholdmedia]

I 'm not sure why you keep saying it can't be written to, we have already done it using lsirec. I can paste the dumps of the sbr when I return home if you like.

I have mines as well, thanks. After all, I am not saying it "can't be written to"; I wrote "is write protected by the firmware". That is, with firmware (i.e. without erasing flash), you may not even easily use EE programmer ICP (unlike desoldering, which may not be something you'd want to do routinely).

Also, while toying around with lsirec, I found that I could not write SBR with it without entering MPT mode (that is, erasing the flash) neither. Reading worked okay though.

As I mentioned, two different people are doing it on eBay as well, for nearly a year now.

But neither mention using lsirec, nor indeed any software for doing so, and that is for a reason.

There's no Dell signing on the sbr's, just the standard checksum, again we have already modified them and dell boots them just fine, you just have to maintain the sub vendor and product IDs.

The official LSI firmware is signed, not the SBR.. It also has partitions and stuff, and there were some partition mismatch issue if I remember well.

[Fohdeesha]

Actually one of the eBay listings not only mentions lsirec, but had it in their eBay screenshots. Just follow along the h310 crossflashing guide I linked above, our h710 method is identical except for modified sbr size and offsets. Everything else is the exact same

[strongholdmedia]

I doubt that. It is highly unlikely you could hostboot the h710 (or, indeed, any 2218) with 2118it.bin. Also, for me, the Sun/Linux lsiutil (the one mentioned) did not at all work with the h710 (firmware or otherwise). It did not even recognize that. Moreover, the SAS address is also at a different offset, and there is two of it.........

[Fohdeesha]

The h710 (d1 pcie 3.0 revision) gets flashed to 9207-8i, not 2118. No need to even bother with the SAS address manually, you leave it blank (0x00) in the SBR as recent firmware doesn't care, then you just use sas2flash to set the SAS address to what you want. No idea why lsiutil did not see your card, it has seen all of our testbed h710s without issue. Not sure why you have had so many issues, it's really quite simple. You can keep "doubting" all you want but it will be demonstrated and published very soon depending on my free time. I can even send you an example sbr to flash

[strongholdmedia]

The basis of my doubt is predominantly based on you having "blamed" others on not sharing their "solution" with everybody while yourself keeping talking about free time and stuff.

And also that I am fairly sure that I would not start reversing EFI bytecode with cutter as a routine weekend pastime until ascertainment of having been tried every probable permutation of whatever is written here, there, over there, and even on Russian sites.

Also, the "original ebay guy" mentioned something about hardware revisions. It may be possible that you had success with a different one.

[Fohdeesha]

We've had success on both h710 revisions. The "original eBay guy" has contacted me actually (he's also the OP of this GitHub issue), and he confirmed what we already knew: literally nothing you have said is correct or required, all that is needed is a modified SBR. He even offered to send me them. There has also never been signed dell or lsi firmware for these series of cards, you can drag the firmware into ghidra as I did and confirm that for yourself. Please stop bothering everyone subscribed to this issue with your ramblings, if you wish to keep telling me something both the OP and myself have already done is impossible, please just email me directly. I'm sorry you were never able to figure out how to modify an SBR properly, however that doesn't change the reality of the situation.

[Fohdeesha]

everything is much easier once you wipe the 16mb flash of anything dell: https://i.imgur.com/YqsmZ5m.png

we'll have a guide published in maybe a few days, we might try to streamline/script the process for dummies

[strongholdmedia]

We've had success on both h710 revisions.

Both of B1, C1, D1?

literally nothing you have said is correct or required, all that is needed is a modified SBR.

IF you are not BSing (at this point I don't have anything left to believe this) then maybe they weren't required for him.

He even offered to send me them.

Nice for you then.

There has also never been signed dell or lsi firmware for these series of cards, you can drag the firmware into ghidra as I did and confirm that for yourself.

You are so self-indulged, perhaps you could prove with ghidra or whatever that it is not needed. This is just BS.

Please stop bothering everyone subscribed to this issue with your ramblings, if you wish to keep telling me something both the OP and myself have already done is impossible, please just email me directly.

I don't know if you are dyslexic or anything, but I said literally nothing like this. (This is not the first time I realized you have serious text recognition problems, but until now I didn't say, because I tried to be polite. But your level of disrespect brought me to cease this.)

I'm sorry you were never able to figure out how to modify an SBR properly, however that doesn't change the reality of the situation.

Again, nobody wrote or said that.

I spent like 10 years in the GSM unlocking industry to have quite some experience in telling if someone is bullshitting about RCE / security / technology issues. Now that we stopped being polite, I have to tell that you are exactly this type.

Again, all I've written is how I did succeed doing the task you are bragging about, and how I did not. I also expressed that had I some time earlier, I would have been glad to help.

Again, to note, you are bragging about AoS could have been sending you modified SBRs - an offer you clearly rejected, since you have already been accomplished this very task, and you just need time to assemble your guide whatsoever.

If he finally ends up sending you his complete method in the background so that you can win your first argument ever on the Internet, please be a man and admit where you got your information from (provided they did not request you not to do so).

Finally, to reiterate, as a bottom line, for people having problems with understanding English text: all the above is my experience of the process. I am not wanting to deter anyone from attempting to accomplish this. I do not sell cards, nor work for Broadcom/LSI.

I just wanted to mention what obstacles I did end up having, while starting exactly the same way ("if anyone can do it, I can, too"). I do consider myself wise not proclaiming it up front, however (or, rather, at all, even in retrospect, provided that no script kiddie had been turning up to annoy me).

Meanwhile, please rest assured, as Dostoyevsky put it, "Talking nonsense is the sole privilege mankind possesses over the other organisms.". Who am I to deprive you of this foremost evolutionary achievement.

[Fohdeesha]

My lord, it took less time to find a method then it did for you to write that mess. All you have to do is use megarec or similar to zero the onboard flash, then you can use lsiutil or similar to hostboot IT firmware. It's that simple, I still do not understand why you're making such a big deal out of it, compared to the other crossflash guides I have published this was probably the simplest. The thread OP can confirm himself he did not send me any methods lmao. You literally stated "these will not boot without Dell firmware", got schooled, and are using word salad to backtrack. Our discord is getting a kick out of it to be fair

[strongholdmedia]

Definitely. Please come back with your guide. We eagerly await it.

[strongholdmedia]

For anybody else, I now checked - to avoid misleading others - and both of my cards are Rev. D1. I am unsure if it matters (but if @Fohdeesha makes sense, it probably would).

[Fohdeesha]

D1s are the pcie 3.0 capable units and require the 512byte SBR (and 9207-8i firmware), the others (C0 B0 etc) are the older pcie 2.0 rev and take a 256byte SBR and 9205-8E firmware, other than those differences the guides are the same. The SBR struct became obvious after looking at SBR rips from the two respective LSI cards, transplanting the Dell subvendor IDs and updating the checksums got us our SBRs. A couple days later the OP of this thread sent me his, and they matched, which was reassuring. The key is to use megarec or similar to zero out the cards entire 16mb onboard flash and reboot, otherwise with the dell firmware still present lsiutil can not hostboot the card properly. However after zeroing, you just use lsiutil to hostboot it, flash the lsi image, and you're done. My screenshot above is the result of following this process on a D1 h710 mini

[strongholdmedia]

The SBR struct became obvious after looking at SBR rips from the two respective LSI cards, transplanting the Dell subvendor IDs and updating the checksums got us our SBRs. A couple days later the OP of this thread sent me his, and they matched, which was reassuring.

This is true. But you cannot boot with the Dell firmware and such SBR, you cannot boot with the LSI firmware and the original SBR, and you cannot flash H710 (D1 at least) in recovery mode (with megarec), nor after hostbooting it. At least this was my mileage.

[strongholdmedia]

Also no version of sas2fl[a]sh wanted to flash it either. (But the EFI one at least recognized it.)

[strongholdmedia]

You could (probably) flash it with megarec, but you'd need a non-signed (okay, it may just be a checksum or call it what you want) non-partitioned image. For H310, that works because it has a TSSOP package (desolder and be done). H710 is BGA. You either JTAG, or.. ..resort to hacking.

[Fohdeesha]

EDIT: the full finished guide is here, use it instead of the below https://fohdeesha.com/docs/perc/

This is true. But you cannot boot with the Dell firmware and such SBR

You definitely can, that's exactly what we did. The only thing the lifecycle controller checks in the mini-raid slot before deciding to boot or no-boot are the subsystem PCI values. You can see these with lspci:

Subsystem:
[1028:1f38]

If those don't equal a known dell part, the server will indeed refuse to boot like you say, and your card is bricked. So if you blindly flashed over a 9207-8i SBR, you'd be screwed. That's why we took the 9207-8i SBR we needed for a successful crossflash, figured out the struct/location of the subsystem vendor/part IDs, and inserted the "allowed" dell values. So we now had an "LSI IT mode" SBR for a crossflash, but it retained the subsystem PCI values that dell looks for during boot. With this SBR, you can boot all day long. I've attached them in a zip.

Of course since data has been changed in the SBR, you need to update the checksum byte (the last byte in each duplicate copy). It's a really simple checksum (pretty much just addition of all the other bytes), but I'm lazy so I modified sbrtool.py to print the new checksum required, then we can just update the binary with the correct checksum byte:

root@testing:~/lsirec# python3.8 checksum-sbrtool.py parse D1-test.sbr stock.cfg
Checksum value from binary (decimal)
9
Proper Checksum (decimal, convert to hex before writing to binary):
37

I've attached this modified script in the zip as well. It probably needs python 3.5 or higher. I'm not a python guy, so it's probably pretty hacky, but it works.

So anyway, that's how we got valid "IT mode" SBRs that still allowed the server to boot. After that, it's really easy. Boot into freedos and write the new SBR with megarec, and wipe the dell firmware off the card:

megarec -cleanflash 0
megarec -writesbr 0 D1Modded.sbr

Now boot into linux, and use lsirec/lsiutil exactly like our H310 guide, to first boot the empty card from RAM, then once it's running IT mode firmware from RAM, you can use lsiutil to permanently flash the LSI IT mode firmware:

rmmod megaraid_sas
echo 16 > /proc/sys/vm/nr_hugepages

#note: depending on the server you're using, the PCI address used in the following commands 
#might be different. 
#It was 0000:01:00.0 on an R420, 0000:03:00.0 on an R720. 
#I'm sure you can figure out how to get the right address from lspci

lsirec/lsirec 0000:01:00.0 unbind
lsirec/lsirec 0000:01:00.0 halt
lsirec/lsirec 0000:01:00.0 hostboot 9207-8.bin

#the card is now up and running as an IT card, but from RAM
#rescan so the required mpt3sas driver rebinds to it
#then use LSIUTIL to flash the actual onboard flash
lsirec/lsirec 0000:01:00.0 rescan
#you can now launch lsiutil (might take a minute for the card to come up)
lsiutil/lsiutil -e

Now just use the lsiutil menu to flash the IT bin. Option 2 (Download firmware - update the FLASH) > select the 9207-8.bin - it will flash the card. You now have a perfectly working crossflashed H710 mini, running in IT mode. You'll need to now reboot to get the card to fully initialize and come up properly. When it's back up, you should probably program in a unique SAS address using sas2flash (you can use the linux version of sas2flash or the dos version, up to you): sas2flash -o -sasadd xxxx

That's it, that will get you a perfectly crossflashed card. Our actual published guide will have a lot of that scripted so it's not as many commands. I'm sure there's a way to halt the dell firmware or otherwise "get it out of the way" right within linux so you can skip the freedos erasure and reboot step, and I'm sure this is what OP has done to speed up his ebay crossflashing business. However I have other projects to move onto, and the above method is plenty fine for "DIY" users who don't want to buy a crossflashed card, so I'm not going to pursue faster methods. Instructions for other card revisions like B0 are identical, just using a different SBR and firmware bin

After crossflashing, reverting back to an actual dell h710 is also very easy from freedos:

#H710MMSTOCK.rom is just the stock fw right from dell
megarec -m0flash 0 H710MMSTOCK.rom
megarec -writesbr 0 D1Stock.sbr

H710-Crossflash.zip

[strongholdmedia]

So if you blindly flashed over a 9207-8i SBR, you'd be screwed. That's why we took the 9207-8i SBR we needed for a successful crossflash, figured out the struct/location of the subsystem vendor/part IDs, and inserted the "allowed" dell values.

That is ture as well. I did exactly this.

Boot into freedos and write the new SBR with megarec, and wipe the dell firmware off the card:

This is what I did as well.

you can now launch lsiutil (might take a minute for the card to come up)

This part is where I did not have any success with. Without firmware, the initialization lasts ages (like literally another 5 minutes). After that, no matter how I'd been tampering with the driver or the PCI bus, neither the opensource lsiutil, nor lsirec recognized the card. I even tried to patch mptsas2_scsih, to no avail (well, not true; I instead found a lot of issues of disagreement among the linux kernel developers on how to tackle different issues :P but didn't get closer to my goal). So I ended up patching the EFI utility instead (which was something of a lesser nightmare, given the current state of cutter segment analysis).

When it's back up, you should probably program in a unique SAS address using sas2flash (you can use the linux version of sas2flash or the dos version, up to you): sas2flash -o -sasadd xxxx

This also didn't work for me with multiple versions and platforms. Instead, I edited that in the eeprom as well.

But again, perhaps some issues are specific to SAS2308 / D1.

[Fohdeesha]

The above guide is from exactly a SAS2308 / D1: https://i.imgur.com/YqsmZ5m.png

The super long initialization and issues with lsirec not seeing the card is exactly the behavior we saw when there were still traces of dell software on the card. They all went away when we used the master "cleanflash" command with megarec in freedos. I can almost guarantee if you follow the above guide verbatim, on debian, with the same versions of software in the zip, it will work. We did D1 cards, and others have followed it now as well, and nobody is having the issues you are claiming - well, we did before we completely zero'ed the flash. Another big thing is to ensure in the system bios, I/OAT DMA Engine and SR-IOV global are disabled. These being enabled will interrupt lsirec properly talking to the card

[strongholdmedia]

Did surely clear the flash with that.

The two setting you mentioned I vaguely remember that I turned off, due to someone else recommending it. Used Debian Buster with kernel 4.19 (the live installer image).

It is quite great if nobody else had these issues (even though I can neither confirm nor refute this statement). If someone would still run into such, at least they will definitely find this issue. Perhaps then they'll have better luck using your guide.

[strongholdmedia]

megarec -m0flash 0 H710MMSTOCK.rom

As a side note, you could ask whoever you got this file from to dump their IT flash in the same way. I suppose it would make all the hassle unnecessary.

[uffsalot]

@Fohdeesha Thanks for the writeup and the modified sbr, works perfectly on my H710 in my R520:

[Fohdeesha]

megarec -m0flash 0 H710MMSTOCK.rom

As a side note, you could ask whoever you got this file from to dump their IT flash in the same way. I suppose it would make all the hassle unnecessary.

Like the comment above it says, that file is straight from dell (just renamed for clarity): https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=kkr9j&oscode=ws8r2&productcode=poweredge-r720

We did a full 16MB image dump of the IT cards we crossflashed as we had the same idea (just laying down the entire ready to go firmware from megarec would be much faster) but megarec is only built to flash megaraid firmware images, not IT/IR images. It's a simple metadata check that could either be patched out of the megarec binary, or just spoofed and added to the IT image, but that was more work than just publishing the already working lsirec method. If another enterprising individual wants to improve on the guide with megarec patches or similar to speed it up, they have my full support

[Fohdeesha]

@uffsalot glad to help :) Note for anyone else looking at this, my post was not a conclusive guide, just the main required bits. If you're not really comfortable with this stuff I would wait until a full guide is out - for instance those commands are for the D1 card only (Dell 5CT6D) - for B0 revision cards for example you would use the b0 sbr and 9205-8e.bin

[strongholdmedia]

@Fohdeesha Thanks for the writeup and the modified sbr, works perfectly on my H710 in my R520

Could you please mention your BIOS version? Also could you change (back) your SAS address with sas2flash afterwards?

[strongholdmedia]

If another enterprising individual wants to improve on the guide with megarec patches or similar to speed it up, they have my full support

I am more than willing to spend time on this, and now that I finished my thesis, I will presumably also have time. I do not, however, have any relevant hardware at the moment, as the two servers I mentioned are running in production, but seriously consider getting another R720 for "research issues".

(Unsure if anyone is interested in it at all, especially here, but I consider very important to mention that the Linux kernel drivers H710, at least D1, but I suppose all of them, will cause kernel panic on regular shutdown, and will require local intervention / power cycling to restart. I am not sure if iDRAC may help with this, but anyone concerned should run at least kernel 5.2 where these are fixed somewhat.)

[Fohdeesha]

Huh? I nor anyone I've asked has ever had kernel panics on shutdown or otherwise, crossflashed or stock firmware. I have like 4 of these in production and have never seen nor even heard of that

[WildOne69]

@strongholdmedia either you're an incompetent or your one of the eBay sellers selling these cards flashed and you don't want this info published. I've flashed half a dozen since @Fohdeesha posted how to do this here and NOT once have I had an issue with reboots in Linux or FreeNAS. IF you don't have something positive to add, GO away.

[uffsalot]

@Fohdeesha Thanks for the writeup and the modified sbr, works perfectly on my H710 in my R520

Could you please mention your BIOS version? Also could you change (back) your SAS address with sas2flash afterwards?

I'm running bios version 2.7.0 and changing the sas address was no problem.

[strongholdmedia]

@strongholdmedia either you're an incompetent or your one of the eBay sellers selling these cards flashed and you don't want this info published.

That is YOUR prejudice.

I've flashed half a dozen since @Fohdeesha posted how to do this here and NOT once have I had an issue with reboots in Linux or FreeNAS.

Nice for you (even though nobody talked about any kinds of reboots).

IF you don't have something positive to add, GO away.

Please be a pain in your own respective body parts, have you nothing else to do.

[strongholdmedia]

Huh? I nor anyone I've asked has ever had kernel panics on shutdown or otherwise, crossflashed or stock firmware. I have like 4 of these in production and have never seen nor even heard of that

Regardless, it did happen, and I had to upgrade to 5.2. It only happened on shutdown (halt, -h ) and not on reboots or similar though. Here is the whole kernel development discussion.

https://patchwork.kernel.org/patch/10734933/

The guy "Kashyap Desai" proposed a fix for it back in time ages before it has finally been fixed in the mainline. I felt sorry for him, for his patches have been rejected multiple times, for reasons like disagreement about whether the command queue architectural issues in the Linux kernel - which are screwed indeed - should be changed just because "one broadcom driver" "was malfunctioning". In fact he was right but as the patches are rejected, a lot of efforts have been needed to rectify the issue, so it has only that late they have been mitigated.

Then again, YMMV.

NB. The very same version of the mpt3 driver, below kernel 5.0.7, has a DoS vulnerability (not only in RedHat, all mainline kernels are affected). I suspect this is the very same problem but had not the time to verify this, so this may be speculation. I also suspect that it may be used for RCE even if not in the wild.

https://access.redhat.com/security/cve/CVE-2019-11810

[WildOne69]

@strongholdmedia either you're an incompetent or your one of the eBay sellers selling these cards flashed and you don't want this info published.

That is YOUR prejudice.

I've flashed half a dozen since @Fohdeesha posted how to do this here and NOT once have I had an issue with reboots in Linux or FreeNAS.

Nice for you (even though nobody talked about any kinds of reboots).

IF you don't have something positive to add, GO away.

Please be a pain in your own respective body parts, have you nothing else to do.

Nice, YOU get defense just proves how truly incompetent you TRULY are at understanding anything written.

Thank you @Fohdeesha for making IT firmware work on the H710 for Free.

[devinirv]

I have a quick question reguarding this flashing procedure. Has anyone tested or confirmed the same sbr file being used on the regualar dell h710 in pcie 8x rather than the mini monos. Ive xflashed quite a few regular lsi cards the sas 2208 to 2308 IT. The 9271 8i to a 9207 8i however i recently came across a dell h710 d1 in the same pcb layout as the stock lsi 9271 however when i clear the sbr and write a stock one at 256bytes it esecially doesnt clear propperly and the card goes jnto recovery when i try to flash with sas2flsh. No im not into hexediting nor do i have an eeprom reader, im just looking for a clear answer if the 512 sbr in your zip would esencially work? Ive also thought of doing an empty 512 sbr file by not to sure of the repocusions with these h710s.

Any help would be appreciated Thanks

[Fohdeesha]

It uses a slightly different sbr, which my full guide has. Just follow the instructions: https://fohdeesha.com/docs/perc/

[devinirv]

Thank you so much, this worked perfect, was abble to flash 2 of these for my dell systems, going to attempt the mini monos on my buddies 2 r720xd in next few days.