I was so happy to get my CJ64 working, but then I think I totally bricked it with a firmware update.
It went and did the update but during it the screen turned off and wouldn’t turn on again.
I let it sit for more than half an hour, then tried the power button, nothing.
So I put everything back into the laptop case and turned it on. Laptop display stays dead and no external displays are getting a signal.
When I turn it on the led on the side for charging is white (full battery) and the power button led glows white, no other colors but the screen stays dead.
Now I took out the ram just to see if it would flash error codes when turned on… but nothing, still power glows white and so does the charging led. After some time the cpu fan begins spinning, I thin k because the mainboard is heating up. A LAN expansion card shows solid green led and blinking amber led, like it should. But that all the life signs I am getting.
I tried the “Press power button for 60 seconds while battery is disconnected” … no change.
If it was a bad firmware flash and borked itself in the process something is probably corrupt or there is a version mismatch.
@MJ1 is probably on the right track and it might take low level diagnostics to recover.
Curious if a mainboard reset could get it to at least POST.
The EC console might have a clue as to what is going on. I wish this was a part that was offered from Framework directly. Others have made their own expansion card to get the output; it would be a nice little accessory that might sell really well.
Thanks for the hint, if I understand knuts writeup correctly I need a CH341a flash programmer and a WSON8 Probe to connect the usb flash programmer directly to the EC chip on the mainboard, power the mainboard and reflash it via a program called ectool?
Hey hey, the tools arrived and I am trying to figure out which is the right chip, there are three Winbond 25q80ewig on the board, one on the top side between nvme slot and and (below) the ram and two on the back side mirrored left and right near the USB ports. ( Schematic )
I am assuming it’s one of those three right?
The Nuovoton npcx993f seems to be the EC, so I assume the winbond chip on that side is the one I need to flash?
I would think the larger flash chip, the Winbond 25r256, is for the EC. But yeah, whichever is next to the Nuovoton npcx. I think the EC flashing write-up has a part about reading out the flash first. Always good to read & save a backup of it first.
Hey thanks, I did that now got a .bin file of about 104k out of it.
Now I am wondering which file to actually write onto the chip. Is it the winux.bin file from the efi shell zip? Or where would I get the correct file?
Thanks!
(Really, you guys are great, I couldn’t do this without all the help!)
p.s.
What worries me is that the wInbond chip, while the closest of the winbond chips to the EC is not really that close to it, and there is another winbond chip on the other side also near that sides USB ports. I wonder if those chips have something to do with the USB power controller.
The Winbond chip on the top side is bigger though than the other two and, while I ordered a 8x6 and a 6x5 probe they sent me two 6x5s, so I can’t interface with the top chip
If they read out the existing chip on the board, part of it is going to have the corrupted or non updated bios code right?
They would need virgin code to rewrite to the chip so the system has a chance at coming back to life correct or is this what is going to be flashed from the BIOS update package?
I remember someone else doing something similar and they needed a working copy from a functional board to write to this chip that another user copied and uploaded.
It has been a while since I reread those threads and became familiar with some of the details involved.
I saved both back side winbond chips to bin files, both bins have the same size, so I assume both winbond chips have the same content? Could it be a redundancy?
If anyone could capture the bios from their ultra 7 155h ec chip I would be really grateful, or could point me to the mentioned old upload.
It’s been quite some time since I read through the threads on recovering from bad firmware updates like this, but I thought I read of someone extracting the file needed from Framework’s official updates. I think there has been at least a couple threads on people doing this.
Yeah. The backup read out from it is unlikely to be useful, but as general procedure I feel it’s always good to save a backup. Maybe you realize you flashed the wrong chip! Or in some other way you wind up worse off. You can just restore your backup.
I’ve never seen mention of such redundancy, I don’t think there is. You could run a checksum on the files to see if they are the same.
I pulled the contents of this one off under the name “under-side_bottom-left_Winbond_25Q80DVIG.bin”. Finally, when I compared its contents to the dump I got from ECTool, it was an exact match.
The ECTool dump is the current EC firmware on the mainboard. So if the backup he read out from that Winbond 25q80 chip matched exactly for him, then that is the EC’s flash chip.
He was doing this with a fully working mainboard if I recall. Just to identify the right chip and ensure that he could recover, via manually flashing, should he need it.
Presuming Framework continues to the Winbond 25r256 & Winbond 25q80 in the same way on your ultra 7 155h, as used on Knut’s board.
Thanks, so I just need to get my hands ok a working file then flash the chip closer to the Nuovoton and it should work, and if it was the wrong one I can simply reflash the backup.
Just need a file now.
I have used UEFITool NE to extract the .cap file from the EFI shell zip, but its 34.5MB big, I used an LLM to tell me what to do but it was making up stuff that didn’t work.
I have not found the correct file inside the cap file dump. There are a lot of header.bin and body.bin files in various folders.
Just to clarify the author in that post used the programmer to read the chip and HE saved it to left winbond-etc.bin
Then he compared what he downloaded from the chip directly vs the ECTOOL software and saw that the same code was in both extractions.
Not sure where one would find the correct binary file in the latest BIOS to flash to the current winbond chip.
Either it would take someone uploading a current working mainboard with the current firmware to download and upload the binary file or maybe support could put a message into the dev team to have them point out “oh it’s xxxxx file” in the current bios CAB screenshotted above.
It theoretically is possible to search all the files for a binary match of the code from the CAB vs. what was pulled off the chip but that only would work if the versions are the same and the current code on the board itself is not corrupted. Hope that is clear enough. It took me a few times reading it over to realize what was going on. Good luck. This is a good read.
The EC flash image will be 512 KiB and the AP flash image will be 16 or 32 MiB.
If you have dumps that contain any data, you will be able to identify which chip housed the EC firmware by the presence of strings like RO_FRID and marigold.
Just my 2 cents.
I think it is very unlikely to be bad EC firmware. It takes only a few seconds to flash, whereas the rest of the flash process takes 5-10 minutes.
So, i would skip trying to fix the EC firmware because it is very unlikely to be wrong.
You can even prove the EC is ok using a EC CCD to view its console port.
I would probably focus on getting the BIOS firmware fixed.
I would agree that it is not likely to be the embedded controller firmware. Your embedded controller is working fine: the charging lights come on, the power key light works, it responds to you clicking the power button; it does all of this without crashing, which would be indicated by the lights all turning off and back on.
