[REQUEST] Asus A550JK & K550JK & X550JK BIOS Unlock

[Lost_N_BIOS]

That may or may not work, in the situation we are discussing, but you'd only find out if it failed after a risky reboot. Proper way would be to reflash the original dumped FPT BIOS region, but it's very hard to know the outcome since I did not see the original command, the original error and then the final message.

What I was mainly confirming on your question, in a normal situation where you dumped a BIOS region, edited it, then flashed back via FPT, but knew it would brick on reboot due to some error or you noticed bad edit in the BIOS etc, yes, before a reboot you could write in a proper BIOS region again via FPT before rebooting and that would fix any possible mistake the first one caused since no reboot yet.

In your particular case, it may or may not have mattered, due to the "Size error" you got that mean you either did not write to the BIOS region, or you wrote in more than the BIOS region (So wrote over some other region also). So following that with a proper BIOS region re-write may not have fixed it, due to the other non-BIOS region areas that were written to following the "Size error" and you saying "Yes" to flash anyway.

GUI only does the CMD line stuff in the backround, same as you would do in a CMD line. Let me know once you get the new system going and we can try again, this time you stop and take image on any and all errors and do not move forward until I say OK

[shong57]

As an answer to the "flags" I added into the command, it was exactly the ones you instructed me to type in; flashing only the bios region. And the size mismatch error pops up after I flashed the modded bios dump.

And yeah, I'll be slower this time. I was too quick and excited that time.

[Lost_N_BIOS]

You can't get size error when flashing same size file as the region being flashed, so something was wrong there, mistyped flag, or some issue with using FPTx64 possibly, some Win10 issue etc

[shong57]

Lost_N_BIOS pid='153108' dateline='1555643930']You can't get size error when flashing same size file as the region being flashed, so something was wrong there, mistyped flag, or some issue with using FPTx64 possibly, some Win10 issue etc

So, I got the laptop fixed. Should I try doing it again? I'll first test original FPTw by making a dump of current bios by the way. I'll let you know what happens.

EDIT: Here's the result when I tried using 32-bit fptw.

   

[shong57]

Hmn, well, after thinking a lot for quite some time. I have a question. Am I able to verify the bios bin first before flashing it? The fptw seems to have that command, I tried using the flag "-help" and it came up with a lot of flags for me to choose from. And there's one related about verifying, it's "-verify"

Sorry for the long delay though, I got kinda shaken up from the bricking last time. 

[Lost_N_BIOS]

Ahh, so a crap Win10 issue, not a FPT issue! Do from DOS instead then, it's better doing that anyway, then you don't have to worry about 32/64 bit, nor running CMD as admin or having ME FW drivers installed.

The verify function from FPT only verifies the file it dumps (right then) vs the same contents it dumped from, or verifies that it wrote what you gave it.

If you get size error again, don't reboot the system! Show me image of command entered and error all on same screen, then leave system as-is without rebooting until we can correctly flash it.

No worries about long wait to reply back, I know that feeling too You can save yourself from that stress by ordering Ch341A + SOIC8 test clip w/ cable, total cost shipped $6, let me know if you need some linked examples. A set of those will save you from any future bad BIOS flash, and it will also allow you to flash in anything you want, anytime, without restrictions

[shong57]

Mhm, okay then. But how do I get the DOS version to work? I don't know how.

But still, I got some picture of me trying to verify the bios dump you made for me. And the size mismatch only shows when I tell it to verify the one you made. The normal unmodded dump is fine though. I don't think it's FPT problem, but if it is. I'm fine with doing it the other way, just wanna make extra sure.

[Lost_N_BIOS]

Boot to DOS on USB, here's how to make bootable DOS USB if you don't have other preferred method
Win98 SE USB Boot (Follow steps 1-4 to create bootable USB)
https://www.win-raid.com/t3756f16-lt-Req...l#msg53541

Once you've created that, copy all contents from the FPT DOS folder to the root of USB (nothing in folders), and a copy of your original biosreg.bin and the mod biosreg.bin file.

I don't see any Size Mismatch errors there, only Data Mismatch in those images, which is expected since you are comparing mod BIOS with current BIOS contents

[shong57]

Boot to DOS on USB, here's how to make bootable DOS USB if you don't have other preferred method
Win98 SE USB Boot (Follow steps 1-4 to create bootable USB)
https://www.win-raid.com/t3756f16-lt-Req...l#msg53541

Once you've created that, copy all contents from the FPT DOS folder to the root of USB (nothing in folders), and a copy of your original biosreg.bin and the mod biosreg.bin file.

I don't see any Size Mismatch errors there, only Data Mismatch in those images, which is expected since you are comparing mod BIOS with current BIOS contents

Oh well then, I also tried flashing the bios directly from the cmd. And it gave me same error as when I tried to verify it, I quickly flashed the unmodded dump back of course. I guess doing it the DOS way will work. But if the error pops up even in DOS, will I be able to flash the unmodded dump back? I'm too scared to make any mistakes again. 

Also, another question, can I fix the 15 seconds POST delay? When the laptop returned to me after the shop fixed it, it came to me like that.

[Lost_N_BIOS]

Directly from CMD, in windows, if yes, why??? We already confirmed that should not be used

Yes, in DOS you can reflash other dump too, as long as you do not reboot. If you get the same error in DOS, then I will redo the mod, but I think this is a windows related issue, or your BIOS chip is somewhat faulty and not allowing some byte to be erased or written (I doubt the replaced it, probably reprogrammed it in two minutes and sent back to you)

Sounds like they possibly broke the ME FW causing the 15 second delay, we'll have to check that later

Did you order CH341A + SOIC8 test clip cable yet? You should have long ago and it would been there by now, only costs $6 total
Then you wouldn't have any of these issues, or worries