No, BIOS Recovery does not clear passwords. The process for doing so it as follows:
- Power off board.
- Move yellow jumper to pins 2 & 3 of the BIOS Configuration header.
- Power on board.
- The board should go into BIOS Setup in Maintenance Mode, which will present an option to Clear Passwords. Select it and verify intent in dialog that follows.
- Exit from BIOS Setup with a save.
- Power off.
- Move jumper to pins 1 & 2.
- Power on.
If the Chassis Intrusion notification is display, just press <enter>.
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...
- Download the .BIO file for the latest-available BIOS.
- Using ITK, generate a modified version of this .BIO file that has Chassis Intrusion notifications disabled.
- You could also try putting replacement passwords in this image, but I don't believe that these will override those already in place. Still, it is worth the try; worst case, it doesn't work; best case, it works (you can clear these passwords later).
- Once you have saved this modified .BIO file, place it on a freshly-formatted (FAT32) USB 2.0 (not 3.0!) flash disk.
- Use this flash disk to install this .BIO file using Recovery Mode.
Instructions for Recovery Mode:
- Power off the board.
- Remove the (yellow) BIOS Maintenance jumper from the header.
- Insert the USB flash disk into one of the black (or yellow) USB 2.0 ports on the back panel of the board. Do not use (blue) USB 3.0 ports and do not use front panel (cabled-up) USB ports.
- Power on the board. It should proceed to install the .BIO file using the recovery method. When it completes, it will tell you so.
- Power off the board.
- Restore the BIOS Maintenance jumper to the 2 & 3 pins of the header.
- Power on the board.
- If the .BIO file installed successfully, BIOS Setup should start up in Maintenance Mode and you should then be able to clear the passwords.
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...
What processor are you attempting to use with the board?
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...
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.