If it makes you feel better, I bricked a supermicro C7Q67 a few weeks ago. I went to do a routine updating on a board that the 'tree' gave me. It went through the motions of updating, never post'd again.....its now an I5 paper weight. SM support actually let me down on this one, basically told me to go pound sand....apparently this board is known for flash failure incidents...there was a thread here about it!
Board arrived this Friday, looking at the date of the quoted posts gives you an idea how much love I have for the Swedish postal service these days!
Anyway, I tried first to recover it using the BIOS recovery method quoted by pfcom below.
However as pfcom says it seems whenever the CATERR LED is lit you're basically fucked, and it was on this board...
So I desoldered the little Macronix MX25L6406E BIOS chip and flashed the latest BIOS using my Willem GQ-4X programmer and the ADP-081 adapter.
Board POST:ed just fine after that endevour: It should be illegal to not put a socketed BIOS chip or a ICSP port so it can be programmed, but I digress.
Thanks allot TC for the board!
so bricked by the spyware!
something else to blame Intel for!
Yup, it sure seems that way!
I do wonder if the JPME1 jumper that must be shorted when flashing the BIOS on this board actually is the same as the NSA uses to disable the ME on their boards?
It seems like that might be the case, when I have some time I'll see if the board works with that jumper there. (I know the NSA uses a software switch but that also exists in the BIOS, but it's temporary as I understand it).
Being a slow learner , when I reflashed second of the two C7Q67s from thread you referenced, I recall no reboot and having that sinking feeling after all the drama with the first
However, unlike the first, the second didn't light up its CATERR LED and I recovered it by following SuperMicro BIOS Recovery instructions (BIOS image on USB flash key and Ctrl&Home IIRC)
I did. Followed their instructions to the letter. It had 1.0a on it. Updated to 1.1 as per the instructions, that was successful. The upgrade from 1.1 to 2.1 is what pooped the bed. Flash went without an issue, upon reboot it just never POST'd again.
Being a slow learner , when I reflashed second of the two C7Q67s from thread you referenced, I recall no reboot and having that sinking feeling after all the drama with the first
However, unlike the first, the second didn't light up its CATERR LED and I recovered it by following SuperMicro BIOS Recovery instructions (BIOS image on USB flash key and Ctrl&Home IIRC)
Before flashing C7Q67s it's critical to observe Read_This_Before_Flash.txt from within BIOS Zip
Unfortunately (NotSo)SuperMicro seem to have included this warning only in BIOS 2.1a and later
Essentially one must disable Management Engine before doing BIOS update
If not, same outcome as doing BIOS update from command prompt within Windows in the old days
I did. Followed their instructions to the letter. It had 1.0a on it. Updated to 1.1 as per the instructions, that was successful. The upgrade from 1.1 to 2.1 is what pooped the bed. Flash went without an issue, upon reboot it just never POST'd again.
If it makes you feel better, I bricked a supermicro C7Q67 a few weeks ago. I went to do a routine updating on a board that the 'tree' gave me. It went through the motions of updating, never post'd again.....its now an I5 paper weight. SM support actually let me down on this one, basically told me to go pound sand....apparently this board is known for flash failure incidents...there was a thread here about it!
Do you think they have faulty BIOS chips??? That sounds a ton worse than my Soyo SY-K7VTA-B motherboard from facking China! Soyo and Chaintech were known to F-up on the BIOS! But even for both motherboards, (including the Chaintech CT-7AJA2E) no such kind of bullshit...
If it makes you feel better, I bricked a supermicro C7Q67 a few weeks ago. I went to do a routine updating on a board that the 'tree' gave me. It went through the motions of updating, never post'd again.....its now an I5 paper weight. SM support actually let me down on this one, basically told me to go pound sand....apparently this board is known for flash failure incidents...there was a thread here about it!
yes, i remember reading something about this from gigabyte. they say the main bios chip is flashable but the backup bios chip is read-only and cannot be written by the user, so that could be it.
As a side note, when it restarts like that after a few seconds, it can sometimes be due to automatic overclocking. Did you have anything like that configured? It does seem odd that it just happened out of the blue, but as others have mentioned, maybe the CMOS battery is on its way out?
No automatic overclocking, CMOS battery seems fine. PC is keeping time and booting fine ever since.
As a side note, when it restarts like that after a few seconds, it can sometimes be due to automatic overclocking. Did you have anything like that configured? It does seem odd that it just happened out of the blue, but as others have mentioned, maybe the CMOS battery is on its way out?
Yes, a good 32-bit CRC will detect the vast majority of errors, although it will not allow for correction, this is often sufficient for something like a CMOS data set.
Historically, the sorts of "check" algorithms employed have been all over the map, in terms of complexity and durability.
Sun uses a simple longitudinal parity to "protect" the IDPROM in its machines -- but, there are only 15 bytes of data involved (the parity byte being the 15th). Amusingly, even this simple check would be sufficient to catch the most common data corruption modes (i.e., a failure of the integrated battery in the BBSRAM)
By contrast, the balance of the NVRAM (including the potential code stored in nvramrc) was protected by another hash.
You could patch (some) early PC BIOSes freely by simply "compensating" for every desired changed value with a complementary change in some other "unused" value. E.g., if you want to change a byte from its present value of 0x23 to 0x34 (a net change of +0x11) then simply change some other byte from it's current value of 0x86 to 0x75 (a net change of -0x11); you don't even have to know where the checksum is stored as the "net" sum will be unchanged!
But, nowadays, with modular BIOSes, more aggressive hashes are used (including explicit "encryption" of the BIOS) as it can conceivably be modified in the wild.
Leave a comment: