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.

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.

@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).

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]

Zitat von CodeRush im Beitrag #2

---

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.

---

@mikhoul, will look at it in a few days, have really no free time now.

Zitat von CodeRush im Beitrag #39

---

@mikhoul, will look at it in a few days, have really no free time now.

---

@mikhoul
I think copy & paste CAM5 to the version 2.02 table should be enough to re-enable it.
Replacing the compiled ACPI table with the UEFI Tool is possible as well, the problem is that those bay trail based tablets tend to have some kind of checksum protection which prohibits any modifications.
I used some cheap work-around which loads the modified ACPI table just in the windows registry, it needs Windows testmode enabled:

bcdedit -set testsigning on
 

Then load the new compiled ACPI into the registry:

asl -loadtable dsdt.aml
 

@Wootever, BTW, sorry for not breaking that stupid protection that time. Got too much to do and the forgot about it completely. This Texlast PDAs are really interesting fro BIOS standpoint, so I will probably just buy one for tinkering around...

Zitat von Wootever im Beitrag #41

---

@mikhoul
I think copy & paste CAM5 to the version 2.02 table should be enough to re-enable it.
Replacing the compiled ACPI table with the UEFI Tool is possible as well, the problem is that those bay trail based tablets tend to have some kind of checksum protection which prohibits any modifications.
I used some cheap work-around which loads the modified ACPI table just in the windows registry, it needs Windows testmode enabled:

1
 

bcdedit -set testsigning on
 

Then load the new compiled ACPI into the registry:

1
 

asl -loadtable dsdt.aml
 

---

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20150818-32
 * Copyright (c) 2000 - 2015 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of dsdtc6j6.dat, Tue Sep 01 12:11:49 2015
 *
 * Original Table Header:
 *     Signature        "DSDT"
 *     Length           0x0000F6D0 (63184)
 *     Revision         0x02
 *     Checksum         0xD7
 *     OEM ID           "ALASKA"
 *     OEM Table ID     "A M I "
 *     OEM Revision     0x00000003 (3)
 *     Compiler ID      "AMI "
 *     Compiler Version 0x0100000D (16777229)
 */
DefinitionBlock ("dsdtc6j6.aml", "DSDT", 2, "ALASKA", "A M I ", 0x00000003)
{
    /*
     * iASL Warning: There were 2 external control methods found during
     * disassembly, but additional ACPI tables to resolve these externals
     * were not specified. This resulting disassembler output file may not
     * compile because the disassembler did not know how many arguments
     * to assign to these methods. To specify the tables needed to resolve
     * external control method references, the -e option can be used to
     * specify the filenames. Note: SSDTs can be dynamically loaded at
     * runtime and may or may not be available via the host OS.
     * Example iASL invocations:
     *     iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
     *     iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
     *     iasl -e ssdt*.aml -d dsdt.aml
     *
     * In addition, the -fe option can be used to specify a file containing
     * control method external declarations with the associated method
     * argument counts. Each line of the file must be of the form:
     *     External (<method pathname>, MethodObj, <argument count>)
     * Invocation:
     *     iasl -fe refs.txt -d dsdt.aml
     *
     * The following methods were unresolved and many not compile properly
     * because the disassembler had to guess at the number of arguments
     * required for each:
     */
    External (_SB_.PCI0.LPCB.TPM_.PTS_, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
    External (NDN3, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
 
    External (_PR_.CPU0._PPC, UnknownObj)
    External (CFGD, UnknownObj)
    External (DPTF, UnknownObj)
    External (PDC0, UnknownObj)
    External (PDC1, UnknownObj)
    External (PDC2, UnknownObj)
    External (PDC3, UnknownObj)
    External (TCH1, UnknownObj)
    External (TCH2, UnknownObj)
 
    Name (LAPB, 0xFEE00000)
    Name (CPVD, Zero)
    Name (SMBS, 0xEFA0)
    Name (SMBL, 0x20)
    Name (SRCB, 0xFED1C000)
    Name (SRCL, 0x4000)
    Name (PMBS, 0x0400)
 

I've read it could happen because I'm not using the same version of IASL that was used to compile the DAT file, but I'm not really sure about it ???

Could you give me some clues to remove those errors or how extract the DAT file to DSL file without having error OR maybe those errors can be ignored ?

I could also try to extract with an older version of IASL.exe from around sept 2014 when the bios was made by Teclast.


I'm in the process to mount a VMware Mac machine to see a Mac OS software Called DSDT2BIOS v0.4.11 and MaciASL to see what they offer over PC software since hackling DSDT is very popular on Hackintosh ;-)


Like I said previously One week ago I was knowing nothing about BIOS "inside" but slowly I learn how it work...

@CodeRush
Don't worry, you gave me good support and tried several times to unlock this protection. I think that at some point the effort spend isn't worth the result, especially for those rather immature chinese Bios versions.
The more recent revisions seem to have enhanced code quality: for example Cube i7 Stylus (Core M)

@mikhoul
If the *.dsl compiles correctly it should be able to test at least the camera function.

Zitat von Wootever im Beitrag #44

---

@CodeRush
Don't worry, you gave me good support and tried several times to unlock this protection. I think that at some point the effort spend isn't worth the result, especially for those rather immature chinese Bios versions.
The more recent revisions seem to have enhanced code quality: for example Cube i7 Stylus (Core M)

@mikhoul
If the *.dsl compiles correctly it should be able to test at least the camera function.

---