BIOS update without AC adapter

Hi,

Long story short, the mainboard receives power from battery, but not USB. I’m trying to get BIOS, specifically the PD controller part, to reflash (fairly sure that it just has the wrong firmware; I’ve already flashed the actual BIOS manually). Despite setting flag=0 under AC_Adapter section in platform.ini of the extracted BIOS capsule file (I’ve also tried commenting out the entire sections of AC_Adapter, then CommonFlash), the BIOS update still checks for AC and says “Please make sure system has adapter”, and EFI error 21.

There is a section in platform.ini that says

When enable and BIOS supported, power check will take care by IHISI, and NOT reference [AC_Adapter].

which I’m guessing is why modifying platform.ini doesn’t skip adapter check?

Any suggestions on what/where to modify to actually skip the adapter check, and maybe incompatibility checks while we are at it?
I’m currently trying to extract the capsule file, which UEFITool tells me contains the text “Please make sure system has adapter” (not sure how to extract CapsuleApp.efi), but ifrextractor tells me “Not enough IFR data found to complete extraction”.

EDIT (summary).
Board is flashed to FW 16 BIOS. Reflashed 13 BIOS externally (BIOS works). Flashed EC using EFITool (-f -f to skip checks, write both --rw and --ro images; EC works).
PD controllers remaining.

Why would you want to update BIOS using the battery alone? the mainboard receives power from both AC and battery. There’s no use case for battery-only BIOS update. If an AC adapter is out of reach you’ll run out of battery soon so it’s meaningless to rush a BIOS update. Better to wait until an AC adapter is reliably available. If the computer isn’t charging(according to your tag), updating BIOS alone is very unlikely to solve the problem, reset your mainboard instead

I literally said

the mainboard receives power from battery, but not USB. I’m trying to get BIOS, specifically the PD controller part, to reflash (fairly sure that it just has the wrong firmware; I’ve already flashed the actual BIOS manually)

Did you actually read the post, or just went by title alone?

I confess I am also struggling to parse from your post the reason why you’d want to do this. Could you state it another way? This safety check is there for a reason - to ensure that a battery drain problem doesn’t stop the BIOS update at a point where it might brick the motherboard.

(Bricked machines from BIOS updates are a bit of a hot-topic in this forum of late, and we don’t want more disasters than we’ve had already.)

You can check the EC version in the BIOS menu, what did you find

The board does not receive power via USB, likely PD controller firmware issue. I’m seeing if reflashing the firmware via BIOS update works.

Intel boards allow you to flash PD controller without going through CapsuleApp.efi, therefore bypassing AC check, not AMD boards apparently.

EC is another thing that needs to be reflashed, along with PD firmware, which would be easy if the BIOS update process doesn’t check for AC.

You can reflash the embedded controller firmware without AC power as well.

ectool reflash -f fs0:\ec.bin

(One -f bypasses the AC adapter and battery charge level check; two of them bypasses the board ID check so you can flash an incompatible firmware image.)

This is unlikely to be a firmware problem.
I different usb-pd chip is used on the right and left of the laptop.
So, see if the power adapter works from a different slot.

It is more likely that a FET has failed.
It might be worth looking at the mainboard and look for any chips that look like they overheated.

Ah, saw this post too late. I just took your code and commented out the checks. Unfortunately boots up into the RO image.

I looked more carefully, apparently this is a board that someone flashed a FW16 BIOS on to.

I looked more carefully, apparently this is a board that someone flashed a FW16 BIOS on to. ECTool reads “lotus” instead of “azalea”.

They do all read 5V, and work at least at USB2.0 if I use an externally-powered hub.

In that case, you may want to flash it without the board check (-f -f). You will want to replace both the RO and RW images

FWIW, right now, there’s no guarantee that any given Framework device can consistently boot the RW image even under normal circumstances.

Thanks! Just flashed it with --ro, and input cover works again! Good to know about booting RW images.

Now for the PD controllers.