With a length of 0x1F8000 i got:
2D985E196FF698B7C33FD24C0BD675AEDA63245E01FA8316BA1AF812737FD900
I checked it a few times, guess i’m missing something.
I’m using HxD to get a part of teclast_dump.bin file (Ctrl + E) and save it to hashed.bin file, then use 7zip 9.38 beta to calculate SHA256 hash of it.
I only included the FPF Mirroring File which is specific, other settings were equal.
I tried to flash the txe directly via fptw, with -txe parameter there was a size mismatch. Flashing without any parameters results in a broken txe and flash descriptor, which locks writing access completely.
You are right, i made some silly mistake and saved the file as text instead of hex data. Thanks!
No problem, please report if the modified BIOS works without recovery mode kicking in.
@ CodeRush
Thanks for clearing that up. You would think that if 1.1.2 is BYT-MD and 1.1.1 is BYT-I that 1.0.6 would be BYT-MD and 1.0.5 BYT-I but Intel knows best. 
Yes, I now remember extracting 1.0.6 from an HP tablet. It’s previous BIOS had 1.0.4.1090 so 90 is for BYT-I and 89 is for BYT-M/D. I have started writing a list from now on:
Intel could have made their lives a little easier by changing the $SKU but alas, doesn’t matter. I will re-upload them correctly now
The only “update” missing is a 1.25MB v1.0 BYT-I image. I have only three 1.25MB “thin” sku images (more rare). I’m fairly certain that 1.0.4.1089 and 1.0.5.1120 are BYT-MD, maybe 1.0.2.1067 is BYT-I. Otherwise, we’ll wait until some 1.25MB BYT-I is extracted from an SPI image.
EDIT: I hope the same freak-show is not a thing for TXE 2.0 as well (Braswell and Cherry Trail). Fingers crossed.
@ Bugger Vance
Makes sense, if you flash the TXE firmware without that parameter (-txe) it’s going to replace the whole SPI image with the TXE firmware. That will lead to a brick obviously. FPT has a small warning if it detects that the image you are trying to flash is smaller in size than the SPI itself. But it does not prevent flashing an equal-sized .bmp image for example, it has no such checks.
Also, if you can, run FWUpdLcl64 -save TXE.bin to create a TXE UPD image. I’ve never seen/found one (not that they are used much after ME8 but still). Usually I can cut normal sized images after FTPR region and create UPD images but without a sample to compare such action is not wise at all.
Generally, it’s surprising that since Novemeber 2014 (when I first wrote the TXE thread), noone has ever verified whether everything is working, because not a lot of people have TXE systems or even know they include such firmware inside. Anyway, I’m just explaining why I am asking those things from you. 
Will provide one as soon as possible.
I first heard of ME/TXE when i bricked my Z68 board after a incorrect flash update to a ivy bridge compatible bios, i can understand why ME or even more TXE is pretty uncommon, although it seems to have a pretty large relevance to the system.
No problems in asking questions, i think it is a nice way for me to have something (even if little) to contribute.
btw Bugger Vance here, my first registration attempt didn’t work, so i used Bugger Vance as temporary replacement, doing posts since the txe update up until now.
Still waiting for report. Did recalculation of that checkup work?
I made a few more tries, just to make sure that i did no mistake.
This version is completely original and has only a slighty modified acpi table:
http://www6.zippyshare.com/v/TaTz1V1s/file.html
- it boots windows and the modified acpi table seems to be correctly used, but it shows the EFI_NOT_FOUND warning at startup.
[edit: only works if flashed over a existing working bios, a clean flash doesn’t boot at all]
This version is the same as above but has the re-calculated hash value included:
http://www12.zippyshare.com/v/S7JIDgIi/file.html
- tablet doesn’t boot at all, i can feel that the cpu gets slightly warmed up, so the boot process gets interrupted somehow.
[edit: both flashing over a existing working bios and clean flash doesn’t work]
What i did:
opened teclast_acpi_mod.rom with HxD, start at offset 581000 and copied the block with a length of 1F8000.
Made a copy of the block in a new HxD file and saved it as hash.bin, then used HashMyFiles to see SHA256 value:
120E6B8C9560817A267CF5A4973C3FAC61F5192C2448008F7BF952349C4C72C8
back to teclast_acpi_mod.rom at offset 7E0064, exchanged:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB
with the one from above and saved it at teclast_acpi_mod_hash.rom
Did the same procedure on the original bios file, HashMyFiles gave the correct result:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB
Edit:
My previous acpi modding test did only work because i just flashed the modified parts with [fptw -f acpi_mod.bin] over the existing txe/bios area.
With a clean flash (erasing complete flash area) it also doesn’t boot the tablet.
Here is a savefile from version 1.1.2.1120, if needed i can try to do the same for 1130 or other versions.
(.txt is just added for uploading)
txe_save_1120.bin.txt (944 KB)
Please try this one, I’ve tired to patch CalculateHash function to always return EFI_SUCCESS and removed all the hashes. Try it and see if it works.
teclast_dump_patched.zip (2.42 MB)
Unfortunately the same behavior as before, tried a "update" and clean flash and both resulted in a brick.
Clean flash with my previous (unmodified) dump is working.
@ Wootever:
Thank you for the UPD image. It’s as I thought, I can cut after a certain point and create them from the RGN/EXTR images. Most probably the same applies to v1.0 3MB, if you want you can do the same with 1.0.6.1120.
For the record, when you and CodeRush figure out the ACPI puzzle, the final modded SPI image for your tablet should have TXE 1.1 1.375MB v1.1.1.1130 firmware (and not 1.1.2.1120 as you currently have) based on this “table”:
@ CodeRush:
You don't have to reply to that if you can't/don't want to. I checked a Cherry Trail TXE image today and it was 2.0.0.2060 as the current Braswell that we have. It seems to be identical (well apart from the fact that the one I found today is clean/RGN and not FITC-dirty/EXTR). So I guess Intel is not doing the same thing with M/D or Tablet this time around. However, the 2.0.0.2048 and 2.0.0.2056 Kits that we have only mention Braswell and not Cherry Trail. So I conclude that with TXE 2.x, the firmware is the same but there are seperate Kits due to the different documentation required when building a Cherry Trail SoC image as an OEM.
@plutomaniac , you are right. I don’t have much experience with Braswell yet, but I will catch up soon.
@Wootever , crap. Will do another round of reverse engeneering.
@plutomaniac
I attached a savefile from txe version 1.0.6.1120, i also got a report from a Teclast X98 Air 3G (which uses 1.1.1.1130).
txe_save_1.1.1.1130.bin.txt (944 KB)
info_1.1.1.1130.txt (1.87 KB)
txe_save_1.0.6.1120.bin.txt (2.05 MB)
Alright, all TXE firmware seems to be able to be cut after a certain point and create UPD images. The other topics will be updated with the findings of this topic.
Again, thank you both for the info, files etc. Now wait for CodeRush to see if you can get the modded bios working.
After some research i found additional information about the battery data, it is stored in a module named “BATMonintor”.
The battery fuel gauge is a Texas Instruments BQ27441-G1
BQ27441 Technical Reference Manual
Data Memory Summary Table, Subclass ID 82 is stated at page 42.
On the attached file V975W_BatteryMonitor.bin it is described at offset 0xE30:
40: 41 [Qmax Cell 0]
41: F4 ^
42: 00 [Update Status]
43: 00 [Reserve Capacity]
44: C8 ^
45: 01 [Load Select, Load Mode]
46: 0E [Q Invalid MaxV]
47: DB ^
48: 0E [Q Invalid MinV]
49: A8 ^
4A: 1C [Design Capacity]
4B: 84 ^
4C: 69 [Design Energy]
4D: 82 ^
4E: 05 [Default Design Cap]
4F: 3C ^
50: 0C [Terminate Voltage]
51: 80 ^
52: 00 [Reserved/Unknown]
53: C8 ^
54: 00 [Reserved/Unknown]
55: 32 ^
56: 00 [Thermal Rise Factor]
57: 14 ^
58: 03 [Thermal Time Constant]
59: E8 ^
5A: 01 [SOC Interrupt Delta]
5B: 01 [Taper Rate]
5C: 90 ^
5D: 10 [Taper Voltage]
5E: 04 ^
5F: 00 [Reserved/Unknown]
V975W_BatteryMonitor.bin.txt (16.5 KB)
Hi @CodeRush ,
I just found this post yesterday when Googling I was looking for an answer about how saving a modification in the ACPI/DSDT part of a BIOS.
From what I understand of this thread I really need your help !
5 days ago I was knowing NOTHING about BIOS programming or modification other than "press delete to enter in BIOS" and change the settings or update my bios.
I bought also a Teclast X98 Air II tablet from China with Windows and found a "Big" problem with the original 1.03 BIOS the battery drain in sleep mode.
So Teclast issued a new 2.03 BIOS that fix the drain in sleep mode BUT when they programmed the ACPI/DSDT part of the BIOS they forget to include a "CAM DEVICE"
for the front camera in the DSDT 
. Teclast changed the hardware for the "front camera" and seem to don’t care about users who bought the X98 first.
To make a short story after looking for a fix on Chinese, Russian Forum to find only peoples complaining about the situation I said to myself I could try to fix it since I’m self-taught.
I made lot of progress and learning about BIOS in the last days but I have underestimate the magnitude of the task
What I have done:
I’ve learned it possible to do and I’ve extracted the the DSDT from BIOS 1.03 (Working Camera with Drain in Sleep mode) and from BIOS 2.03 (No drain but no support for front camera).
Si I have disassembled the DSDT.dat to DSDT.DSL and compared the 2 files with "ExamDiff" to see the differences between the version in the DSDT part of the BIOS.
After used DSDT editor cause it highlight the syntax of the code and also it build a "tree" to clearly see the different parts of the DSDT,
this way I’ve been able to see why the front camera is not working in 2.03 BIOS cause they put another DEVICE and left out the "ORIGINAL DEVICE".
PROBLEMS
My first problem is when in use IASL.exe to disassemble .dat to .DSL it throw me errors 
. I don’t have enough knowledge to know if those errors can be ignored or how they have to be fixed ??? I’ve read that those error can show because DSDT can have been compiled with an older version than the one I use but I’m not really sure.
Second problem I did not found how the "fixed" DSDT will be put in back in the BIOS ? There’s lot of support for HackinTosh, Mac, Linux but I found almost nothing to bring back the DSDT in BIOS.bin excepted this software ACPI Patcher.exe http://www.insanelymac.com/forum/topic/1…r-bios-and-aml/ that don’t seem to work with my BIOS.
I’d really like that you help me to succeed to fix the 2.03 BIOS to have the front Camera working on my Teclast X98 Air II.
Here’s a link to a Zip archive with the DSDT.dat DSDT.DSL BIOS.BIN and even an HTML interactive file to show quickly the difference between 1.03 DSDT file and 2.03 if you need to look at what I have to help me.
https://mega.nz/#!9pgX1BzC!eWtj44NTfAvbe…gI7qac-NgqzGGck
Best Regards from a Newbie 
Thanks a lot for your help ! 
I will wait for your help, In meantime I will try to learn a little bit more on ASDT file with a Mac VM machine since they seem to have some tools available only on Mac OS to manipulate DSDT I will let you know if I make some progress.
Thanks again for the help and have a good day !