marcan
reading SBR from 2208 shows the data to be offset by a few bytes
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?
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.
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.
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).
To add further to the confusion, I have dumps that have second copy at 0x80, others at 0xe0..
@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?
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
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.
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.
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
Our H310 guide, for reference: https://doku.phoxden.net/plugins/servlet/mobile?contentId=7208964#content/view/7208964
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.
Had to write my thesis, and will have grad exam tomorrow; as such, this whole ordeal has been forgotten, thanks for remindig me anyway.
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
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;
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.
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
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.
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
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.........
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
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.
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.
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
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.
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
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).
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
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.
Also no version of sas2fl[a]sh wanted to flash it either. (But the EFI one at least recognized it.)