search

merge / skulls

pre-built coreboot images and documentation on how to flash them for Thinkpad Laptops
GNU General Public License v3.0
677 stars 65 forks source link

losing battery-charge while fully powered off #172

Closed alexgill closed 3 years ago

alexgill commented 3 years ago

output fr 'util/me_cleaner/me_cleaner.py -c' ++++++++++++++++++++ Full image detected The ME/TXE region goes from 0x3000 to 0x500000 Found FPT header at 0x3010 Found 1 partition(s) Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000 ME/TXE firmware version 8.1.0.1265 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x The AltMeDisable bit is SET Checking the FTPR RSA signature... VALID

alexgill commented 3 years ago

no response/activity -- closing

fhvyhjriur commented 3 years ago

Could you try heads-maximized images? Those are prebuild images for the bottom-8M and top-4M chip. You only need flashrom to install them. If you have not flashed the bottom 8M-chip and unlocked the IFD, then you have to flash the bottom 8M chip with external flasher. What that would do: It would shrink, and disable the Intel ME closed source software. This could fix your issue. It would be interesting for many people if such a batery drain problem is related to a always-on Intel ME that would be fixed by disabling intel ME.

alexgill commented 3 years ago

hi, sure i'd like to try this, but checking this repo and Heads, i'm only finding the heads-maximized config -- where are these two pre-built images, thanks

fhvyhjriur commented 3 years ago

Yes, its at the moment not that clear where to find those images. You can read (if you like) the discussion about the heads maximized images here: https://github.com/osresearch/heads/pull/703

Its build in circleci. You can login/access circleci with your github account. Here the heads developer explained it: https://github.com/osresearch/heads/pull/703#issuecomment-735897035

The very latest build is from today. Its this one here https://app.circleci.com/pipelines/github/tlaurion/heads/636/workflows/20a7c648-5217-4aaa-af8d-d511212a14df/jobs/684/artifacts

There you can also find the x230 top spi chip image: https://684-103208611-gh.circle-artifacts.com/0/build/x230-maximized/heads-x230-maximized-v0.2.0-974-g5343fd3-top.rom The bottom 8m image: https://684-103208611-gh.circle-artifacts.com/0/build/x230-maximized/heads-x230-maximized-v0.2.0-974-g5343fd3-bottom.rom

And if you have already fully unlocked your IFD, you can flash internaly (no external clips required) the full 12m image: https://684-103208611-gh.circle-artifacts.com/0/build/x230-maximized/heads-x230-maximized-v0.2.0-974-g5343fd3.rom

Thrilleratplay commented 3 years ago

@alexgill Have you tried flashing the stock BIOS back or removing the battery from the laptop for the same amount of time to see if you get the same battery loss? If you are sure that it the device is being powered off and not in standby, it may be an aging battery. I recently replaced the battery for my x230. Try to rule out if it is physical or not.

@fhvyhjriur Why are you suggesting Heads to solve a battery problem!? First off, the firmware should have nothing to do with a battery drain and suggesting a user install Heads to solve an unrelated problem is irresponsible. Second, configuring a Heads devices is far more complicated than a Skulls device and requires a USB hardware dongle.

fhvyhjriur commented 3 years ago

I understood that the user have Intel ME enabled (quote "maybe those MEI gears are still turning"), have a external flasher and is willing to try out something. The heads-maximized images have ME disabled and shrinked. When @alexgill have the same issue with those images, then the issue is not related to "intel ME gears still turning in the background". This test would answer his speculation. Yes, removing the battery out of the notebook for the same time the percentage normally drops and compare if the loss is the same can be tested. But "intel ME gears still turning in the background" would still not be answered to the user.

alexgill commented 3 years ago

@Thrilleratplay thanks for considering and commenting: I'm fortunate to have three x230's, two with the Skulls image flashed and IFD and ME modified, along with multiple batteries for testing. Additionally, nvramcui has usb_always_on disabled. So yes, I've tried and re-tried of these combinations, and would rule out your suggestion. As a matter of interest, I've been looking to get Heads setup, so this is something I am happy was suggested, caveats acknowledged. Wondering though if this loss of charge is the case too for others.

@fhvyhjriur so I did flash the full image but am encountering a black screen and spinning fan, so will work on it and externally flash back if or as needed.

fhvyhjriur commented 3 years ago

Before reflashing back, try swapping DIMMs. Remove at first one dimm when you have two installed. Try to boot. Remove both dimms and let the x230 start for 10 seconds(of course it wont work with no memory). Then turn it off by disconnecting all the power sources instead of pressing the power button. Leave it for a minute and then install one dimm and only the 20V-DC power source(no battery). This helped in my case few times when jumping between different images on the SPI-chip. It helps sometimes for example with EC and sometimes with strange raminit-savings in the nvram.

