Hi,
Trying to find a block diagram or timing-chart on how the the boot-up flow works on the lowest level.
i.e. order of EC vs AP/SoC booting, where the first-stage firmware is located, and so forth.
also curious if there are any safety-mechanisms / recovery modes in case the EC firmware and/or the AP 1st stage / bootloader fails to be updated.
Thx!
Hi.
I have done work on the EC code so know a little about this.
I don’t think there are any safety-mechanisms.
I think the update program does some checksums and verifies it has written correctly, but if those fails or the laptop is switched off / halts in the middle you are out of luck.
If it fails to be updated correctly, one needs to send the main-board in for repair.
There are some reports of people using flash probes to recover, but that is not easy.
FW do not provide instructions on how to recover.
Summary: Be very very careful when updating the BIOS.
hi james, sorry late reply, new on forum so post notification ended up in spam.
interesting, I thought most intel/amd “EC platforms” and BIOS companies like Insyde had systems to avoid any risk of bricking a device. In the ACPI spec, there seem to be lots of (fairly bloated?) ways to use eSPI + nor-flash ic’s with 2nd stage boot-loaders that are write-protected. then use dynamic memory remap features to ensure a failed boot always can fall back to the previous firmware and/or a recovery mode.
so the BIOS in the framework case, where is that stored physically?
i believe these is one for the EC and one for the AP right? tried to find the code that runs the sequencing when updating early bootloaders, but was a bit hard to navigate the source (thus asking around here)
ps. there is a dedicated TPM ic on the board so guessing there are some pcr/root-of-trust happening too. is that used today?
I am not from FW. I am another user like you.
But, after reading threads like this one, I think it is quite easy to brick the FW and if there were easier ways to recover, FW support would have told that person how to do it.