Cant do first command: "fptw64 -f spi_fix.bin"
Error 368: Failed to disable write protection for the BIOS space.
FPT Operation Failed.
f.rar (431 Bytes)
Download the fixed partitions to flash manually:
http://www.mediafire.com/file/ujkql1796k9ej5x/fixes.rar
1. fptw64 -desc -f fd_fix.bin
2. fptw64 -gbe -f gbe_fix.bin
3. fptw64 -me -f me_fix.bin
4. Update BIOS via the in-BIOS flasher using spi_fix.bin
5. Reset BIOS defaults
6. fptw64 -greset
Everything should be ok now.
Hallelujah! It worked! Everythingâs good now. 
If itâs not too much trouble, I wouldnât mind knowing if there are any differences between the ME firmware in the BIOS and the one at ASRockâs microsite, or any other interesting features about the BIOS. Iâm guessing thereâs an extra step necessary somewhere along the way that the boards without HDCP 2.2 can ignore. Itâd be interesting to see if any of the code has anything useful to researchers.
EDIT: Hereâs a possibly interesting point for researchers. I took a risk and tried to update the LSPCON firmware myself after the BIOS flash. (The LSPCON was still at 1.66.) I bumped it to 1.72, based on a download for some Intel NUCs. I checked, and sure enough, HDCP 2.2 was broken again. I downgraded to 1.66 for the Z270 version of my board. Still broken. When I flashed the full BIOS again, HDCP 2.2 worked again. I could be way off but I suspect one of two things is happening.
- The ME firmware somehow expects the LSPCON to stay at a certain version/config without board-specific code/steps being used during the upgrade process. When changed, ME gets confused and shuts down HDCP 2.2.
- The LSPCON firmware is board-specific. If you flash it, the HDCP 2.2 keys get screwed up, and HDCP 2.2 stops working.
My uneducated guess is that itâs a bit of both. The BIOS download may flash ME and the LSPCON in order to keep them in sync. It also accounts for tinkering fools like myself. 
Anyway, itâs all there if anybody would like to tinker with the BIOS code and see whatâs inside. Iâm definitely curious.
@ crown_nick:
Ah thatâs great. So it was a bug in ASRock BIOS after all. I can verify that the CSME from 1.10, 1.11 and 1.40 have the exact same settings so the problem wasnât there. I suppose that at MEInfo you still see None at LSPCON. If thatâs the case then it seems that it doesnât matter.
The CSME inside the BIOS/SPI image is Configured (EXTR) whereas the Unconfigured/Stock (RGN) provided by ASRock are used for FWUpdate tool purposes only in this case. They are the same found at the first post. Read the âFirmware Regions (RGN/EXTR)â at the first post as well as Section A of the CleanUp Guide to understand the difference between RGN/EXTR and DATA Configuration states.
first command error: fptw64 -desc -f fd_fix.bin
Error 451: The host CPU does not have write access to the target flash area. To enable write access for this operation you must modify the descriptor settings to give host access to this region.
FPT Operation Failed.
f.rar (626 Bytes)
@ crown_nick:
It should be the latter as HDCP is licensed so I assume the firmware is board/OEM specific. It could also be some sort of security counter-measure in conjunction with CSME & SGX but my uneducated guess goes to the latter point you made at your edit.
@ Gleb:
Did you reboot after doing âsetup_varâ the last time? That command is temporary and works until the next reboot. So you need to do the âsetup_varâ steps again and then those of the last post.
Sweet. Iâll take a look. (Also, if youâre curious, I added an addendum to my original post.)
FYI, the LSPCON Ports entry didnât have anything. Iâll read up on the points you mentioned. Sounds like thereâs something unique in the firmware found in the BIOS that my board needs. Iâm not surprised. I just wish ASRock had put up a big warning when they put out their original firmware fix, stating that people like myself should wait. If wishes were fishesâŚ
Yes, it was rebooted, i try again.
4. Update BIOS via the in-BIOS flasher using spi_fix.bin
spi_fix.bin must be on flash disc and update bios inside bios tool, yes? Normal updaiting bios?
Saw and replied by an edit of my own. 
Doesnât sound strange to maybe have some sort of BIOS GUID or similar which holds something HDCP board specific but I wouldnât know. In this case they did mention that SGX was broken/disabled so that was probably it. I guess someone could bin-diff the two SPI images from ASRock and see what has changed via UEFITool/UEFIExtract but that may sound easier than done if ASRock has made a lot of changes since the beta.
Well the BIOS was Beta to be honest. I assume that they hadnât realized that HDCP was broken before your report.
@ Gleb:
Yes, normal BIOS updating at that step
First command still doesnt work.
When i loaded from flash disk i run setup_var 0x6a9 0x01
pressed "enter"
wrote "reboot"
and i tryed write "exit" still first command doesnt work
IMG_0573.rar (2 MB)
Normally I would tell you to reflash the CSME region only but in your case I can see that your GbE firmware is also corrupt/missing. Anyway, try from step 2 (ignore the Flash Descriptor reflash). There is no ârebootâ command afaik, just issue the setup_var command and then reset/CTRL+Alt+Del or something.
Last guestion, i have warranty on my mobo, this flashing will not cancel warranty ? And this is 100% error in mobo? Cuz if that flashing will not work i must sent mobo to asus.
Yes, it is a SPI image error. No it technically wonât because they wonât know about it and you can repair your system without dealing with support & time-lengthy RMA processes.
There is a good chance that the BIOS option we enable via setup_var unlocks the ME region only, maybe thatâs why you cannot reflash the rest (BIOS excluded, it has its own irrelevant protections). In that case, we can definitely repair the ME region at least. Do âsetup_var 0x6A9 0x01â, reboot, âfptw64 -me -f me_fix.binâ, reboot, âsetup_var 0x6A9 0x00â, âfptw64 -gresetâ.
That should fix the ME firmware problem. However, I did notice that another region (Gigabit Ethernet/GbE) is corrupted. Since your motherboard has a socketed SPI chip, you can buy a cheap 5$ programmer and fix everything at once using the original âspi_fix.binâ I gave you. If you donât want to do it yourself then you should RMA it as long as Warranty exists. In your case it is not difficult to fix with the aforementioned cheap programmer but the choice is yours.
Hello,
If I use âfptw -d test.binâ and I will get dump instead of access error, compare it (as here recommended using Beyond Compare utility) to bios from manufacturer home page - they must be identical? Does â.binâ extension play roles here, because official bios file doesnât have extension.
The extension does not matter at all, it could have been called âbanana.swordâ and that would have changed nothing. As for the question, no they wonât be the same as the ME firmware is not static. Read Section A of the CleanUp Guide to learn about âInitializationâ.
@ plutomaniac
ok,
If no access error, then it is safe to use fpt? As I could understand earlier, Gigabyte provides full SPI bios Image.
And the command will be 'fpt -f BiosFileName(without any extension)? Or some extra parameters can be used for better result?
It is safe to run under Windows or better in DOS?
*My point is just to be sure that bios was fully rewrited(without hardware programmer).
Honestly, you constantly ask questions and most of them are borderline useless to say the least. If your system is ok, leave it. Nothing more needs to be done.
@Plutomaniac
I ordered a programmer cuz if we can fix ME Fimrware, second problem will still open.
After procedure with programmer what i must to do? Update bios or samething?
@ plutomaniac
ok,
But my system is not ok(itself restarts/wakes up after shutdown/sleep and issue is not related to OS or PSU). That is why Iâm asking about full bios reflashing. Just to understand the issue is bios related or not. Or motherboard is defective.
Intel MEI Driver v11.7.0.1054 MEI-Only Installer
@ Gleb:
Good choice. You can fix all problems quickly that way. Once you get it, you can basically follow the guide from CodeRush that I linked above using the âspi_fix.binâ full SPI chip image. You can ask for help again when you receive the programmer if you like, no problem.
@ andr84:
I remember that we have talked in the past as well but I help so many users with so many different issues that I cannot possibly remember what your systemâs problem is, what we tried, what I suggested and so on. Especially after a long period of time. So Iâd like you to tell me all these details, I donât have time to go back many pages and read them all to figure things out again. Help me out to maybe help you as well.