Zitat von RayeR im Beitrag #308They can then choose and download specific patches and apply them to theirs own DSDT (or could be on BIOS image for this purpose). Some patterns that needs to be replaced are generic in various BIOS ACPI tables so this can save some work and could extend patches for other motherboards...
this method is low effective, since the skylake+ bioses has a huge number of new acpi 2.0 commands in many places and the generic patterns will have to replace a lot of lines with their acpi 1.0 equivalents, which still need to be written.
Exploring acpi.sys on Windows Longhorn betas: 4008 - integers are 32 bit, support most of acpi 2.0 opcodes (except CopyObject, Timer, QWordConst) *** 4042 - last version with 32 bit integers 4051 - first version with 64 bit integers *** 4074 - support new opcode CopyObject *** 5048 - import table match win xp !!! *** 5342 - support new opcode Timer and QWordConst, PDB published on Microsoft SYMBOL Server 5365 - integers are 32/64 (switched depending revision of DSDT table, V1=32, V2=64), added Dynamic conversion of types, PDB published
Zitat von RayeR im Beitrag #300replace AMLI - acpi.sys by opensource counterpart from ReactOS? It seems they use ACPICA and it should be much more up to date than obsolete WXP original file. But I can imagine that it would be a hard work, probably the kernel intrface of ROS is not exactly same as WXP...
MS uses own implementation of acpi and it very far from acpica, and yes, acpi.sys is not just acpi driver, it also implement some pnp/pci/resource functions and connected with kernel/hal
Zitat von RayeR im Beitrag #300 I also read somewhere that years ago some part of MS Windows sources had leaked (not sure if it was W2K/XP or other version) so if we could get acpi.sys sources it would be possibe to upgreade to implement newer 2.0 functions. If not maybe still possible to write some driver/filter that will be called before acpi.sys it will transform necessary things 2.0 to 1.0 and pass it further to original aspi.sys.
- part of nt4 and win200 sources leaked, mainly user-mode, drivers not leaked - this is impossible because we cannot emulate new commands by old acpi 1.0 syntax. we cannot skip new commands because logic will destroyed
ME driver need only if you use Intel's "ME/ICC/CLOCK software" (Clock Commander, FWUpdate and etc) Extreme Tuning Utility (XTU) may be require this driver but i dont not sure.
p.s. This driver is just software bridge between users apps and ME(HECI) hardware
For develop "real" usb3 hub/stack driver you better look to files from leaked sources of Windows 10 for ARM. It has folders with probably usb3 driver itself, usb3hub, usbport and even usb2.0 ehci driver
Zitat von skrellioge im Beitrag #3 In which BIOS did you find these strings?
in gigabyte, "Setup" module, also in "SiInitPreMem" exist strings like "SPD Micron Hynix Elpida Samsung" you can explore stolen ami uefi source code for memory controlling/spd reading (for old platfrom ivy/sandy)
Zitat von skrellioge im Beitrag #1 But i could not find anything for adding the SPD data to a normal vendor BIOS.
bios memory support on PC platform is designed as plug&play, so vendors dont need hardcode spd data in bioses. but in bios modules exists some strings, representing memory modules names like "g.skill pc3-1600-bla-bla", this maybe patches or something hardcoded to this modules
1) extract with UEFIExtract/UEFIDump 2) search all modules for "JFIF" string or binary "FF D8 FF E0"/"FF D8 FF E1" 3) temporary rename each result to *.jpg, check for msi logo 4) replace "as body" in UEFITool to your logo
Zitat von diderius6 im Beitrag #269 Did you use this? Policy[0].AllowPromotion = 1 Policy[1].AllowPromotion = 0; // Disable's C2 Policy[2].AllowPromotion = 0; // Disable's C3
No, i already wrote about power states on my skylake - acpi C2/C3 hardware (or bios or some poor documented bios setting) is broken for any OS, only cpu still can do it (itself, two asm commands, without external dependies). windows think that platform support c2/c3 and use it, but cpu do not enter these modes properly and windows never know what doing a semi-useless job (30-40% cpu in power saving mode, thank for this at least)
Zitat von Omicron im Beitrag #1881 I'm wondering if someone might try starting up a generic MS driver and seeing what functions it calls (the additional ones you mentioned as part of 8 and up) and seeing if implementing these might make them work (sort of like the people doing the Windows 2000 extended kernel project.)
i tried win8 driver on win7 some time ago, matching import is not enough, ms usb3.x driver uses some implemenation of api on win8+. so on win7 x32 i got kernelfault where all functions are exported from kernel/hal. i dont dig deeper
Zitat von Erecik im Beitrag #1Hey! Voltage is also fine, providing stable 5V but only in UEFI. Right before Windows is loading voltage drops to something like ~1.2V
Zitat von Fernando im Beitrag #1879Which specific bytes should I try to change in which manner?
any byte inside any string, Error=>ErrOr, you will not touch asm code this manner if you use signtool.exe, it will recalculate cheksum in PE header too
Zitat von Omicron im Beitrag #1876 Posting this per request: The most recent 1809 xHCI generic drivers also do not work under Windows 7 (didn't even get to the hub or switch phase,) the xHCI driver itself again fails with "The driver may be corrupted or missing. (Code 39)." This same error occurs with the 1607, 1507, or 8.1 drivers.
x64 generic win8 and win10 drivers compiled again new kernels, so win7's kernel lack exports some procedures on x32 generic win8 driver has same imports from kernel like on win7, but generate kernelfault on loading time
Win-Raid Forum (Drivers - Firmware - Modding) » Search for Mov AX, 0xDEAD's content 
Tue Apr 23, 2019 5:39 pm