losing battery-charge while fully powered off #172
Comments
|
no response/activity -- closing |
|
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. |
|
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 |
|
@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. |
|
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. |
|
@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. |
|
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): 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). 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. |
|
@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 ... |
|
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. |
|
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. |
|
@fhvyhjriur I've had the opportunity to do some testing:
observations
|
alexgill
changed the title
|
@fhvyhjriur A few ideas for what is draining power from the battery when off:
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. |
To remove everything that could be not 100% clear in understanding: 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?
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 |
|
@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 😄 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. |
|
@fhvyhjriur Right, my mistake. |
|
@alexgill 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? |
|
@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 :) |
|
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. |
|
@alexgill |
|
@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. |
|
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. |
when the laptop is powered off, the battery will lose a couple percentages in charge per day -- i've been updating with new Skulls images (thanks!), and have also ensured USB charging is disabled in the nvramui
my superstitious hunch is it has to do with MEI, which I ran and re-uploaded successfully when initially doing the external flashing-- maybe those MEI gears are still turning..?
any direction would be appreciated, and I'll plan to close by the end of the month
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
The text was updated successfully, but these errors were encountered: