For the daring there is a one-shot software method where you reprogram the boot block of your running workstation*****, for the cautious or daring who made a mistake there is an almost foolproof hardware method.
Why? Dirt cheap 8 or 12 core workstations with 128GB+RAM and 10+ SATA ports!
*2020-06: this method may not work - it seems you can do everything EXCEPT write the boot block, possibly a PCH hardware security feature. You can still do a full dump from software which is a very safe way of getting a backup.
This is to allow HP’s C602 chipset Socket 2011 workstations that shipped with Sandy Bridge CPUs and firmware to use Ivy Bridge CPUs. Is that you mean by skipping a gen?
100%, but school has been kicking my ass, even over the break (got homework over the “break”…) so I haven’t worked on my home server yet. It’s been powered off for months
Quick update on ME firmware. Disable AMT in the BIOS or by the header and you can ignore the ME firmware version. Just upgrade your bios to an appropriate version (eg v3.85) and flash your boot block with the 2013 version.
I got my v2 test CPU (an astoundingly slow E5 2603 v2, 4 cores @ 1.8GHz. It’s about as fast as a dual core laptop i5) working with 2013 boot block and AMT disabled. Worked for getting into BIOS, using FreeDOS, using linux desktop and server.
I did also upgrade to ME v8 firmware by replacing the ME region in a dump of my BIOS with the ME v8 region of the v3.85 BIOS update file. It shows up correctly in the BIOS. I didn’t get it working with the v2 CPU, but I think that was down to trying to initialize the upgraded ME with the v2 CPU, when I should have been using the v1 CPU then swapping in the v2 CPU after.
So, for all considering a Z420/Z620/Z820 v1 for the purposes of upgrading it to use v2 CPUs (all…15? of you), and worried about needing to upgrade the ME firmware - you needn’t bother. Enjoy the wonderful AMT-disabling motherboard header HP has provided.
i have a z420 v1 and am trying to make it v2 cpu compatibles the sw/easy way but idk where to start if anybody can help me i would appreciated. i purchased a 1603 v1 cpu just for this purpose, thank you.
I’m going to go into a lot of detail but here are the two takeaways:
The “one-shot” software process does not work - it succeeds in reading and writing from/to the chip but the boot block is not modified.
In my case using an external power source (other than the Pi) caused unstable reads and actually corrupted my chip even though I never attempted a write. Stick with the Pi for the 3.3V source.
I have a z820 v1 and have been trying to upgrade the boot block. I wanted to share a couple of things from my experience.
First I tried to perform the “one-shot software method” described above. I can confirm that it did not work for me. I moved both of the jumpers as described in the guide and while this did enable me to use the tool in the guide to successfully read the flash and then write it (after modifying it to add the 2013 boot block) the boot block remained unchanged afterwards.
I then tried to do the hardware version of the flash using the chip clamp, Raspberry Pi, etc. Based on suggestions in the guide I first tried to use an ATX power supply’s 3.3V rails to supply 3.3V power because the guide seems to imply that this will give a greater chance for sufficient power than the Pi’s 3.3V power rail.
I verified that I was getting 3.3V from the ATX power supply leads with a multimeter and then connected everything up. I was able to read and save the chip contents to a file but I kept getting different checksums in spite of repeatedly adjusting and reattaching the clamp.
Finally I decided to remove the ATX power supply from the equation and use the Pi’s 3.3V pin. Immediately I started getting consistent flash reads, with four reads in a row giving an identical checksum. However while the saved files were consistent there was something very wrong with them. I eventually learned that the chip contained only continuous 0’s for the first 100-200 bytes and all data after that was contiguous 1’s.
In spite of the fact that I never attempted to write to the flash, something in my process of using the ATX power supply and reading the chip corrupted it. I confirmed this by putting the machine back together and turning it on. It repeatedly turned the fans on for a brief moment before shutting them off until I pulled power. At that point the power button LED flashed red and the machine started beeping four times (even though power was disconnected). The machine was definitely bricked.
Fortunately I had the file that I read and modified from the “one-shot” process. Since I was now getting consistent reads (albeit of a corrupted chip) I wrote the modified file, re-read it and verified that the chip’s checksum now matched the modified file. I put everything back together, powered the system up and it POST’ed successfully and shows the 2013 boot block.
Based on this I strongly recommend avoiding an external 3.3V source. Even if you have to go to the trouble of removing cards, disconnecting drives and power connectors, etc. the Pi as the power source seems to be the best chance for success.
Good to hear you were able to figure everything out. I’m removing the recommendation to use ATX 3.3v from the guide since the Pi’s supply has proved sufficient in several cases, and adding clear warnings about the software flashing method.
However, one question, when you used the ATX 3.3v supply, were the grounds (Pi/motherboard/ATX supply) connected together as well?
As to the checksums, there is behaviour where they change on every boot due to variables stored in the BIOS getting updated (iirc it was boot count and some ME stuff). So if you dump the BIOS and reboot the checksum will change.
