L430 with BIOS G3ET68WW (2.07) / EC G3HT39WW (1.13)

[q60]

any way this works w/ my machine? i am interested in using 42T4235 battery.

[valpackett]

spispeed=32768

Whaaat?! That's ridiculously high, I've been using 1000.

Also, these clips like to not attach properly. In my case, if the Pi did not reset, it's not attached.

[leecher1337]

Also doesn't work with 1000. Hmm, so you attach all wires to the clip, then attach 3.3V on pin8 and then the Raspberry Pi resets? I just get a message about undervoltage for a short moment, may be due to my crappy power supply of the Pi, but as it's just a short undervoltage, I don't think it's the reason. Anyway, will try with a new Power Supply for the Pi tomorrow.

[valpackett]

I keep the clip always connected to the Pi, including 3v3 (using pin 17 for 3v3 since it's close to the others), when I need to flash I just connect the clip to the chip, if the attachment is good the Pi resets.

In-system programming is tricky, electricity is weird magic, this exact same Pi setup does not detect the flash chip in a different device I've disassembled recently (an IP camera) :/

[leecher1337]

I found some schematics where pin 3 and 7 also need to be connected to 3.3V. Is my PIN layout above correct?

[valpackett]

Yes, I have these two unconnected.

[leecher1337]

Verified that the chip clip is attached correctly with Multimeter probes, no luck so far. But I don't really understand why it works for you with Pin 7 being LO (as not attached to VCC):

HOLD - this is a 'wait' pin for the SPI bus. When pulled low, it puts the SPI bus on hold. This is different than the CS pin because it doesnt stop the current transaction.

[valpackett]

Boards usually do tie these pins to VCC (if they don't have fancy digital security control over WP), have you found something on the boardview suggesting otherwise?

[leecher1337]

You are right, this sounds reasonable. As I read that the CH431A may connect these lines to VCC (which would be OK for flashing a chip in the Socket, which worked with this programmer), could it be that I trashed my board/chip by using the CH431A? :-/

[jwise]

FYI -- I have heard noises that the Nuvoton ECs get upset if they fail to find a firmware image (in particular, they may continuously try to reread the flash, which woul dprevent ch341a from talking to a flash that is controlled by a sad EC). I have heard from mjg59 that a board in such a state can be recovered by using an external power supply to power up Vcc on the flash and undervolting it sufficiently that the flash will operate but the EC will not boot. I have not tried this myself on my x2100.

[leecher1337]

Yes, there is an article explaining that: https://mjg59.dreamwidth.org/50924.html
However, after seeing that the chip clip doesn't work, as precaution, I made my experiments with another Mainboard which is designated to go to the Trashbin anyway. That Mainboard also has the same Flash chip and also shares Flash with the EC, but BIOS is unmodified and therefore OK, so EC should be able to read the flash without issues on startup. So I guess there must be another problem why it is not readable.

But it could very well be the reason why the CH431A doesn't work. According to Schematics, the RUN Led is connected to CS. As connecting the CH431A directly emits not only VCC but also a CLK signal, it could interfere with the EC also powering up and trash the Clock signal on the line. So maybe I have 2 problems here: RaspPi not working, maybe due to wires being too long or something like that (that would explain why it works for unrelentingtech, because CLK gets initialized only after EC initialization when running flashrom) and CH431A not working because it doesn't let the EC initialize properly by spamming the CLK line and trying to grab CS?

[leecher1337]

Edit: I did some further experiments on another board and found out the following:

As long as I leave CS connected to RaspPi, there is a clock signal on the bus, but no data is being transmitted, as CS remains HI. If I just leave MISO connected (or connect everything except CS) and supply GND and VCC, I can see traffic on MISO line, so the EC seems to search for his firmware. What really troubles me is that it never stops, so the EC doesn't seem to be successful in reading its firmware. Now as I did the experiments on a trash-board, this is quite alarming, as I didn't flash anything new to this board's BIOS, so either I have ruined the flash chip with my experiments (never connected more than 3.3V, so I doubt that I fried something) or there is another reason why the EC is unable to get its firmware, possibly corruption due to 2 masters on the bus...? As the RaspPi only has a 3.3V output, I'm unable to try the undervolting thing, I don't have equpment for that. So the only thing left to try is to pay someone to desolder the flash chip...? As RasPi seems to keep the CS HI, I wonder how @unrelentingtech is able to skip over EC initialization...?

[leecher1337]

@unrelentingtech Which chip clip do you use? The one that came with the CH431A is a piece of junk, used a few times, now it doesn't have a grip anymore and I cannot continue, as I only have 2 hands so cannot additionally hold the clip in place (besides that, cables are also falling off the connectors, seems they were not properly soldered, though they had contact, China-garbage!). Are these Pomona-Clips worth their money? They are very, very expensive.

[valpackett]

I use the usual aliexpress one, with very narrow spacing between the pins (didn't want to solder so I just spread the pins far apart enough that a 2.0mm pitch header barely fits on them)

[leecher1337]

Hm, sounds similar to mine then, is there something that I should take care of when using these? I wonder why mine went bad so quickly (after approx. 10 uses), it just doesn't grip anymore:

I'm asking myself if I should waste even more money just trying to recover it or just accept the fact that it's trashed. I'm really surprised that recovering BIOS is such a pain on these machines. It would have been interesting to find out if there is a way to properly flash with Lenovo update tool, but well, lesson learned: Don't use vendor tools.

[valpackett]

hm, no idea. Mine doesn't clip well on a different chip but does fine on the lenovo one.

Well, if you think it is the conflict with the board, desolder the chip and try connecting to it without the board having any possibility to interfere.

I guess another lesson is to ensure you have working flashrom before messing with internal flashing at all :)

[leecher1337]

Hm, will need to pay someone to desolder and resolder it. So in order to ensure that there is a proper image to flash before resoldering it (I guess this can be done max. 1 times and even this is risky), do you by chance have a full 2.54 ROM image (g3et94ww) which incorporates working EC firmware with my patches applied? Then I would just need to patch MAC address and other stuff from my Flashrom Backup and can flash it directly to the machine (flashrom backup didn't image ME area, so my image is incomplete in that regard). Not sure if I find someone who can do it anyway, but at least I have a 1:1 image that I can flash then.

[jwise]

If you're in the US, you can send me the board; I have both a setup to externally power things, and a hot air rework setup at my desk.

[leecher1337]

@jwise Sorry, I'm in AT, but thanks for the offer!

[leecher1337]

@unrelentingtech

Do I have to remove the CMOS battery before attaching the chip clip with the programmer to the flash chip?

I didn't remove anything, often not even the actual laptop battery lol

I do connect 3v3 to the Pi. I'm pretty sure the chip won't get any power from the system until the system is on (which requires the EC… so it must be able to turn enough power on without the firmware to be able to even read the firmware…?). Just tested with a multimeter, no voltage on any pins when the laptop is off.

As I haven't tried this yet in fear that I brick something: So, do I understand correctly: You always have PSU and/or the battery connected, so board gets supplied with 3.3V. You said that there was no current between Pin 4 and 8 of the SPI when machine is turned off. According to schematics 3D3V_SPI is connected to 3D3V_S5. I don't see a diode in the schematics that would prevent 3.3V from the Pi flowing back to 3D3V_S5. The KBC seems to be powered by the 3D3V_AUX_KBC, which is connected to 3D3V_AUX_S5.

Therefore, my simple question: Does flashing with the RaspPi work for you if you take out the Main Battery AND disconnect AC, or does it only work if you have either Battery or PSU or both connected?

[valpackett]

I have never even tried to connect AC. Flashed both with and without the battery, it always worked.

[leecher1337]

@unrelentingtech Success! I got a new chip clip and wired it to the RaspPi properly, verified all lines before connecting it to RaspPi and tadaa - worked! :)

So I'm back up and running. The interesting thing that I found out is, that it was indeed a checksum issue. I have no idea, how these images worked for you without the proper checksum. It should have failed all the time. The checksum algorithm was a bit tricky to find, because the field with the checksum in it never gets accessed directly, that's why I haven't found it. More information can be found in this commit: https://github.com/leecher1337/thinkpad-Lx30-ec/commit/cdb783ed2b7f8c18ac10d26ee668b358405973b6

I will now create an update for thinkpad-ec and issue a pull-request here asap.

[valpackett]

Interesting, maybe the state of the check was cached somewhere and I never waited enough time with no power connections to clear all the volatile memory.

In any case I gave my L430 away to a family member (as it was originally purchased for that), so have fun with further research :)

[fakamaz]

So I've installed x2100-ec-sys kernel module - no problem, yet when I try to run the code to actually force the battery to charge here's what's happening:

ThinkPad-L430:~$ sudo rmmod x2100-ec-sys

sudo modprobe x2100_ec_sys write_support=1

ThinkPad-L430:~$ sudo echo -ne "\x0c\x60\x02" | dd of=/sys/kernel/debug/ec/ec0/ram bs=1 seek=$[0x1004a]

dd: failed to open '/sys/kernel/debug/ec/ec0/ram': Permission denied

So, anyone here knows what's going on here? As technically I use "sudo" and I did enabled write support... And no errors where produced, yet it's still "denied"...

Also, when I manually go to the /sys/kernel/debug/ec/ec0/ram - I can go as far as to "ec", later it takes a huge amount of time to load any contents AND when I try to change "ec" folder permissions - they are being reversed as soon as I close the window...

I'm doing the above under Nautilus.

[valpackett]

@fakamaz you're doing sudo on the wrong thing. it should be on dd, not on echo.

[leecher1337]

You can just download and boot the ISO I created in https://github.com/leecher1337/thinkpad-Lx30-ec to conveniently do the memory patching.

[q60]

keyboard patches don't work for L430.

but battery patch works. the thing it yields is cd iso though, not an img file.

Generated dependancies from descriptions
./scripts/ISO_copyFL2 from_iso g3uj13us.iso.orig l430.G3HT40WW.s01D4000.FL1.orig 01D4000.FL1
./scripts/FL2_copyIMG from_fl2 l430.G3HT40WW.s01D4000.FL1.orig l430.G3HT40WW.img.orig
IMG at offset 0x4001d0 size 0x20000 (EFI::Capsule::PFH_header l430.G3HT40WW.s01D4000.FL1.orig)
./scripts/hexpatch.pl --rm_on_fail --fail_on_missing --report l430.G3HT40WW.img.report l430.G3HT40WW.img l430.G3HT40WW.img.d/006_battery_validate.patch
Attempting to patch l430.G3HT40WW.img
Applying l430.G3HT40WW.img.d/006_battery_validate.patch -4151,13 +4151,13
mkdir nuvoton-tools
wget -O nuvoton-tools/npce885crc.c https://raw.githubusercontent.com/leecher1337/thinkpad-Lx30-ec/main/fwpat/util/npce885crc.c
--2022-07-31 19:01:03--  https://raw.githubusercontent.com/leecher1337/thinkpad-Lx30-ec/main/fwpat/util/npce885crc.c
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.110.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3276 (3.2K) [text/plain]
Saving to: ‘nuvoton-tools/npce885crc.c’

nuvoton-tools/npce885crc.c 100%[======================================>]   3.20K  --.-KB/s    in 0s      

2022-07-31 19:01:04 (33.8 MB/s) - ‘nuvoton-tools/npce885crc.c’ saved [3276/3276]

gcc -o nuvoton-tools/npce885crc nuvoton-tools/npce885crc.c
./nuvoton-tools/npce885crc -o 0x8000 -u l430.G3HT40WW.img
NUVOTON Insyde firmware CRC calculator v1.00
(c) leecher@dose.0wnz.at 02/2022

Searching at offset 8000
CRC Start address=0048800A
Assumed load address: 00488000
CRC indexing offset = A
Calculated CRC = 9C, file CRC = 9C --> OK!
cp --reflink=auto l430.G3HT40WW.s01D4000.FL1.orig l430.G3HT40WW.s01D4000.FL1.tmp
./scripts/FL2_copyIMG to_fl2 l430.G3HT40WW.s01D4000.FL1.tmp l430.G3HT40WW.img
IMG at offset 0x4001d0 size 0x20000 (EFI::Capsule::PFH_header l430.G3HT40WW.s01D4000.FL1.tmp)
mv l430.G3HT40WW.s01D4000.FL1.tmp l430.G3HT40WW.s01D4000.FL1
./scripts/ISO_copyFL2 to_iso g3uj13us.iso.tmp l430.G3HT40WW.s01D4000.FL1.tmp 01D4000.FL1
mcopy -t -m -o -i g3uj13us.iso.tmp@@71680 g3uj13us.iso.report.tmp ::report.txt
mattrib -i g3uj13us.iso.tmp@@71680 -r -s -h ::AUTOEXEC.BAT
mcopy -t -m -o -i g3uj13us.iso.tmp@@71680 g3uj13us.iso.bat.tmp ::AUTOEXEC.BAT
mdel -i g3uj13us.iso.tmp@@71680 ::EFI/Boot/BootX64.efi
mattrib -i g3uj13us.iso.tmp@@71680 -r ::FLASH/README.TXT
mdel -i g3uj13us.iso.tmp@@71680 ::FLASH/README.TXT
cp g3uj13us.iso patched.l430.iso
cp g3uj13us.iso.report patched.l430.iso.report

Your build has completed with the following details:

Built ISO: 49d88353d0053474072c76225f24a03b22ecfca4  patched.l430.iso
Based on code from: l430,l530 BIOS 2.54 (G3ET94WW) EC 1.14 (G3HT40WW)
Buildinfo: v1-430-g7993bf (20220731) patched.l430.iso
Built FL2: 62e75acc69a9efca2b20c137af1209d784e0e2a8  l430.G3HT40WW.s01D4000.FL1

Patches applied:
l430.G3HT40WW.img.d/006_battery_validate.patch

i've tested this EC firmware on real hardware and it worked, but my battery seems dead - it's capacity is below 50% and it's in a deep discharge :/

also a small hint. if anyone runs into trouble upgrading firmware because of dead battery and removing it doesn't help...

1. download win98 bootdisk https://www.allbootdisks.com/download/iso.html
2. extract img from it using geteltorito
3. flash it on your usb stick
4. extract img from firmware iso
5. flash it on another usb stick
6. boot from win98 bootdisk
7. choose to not use cdrom support

8. c:
   cd flash
   rem do this to flash EC
   dosflash /sd /ipf ec /bbl /file g3et94ww/$01d4000.fl1
   rem bbl flag does some magic so it doesn't check for battery

[hamishcoleman]

@q60 there are no keyboard patches available for the L430, so that will always fail. Have you tried make patched.l430.img to make the image file? It looks like from your build logs that you are trying to make ...iso

[q60]

@hamishcoleman i did as you can see on the screenshot. logs show the same, i just disabled keyboard patches there

[leecher1337]

@q60 there are no keyboard patches available for the L430, so that will always fail. Have you tried make patched.l430.img to make the image file? It looks like from your build logs that you are trying to make ...iso

There are keyboard patches available for the L430, I swapped the keyboard on this model. I guess the error is due to omitting the 0byte files of the keyboard patches?

You could try my fork https://github.com/leecher1337/thinkpad-ec/tree/Lx30 or just recreate the missing 0byte files from there.

[hamishcoleman]

Perhaps I should be more technically correct - this repository expects 5 patches to be available if the keyboard is to be patched, there are not 5 patches available in the l430 area, so the entire basis for this repository's expectations will fail. Creating zero byte files is also disallowed as that is a sign that you are trying to force this repository to do something that it is not expecting - it is deliberately designed to be defensive. The existence of the zero byte files was a hack that was made to try and avoid fully supporting the way this repository was built, so I removed the zero byte files.

[leecher1337]

Now what to do if you don't have patches for dead keys available, like in this case? Fn keys swap is also something that doesn't apply to this firmware version (there is already support for it in BIOS/Firmware).

[hamishcoleman]

I would be redesigning the code that creates the lists of patches so that it has some form of a manifest and can adapt to different patch sets

[leecher1337]

Isn't that a bit of an overkill given the fact that you can just control it with the existing framework anyway? If you don't like 0 byte files, maye just create the appropriate files with the content "Does not apply to this firmware" in it. Then you have a clear indication that it's not necessary/needed for that firmware architecture and it still works with the existing framework without a lot of code modifications.

[hamishcoleman]

I see this less as overkill and more of expanding the framework to be useful in more cases - as and when it is needed to be expanded - and not trying to force new features into an existing framework. Certainly providing other people with clear indications when there is any surprising deviations would be useful. I am aware of other patches that would probably be easier to integrate if the enable/disable configuration and patch manifests were more explicit and less hardcoded.

[leecher1337]

Ok, I see, so I'm looking forward to your modifications then. It's a pity that the KB-patch remains in a non-working condition until you expand the framework. In the meantime @q60 can either use my fork that provides the 0byte-files workaround or create the files himself in this repo.

[fakamaz]

So the last time battery fix worked just fine on L430, but this time around I have a problem compiling kernel... regardless if it's MAKE or dkms build -m x2100-ec-sys/1.0 I have this as a result:

ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it.

make[1]: [Makefile:750: include/config/auto.conf] Error 1 make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-53-generic' make: [Makefile:5: all] Error 2

Any help?

[leecher1337]

Aren't you in the wrong repo here? I guess you should post it at https://github.com/exander77/x2100-ec-sys This patch framework here doesn't need the driver that enables to interact with the controller at runtime. If you don't want the permanent patch from this repo and only want a temporary in-memory fix, I recommend to use the ready-made ISOs from https://github.com/leecher1337/thinkpad-Lx30-ec/releases

[fakamaz]

Aren't you in the wrong repo here? I guess you should post it at https://github.com/exander77/x2100-ec-sys

Yeah, I had a feeling I should've posted it there; but since the main description as to how to patch it was located in this one - I decided to post here... Anyway, I'll try with the ISO, as to not wanting a permanent fix...

Well, as far as I see, permanent fix still relays on that particular kernel installed; which failed for me for some reason this time... so, you know... back to square one.

[leecher1337]

The permanent fix doesn't rely on the kernel module, this repo here just patches the firemware files so that you can flash them, no need for a kernel module to do that.

The kernel module is just needed to write to the EC in memory so that you can revert back to original firmware with a simple power cut reset, that's what my ISO does. So, no, you don't need the kernel module for permanent patching.

[fakamaz]

Well, it was fun! :)

