@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:
@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
Thanks a lot !
I thought about it last night (loading table via MS ASL) to test it before patching the bios.bin file.
But even for it I'm stuck with the DSL file that give me some errors --->
/* * 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
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.
Thanks, I’m downloading Yosemite Image for VMplayer and will test it, from what I see i’m almost sure that adding the good CAM device with the others should work, worst case I will remove the OV cam before adding the one from 1.2 bios.
Will let you know about my progress and the Mac tools when I will give them a try.
Hey guys, I need to do this for my GA-Z97M-DS3H.F5 (Rev1.1), I’ve already extracted the Tables and patched them, just want to get them on the ROM! Thanks
?
