question about PCIe cards...

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
I don't know where to post this so "general" it is... wish there was a section in hardware for this kind of discussion....

So, a little context. I've been messing around a lot with flashing firmware on SAS controllers. I've gotten to the point where I'm even using a CH341 /USB adapter to read/write the I2C EEPROM chip off the PCIe cards. The SBR of the SAS controllers is stored on this EEPROM and I've been using the EEPROM programmer to recover SAS cards that I've bricked in my experimentation.

In all this playing around, I've found that the SBR can be of 2 different sizes (maybe more? but I've observed at least 2), the typical seems to be 256-bytes, while *some times* on HW RAID cards, it is 512-bytes. In both cases, the contents of the SBR is usually stored twice in that 256 or 512 byte block of data. The EEPROM chips are usually 8k, so there's a lot of empty space filled with 0x00, but i guess also means it might be possible to have larger SBR? The SBR contains various "configuration" data it seems, among them are things like:

PCI class ID
PCI vendor ID
PCI product ID
PCI subsystem vendor ID
PCI subsystem product ID

and other bytes seem to be used by the firmware code as configuration settings it seems. The various PCI ids of course are pretty typical for any PCIe card. what i've noticed is that the offset for the various PCI ids in the SBR is different in the 256B vs 512B formats. so, for the host system to detect these PCI ids isn't simply reading the bytes at a pre-determined offset without knowing which format SBR is in use.

Also, i can add junk bytes after the 256B SBR format and it doesn't cause a problem. So however the data in the SBR is read by the host system, it knows when to stop reading. The "megarec" program also seems to know when to read 256B or 512B when reading the SBR to a file.

Which brings me to my question, how does one programmatically determine which format SBR is in use? Is there some byte near the beginning of the SBR to determines if the SBR is 256B or 512B? And consequently, to know at which offsets to find the PCI class ID, vendor ID, etc.?

BTW, this is mostly on varieties of the LSI SAS2208/2308 based SAS controllers. I'm finding even the same model controllers can have different SBR sizes in *some* cases, but work just fine. For example, on a SAS2208 with a 512B SBR, if I put the 256B SBR on it, it breaks. But I also have SAS2208 cards that come natively with 256B SBR and work just fine. So, even though both are the same hardware, they are expecting different SBRs....

Any ideas?
 

BeTeP

Well-Known Member
Mar 23, 2019
653
429
63
Firmware reads the device ID of the EEPROM chip and looks up its size in a table.
 

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
Firmware reads the device ID of the EEPROM chip and looks up its size in a table.
how does the firmware know where to look for the device ID? it's not at the same location for 256B vs 512B SBR? where is this "table" stored? I have the same firmware image working with both 256B and 512B SBRs, on the same hardware, so my guess is that this "table" is stored somewhere else?
 

BeTeP

Well-Known Member
Mar 23, 2019
653
429
63
The table (usually pretty short list of supported EEPROM chips) is stored in the firmware code. The device id is hardcoded in the EEPROM chip itself. It is not a data address. The chip reports it back to the device id request command. Just read the protocol spec.

PS for know-it-alls:
The "device id" above is referring to the "EEPROM chip device ID", not the PCI Vendor ID and Product ID of the adapter.
 
Last edited:

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
The table (usually pretty short list of supported EEPROM chips) is stored in the firmware code. The device id is hardcoded in the EEPROM chip itself. It is not a data address. The chip reports it back to the device id request command. Just read the protocol spec.
as mentioned above, i know where the device ID stuff is stored in the EEPROM, i've been re-programming the EEPROMs to experiment with things. that's how i found cards with different size SBRs, even of the same model and firmware.

Do you mind pointing me to the protocol spec? Is it publicly available? I'd love to read the specs and get definitive answer, but i've searched for some time and I can't seem to find such spec that is publicly available.
 

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
people who know do not ask stupid questions


LMGTFY
you are completely unhelpful and insulting. I2C protocol does not specify the contents and format of the SBR. you clearly don't understand the question. and if you don't care to be helpful, leave the conversation.

if anything, I probably need to read the PCIe spec, but the PCISIG requires membership to access those docs.
 
  • Like
Reactions: Aestr

BeTeP