I've loaded up your iso, make a hot-patch (thanks god!!!) and on the restart the message of the "wrong battery" was gone; yet... when Linux loaded up, it successfully got frozen, right on the user selection screen!

Ok, I've rebooted - unplugged battery and AC cable and re-started my computer. It loaded up normally, except... it went into constant screen refresh loop - where it'll blink all the time with the screen and pretty much re-set anything I try to do; e.g. try to type something? Nope.

Try to get to the re-start or shut-down button? Too late!

After a few mins I was able to shut it down - unplugged the battery and AC and it work just fine... so... something went wrong apparently :) The question is - what? I am curious.

[leecher1337]

Very weird, given the fact that I initially tested all this on a L430 and you also already tested it on another L430 successfully. Also the patching routines are written in a defensive manner first checking the bytes at a given location before overwriting, so they shouldn't accidentally patch the wrong area (and if they would have done so, chances are high that the battery nag wouldn't have vanished). I also don't think that I messed up something when adding support for the other models, but who knows... Even if it would have messed up the battery check, there is no explanation for the machine acting so weird (involving other components like screen output running havoc).

As it was a L430, you can theoretically try the first ISO that got released on the Releases-page, which was L430 only and which I tested on the real machine before finally patching the machine's EC permanently. But I don't think that current ISO really contains a bug.

