Hello,
i’m currently using a modified acpi table loaded into windows testsigning mode, i would rather have a “built-in solution” directly stored in the bios.
Is it possible to replace/modify the original acpi table without breaking anything else?
It depends on BIOS vendor and version, but a generic answer is yes.
Can you please be more specific? What exactly do you want to change/add/remove? There are 2 approaches here: modification of tables stored in BIOS binary and writing a DXE driver to perform that modification in runtime, so I need more context to decide what will be a better option in your case.
On my Bay Trail based tablet there is a problem with the battery implementation, this seems pretty common on earlier Z3735D revisions.
They all share the same basic intel uefi layout, with small differences suited for the integrated hardware.
The main problem is that the battery stats are completely impractical, with a probably false hardcoded max capacity value and improper acpi functions.
The fuelgauge is a Texas Instrument BQ27441:
http://www.ti.com/lit/ug/sluuac9a/sluuac9a.pdf
My idea was to add new registers for the fuelgauge, correct the max capacity and edit BIXP object informations.
Fuelgauge seems to be described at: Scope (_SB.I2C1) on i2c bus 0x0055.
_BIX:
DECC = FG3C [DesignCapacity at 0x3C, it seems that the fuelgauge only reads a stored entry from bios]
FUEC = FG0E [FullChargeCapacity at 0x0E (compensated capacity of battery fully charged)]
_BST:
BUF4 = FG04 -> VOLT [Voltage at 0x04]
BUFC = FG0C -> RECT [RemainingCapacity at 0x0c (compensated remaining battery capacity)]
BU1C = FG1C -> PERC [StateOfCharge at 0x1c (predicted remaining battery capacity as a percentage of FullChargeCapacity)]
other registers like temperature (0x1E) aren’t exposed.
Otherwise i have no idea where the hardcoded battery values are stored, it may be more practical to edit these instead.
Edit:
Link for decoded acpi table: http://www67.zippyshare.com/v/o2APbK4Z/file.html
baytrail_v975w.txt (431 KB)
Ok, thanks, the best solution here is to get ACPI tables from BIOS, change them, check correctness by using a bootloader that is capable of replacing ACPI tables (I’ve used Clover Bootloader for that) and than reintegrate this new tables back into BIOS benary, if all works as expected.
Can you boot your tablet into UEFI Shell? If so, you can dump your BIOS using Intel FPT for BayTrail and we can study it to see where and how exactly are the ACPI tables stored there.
Thanks for your support.
Original Bios:
http://www22.zippyshare.com/v/sgVipMpJ/file.html
Here is a dump from fptw under windows, the txe engine is also updated:
http://www70.zippyshare.com/v/xh44T62Q/file.html
If needed i can also wipe and reflash/dump the bios on the efi shell (without txe update, not sure if this makes a difference).
The table you need to alter is stored here:
The main problem with this BIOS is that look like it’s protected by some crappy checksumms that should be recalculated, so I relly don’t recommend to do anything without a SPI programmer in hand.
Fortunately i have a SPI programmer at hand (only a CH341A attached with a logic level converter and 1.8V input) but it is working.
I’m also willing to try some experiments, a complete brick would be unfortunate but also acceptable.
Then just extract this raw section’s body, decompile it, edit how ypu want it, compile and replace the original section’s body with a new one using UEFITool 0.20.5. If the system stops working it means that this stupid “protection” kicked in and we need to disabled it. I had already a positive results on removin that parotection from a similar BIOS, so I don’t think it will be hard.
Thanks, i previously made the mistake to "extract as it" instead of the body.
I exchanged the corresponding section body and flashed the bios via fptw.
After a shutdown and reboot it starts in UEFI setup mode and shows EFI_NOT_FOUND!, i guess this is the checksum protection.
However, i can boot into windows with "Windows Boot manager" and the modified acpi table seems to function properly.
Good, now we need to stop Recovery module from kicking in. Will dig into it now, but need some time to figure the thing out.
Hello Bugger Vance,
I know this is not the reason for your topic but since finding more advanced users is rare, I wanted to ask you some things regarding your TXE updates. I noticed that you upgraded using FPT or a programmer from TXE 1.0.x to 1.1.x. Although it should be fine according to Intel, you are the first I’ve seen doing it. I hadn’t found a user to test such a thing until now. Did it work as intended? Did TXEInfo and TXEManuf report everything as working properly?
Also, although as far as version itself is concerned, 1.1.2.1120 is the latest firmware, I recently found version 1.1.1.1130 which a) has a higher VCN (12 instead of the old 11) and b) a latter date (November instead of August 2014).
This is strange because the “older” version is actually newer. I was thinking that maybe Intel has a separate branch for Tablet/IVI systems apart from the usual Mobile/Desktop. But analyzing both “m/d” and “tablet” firmware shows no important changes, not at SKU or anything else not-worthy (at least as far as I can see).
Since you have a programmer and the required knowledge, can you try this “tablet” (as I call it for now) v1.1.1.1130 firmware? According to VCN and date it should be newer than v1.1.2.1120 either way. Attached below if you want to try, though I understand completely if you don’t want to.
1.1.1.1130_1.375MB_PRD_EXTR.rar (659 KB)
Hello, after i read your guide (very helpful, thanks) i saw that firmware version 1.0 and 1.1 seems to be fully compatible, comparable like ME on Z67 -> Z77 i thought.
I used the intel flash image tool to exchange the TXE firmware, the only thing which i included from the previous version was FpfMirrorNvarValues.txt
Edit:
Screenshot #1: updated txe from 1.0.2.1060 -> 1.0.6.1120 via intel fwupdate tool and 3mb txe firmware.
Screenshot #2: built-in txe 1.1.2.1120 made with intel flash image tool.
Edit2:
Anti theft technology seems missing on v1.1
Edit3:
Screenshot #3: built-in txe 1.1.1.1130 made with intel flash image tool, nfc seems to disabled/removed (device has no nfc controller)
You are right, Intel now has separate releases for BYT-I and BYT-M/D, which makes much pain in some well-known place for BIOS developers because now need 2 BIOS versions for the same board.
BTW 1.1.2.1120 is now the latest release version for M/D and 1.1.1.1120 is for I, all other versions are either betas or vendor-specific releases.
AntiTheft is now EOL and needs to be disabled on all platfroms supporting it. Intel will shutdown ATT servers in very near future, so if ATT is suddenly disabled in your new BIOS - it’s a good sign.
It seems also possible to directly update the txe firmware with fpt(w), but it requires an updated descriptor as well.
Communication error.
Edit: not advisable at all, the descriptor seems to be damaged = no write access.
Found the first hash, working with teclast_dump.bin now. The algorithm is SHA256, hashed block begins at offset 0x581000 (right after NVRAM space) and has length of 0x1F8000 (ends right before the second PEI volume). The hash itself is stored at offset 0x7E0064.
Please recalculate the hash of this region in your modified BIOS and replace the hash value. There is another hash at offset 0x7E008C, but it’s for PEI volumes (both have length of 0x45000) and therefore needs no changes.
CodeRush thank you a lot for that piece of information. I was cracking my head for months now. Finally it makes some sort of sense. That would also explain why 1.0.6 firmware was "older" than 1.0.5, they were targeting different platforms.
I checked both 1.1.2 and 1.1.1, the only differences I found after unpacking were these at BUP and TPM (apart from the signatures, $MN2 date/vcn etc):
I will add 1.1.1 as Tablet and 1.1.2 as M/D at the thread. Btw, 1.1.1.1130 seems to be PV/PC and not Beta/Alpha based on the PV-bit:
Since there doesn’t seem to be any way to determine which firmware is meant for tablet and which for desktop/mobile, I appreciate you letting me know which is which. The other questionable versions are 1.0.5 and 1.0.6, maybe 1.0.6 for M/D and 1.0.5 for Tablet? TXE is such a mess…
@ Bugger Vance: Thank you the reports, pictures etc. Anti-Theft is also mentioned at the documentation of v1.1 as always disabled/not supported for TXE. No idea why they left it there instead of removing it completely, just a leftover I guess.
Regarding those changes between the firmware (1.1.1 and 1.1.2), do you modify the TXE image with FITC before flashing it? Take your original BIOS from manufacturer and transfer the TXE settings manually to the new firmware to make sure everything the manufacturer intended to be there are actually there feature-wise.
Also, you should be able to flash the ME via FPTw since your flash descriptor is unlocked as far as ME is concerned:
It’s actually the other way, 1.0.5 is for M/D and 1.0.6 is for I. The lates versions of both are 1.0.{5|6}.1120.
Thank you for all your effort, i tried to reconstruct your suggestions, but i have may some misunderstanding here.
I’m using HxD and openening teclast_dump.bin, i go to offset 0x581000 and use highlight block with a length of 0x1F800, then i use HashMyFiles to calculate the SHA256 value which is:
F18F88345455B6220980204F6D6B8BB6ECEF0DB6DBF9352C2B89A140CA7F837C
But the hash at offset 0x7E0064 seems very different:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB
Edit: typos
Not enough zeros in 0x1F8000, sorry. Please try it again with a correct length.