I've got a second hand DX79SI. Previous owner has set a BIOS password, and I can't figure out how to clear it. The board doesn't react to the BIOS_CFG jumper, in both positions (1-2 or 2-3) just reports "The system chassis was opened. Enter password to unlock the system." Removing the jumper completely leads to recovery mode.
I've tried to short the Intrusion header with a jumper, but nothing has changed, the behaviour is still the same.
Any suggestions? Does the BIOS recovery update clear passwords?
Please note I can't even boot to DOS/EFI shell thus I can't use any tools.
I'd be grateful for any hints!
No, BIOS Recovery does not clear passwords. The process for doing so it as follows:
If the Chassis Intrusion notification is display, just press .
Hope this helps,
Thanks! Unfortunately I've tried that already, and it doesn't work. Both jumper settings (1-2 or 2-3) lead to exactly the same behaviour, all I get in both cases is the error message about intrusion and then request to enter password. What's strange is that removing the jumper completely correctly puts the board into recovery mode, thus the config header works...
I've tried the Intel Integrator toolkit, and disabled the intrusion detection completely, but still no change.
Are there any tools to edit the BIOS binary as read from flash? I could desolder the SPI flash chip, and tweak its content... I'd love to make the board work, it's a really decent one...
EDIT: the BIOS should be the last one, 0650. I managed to update it via recovery mode.
I have a query in to the BIOS experts regarding this issue. In the meantime, I have a suggestion for something for you to try...
Instructions for Recovery Mode:
Let me know how it goes.
I've downloaded the ITK T.0.4.575. It didn't like the BIOS, telling me it's an old one, and started ITK4 (?) for me. I was able to disable the chassis intrusion, but I could not find any method to change or delete passwords. Anyway, I have flashed the modded BIOS back to the board, using recovery mode as suggested, but unfortunately, the behaviour is the same. The board is still complaining about chassis intrusion and asks for a password.
I am beginning to think it's either a rare race condition of a BIOS bug and accidentally activated chassis intrusion, or the board is somehow damaged. The BIOS bug is more likely, because I cannot think of any damage that would explain the odd behaviour of the BIOS_CFG jumper... (1-2 behaves the same as 2-3, and 2-x is properly detected).
Is there someone who would be able to dump the whole SPI part (using FPT) and send it to me?
Getting a dump of someone else's flash part will not help you. The flash part is "branded" with board-specific information - Serial Number, MAC address, etc. - and there are no tools available (to the public) that can be used to change this branding. If someone were to give you the contents of their flash part, you would be running using their MAC address and exposing their serial number. This has many identification ramifications, including Windows O/S licenses (Microsoft's activation and update protocols utilize a lot more information than just the license key).
Yea, this is likely a BIOS bug. There's not much that you can do about it, however. This board is long past its End-Of-Life and End-Of-Interactive-Support dates. Intel exited the Desktop Boards business almost three years ago and the development and support folks long ago either moved on to other projects or left Intel (or, like me, retired). If the person who sold you the board cannot help you with the password, you are likely going to be out of luck...
I would add that the Chassis Intrusion (CI) is a latched event. That is, once the signal has been latched by the circuit, the chipset retains its knowledge of it until it is manually cleared - and you have to get by the password event before this will occur...
Yep, I guessed I'd be reusing someone's MAC number, but the board wasn't supposed to run permanent Windows installation, just an eval without activating, and that wouldn't bother me much. I am not sure where those things are stored, but if the serial number is in SMBIOS structures, I could tweak it.
The CI is probably latched in flash variable, because clearing CMOS didn't help.
The CPU is E5-2658 SR0LZ. I've tried a bunch of others, but they didn't work. I might be able to find another one with some effort, I have a board with 10 core IVB stacked somewhere, but I am not sure if that would help.
Anyway, I'll try to extract the flash part and read it back, just for the fun of it. The board didn't cost me much, so if I'll damage it in the process, no big deal.
Thanks a lot for your help so far!
This processor is not in the list of supported processors. This likely mean that the BIOS does not have any microcode updates for this processor and it is thus possible that this processor's errata could contribute to issues seen with the BIOS. This was the first warning I received from the validation folks at Intel when I asked then about your problems. I will be honest, though, this issue sounds more like a bug in the BIOS to me...
BTW, you can find the list of processors compatible with the DX79SI/TO/SR boards here: http://processormatch.intel.com/Processors/CompatibleProcessors?componentName=dx79si Compatible Processors.
I'd expect Intel folks telling me microcode could be the root cause I am also guessing BIOS bug is more likely - if the microcode would affect CPU's ability to read IO ports, the whole thing have crashed in SEC already. Even if it would, I am not ready to shell out a few hundred bucks for the 'right' CPU just to find out.
Anyway, thanks a lot for your help. I will put it on a backburner for the moment, I have a plenty of urgent things to do these days.