If you don't trust the auto patching routines, you can also just boot up the ISO, got to the prompt and just patch the battery routine manually as described in this thread so that you can manually double- or triple-check the bytes at the given location just to be sure.

Not much else I can think of software-wise, maybe memory write went to the wrong address due to timing conditions or something like that. But during development I patched the EC memory a dozen times and it didn't mess up like that.

Also weird that it apparently messed up the state of some components in a way that you had to unplug and re-plug power 2 times. Maybe first time wasn't enough to reset the state of all components, maybe some capacitor was still loaded and kept its state.

Maybe the battery caused it, as it wasn't blocked anymore due to the patch, got charged and caused some power spikes or something like that causing other components to malfunction? If you want to do further experiments, you may want to unplug battery, patch and reboot with AC connected and check if it works fine for some time. If plugging in the battery causes the mess, I'd blame the battery.

But that's only my guesswork, not much that I can check as long as the problem cannot be reproduced here.

[fakamaz]

That's a good idea actually; haven't thought of the battery messing it up, so I'll definitely test this out! Thanks for the detailed answer, BTW.

And, actually, and this is soooo strange to me - it's not two different L430! It's the same one! And yes, before it went just fine even without iso; now? I can't do it for some reason. So yeah, after work today - I'll give it another spin.

UPDATE: So, after second run, and as you've suggested - it worked! So might be a battery which caused that glitch... Anyway, thanks for your help, mate!!!