When this dont help, you can first try out with the external flasher the latest image from the branch named x230-external flash here: https://app.circleci.com/pipelines/github/tlaurion/heads?branch=x230-external-flash

For external flashing here the top(4m): https://679-103208611-gh.circle-artifacts.com/0/build/x230-maximized/heads-x230-maximized-v0.2.0-989-ge4b3344-top.rom And the bottom(8m): https://679-103208611-gh.circle-artifacts.com/0/build/x230-maximized/heads-x230-maximized-v0.2.0-989-ge4b3344-bottom.rom

When it then still not work, i would flash a Lenovo bios backup first. If you dont have any backup made, you can read out the software from the third x230 you have not flashed with coreboot/skulls. When this worked, i would then download two lenovo-iso images that also flash the EC-firmware and jump between those two once (to make sure EC is flashed at least once). I would first use this one here: https://download.lenovo.com/pccbbs/mobiles/g2uj32us.iso And then this one: https://download.lenovo.com/pccbbs/mobiles/g2uj33us.iso

After i flashed the second updater image, the latest EC(fixed a security issue CVE-2019-6171 - more about that here https://github.com/hamishcoleman/thinkpad-ec/blob/master/README.md ) would have been flashed. I would then boot once, reset the bios config, boot once again and turn it off. Then flash once again the top and bottom image from heads-maximized(maybe again a different version from here https://app.circleci.com/pipelines/github/tlaurion/heads?branch=x230-external-flash ). This should finally work then because you have now really reset everything and every firmware-setting you could.

alexgill commented 3 years ago

@fhvyhjriur This is great info. I'm at the point where it's looking like the external flashing route is now next, and got my BIOS backups, along with those you reference. Question tho': flashrom is not recognizing or writing not matter the flags. With the outputted errors (below), at this point I imaging even with external re-flashing, there might no longer be an available option... My background with SPI is still small, so would you again please comment? 

...
Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xe3, id2 0x301f
Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xe3, id2 0x301f
Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xe3, id2 0x301f
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on buspirate_spi.
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xe3, id2 0x1f
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI).
===
This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
...
fhvyhjriur commented 3 years ago

What spi-writing/reading hardware are you using? You got the backup from the other x230 running oem lenovo bios and there you had no issues to read out the spi content from both chips?

General: The clip-connection on the SPI-chip is something really important. When having such issues, you can always remove and attach it once again to often solve such issues. Also use the shortest possible cables you have between the clip and the spi-hardware.

alexgill commented 3 years ago

After properly applying the SOIC clip connection, detecting/reading/writting/verifying was fine! At one point, A led on the cover (LED 4) blinked three times when power was given, but with subsequent flashing of different images, it's now in a state where pressing the keyboard power button lights for 1 second, but that's it: no fan activation or anything else except silence, even with the the DIMM procedure you recommend. With or without the CMOS didn't affect the outcome either. Not exactly sure where it went wrong, but if attempting this again on laptop 2, I'll have some better experience.

alexgill commented 3 years ago

@fhvyhjriur I've had the opportunity to do some testing:

observations

jcholsap commented 3 years ago

@fhvyhjriur A few ideas for what is draining power from the battery when off:

  1. Is a periperal attached, USB, wired ethernet, anything, that could be draining power?
  2. Is tthe mobo damaged where a component is failing and draining current?
  3. Was teh flash image corrupted? Perhaps the ME is, in fact, not disabled but busily thrashing about?

But you also said it is now bricked. Also, You don't need a DMM. But you do need to match teh correct RPI I/O pins to the correct SPI pins. And, I'm aware that there is an issue with the more recent Intel firmware update. 2019 I think is the "newer" update, anyway it has issues and I don't think you can disable the ME.

Try to recover by flashing back the backup images. That should help to divide the problem in half and indicate what is the issue.

fhvyhjriur commented 3 years ago

@fhvyhjriur I've had the opportunity to do some testing:

* after re-flashing and applying g2uj33us.iso and g2uj33us.iso,  external_install_bottom.sh ran but without option 'm' for ME cleaning -- after 12 hours powered off, there was NO battery charge loss (except for the cost of a power-up which is fractional)

* now re-flashing, but with ME cleaning, there was significant drainage having waited 12 hours  -- as if the laptop was in an S3 suspend mode

To remove everything that could be not 100% clear in understanding: You had flashed the latest g2uj33uc.iso that is the bios update lenovo-version 2.77 that include UEFI 2.77 (G2ETB7WW) and EC-Firmware 1.15 (G2HT36WW). This you installed on a different x230 that had never coreboot/heads/skulls installed?

Have you modified the IFD (intel file descriptor) by using external_install_bottom.sh from skulls to remove the write protection in the fist case? Did you later had not to disassemble your x230 and flash with external flasher to flash the modified/shrinked intel ME?

observations

