Success in recovering from bad BIOS upgrade - Framework 13 AMD 7040

Only if it is caused by the firmware being damaged.

I’m not sure why the board doesn’t boot. I got it through a mystery box order. I’m trying to troubleshoot the issue. I got the following error code when trying to boot the laptop: wggggggggggggobggggggg

Did you get a .fd file from that?

Yes. If you use it on the capsule, it should produce biosfile.fd and ec.bin.

Great, thanks! Any idea how to find the bios chip on the 16?

Also, which one of those is the right one to flash?

It should be a WSON 6x8 on the top side of the mainboard, potentially under a plastic flap. You can confirm via the markings that it is a 128Mb or 256Mb flash part.

You will want to flash BIOSFILE.FD to it.

Make sure you use the right voltage. :slight_smile:

Really great topic, saved my motherboard after a BIOS upgrade failure! (3.18 → 3.20)

I followed your steps (bought the same stuff for ~32€, used the same tricks with ceramic coasters - first time I used them in ten years :sweat_smile:, same commands) and it worked!

Some notes:

  • I also did four ROM reads and got one failure (the second read). The pogo was stable.
  • Reading the ROM takes 4m40s.
  • I extracted the 3.20 BIOS from the UEFI capsule by searching the first four bytes hexdump showed me from my extracted corrupted BIOS : 0810 5f00
    • I found the offset from start to be 1993293 bytes, like cesfahani said above with BIOS 3.07.

    • I also tried GitHub - vaginessa/InsydeH2O-extractor-2 · GitHub as mentioned above, and it gave same BIOS image.

    • Extraction command:

      tail -c +1993293 Framework_Laptop_13_Ryzen7040_capsule_signed_allsku_3.20.cap | head -c 33554432 > framework-3.20-rom.bin
      
  • Writing the ROM was a bit frightening : I had two fails, the third time it worked. :fearful:
    • First time I used -w only (so with verification enabled by default). It took 12m51s and finished with verify error: :anxious_face_with_sweat:

      $ flashrom --programmer ch341a_spi -w framework-3.20-rom.bin --progress
      flashrom v1.6.0 on Linux 7.0.0-28-generic (x86_64)
      flashrom is free software, get the source code at https://flashrom.org
      
      Found Winbond flash chip "W25Q256JW" (32768 kB, SPI) on ch341a_spi.
      Reading old flash chip contents... 
      [READ: 100%]...done.
      Updating flash chip contents... 
      Fixing total value of stage 2 progress on the fly.
      [... skipped some noisy output ...]
      [READ: 27%][ERASE: 100%][WRITE: 94%]...Erase/write done from 0 to 1ffffff
      Verifying flash... 
      [READ: 100%]...FAILED at 0x002db827! Expected=0xf5, Found=0xeb, failed byte count from 0x00000000-0x01ffffff: 0xd96
      Your flash chip is in an unknown state.
      
    • Second time, I used -nNw to skip verification. It took 4m40s to write. Then I did a read to check myself, and the checksum was not matching again :scream:

    • Third time, I used -w with verification. It took 9m21s and terminated successfully: :face_exhaling:

      $ flashrom --programmer ch341a_spi -w framework-3.20-rom.bin --progress
      flashrom v1.6.0 on Linux 7.0.0-28-generic (x86_64)
      flashrom is free software, get the source code at https://flashrom.org
      
      Found Winbond flash chip "W25Q256JW" (32768 kB, SPI) on ch341a_spi.
      Reading old flash chip contents...
      [READ: 100%]...done.
      Updating flash chip contents...
      Fixing total value of stage 2 progress on the fly.
      [READ:  0%][ERASE: 100%][WRITE: 100%]...Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Fixing total value of stage 1 progress on the fly.Erase/write done from 0 to 1ffffff
      Verifying flash...
      [READ: 100%]...VERIFIED.
      

      I did a read and checksum again to be sure, and it matched! :grinning_face:

  • Then I unplugged the CH341A from USB, removed the pogo, put back the RAM and SSD on the mobo, connected the battery, the keyboard and closed the case. I powered on the laptop, and about one minute later, it was booting on the SSD :smiling_face_with_sunglasses: :partying_face:

Where would someone with zero hardware experience learn all the background and details necessary to do this? I have not even heard of some of these gizmos being thrown around in this thread, so it might take a while. However, I am out of warranty, so if this destroys my mainboard, I would have needed to buy a new one anyway. Any useful YouTube guides?

Since you’re out of warranty, well there is not much to lose…

you can watch this video to get an idea of how to do it (there are several methods in the video, some of us here like me used the pogo pin + CH341A one) :

https://www.youtube.com/watch?v=kB7scNyY8Ck

I think this would be an ideal subject for an official FW video on how to recover from a failed bios update.
Ok, it is really fiddley, probably best done with a soldering tool, but maybe, if FW saw how difficult it is, they would design the next mainboard better and make the process easier.

Thanks! I’m wondering if you also used a Raspberry Pi like the original poster. My understanding is that the “good” firmware needs to be transferred into the corrupted chip, so I’m wondering where that good firmware comes from. AI is telling me I can simply transfer from a working Linux laptop. A full shopping list would be very helpful (if you have time).

The good firmware can be downloaded from official BIOS release topics like Framework Laptop 13 Ryzen 7040 BIOS 3.20 Release STABLE

Then you have to extract the BIOS image from the capsule (.cap) file. You can do that with commands given above (with tail / head).

I did not use raspberry pi. I have some of them, but not sure in what state they are (probably need to reinstall the system), and also require a little wire routing. It would have be a fun project but unfortunately I had really few time for that (day work, small children at home running all around and touching every new thing they discover :sweat_smile:), so I bought the programmer and necessary adapters in a rush.

Peculiar to me that Framework aren’t covering the brickings out of warranty when it is their bug that bricked it. Such shenanigans is what out of warranty recalls are for. If their policy is they won’t cover the consequences of their updates then they need to state they have no responsibility if their bios update fails and bricks the machine; and that bios updates should no longer be recommended upgrades for those out of warranty.

A BIOS with a bug like this should not be marked as stable any longer. I already criticized that on BIOS 3.18 with the bug regarding docking stations, but the bug wasn’t even mentioned in the known issues.

I don’t think anyone knows what is causing this yet.
It could be flaky hardware that the user hasn’t complained about before.
It could be a bug in the previous BIOS that has gone unnoticed so far.
It could be a bug triggered by particular hardware being left connected while upgrading the BIOS.
It seems to me that it’s probably only affecting a small percentage of people, but I’m uncertain about this.
I’ve successfully upgraded my laptop through every version of BIOS starting from, if I remember correctly, 3.03 with no upgrade failing, though some had bugs. I’ve no idea if I was just lucky, careful about avoiding possible things that could trigger unusual bugs, or happen to have 100% stable hardware. I can’t tell.

One more question. I was told by AI that the chip must be powered during the process. Does the pogo pins provide power, or should I power it some other way? Should the battery be taken out and the broken computer be left completely unpowered?

The flasher will provide power to the chip, yes.

I’ve done it with the battery connected and disconnected. The AP firmware chip is not powered by the bus while the machine is in S5/G3 but if you want to be doubly sure, go ahead and disconnect the battery.

Whether or not you are right, this is not the correct thread for it.

Personally, I did flash the BIOS battery disconnected and AC adapter unplugged.

Mine showed the same screen, as the original poster…

I couldn’t turn off the laptop.

I unplugged all of my expansion cards, opened it up, and unplugged the battery, which shut the machine down.

plugged the battery in, plugged a usb c expansion in and a 100w usb c power source.

Turned the laptop on.

It eventually showed a memory training screen, then a screen which is showed flash status… which eventually got to 100% and it rebooted.

Unfortunately it now doesn’t display anything…