[leecher1337]

Great to hear! Hopefully you get the battery working again.

[Blas12boca]

¡Me alegro de oirlo! Esperemos que la batería vuelva a funcionar.

Hello, I have a problem. I have bios 1.13 and I can't put the patch because it asks for bios 1.14. I don't understand much. I used the iso. Could you help me please I want to know if my battery works.

[leecher1337]

Then just update to 1.14 BIOS first?

If you want to be safe, upgrade BIOS to vanialla 1.14 and then try out the non-permanent patch from https://github.com/leecher1337/thinkpad-Lx30-ec so you don't brick anything, if you just want to know if your battery works.

[Blas12boca]

Then just update to 1.14 BIOS first?

If you want to be safe, upgrade BIOS to vanialla 1.14 and then try out the non-permanent patch from https://github.com/leecher1337/thinkpad-Lx30-ec so you don't brick anything, if you just want to know if your battery works.

is that to update the BIOS asks me to have the battery working. and to update the bios from a bootable usb is more difficult and not do it.

[leecher1337]

You can use vendor supplied mechanism to update BIOS to 1.14 (see Lenovo website).

After you updated to 1.14, boot the thinkpad-LX30-ec ISO and you can make a runtime patch. That will remove the error message about battery authentication failure until you unplug battery and power which would reset back to original embedded controller firmware (which will display the error with wrong battery, so don't do this after patching unless something goes wrong). You can repatch woth non-permanent patch at every time.

Here is a video showing how to make non-permanent patch: https://www.youtube.com/watch?v=TB2zSC_U-yA

[Blas12boca]

You can use vendor supplied mechanism to update BIOS to 1.14 (see Lenovo website).

After you updated to 1.14, boot the thinkpad-LX30-ec ISO and you can make a runtime patch. That will remove the error message about battery authentication failure until you unplug battery and power which would reset back to original embedded controller firmware (which will display the error with wrong battery, so don't do this after patching unless something goes wrong). You can repatch woth non-permanent patch at every time.

Here is a video showing how to make non-permanent patch: https://www.youtube.com/watch?v=TB2zSC_U-yA

Lenovo update mechanism asks me to have the battery working to update the BIOS. otherwise Lenovo site gives you an ISO file to update but it is very difficult to update it that way I can't find a solution I hope you understand me I'm using the translator.

[leecher1337]

Iirc., you can start WinFlash64.exe on Windows directly without the launcher program WINUPTP.EXE, which checks system power status before initiating a flash. For L430, command line should be:

WinFlash64 /bbl /vcpu /sn /sd /v /exit /ipf bios ec /file <filename>

WinFlash64 command line options can be found here. No warranty for this hint, if you brick your machine, don't blame me but get a chip clip to restore it, if it goes wrong.

[leecher1337]

Another option would be to use a patched WINUPTP.EXE that just skips battery check. I patched WINUPTP from the following package for L430 (assuming that this is your machine):

https://support.lenovo.com/us/en/downloads/ds029124-bios-update-utility-bootable-cd-for-windows-10-64-bit-81-8-7-32-bit-64-bit-xp-thinkpad-l430-l530 (g3uj33us.exe)

Here you find the patched WINUPDP.EXE that should skip battery check: WINUPTP.ZIP