Well-Known Member
Mar 23, 2019
653
429
63
you are completely unhelpful and insulting. I2C protocol does not specify the contents and format of the SBR. you clearly don't understand the question.
You wouldn't know helpful if it hit you in the face. In my first post I explained in the simplest terms possible how the controller knows the size of the EEPROM chip soldered into the board (which was your original question btw). But alas I might as well be talking to the wall. It's ok. It was obvious that your confusion stemmed from lack of basic understanding of how I2C works. So I recommended you to read the I2C protocol spec.

And then you responded with even more bullshit and attitude. But sure it was me who was unhelpful and insulting.
Have a good life.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
In my first post I explained in the simplest terms possible how the controller knows the size of the EEPROM chip soldered into the board
<jumps in DeLorean whilst happily admitting he knows sod-all about EEPROMs>

Firmware reads the device ID of the EEPROM chip and looks up its size in a table.
how does the firmware know where to look for the device ID? it's not at the same location for 256B vs 512B SBR? where is this "table" stored?
The table (usually pretty short list of supported EEPROM chips) is stored in the firmware code.
Seems to me that BLinux already knows that the mythical table is stored in the firmware, but he's asking for some more detailed information on what magic needed to happen for this stuff to be read, and from where (of course, someone asking for technical information on this forum is as rare as rocking-horse shit!). Maybe it really is bone-headedly simple for someone as awesome as yourself to understand, but most people respond better to being given a gentle push in the right direction for the information, rather than doing as you did and assuming that BLinux seemingly doesn't know what a search engine is. As a mere moron, I haven't learnt the spec off by heart so perhaps you can point out to us all the part of I2C that governs this particular aspect?

Because at the moment you're just coming across as a colossal arse, riding an ass into Rectumshire and I look forward to your further explorations of just how much politeness you can excavate from your intestines. If you don't possess sufficient knowledge, patience or eloquence to provide someone with a straight answer to what I feel is a legitimate question, please do us all a favour and refrain from depositing further diarrhoea on your keyboard.
 

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
@EffrafaxOfWug no need to inquire with BeTeP further, he/she is clearly not understanding the question, and has no interest in helping. pointing me to the I2C protocol is meaningless, I already mentioned I'm communicating with the EEPROM chip via I2C and that is how I'm reading out the EEPROM contents. My question wasn't about how to communicate with the EEPROM, it's about how to handle the different contents of the SBR (in the EEPROM) in the same hardware and firmware.

To further this discussion (without BeTeP), here's an example to illustrate the point: below are screenshots of hex dumps of the EEPROM from 2 H710 cards, which are based on LSI SAS2208 SAS RAID controller, same SAS2208 chipset, and same firmware, yet, SBR is different:

H710_MCR5X_SBR.png

And here's the other one:

H710M_5TC6D_SBR.png

In the first one, the "meat" of the SBR is from offset 0x00-0x7F. that last byte at 0x7F is a checksum. The 2nd half is an exact copy of the same contents, maybe as a backup? This is the format of the 256B SBR.

In the second one, the "meat" of the SBR is from offset 0x00-0xDF, and again, last byte at 0xDF is a checksum and the 2nd half is a copy of the first half. This is the format of the 512B SBR.

Both H710 cards run the same firmware. If I put SBR#2 onto card#1, it breaks. Same vice versa. So, clearly card#1 needs SBR#1, and card#2 needs SBR#2. So, if the firmware is the same, and the SAS2208 chipset is the same, there must be something else different to explain why they need different SBRs to work.
 

BeTeP

Well-Known Member
Mar 23, 2019
653
429
63
@BeTeP confirmed for autist
well if that's what it takes to stand out in this circlejerk - I'll take it as a compliment.

I just wish anyone would be able to point out even slightest technical inaccuracy in anything I said instead of just telling each other how big of an asshole you all think I am.
 

RageBone

Active Member
Jul 11, 2017
617
159
43
TLDR of my partially bogus thoughts: Have a look at BinWalk, a great tool to figure stuff out about binary-files.
Edit: Because the info is very likely contained somewhere in the Rom-conten / the firmware -image / -binary.
i don't have enough time to really think this through or clean it up.
as far as i understand the hole matter, everything is encoding dependent.
So first assumed step in the hole process of loading the cards firmware could be to query the actual ROM-Chip if it exists and what it is, how big it is, etc.
There would be your first point of distinguishing between the Card ROMs.
That part should be on the i2C spec side.