* if anyone reading has a suggestion on what appears to be a bricked x230 (only the keyboard LED lights) please share your suggestion (use of multi-meter is rudimentary)

You have fixed now the x230 that appears to be a bricked x230? You flashed the backup from the oem-bios of a x230 you have made before or did you flash a backup from a different x230 that had still oem-bios running?

@jcholsap I think your ideas was for @alexgill and not for me, right?

alexgill commented 3 years ago

@jcholsap no peripheral connected, and same issue observed on more than one x230; and as for mismatching the RPI pins, if I did, I'm not aware :smile:

I have two laptops -- let's call them x230-1 and x230-2, and both were running the Skulls image with the ME disabled but losing charge... With the posting here on Nov 18, I took the recommendation flashing a Heads image internally, but resulting in a black screen and spinning fan. Where I might have errored is using the RPI4 to attempt the external flashing -- so in the end x230-1 is currently bricked.

This week, using a CH341_a on x230-2 (running Skulls), it was flashed back to its original oem-bios and both g2uj32us.iso and g2uj33us.iso applied. Thereafter, Skulls was flashed externally -- first without the ME cleaning option (which after one test seemed to not affect batt charge). Later I flashing externally, but with ME cleaning option (a test seems to bring me back to square one: I don't think the Lenovo versions affected with original issue).

I aim to perform some further testing over some 24-hour periods with an ME and non-ME setup and will revert.

Thanks for the replied and hope that's helpful and a bit clearer.

jcholsap commented 3 years ago

@fhvyhjriur Right, my mistake. @alexgill FYI, I have flashed mobos with an RPI4. It looks like you are on your way to isolating the problem. I suspect you can restore your X230-1 by writing back the original images. Did you know that there is an SPI controller in the battery? That "shouldn't" be an issue. But might be worth swapping batteries at some point as a matter of isolating the fault.

fhvyhjriur commented 3 years ago

@alexgill Great findings! Could you also put the known and on the x230-2 tested working spi-backup(both spi chips) on the x230-1 that was not booting up?

You have not accidentally broke off the PCB the famous resistor next to the SPI chip when attaching the SPI-clip on your x230-1? https://www.youtube.com/watch?v=6UqxOj2-MlM https://www.reddit.com/r/coreboot/comments/dhwdss/did_i_just_brick_my_x230/fmytpm0 Its a simple check done in some seconds and you can easy compare between both x230 devices.

alexgill commented 3 years ago

@fhvyhjriur Spot on -- there was indeed a missing SMD resistor and dabbing a bit of solder in its place got the x230-1 working. Since both heads-x230 roms had already been flash, I was able to boot fine. That was yesterday, and 25 hours later, the battery measured from 61.32 to 60.7 (on account of the boot up) -- this tells me there is no leakage. I have been testing this issue with Skulls and can conclude that with or w/o ME cleaning, there's indeed a slow but significant loss. The next troubleshooting I can offer is to flash Skull onto the top chip (while leaving heads-x230-maximized...bottom) and then test -- if you think it might be of use.

@jcholsap glad the RPi4 got the job done for you, and perhaps I might have been using the wrong 3.3v connection, but I indulge to believe that wire zapped that resistor away :)

alexgill commented 3 years ago

To conclude, since flashing Skull (top) with the Heads (bottom -- 'heads-x230-maximized-v0.2.0-989-ge4b3344-bottom.rom' linked to earlier), there's no more observed battery loss! Many thanks for the help. And although I'm not understanding the 'how & why' yet, I got the 'what', and so I'll leave this open for visibility this month before marking it closed.

fhvyhjriur commented 3 years ago

@alexgill Heads-maximized have different IFD(intel file descriptor), The freed up space by shrinking the intel-ME have been used by heads-maximized images for other functionality instead of leaving the space empty. The IFD in the **30 series is saved in the "bottom" SPI chip. Thus you are using now the modified/different IFD from heads-maximized but using skulls that was planned for the "oem-IFD". But its good to know that skulls is booting up. I dont know of any other reports that someone have tested that. Thanks for finding out that the heads-maximized-IFD works with skulls precompiled images flashed on the top chip. This kind of solved the reported issue here: https://github.com/merge/skulls/issues/178

alexgill commented 3 years ago

@fhvyhjriur running with the heads-maximized on the bottom has been just fine as far as I can tell -- thanks for all the input

In conclusion to the original issue of losing charge, no matter what's on the bottom SPI, loss seems to still happen if doing a 'systemctl hibernation' with Deb 11. If the battery is pulled and then re-inserted after hibernation, or with a 'poweroff', there's no observed drain.

alexgill commented 3 years ago

One final observation: the scenario of losing battery-charge while fully powered off is specifically after hibernation (STD), and in this state, while the laptop appears fully OFF, the Ethernet adapter will give a link-light... Pulling and then restoring the battery corrects this.