Right! I didn’t pay attention to it, actually… Where 32KB-96KB room come from? Even 32KB is a lot! With all debugging enabled WinSLIC is 27KB and 4KB w/o. Yet, I think "Press F5" is better anyway. Agreed… but you not going to use any lib stuff, do you? IMO, just by switching ASM -> C you binary will be 1.2-2 times bigger right away… Looks like your ideas are crystal clear now! You have beaten that flu already, right?
Ok. Got a hold of Dell Dimension e510 Code: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000A0000 (usable) BIOS-e820: 00000000000F0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007FE88C00 (usable) BIOS-e820: 000000007FE88C00 - 000000007FE8AC00 (ACPI NVS) BIOS-e820: 000000007FE8AC00 - 000000007FE8CC00 (ACPI data) BIOS-e820: 000000007FE8CC00 - 0000000080000000 (reserved) BIOS-e820: 00000000F0000000 - 00000000F4000000 (reserved) BIOS-e820: 00000000FED20000 - 00000000FEDA0000 (reserved) BIOS-e820: 00000000FED00000 - 00000000FED00400 (reserved) BIOS-e820: 00000000FEC00000 - 00000000FED00000 (reserved) BIOS-e820: 00000000FEE00000 - 00000000FEF00000 (reserved) BIOS-e820: 00000000FFB00000 - 0000000100000000 (reserved) And realized I do have type 1 region (100000 - 7FE88C00) Modified to confirm: Code: cfne820hwm_skip: if (DEBUG_SYS_E820_ENABLED = 1) writeoute820crlf writeout "^-Skipping e820 line for reason: [" dispdwordhex eax writeoutcrlf "]" call Wait_for_KB_Key Indeed it's used! It just scroll our so I cannot sees it early. Checked again and realized I had goofed early – I set DEBUG_SKIP_URM_STUFF= 1. I changed to DEBUG_SKIP_URM_STUFF= 0 and got: Code: Done Getting H820 line... Executing Main Code... Using Fallback SLIC location... Patching RSDT for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [000D1070] Patching XSDT (if it exists) for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [000D1070] Skipping Replacement Int15H Handler... Loaded DOS, run dos_e820.com and got very same map as above… Traced again and found I goofed DEBUG_SKIP_INTHOOK_STUFF too. Turned it back and got: Code: Done Getting H820 line... Executing Main Code... Moving SLIC to resvd memory... Detected SLIC length is : [00000176] Copying SLIC from: [000D1100] to [7FE84400] Patching RSDT for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [7FE84400] Patching XSDT (if it exists) for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [7FE84400] Activating Replacement Int15H Handler... The map changed to: Code: BIOS-e820: 0000000000100000 - 000000007FE84400 (usable) BIOS-e820: 000000007FE84400 - 000000007FE88C00 (ACPI data) BIOS-e820: 000000007FE88C00 - 000000007FE8AC00 (ACPI NVS) I.e. we have reserved 7FE84400 - 7FE88C00 = 4800h = 18432 bytes of memory. Checked with SLIC_Dump_ToolKit… ACPI map is: Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR DELL 000FEB01 36Root System Desc.Pointer | |- RSDTDELL DM051 000FD211 64Root System Desc.Table |- XSDTDELL DM051 000FD265 92Extended System Desc.Table | 00 |- FACP DELL DM051 000FD35D 244 01 |- SSDT DELL_ex FFFCA4CE 172 02 |- APIC DELL DM051 000FD451 114 03 |- BOOT DELL DM051 000FD4C3 40 04 |- ASF! DELL DM051 000FD4EB 103 05 |- MCFG DELL DM051 000FD552 62 06 |- HPET DELL DM051 000FD590 56 I.e. no SLIC... That’s how it looks on PC with SLIC (very different PC!): Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR DELL 000FEBF1 36Root System Desc.Pointer | |- RSDTDELL B9K 000FD032 68Root System Desc.Table |- XSDTDELL B9K 000FD09A 100Extended System Desc.Table | 00 |- FACP DELL B9K 000FD1BA 244 01 |- SSDT DELL_ex FFF5DB88 172 02 |- APIC DELL B9K 000FD2AE 146 03 |- BOOT DELL B9K 000FD340 40 04 |- MCFG DELL B9K 000FD368 62 05 |- HPET DELL B9K 000FD3A6 56 06 |- OSFR DELL B9K CFE55C00 124 * 07 |- SLIC DELL B9K 000FD3DE 374Software Licensing Desc.Table Checked with HWDIRECT: SLIC found at 000D1100 & 7FE84400 - exactly as BIOS said during the boot: Copying SLIC from: [000D1100] to [7FE84400] I.e. SLIC was loaded, but not included into ACPI tables… Truthinjection, Is there a way to add “verbosity” to ACPI tables processing? Or I can PM you RwV1.4 dump... Sorry for the long post…
Looked at Code: handler_int15h: I guess, what we need is a simple DOS program to call int 15h/ax=0xE820/ebx='RSVD' and see the output. Will it work from Win too?
Windows takes over for all of the BIOS interrupts. It only seems to use int15h to initially get the memory map. A DOS program could indeed call the 'RSVD' tag to detect if it were there, but usually it's pretty easy to see if that worked from DOS just by looking for a pair of adjacent 'ACPI data' regions. Of course, that is dependent on the memory layout, but it's usually not hard to figure out which one is the 'new' one.
OK. That actually clears everything up right there, I think. Both the RSDT and XSDT are located in the F0000 memory region, which the Intel chipsets mark as read-only. So, the patch procedure runs, but it never actually changes the memory regions. My ancient alpha version of WindSLIC actually made that region read-write, but I took that out because it was very pesky to get chipset datasheets to determine the proper values to use to do it for different chipsets. Then, the Core-I5 and Core-I7 processors changed everything again, so I gave up and tried a different tactic, which worked on AMI/Award/Intel BIOSes (because they put the tables at high addresses which aren't locked read-only by the BIOS). What type of chipset/processor is this machine? I really wonder how the various loaders actually enact the changes. Perhaps I can learn something from them?? -tij-
Two more, although it doesn't matter now... 1st w/o SLIC, 2nd with existing one. Same thing (for the 1st) SLIC added memory but not to ACPI structures. Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR DELL 000FEB01 36Root System Desc.Pointer | |- RSDTDELL 9100 000FD204 64Root System Desc.Table |- XSDTDELL 9100 000FD258 92Extended System Desc.Table | 00 |- FACP DELL 9100 000FD350 244 01 |- SSDT DELL_ex FFFCAC83 172 02 |- APIC DELL 9100 000FD444 114 03 |- BOOT DELL 9100 000FD4B6 40 04 |- ASF! DELL 9100 000FD4DE 103 05 |- MCFG DELL 9100 000FD545 62 06 |- HPET DELL 9100 000FD583 56 RSD PTR DELL 000FEBF1 36Root System Desc.Pointer | |- RSDTDELL M09 000FCE2B 84Root System Desc.Table |- XSDTDELL M09 000FCE97 132Extended System Desc.Table | 00 |- FACP DELL M09 000FCFBF 244 01 |- SSDT DELL_ex FFF6D3CA 154 02 |- APIC DELL M09 000FD0B3 146 03 |- BOOT DELL M09 000FD145 40 04 |- ASF! DELL M09 000FD16D 146 05 |- MCFG DELL M09 000FD1FF 62 06 |- HPET DELL M09 000FD23D 56 07 |- TCPA DELL M09 000FD499 50 * 08 |- SLIC DELL M09 000FD275 374Software Licensing Desc.Table 09 |- SSDT DpgPmmCpu0Ist 7FDFFC40 373 10 |- SSDT DpgPmmCpu1Ist 7FE00049 373 11 |- SSDT DpgPmmCpuPm 7FE00452 320
Another success - so far!! I can report another success. Used an Intel Pro/1000MT Dual Port Server Adapter with a rather old Abit SA7 motherboard as a test and worked perfectly. Although I am fortunate in that all my PC's and laptops had modifiable bioses I really needed something like this for my unmodifiable Dell SC440 server that is currently running Windows Home Server. It is currently activated using the old SLP method but as the next version of WHS is to be based on Server 2008 I needed the option of adding a SLIC. I haven't had a chance to try the network card in the server yet but can anyone confirm that the mod will not remove the SLP marker that is in the real bios. A big thank you to truthinjection and all the other modders here for the outstanding work you are doing.
Why not PM him? He might share that piece of source code... Will save you lots of time! I wish I can help somehow... Actually, what post you talking about?
I'm not sure how much that would help, since the code would have to be modified to work with the rest of the WindSLIC code, anyway, but if it isn't fairly obvious, I'll do that. (Also, if zsmin is modifying GRLDR, then the source code is in AT&T-syntax assembly, which is easier to read, but not what the current project is written in, so translating would be a manual process). I added a link to the relevant post in the original reply, above. -tij-
My gut feeling is "No, it's not possible using a built-in card." I've never seen a built-on gigabit card with its own flash. Doesn't the above say "No Flash Present"? Flash is what you'd need to overwrite to do the trick. Technically, you can always try it. It will probably fail without doing anything at all, and even if it tries and doesn't work, you'll probably just lose PXE boot support... probably. There are ways (using a Linux live-cd) to be extra careful and back up the various ROM (the more important eeprom, not just the flash rom) on the card to be more sure/safe. Sorry / Good-luck! -tij-