But that still doesn't tell the card anything real about the data on the Rom. Just how much could fit onto the ROM, and it doesn't really need that info.

So on to the next part. Reading the Rom Content.
It doesn't need to know anything about the content to read it.

After or while reading the ROM content, the card or who ever is loading it, can start interpreting it.
Depending on how the Card is designed, the ROM does not need to be in any spec compliant format.
Two scenarios that i can think of:

Scenario; Rom is connected to the Core and PCIe and functions as optionRom:
Since it has to be readable by the System through PCIe as an OptionRom, it had to be compliant to the OptionRom-spec.

Scenario; Designer said **** all specs and the card Core is the only thing:
The designer could Hardcode ID Placements and what ever he wants. You have no way of ever finding out how this thing is structured, unless you go through exorbitant amounts of reverse-engineering device-Drivers, etc.

But the last scenario is very evil and i'd say unileky.

I assume, developers are lazy (good!) and use some rather easy to implement standard.
For example a filesystem for such ROM-devices.

A useful tool to figure out whats going on, would in this case be BinWalk, which detects filesystems and other known formats.

Oh jea, and the misunderstanding seems to be with the Device-ID.
We have to differentiate between the Rom Device, eeprom in this case i think, and the card - Device-Id contained inside the ROM-Content.
i2C should i think have a spec on how to query i2C device specific data like VendorString, device-id, Size etc.
there probably is one for i2C Storage ROMs too, to define like Size and Type attributes
So BeTeP probably meant, but failed to communicate that good enough, the Device-ID of the eeprom.
Hence pointing you at the i2c spec where that should be explained.
 
Last edited:

RageBone

Active Member
Jul 11, 2017
617
159
43
Well, did you add that or did i just overlook that previously ? I could swear i have read it like 3 times and you just mentioned the "device-ID" without the Context. But i guess i should practice reading again >.<

@BLinux there are "diff" tools to precisely show / highlight differences.

Edit: Binwalk-ing the Broadcom 3008 of my SM X10 SRH CF that has 3 different binarys for what ever reason, isn't revealing anything.

What Linux Kernel-Module is the LSI card using? We could deduce things from the modulecode
 
Last edited:

BeTeP

Well-Known Member
Mar 23, 2019
653
429
63
I think I figured where @BLinux's confusion comes from.
In addition to being an arrogant moron, he just does not speak English. Now it is clear that he has read my "Firmware reads the device ID of the EEPROM chip" as "Firmware reads the device ID off the EEPROM chip".
 

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
Are the EEPROM's identical? What are their part numbers?
Not completely identical. They both look like from ST Micro from what I can make out of the logo. Both are same part number: 24C64RP, both have 8k. the one with K226K is the one with 256B SBR. the one with K246K is the one with 512B SBR. Is the K226K vs K246K the magical difference between why one has 256B SBR vs 512B SBR?

IMG_20190606_172541593.jpg

IMG_20190606_174058959.jpg
 

BLinux

cat lover server enthusiast
Jul 7, 2016
2,669
1,081
113
artofserver.com
I think I figured where @BLinux's confusion comes from.
In addition to being an arrogant moron, he just does not speak English. Now it is clear that he has read my "Firmware reads the device ID of the EEPROM chip" as "Firmware reads the device ID off the EEPROM chip".
@BeTeP I don't know what your problem is, but apparently you have many. Are you just an angry individual? Is it that you lack social skill? Is it that you never learned proper manners and how to communicate with your fellow humans? Or, is it your low self-esteem issues that require you to insult me to make yourself feel superior? So far, you've called me "stupid", "arrogant moron", and incompetent with the English language; maybe try a little harder? Oh, and by the way, English is a 2nd language to me, so feel free to make yourself feel superior because you have command of a language better than I. It doesn't bother me, but does that help you feel better about yourself? Maybe what you really need is a therapist. Go get some help, but whatever you choose to do, you should leave this conversation. Whatever superior knowledge you think you have about I2C isn't worth the drama you bring along with it, so leave. I know you think my English isn't great, so let me make this short and simple: go away. Do you understand my English now?