Sadly the driver won't work on your machine does not matter what I do ( except reallocating x/rsdt ). The problem is that ( if acpi version >= 2.0 ) windows uses xsdt and forgets about rsdt. so if there is no sdt ptr that points to a slic structure in xsdt it won't activate... since there is no free space after xsdt and realloc of the lowest table does not work 'cause of rsdt this is a bad situation... sorry tuvi132 I can't help u here to get it to work. The only option would be to "overwrite" rsdt or one of the sub sdt ptr like BOOT but I don't want to do that... because I don't know if u loose some functionality... like sleep mode or such.. Btw.. does a loader work on ur machine?? EDIT: Question to all slic-tool authors and bios modders: Is it a good idea to overwrite one of the sub-ptrs if there is no space available like in this case??
secr9tos grub based loaders work perfectly for me.. I remember that a lot of people having the same problem with vmware vm's. zsmin fixed something to make it work.
Could u please install one of the grub based loaders in the vm and post the screen here if u don't mind? I've a theory how the loader does it ( overwrite BOOT ) but a proof would be nice so..
No prob, take your time! Edit: Got it... And one more thing - any brief description to get up to speed with PCI commands: Something like read this register, enumerate that stuff, etc. Don't write - just post a link if you have it handy - if not I'll dig it out myself. Thank you! Edit2: Does it have to be a driver, even for XP?
@Apokrif: Well u can use the driver to read & write to the pci bus and yes as far as I know u need a driver to access the pci. @tuvi123: Thanks for ur pic. so the rsdp, xsdt & rsdt got reallocated, nice, but this won't work for my driver 'cause windows ignores the new rsdp after ospm has booted up. at least if never worked in my tests.. EDIT: I'm working on a fix so .... maybe it will work maybe not
nice to see you're working on a fix.. hope it will work. when it's ready please notify me and I will test it. btw- on my x86 vm I've got the same problem.
I've just disassembled winload.exe and don't think it will be an easy task for a driver to successfully reallocate r/xsdt so that windows takes notice of that change: Here is a shout extract form the assembly However I did not find anything related to EBDA or the segment ptr 40:0E.. strange.. does anyone know more than I do at the moment? EDIT: i found the "__stdcall PcatGetExtendedBiosDataArea(x, x)" function winload.exe but this causes trouble though... especially for my driver
Double the gun, double the fun... ahh I meant double the slic. No honestly, I'll fix this but at first I'm focused on the "realloc rsdp" problem. This is the stat of my current research: 1. winload.exe builds a acpi node Code: ... .text:0040856E ; __stdcall OslpBuildAcpiBiosNode(x) .text:0040856E _OslpBuildAcpiBiosNode@4 proc near ; CODE XREF: OslLegacyHardwareDetection(x)+C3p ... .text:004085D6 test ebx, ebx .text:004085D8 jnz short loc_4085E6 ; -> jumps to GetRsdt .text:004085DA mov [ebp+var_8], 0C0000017h .text:004085E1 jmp loc_40866C ... 2. winload.exe queries the rsdp ( unlikely acpi.sys ) Code: ... loc_40D9B6: ; CODE XREF: PcatpGetRsdp(x,x)+9Dj .text:0040D9B6 cmp [ebp+var_4], 0 .text:0040D9BA jnz short loc_40D9DA ; -> jumps to GetRsdp ( label ) .text:0040D9BC lea eax, [ebp+var_C] .text:0040D9BF push eax .text:0040D9C0 lea eax, [ebp+var_8] .text:0040D9C3 push eax .text:0040D9C4 call _PcatGetExtendedBiosDataArea@8 ; PcatGetExtendedBiosDataArea(x,x) .text:0040D9C9 test eax, eax .text:0040D9CB jl short loc_40DA38 .text:0040D9CD mov eax, [ebp+var_8] .text:0040D9D0 mov ecx, [ebp+var_C] .text:0040D9D3 mov esi, eax .text:0040D9D5 lea edi, [eax+ecx] .text:0040D9D8 jmp short loc_40DA34 ; -> jumps to GetRsdp ... loc_40D9DA: ; CODE XREF: PcatpGetRsdp(x,x)+18j .text:0040D9DA mov esi, 0E0000h .text:0040D9DF mov edi, 0FFFFFh .text:0040D9E4 jmp short loc_40DA34 ; -> every rsdp stuff is done here! ... My current idea is to "rebuild the acpi node" but this is difficult cause I don't know the base address of winload.exe after it has been mapped to physical memory... Does anyone have an idea on how to solve this???
Don’t know how to find “base address of winload.exe”, but does get loaded on same physical address on your test PC all the time? If yes – can you “hardcode” call to OslpBuildAcpiBiosNode(x) into your driver just to see if it works?
Maybe but in the end there is only one way to find that out: code, disassemble & debug ... as well some trial and error
Has anyone tested this with the DISM /ADD-DRIVERS command. Would that work for Pre-Activation ? EDIT: and thanks for the source codes, much appreciated.
So we need a method where each user can create a self signed certificate and manage a way to integrate that certificate into the Trusted Root inside the WIM. I know the old Vista method was like a million steps and could only be done on an already installed OS. Maybe I will poke around Technet/MSDN and see if we can do this offline somehow.