Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commands to safely flash the FW16 EC. #56

Open
jcdutton opened this issue Dec 20, 2024 · 3 comments
Open

Commands to safely flash the FW16 EC. #56

jcdutton opened this issue Dec 20, 2024 · 3 comments

Comments

@jcdutton
Copy link

What are the commands to safely flash the FW16 EC.
I have the output "ec.bin".

  1. I understand that there are some flags to set, so the RO portion does not overwrite the RW portion.
    How do I set those flags?
  2. How do I ensure I only write to the RW section, so that I can recover from a bad flash if I need to.
  3. What is the recovery procedure if the RW section is written with a faulty image?
    Please can someone list the commands assuming all I have is Linux OS and an EC CCD serial console connected.
  4. Is there a way to load a test EC image into RAM and jump to it, without needing to write to the EC Flash at all?
    This would be good for test purposes.
@DHowett
Copy link
Contributor

DHowett commented Dec 20, 2024

Alas, this is somewhat underdocumented. It is for this reason that I wrote ECTool.efi.

I'll answer your questions as best I can given that as a reference point.

  1. Copy ec.bin to your ESP or other bootable device with the EFI shell roughly following the steps on my blog post. Flash it with ectool.efi reflash --rw fs0:\ec.bin.
  2. --rw will do this.
  3. If it fails to boot or the EC crashes, it will automatically fall back to the RO section. If you have CCD access and it does boot, you can probably issue sysjump ro via the console.
  4. Alas, no. I've done limited research on this which I've written up in framework-espi-recovery1

ectool.efi will prevent you from flashing an unrecognizable firmware image or one built for the wrong device.

Footnotes

  1. There's a branch on that repository that allows you to build arbitrary shellcode as a series of console commands that will live-patch a running EC. It has not been tested on lotus, azalea or marigold.

@jcdutton
Copy link
Author

Thank you. I am looking through the source code of ectool.efi to see what checks is does before writing to the flash.
What is the intention for what happens with this command:
ectool.efi reflash fs0:\ec.bin <- i.e. One accidentally forgets the --rw
I am wishing it to do nothing, unless one adds --ro , --rw or --all.
Regarding (1), are the flag setting not needed any more?
Regarding (4), one probably needs to add support for it in the early flash boot. I.e. It waits for a specific pattern of bytes from the CCD serial port, and if it sees them during early boot, it instead boots via the serial port instead of from flash.

@jcdutton
Copy link
Author

I have experimented a bit. Safe ways to test new EC firmware:
Using the CCD, sysjump RW switches to the RW image. It power cycles the laptop to do this, so best done when the laptop is powered off, but attached to the PSU, so the EC stays on.
Steps that can cause it to return to RO.

  1. crash
  2. power off laptop and remove PSU and wait for 40 seconds. It causes the EC to power off (hibernate message on CCD console). But...I think the EC has to be working to power itself off.
  3. If 2 does not return it to RO, then a complete removal of power/battery should work or a system reset using the chassis open switch.

Note: I have not found how to set any of the "flags", so if the flags are different, other people might find different behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants