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

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, 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)

Zitat von plutomaniac im Beitrag #11

---

I was thinking that maybe Intel has a separate branch for Tablet/IVI systems apart from the usual Mobile/Desktop.

---

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.