Hmm, the web page says SOIC-8 (and some other things, I guess), and my WSON-8 test clip doesn’t fit. Is it because it’s a WSON-8 6x5 instead of a WSON-8 6x8?
That’s just a list of the packages that the chip is available in. It can be bought is any one of those listed.
I have a mixed update. It took a few weeks for the WSON-8 6x5 test probe to arrive, but it came yesterday. I was able to use it to pull the contents of the flash closest to the EC on the bottom side of the mainboard, and the first 0x80000 bytes exactly match what ECTool pulled in its backup, so that looks good.
The other two flash chips on the bottom have what appears to be other firmware for some other components. Both have very different contents and none of them match the ECTool backup, so I’m just going to leave them alone. If someone wants, I can post the contents of those chips somewhere.
So, feeling confident I have an escape hatch, I reassembled my laptop, and… it wouldn’t charge or boot. It had been disconnected from battery for like 3 weeks. I was pretty careful handling the mainboard, so I’m not sure what the issue could have been.
I saw some suggestions that I should pop out and in the CMOS battery and try trickle charging it. Unfortunately, I cracked the CMOS receptacle, so Framework is luckily replacing the mainboard for me. When I get that replaced I guess I will get new flash backups and then finally try the flashing.
2 Likes
While I’m waiting for my replacement mainboard, I had a question. Is there any reason why touching the test probe and doing “read” and “verify” operations from the flash programmer could mess up the mainboard? I still don’t know why the first one wouldn’t charge and want to make sure it wasn’t because of my read and verify to create the backup. I didn’t do any erase or write operations.
I can’t think of a reason that would cause a lasting problem. However, if you are using an 11th gen laptop you’re probably seeing the fairly well-known RTC battery bug. Sometimes it requires trickle charging the entire machine (not just the RTC battery) from a 5V source rather than a PD source.
I’m really glad you were able to verify the flash! Sorry that you ended up getting held up by unexpected tech trouble 
1 Like
Mine is 12th gen, so I didn’t think that was the problem. I wasn’t able to trickle charge it with a non-PD charger (or I didn’t wait long enough before I took matters into my own hands and broke the part, oops). Thanks for the response. New board is on the way, so I’ll see how that goes soon.
Well, everything is good now. I received the new mainboard and it works. I was able to use ECTool to reflash the modified EC firmware… had a bug there, was able to restore from backup and fix the bug and reflash again, and now my laptop is working like I always wanted. I ended up not needing to use my backup, but I’m glad I had it just in case, and I’m pretty confident it would have worked.
At some point soon I will write a blog from this because I don’t go through this much angst without producing something out of it, haha. Thank you to all who helped with various information and advice.
4 Likes
I’ve written up the entire process, including the bug fix and some debugging. I link to pictures and flash chip dumps that I uploaded, too.
Thanks again to everyone who helped out on this thread. For @DHowett, I link to a proposed minor feature for ECTool. For the Framework team I list a few recommendations at the end.
6 Likes
This is amazing! Thanks for writing it up, and I’m glad we were all able to be part of the journey!
Ah, and if you submit a pull request for ECTool.efi I’d be happy to give it a look 
2 Likes
Thank you for the effort of writing up this interesting journey!
Concerning the original behaviour that prompted your investigations: oddly, under linux with the 3.17 (11th gen) BIOS I am not seeing the keyboard behaviour you report. Instead I see:
- press “A” – key starts repeating after a short delay
- press “B” - a single “b” appears; starts repeating after (same) short delay
- release “A” – repeating stops, but after (same) short delay, repeating of “b” resumes
- release “B” – repeating of “b” stops (as one would expect)
So either the keyboard behaviour changed somewhere prior to 3.17 or linux handles the key press/release messages differently to produce repeating behaviour from it.
I guess I hope it’s linux; otherwise it’s rather tragic to go on a wild firmware goose chase only to have a firmware update void the work – although it does make for a better story if that were the case; and you (and the community) learned a lot along the way.
Huh, weird. I don’t see the EC firmware having any related updates recently, so I don’t really have an explanation there. It’s possible some of the “typematic” functionality is being handled in OS code, I suppose, so it could have linux-only behavior. I’m okay with how things turned out for me, though. I’m quite happy with my fixed laptop, it’s a good feeling to put a little “sweat equity” into it, and yanno, journey before destination, right?
If anyone happens to know how to build the zephyr based EC firmware (for a Framework 16), that’d be helpful.
From a quick look it seems I’ll want to build this EC firmware with this custom zephyr version, at which point I don’t think I can just follow the zephyr getting started guide anymore.
Unfortunately zephyr is like a black box, with “west” python wrapper around for normal use, I wouldn’t even know what to use after building the zephyr project. I thought Zephyr was an OS in the first place. Very confusing.
Any help is appreciated.
Then, for completeness sake, flash the firmware either with the framework-adapted ectools or perhaps better the ECTools.efi bootable tool by the same author.
FYI I’m trying to fix a power limit bug.
1 Like
That is not true. They recommend that damn wrapper. But it is not needed at all. CMake and a single CMake variable pointing to the zephyr git is enough.
And the EC firmware is not just zephyr. It is still Chromium-EC just with a zephyr core, so they can use Zephyrs large collection of drivers and utility code.
The Framework’s EC git is already setup with everything. You just need to execute the build-command the readme tells you and it’ll build everything, including Zephyr, for you. You barely notice the difference between the old Chromium-EC and the new Zephyr-based version.
You do not want to ever touch the zephyr version outside of core Chromium-EC development.
That’s all relieving to hear.
What build command do you mean? The inner one I linked uses zmake, which I have never heard of (I assumed it was a zephyr specific build command).
The one in the main readme
cros_sdk
cd ~/chromiumos/src/platform/ec
make -j BOARD=<boardname>
is also not clear since I don’t know where that path, and with that the makefile, is supposed to be.
Since there’s no resource on this that I could find, I’d very much appreciate a hint since you seem to know.
Seems I confused some things, and no the things I remembered only work like this for the older builds. And it is only documented and designed to build within the full chromiumos tree, which is just a ton of stuff that is wasted for just building the EC firmware…
Fair enough, don’t worry.
Sorry for pinging you @DHowett, but I see you have a PR merged into lotus-zephyr that you also deployed to device. Any chance for an updated blog post or some hints here? The thing I want to fix is super easy and obvious, and even the flashing is fairly transparent with your tools and blog post (just in case I got a bios flasher, still missing the adapters for WSON-8). But the building process isn’t really documented well or at all. If I really have to use a whole suite of non-standard tools I’ll probably spin up a new linux install just for that…
Hey @Seneral! Sorry, I’ve been busy - I would love to put together a quick blog post explaining how to onboard to building Zephyr. It’s annoying but once it’s set up it’s pretty straightforward. Once I get a little bit of time, I’ll do that and drop some info in here as well.
1 Like
Sounds good, thanks a bunch! Take your time, I’m not in a hurry, the thing I want to fix only reduces my performance by 3-4% for my use case while consuming less power - might actually keep my power profile like that anyway. But a bug is a bug and needs to be squashed:)
1 Like
Alright! This is the most barebones guide ever, but I wrote up the steps I took to go from Debian install (in a clean container) to ec.bin.
One of the real benefits to the new EC compared to the one in the Intel 11th-13th Gen Core laptops is that it does support the RW image. You don’t need to risk your laptop by reflashing the backup copy.
Once you’ve built it, grab ectool.efi from here, boot to the UEFI shell, and:
ectool reflash --rw fs0:\ec.bin
ectool reboot rw
(Adjust paths as necessary.)
6 Likes