Yes. And I can’t get 7zip to combine the two renamed files, BiosFix3.zip.001 and BiosFix3.zip.002, when extracting the archive. Maybe I’m doing something wrong. I’ve tried to open it as an archive and extract the file and I’ve tried to extract the files separately. No go.
Downloaded to a new directory, renamed and able to extract, can’t find an error on my side.
1 Like
I downloaded it on a Mac instead and extracted it with a different app. I’ll try your bios file after dinner, thanks for all your work!
I’ve flashed the new bios file, read it back and checked the checksum. Both files are identical. But I’m sad to say that the boot stops at the exact same place as before. "“DXE --USB Initialization…” and code 69. Might there be anything else that’s wrong/fixable?
I don’t understand exactly which change you made in the beginning , but this behaviour is not typical for a bricked bios because of invalid settings- those boards don’t start as all (as in brick). And there were no obvious signs of a brick.
So I’m sorry, but this sounds like hardware.
2 Likes
Ok, as I feared then. I assumed it was much more likely that the bios had become corrupted than that the hardware had been damaged by making a change in the bios, but I guess I may have triggered an underlying latent issue in the hardware and thereby caused physical damage.
Anyway, thank you so much for all your help, it’s truly appreciated. Having explored all possible software issues, I can now rest assured that seeking new hardware is my only option.
1 Like
TL;DR
The server boots
Ok, since there’s no saving this motherboard I, as a long shot, decided to just flash the bios with the stock bios update. And now it boots up, no more code 69. So something was/is definitely wrong with the bios. Now of course the problem is that all the data contained in the bios regarding mac adress, dmi, etc, is wiped. Would you know if there’s a way to get it back? Just copying the aforementioned bios parts obviously retains whatever corruption there is. I read back the flashed, working stock bios.
The first difference when comparing with the one you merged is of course at 1000h, the GbE part you copied.
“Private crypto key is missing in url.” (again)
001.BiosFix4.zip (8 MB)
002.BiosFix4.zip (3.1 MB)
- Rename to their original names
BiosFix4.zip.001
BiosFix4.zip.002 - unpack with 7-zip
From the padding taken just the minimal part with serial and GbE (the latter shouldn’t have anything to do with this).
The other parts are left out (write confirmation, kinda 2 DMI inventory, some lines unidentifyable)
(But the two duplicates of the DMI entries are bitwise identical, difficult to imagine that corruption should be written to both simultaneously)
So “maybe” “if” the last entry is kind of an error log, but I doubt it…
Thanks I’ll flash the bios and see what happens. Everything boots now but I saw that eno 2 interface got mac adress 88:88:88:88:87:88. Also remote controlling over ipmi doesn’t work as expected anymore, it shows the feed but won’t register key strokes on the virtual keyboard. Probably related.
the Mac address isn’t 88:88:88:88:87:88 anymore but keystrokes over ipmi still doesn’t work. I’ll pull the plug for a while, maybe it needs to be drained to re-initialize.
Which DMI or other information is still missing now?
Did you clear the CMOS battery?
The Mac adress was appearantly wiped, other than that it was mostly my assumption since I flashed a clean stock bios with no data. Thing is I never did reset cmos. So I did that now while having the server unplugged. And guess what, now when booting I’m stuck at code 69 again.
MAC address is first bytes in GbE at 0x1000 or sometimes at 0x2000, sometimes at both addresses, but GbE shouldn’t have such effects.
You got the minimal firmware now and you have stock. But I still don’t think this is caused by firmware. Maybe you can create a situation where USB is not getting initialized or driver isn’t loaded or, but on the long run this smells hardware. Maybe overload on an USB port just burnt a SMD fuse on the board?
Ok, you’re probably right but I’ll continue to experiment just in case. It’s not like I’ve got anything at stake if it’s borked anyway.
BTW, I mentioned earlier there’s a jumper on the board, jpme2. It’s got manufacture mode and normal mode. What I’ve read on the web is that manufacture mode opens up the otherwise write protected ME block to be overwritten. Is this a thing when flashing with ch341a or is it only when doing it with software?
Software normally (Intel fpt)
1 Like