None loaded yet
n/a
Using the ectool, I extracted a copy of the ec flash before upgrading from the 3.03 that shipped to the 3.04. I also extracted a copy of the ec flash after upgrading.
Next I tried to rollback the EC to the 3.03 firmware and ectool did not report any issues.
Once I rebooted however, the board appears completely dead. No LEDs at all.
Contact support and let them know what was done. If the board was not exhibiting issues beforehand why update the firmware unless it was to enable a feature or patch a security hole?
There is a good reason why many BIOS are not downgradeable many times due to version mismatches in sub components.
Messing around with just the EC instead of a whole BIOS package (unless the reference is to the whole package and the OP just called it the EC) is dangerous for a reason.
This may be an expensive fix or a long lesson in troubleshooting.
I have reached out to support, but as of yet no response.
And no, not the bios, just the EC code.
What I was trying to do is learn how to compile my own EC code. Being cautious, I used the ectool to make backups of the EC firmware as I received it and after the whole BIOS upgrade to 3.0.4. I wanted to know that I could correctly flash the EC.
@Patrick_Little
Do you have the exact commands you typed that caused it to go wrong?
I could at least tell you where you went wrong then.
I have installed my own EC firmware versions on a FW 16 AMD 7840HS so I have some knowledge about how to do it safely.
Some other people are using my EC firmware, as it makes games perform better and helps prevent battery cycling.
If you have corrupted the EC, you are probably going to need a EC CCD and also a tool to flash the EC flash directly.
As a side note, FW seem to have made the FW mainboards quite easy to brick.
I extracted with ectool flashread 0 524288 lilac-3.0.3.backup.bin
Then I tried to flash it back with ectool flashwrite 0 lilac-3.0.3.backup.bin
I’ve looked into trying to get the CCD working already, and also am currently trying to drop PCBite probes directly on the JECDB pads.
EC CCD would be the way to go. See if you can get any console output.
If you can get some, there are some steps you can do to recover.
I have never actually tried the flash write in the way you did. So I don’t know if it would brick the laptop or not.
I use different commands to flash my EC.
What commands do you use?
Alas! This is one of the big gotchas.
The host command for writing to flash is quite low-level and it directly exposes the behavior of the flash chip. For most flash chips, this means that writes can only clear bits which were previously set–therefore, you must erase any region you’re about to write to before you write to it[1]. I’ve definitely broken a device by not doing this properly before.
Typically, I’d do…
ectool flasherase 0 524288
ectool flashwrite 0 ec.bin
Owing to this and another reason[2], I ended up writing a new version of ectool that you can use from the EFI shell and which supports a “reflash” operation. It writes the RW region first, then the RO region, and verifies the contents before proceeding. You can find info on it here:
Now, for the issue at hand. I have heard that the Nuvoton EC used in modern Framework Laptops supports a serial monitor with which you may be able to restore the firmware. I am unsure whether this is exposed via CCD or requires access to JECDB, but rumor has it that either way you will need to pull TX down to GND during reset.
https://electronics.stackexchange.com/questions/122550/flash-memory-does-the-entire-page-need-to-be-erased-before-writing-just-a-few-b (EE Stack Exchange) ↩︎
On the 11th Gen Intel Laptop 13, there was a contention issue with ACPI that would result in packets being corrupted in-flight. Having the OS running and doing ACPI things would exacerbate the issue significantly. ↩︎
So it was probably just using the wrong ectool 
Right now I’m trying to land PCBite probes on the pads of the JECDB and continue from there.
I use a slightly modified version of @DHowett “reflash”.
I add a few more safety features in, to ensure you only write it if all the checks pass, and you are really sure you wish to do it.
My instructions are here:
The EC flash can fit 2 images in it. For some reason, it calls one image the “RO” image. It is not readonly at all.
The other image is called the “RW” image.
By default it boots the RO image. You can use ectool to switch it to use the “RW”. If the “RW” image fails, it will always revert back to the “RO”.
So, all my experiments have only ever written to the “RW” image, so it always has a known good image to revert to.
My “safety” additions to the “reflash” tool just make it really really hard to accidentally write anything to the “RO” image.
For example, the default on the DHowlett is to overwrite both RO and RW images.
My default is to do nothing, and only overwrite the RO or both RO and RW if one adds a few more command line options.
DHowlett reflash already had some very useful features.
Thank you for that link and all the documentation in there - even a quick scan around and I’ve gained a bunch of insight into what went wrong and how to avoid it.
I’ve tried CCD, but I’m not getting any console output whatsoever. CCD works fine on my azalea board (same EC chip).