Thanks @levelud - How did you dump? Please give details, thanks!
The thing here is we didn’t specifically need a dump, but rather need to know the exact process to program back the boards BIOS in case of failed flash of modified BIOS, in case USB Flashback does not work for some users or due to the badly flashed BIOS (just in case)
If you used SPI Header, what is the pinout?
Those are the picture from doing it.
@levelud Thank you for the dump. Are you sure that the dump came from a healthy, firmware-wise, motherboard? Something is off with that firmware. From what I can tell it is either BIOS v0303 or v0401. Are you able to re-flash it to the stock ASUS firmware using the programmer, after removing the capsule header via UEFITool?
My dump has also worked (will attach later, internet is down here right now).
The SPI header pinout is the same as in the diagram that LOST posted.
Capsule? I didn’t check the file, is it encapsulated? If there is a capsule then this is not a “Dump” Can someone re-host that dump, I can’t download from that site, thanks
@levelud - do you have B0 CPU’s? If yes, what model are they, and SSPEC? I can make some test BIOS for you guys with the B0 programmers since you can recover via programming now.
@maxdata - pinout confirmed above - do you have SOIC16 to DIP8 cable? That’s the one you need, BIOS is not the QFP chip labeled BIOS we originally thought it was
It is a dump but the CSSPS firmware is strange. The official ASUS SPI/BIOS have a capsule which needs to be removed first before flashing via the programmer, that’s what I meant. Here is a temporary link.
Thanks for the rehost plutomaniac! I knew about the Asus capsule stuff, only assumed you meant this dump was encapsulated, which if it is then it’s not a dump.
From my end, ME FW looks same as stock 0801 BIOS, except older, but I know very little about ME 
I only compared in ME Analyzer
Ok, internet works again, here are a few dumps.
This is with LOST’s modded 3501:
https://www.dropbox.com/s/5wo1m46plwm98q…Modded.zip?dl=0
Then I flashed back to stock 3501 and took another one:
https://www.dropbox.com/s/ksv68vs6zpsggv…_Stock.zip?dl=0
Thank you @malucul . Ok, this makes no sense. You say you flash new versions (0801, 3501) and I can see that they have CSSPS firmware 4.0.4.288 but then your dumps include an older 4.0.3.219 which was originally included at BIOS 0303 and 0401. Basically, the BIOS is updated but the Engine firmware is old. That shouldn’t happen when someone is using a programmer. Unless this is not the only BIOS chip on the motherboard but serves as a backup or whatever. From the attached archive, can you run SPSInfo -verbose and SPSManuf -verbose and show me the results?
By the way, as explained in the manual, that motherboard has some interesting jumpers: ME_RCVR1 (restores CSSPS firmware when corrupted) and PCH_MFG1 (unlocks Flash Descriptor for full SPI chip re-flash via software, required to update the CSSPS firmware). It is possible that you need to set the PCH_MFG1 jumper before updating the BIOS from ASUS via the in-BIOS menu. However, again, these should not matter when using a programmer so that’s why the dumps make no sense to me.
sps4.rar (167 KB)
Maybe he’s dumping with the programmer only, and then updating the BIOS with software/built in flasher, thus ME does not get updated?
He may need to choose “Full Update” or enable ME Re-flash in BIOS or via BIOS mod, or move the jumper as you mentioned, if not putting on the new versions via programmer.
This mainboard is working with a retail 4114 right now, but has no power supply right now, so i am not able to flash it. I‘ll probably buy one tomorrow when they are on sale 
i have a 4110 with b0 stepping, but this wasn‘t booting and yes for now is the modded bios for b0 stepping on the board.
Yes that would make sense. Since programmers are now an option, the best thing to do is to use them to flash the stock ASUS SPI/BIOS image (after removing the capsule of course), run the system once and then dump it via the programmer again. Then the dumped SPI can be attached/linked here.
Jumper, always use that when it’s available. Thankfully this is an advanced workstation board so it does have end-user servicing functionality built-in.
I agree, much easier to update ME that way too, program it in all at once and you are done. Did you find a newer SPS FITc than 4.0.3.113? If yes, please PM me, thanks!
Yes that would make sense. Since programmers are now an option, the best thing to do is to use them to flash the stock ASUS SPI/BIOS image (after removing the capsule of course), run the system once and then dump it via the programmer again. Then the dumped SPI can be attached/linked here.
Yes, this is exactly what I have been doing. If someone can strip the capsule off I will burn the resulting binary with the programmer and we will see what happens. Failing that I will try changing the jumper and flashing the usual way.
Unfortunately I do not currently have a retail CPU to boot with for any other testing.
Here is a temporary link for BIOS 3501 with the AMI Capsule Header removed.
That is also an option of course.
Flashed fine using the programmer, but still no change to the POST code. I got stuck at BB again.
Ah sorry, I don’t think I explained properly before. This will probably not help with B0 support, you’ll need to wait for LOST_N_BIOS who is trying to help you with that. I have been trying to find a dump from such a system (with CSSPS 4 firmware) for many months for some research and now that I did, it’s not what I expected. Thus, I pitched in because I saw that the dump was weird for two reasons:
1. It didn’t match exactly what you guys were flashing. Updated BIOS but outdated CSSPS firmware. Turns out, that was because of the missing jumper placement. In the future, I suggest you set it whenever you want to re-flash via the in-BIOS menu. Otherwise, use the programmer for both flashing and dumping. This one is solved.
2. The CSSPS firmware of the dumped SPI image has improper initialization which makes no sense for a system which has booted at least once. I have an idea as to why that may be. Before you uploaded your previous dumps, had you ever run the system properly with a working CPU? It you were trying B0 only then maybe the CSSPS firmware never managed to initialize and that’s why it seemed weird once dumped. Can you run the system once using a working CPU and then dump the firmware once you have re-flashed 3501 to see if that’s causing the issue?
Plutomaniac - I believe everyone has booted with other CPU’s, but they would have to confirm of course - can you please send me any 50654 “PRE” microcodes if you have them, thanks! I looked but could not find anything older than PRD 0x29
@All that can, with B0 CPU’s - Lets test initial launch BIOS 0303 - (Including ME, set jumper or use programmer (suggested)) - I have modified this @ microcodes only - removed 50650 - adding in 50653 for those ES and 50654 (one with stock Plat97-29 and one with slightly updated PlatB7-30)
Anyone testing these, especially if using programmer as suggested >> Please keep a backup safe and ready, for recovery reasons, and during this testing since I am not using anyone’s backup, board serials, UUID, DTS Keys, and LAN MAC ID etc will be lost/null during these test
If success, to remedy above, we build from your backup, or flash back in your backup and then reflash this using Asus built in flash tools.
http://s000.tinyupload.com/index.php?fil…217828811430769
@plutomaniac I have never had a successful boot with this board, so your theory about firmware initialization never being done would be correct in my case. I do not currently have a retail CPU to test with, but I might be able to get a loaner 3104 next week.
@Lost_N_BIOS No good from my end, I still get the same error (I tried both binaries your provided).
That makes sense @malucul , thanks for the confirmation. So I assume that the dump made by @levelud was also after an unsuccessful B0 boot attempt. If any of you can produce a proper dump after a successful boot with a working CPU, please attach/link it here. You would need to use the programmer to flash “WS-C621E-SAGE-ASUS-3501.bin” or “WS-C621E-SAGE-ASUS-0303.bin”, boot the system properly once with working CPU and then dump the SPI chip.
Restricting QS/ES CPUs is usually done in the BIOS by the OEM or at the Engine firmware or even in hardware/PCH (i.e. HM70). If it’s restricted in hardware there is nothing you can do but such a counter-measure is very unlikely in this case. If it’s restricted in the BIOS by the OEM (most likely) then you would need to figure out how to mod the BIOS to get around that but I’ve no idea how to help with that. If it is restricted via the Intel Engine co-processor (CSE), which runs SPS firmware (CSSPS), then you could try nuking/corrupting its firmware via me_cleaner, since I have seen some (rare) cases where such an act would allow running Xeon CPUs on “Consumer” PCH. Not the same but I figure it is worth a shot. For the latter, use the programmer to flash “WS-C621E-SAGE-ASUS-0303_MOD.bin” or “WS-C621E-SAGE-ASUS-0303_HAP.bin” which are produced by the oldest SPI/BIOS from ASUS (0303) after removing the Capsule Header via UEFITool and running “me_cleaner WS-C621E-SAGE-ASUS-0303.bin -O MOD.bin” or “me_cleaner WS-C621E-SAGE-ASUS-0303.bin -s -O HAP.bin”. If both fail to boot with B0 then the restriction is either not at the CSSPS firmware or it is applied at very early stages of CSE co-processor initialization (which starts before the main CPU) so there is noting you can do. But, as I said, my money is on BIOS ES/QS blocking by the OEM.
Here is a temporary link with the aforementioned images:
WS-C621E-SAGE-ASUS-0303.bin → Stock SPI/BIOS image without Capsule Header for programmer use
WS-C621E-SAGE-ASUS-3501.bin → Stock SPI/BIOS image without Capsule Header for programmer use
WS-C621E-SAGE-ASUS-0303_MOD.bin → SPI/BIOS image without Capsule Header and nuked CSSPS firmware A for programmer use
WS-C621E-SAGE-ASUS-0303_HAP.bin → SPI/BIOS image without Capsule Header and nuked CSSPS firmware B for programmer use
There is no such thing.