New Release: WindSLIC v2010.01.15.01 Hi all, Here's a new release of WindSLIC. This version is a bit more 'beta' than the last one, but I went ahead and made an official entry for the Dell ClrScr workaround Apokrif has been using, in hopes that it would work on Dell 9100 as well. View attachment windslic-2010_01_15_01.zip If you're already using v2010.01.14.01, no need to update to this one, as no major bugs have been fixed, and quite likely, some new ones have been added. Edit: Here's the Full Changelog of the new version: ;------------------------------------------------------------ 2010.01.15.01 - Extensive code-reducing attempt ;------------------------------------------------------------ - In an effort to reduce the ROM footprint of the project, various messages were streamlined/reduced. -Various IVT-related macros were replaced with partially procedurized macro-procedure hybrids. This reduced the overall space use just enough to justify the effort, it is hoped. -Various instances of flag-affecting instructions were replaced with non-flag-altering alternatives: - shl x,4 was replaced with lea x,[4*x] twice - add esp,x was replaced with lea esp,[esp+x] -Added a WORKAROUND_1_DELL_VID entry to hopefully allow ROM to work on Dell Dimension 9150 -Removed extra 'Push CS' from wscomfil.asm According to a post on the FASM forum, the 9Ah opcode already does a 'push cs', so there is no need for a second 'push cs', so that has been removed. ;------------------------------------------------------------ Thanks, -tij-
Maestro, you have a winner! Confirmed working on a Dell XPS 400 / Dimension 9150. To others trying to replicate: I took tij's 1.15.01 version, set WORKAROUND_1_DELL_VID =1, and followed the remainder of his instructions as before -- and, like magic, it works fantastically. Apokrif is right -- this machine is ACPI 1.0, so no XSDT. SlicDump Toolkit 3.0 confirms the SLIC at DFE8C400. Happy to post a screenshot of the ACPI tab if still needed / wanted. Now, if we can embed this as a module in the original ROM... but, that's another thread (taking it there now!) (Just for clarity -- this version fixed both the fail-to-boot issue and the SLIC not present issue. Not sure how they were linked, but happy to help disassociate these two issues if need be. XPS400/D9150 is now booting directly to HDD and has SLIC present.)
Interesting. Yeah, the code was originally designed to be less-than-chatty, since it wasn't savable and was all showing up on a boot screen. Even with pauses, this is a lot of info to keep up with. I'll walk through the output you got, highlighting the important parts: --------------------------------- -v- Code Output Begins -v- --------------------------------- Init WindSLIC... Press F5 to Skip... WindSLIC ROM Base: [00001D30] Continuing... Initial ROM Checksum: [7D] Corrected ROM Checksum: [83] Activating WindSLIC... Getting H820 line... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... E820 New High-Water-Mark Found... <- This means that the E820 Handler thinks it has found a valid memory region to borrow from/reserve. [Vital, since only our High-Reserved memory is guaranteed to be writable and since the ACPI tables may have to be moved there to be edited later on during the program] Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Done Getting H820 line... Executing Main Code... Locating RSDP (checking EBDA)... <- This means that the code is looking in the EBDA for the RSDP Using EBDA@: 0009FC00 <- This means that the code found your EBDA (and lists where it is) Located RSDP Table... <- The lack of a "(checking E000-F000)" before this line means your RSDP was already in the EBDA [Interesting! First one I've seen that was this way if it's true] Copying RSDP into EBDA... RSDP table has Version Indicator: 02 <- A Revision 02 means ACPI 2.0, and we should expect an XSDT table to be found RSDP table has a Length DWORD. RSDP Length: 00000024 Determining new RSDP Location. Using EBDA@: 0009FC00 Ready to Copy RSDP to EBDA: 0009FC10 to 0009FC40 <- This is a problem! WindSLIC is screwing this up. It should just use the existing 9FC10 since yours started with it already in the EBDA. This would make anything it does really not be effective, since the 9FC10 is going to be found first and used by Windows. OK: RSDP should now be in EBDA region ending at:0009FC64 <- This means it thinks it has moved the RSDP to the EBDA [which is vital, since we will be editing it, and the EBDA is writable] Note: in your case this is bugged, since you already had an RSDP in the EBDA. I will have to change WindSLIC's behavior for it to work on this type of PC. I will post a version in a few that should fix this bug. Locating RSDP (checking EBDA)... Using EBDA@: 0009FC00 Located RSDP Table... Moving RSDT to Resvd Memory... OK: RSDT should now be in high resvd memory region. <- It believes it has successfully copied the RSDT to our High-Reserved Memory region [Good!] Moving XSDT (if it exists) to Resvd Memory... XSDT Table Ident Found. OK: XSDT should now be in high resvd memory region. <- It believes it has found and copied the XSDT to our High-Reserved Memory region [also Good!] Moving SLIC to resvd memory... Detected SLIC length is : [00000176] Copying SLIC from: [0001F4D0] to [AFF1E000] Patching RSDT for SLIC... Existing SLIC was found... <- The BIOS already had a SLIC in it. No info was displayed to keep the code size down, but maybe this should display the OEMID in DETAILS Mode? Patching Using SLIC Address: [AFF1E000] Patching XSDT (if it exists) for SLIC... Existing SLIC was found... <- Same thing, but in the XSDT [Good, since it should have been in both tables, and it was] Patching Using SLIC Address: [AFF1E000] <- This address is where Windows should find the SLIC when all is said and done Activating Replacement Int15H Handler... <- It thinks it's done everything well and has enabled the replacement E820 handler to reserve the memory. Continuing... --------------------------------- -^- Code Output Ends -^- --------------------------------- OK, that's all, folks. I'll patch that bug, or try at least. Yours is the first PC I've encountered that had the RSDP already in the EBDA, so it's going to be up to you to try the new version and let us know how it works. Get back to you in a few, -tij-
New Release: WindSLIC v2010.01.15.02 [EBDA RSDP Dup. Fix] New WindSLIC release: View attachment windslic-2010_01_15_02.zip Importance: Most users won't specifically need this version if they're already running v2010.01.14.x or higher successfully. Full Changelog: ;------------------------------------------------------------ 2010.01.15.02 - Changed EBDA RSDP Usage Code to Re-Use Addr ;------------------------------------------------------------ - If the RSDP was already in the EBDA, the code did not re-use that addresss, instead plopping a second useless copy into the EBDA. It has been updated to attempt to use the already-present RSDP Addr in the EBDA if it exists. - Moved the VERBOSITY levels up into the user-editable section of the assembly file, so that users can easily find/edit the verbosity. ;------------------------------------------------------------
>“divisible by 24” part is trivial Sorry, I was wrong about it again. To implement it, a global variable is needed to keep a number of messages logged so far. Since is oROM – there is no .data segment – so it has to be on stack. TIJ doesn’t use stack frames, he switches stack, and he has int handler too. I.e. unless .code segment is writable, I don’t see any easy way to implement it… Indeed might be easier to go with COM port logging. But not many modern mobos have it either…
TIJ, The code below: Code: BOOTSPLASH_VERBOSITY = BS_HIDDEN … writeout "Copying SLIC from: [",BS_DETAILED … will generate pushf popf Nothing wrong of course… might be better move pushf/popf inside if() Same holds true about few other macros. Code: ;---------------------------------------------------------- ; -v- macro writeout message,verbosity; NOTE!: NULL-TERMINATED for BIOS, '$'-TERMINATED for DOS ;---------------------------------------------------------- macro writeout message,verbosity { pushf if ((verbosity eq) | (BOOTSPLASH_VERBOSITY > verbosity) | (BOOTSPLASH_VERBOSITY = verbosity)) local wo_end,msg1_start,msg1_end push esi mov esi,msg1_start; set bp to the start of the message call WRITE jmp wo_end; jmp over the message itself (since it is data, not code) msg1_startdb message; store the message here to display it. db DoB_StrTerm; Terminate with 0x00 (Null) (for BIOS) or '$' (for DOS) msg1_end:; store the end label so that length can be calculated. wo_end: pop esi end if popf } ;----------------------------------------------------------
[/QUOTE] I'm sure my design is far from optimal, if it even qualifies as 'correct'. The original source code was commented in chinese, and had lots of notations about inability to use certain techniques at different parts of the boot process. CS-writable here, CS-not-writable-there-have-to-use-stack, etc. I just gave it a try and ended up making my own stack and it seemed to work, so I went on with it. I didn't implement stack frames over most of the code because I wasn't smart enough to do so at the time. If you desperately need to line-by-line count/pause, you could always use one of the 0x9X interrupts I've been stealing to keep track of things. They're supposedly DOS-reserved, but it doesn't seem to use them, so it seems to work ok. (But, like I said, I'm sure it's not 'correct' to do it that way.) I just went with pause every so often, trying to keep it at always less than 24 lines. That technique seems sufficient for my testing needs, at least. And the Apokrif-idea of making a DOS COM file out of it for testing has actually been very good, as it allows for capture of the output. Good luck, -tij-
Ah, good catch! If I remember correctly, I had originally been doing something as an 'else' in some of those, and also the flags were getting lost somewhere I was trying to troubleshoot, so I left the pushf/popf in there. I'm still learning all the ins and outs of side-effects of assembly instructions. There's no need for it in that situation, so removal is advisable. I'll try and remember to do that next time I look at the code. It's interesting to see people examining and trying to improve the code. That should only make it better. Good work! -tij-
OK, I tried the updated version but it still does not work on the HP ML115. Here's the COM output: Code: Initializing.. Press F5 to Skip.. WindSLIC ROM Base: [00000D29] Continuing.. Initial ROM Checksum: [C5] Corrected ROM Checksum: [3B] Activating.. eax:00000010 ebx:00310000 ecx:00000D29 edx:00000D29 cr0:00000010 cs:00000D29 ds:00000D29 es:00000D29 fs:00000000 gs:00000000 ss:00000D29 esp:0000FFC2 esi:00210100 edi:001EFFFE ebp:003117D6 efr:00003206 cr0:00000010 cr0:00000010 cr0:00000010 cr0:00000010 Getting H820 line... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... E820 New High-Water-Mark Found... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Checking for new e820 High-Water-Mark... Done Getting H820 line... eax:00007301 ebx:00000D29 ecx:00000001 edx:00000010 cr0:00000010 cs:00000D29 ds:00000000 es:00000000 fs:00000000 gs:00000000 ss:00007363 esp:0000FEBE esi:00210100 edi:0000FEC6 ebp:0000FEFA efr:00003246 cr0:00000010 cr0:00000010 cr0:00000010 cr0:00000010 Executing Main Code... Locating RSDP (checking EBDA)... Using EBDA@: 0009FC00 Locating RSDP (checking E000-FFFF)... Copying RSDP into EBDA... RSDP table has Version Indicator: 02 RSDP table has a Length DWORD. RSDP Length: 00000024 Checking is RSDP in EBDA. Using EBDA@: 0009FC00 Determining new RSDP Location. Using EBDA@: 0009FC00 Ready to Copy RSDP to EBDA: 000F9910 to 0009FC10 OK: RSDP should now be in EBDA region ending at:0009FC34 Locating RSDP (checking EBDA)... Using EBDA@: 0009FC00 Located RSDP Table... Moving RSDT to Resvd Memory... OK: RSDT should now be in high resvd memory region. Moving XSDT (if it exists) to Resvd Memory... XSDT Table Ident Found. OK: XSDT should now be in HRMem. Moving SLIC to resvd memory... Detected SLIC length is : [00000176] Copying SLIC from: [0000EEE0] to [AFF9F800] Patching RSDT for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [AFF9F800] Patching XSDT (if it exists) for SLIC... No Existing SLIC was found... Patching Using SLIC Address: [AFF9F800] eax:00007301 ebx:00000D29 ecx:0009FC10 edx:00000010 cr0:00000010 cs:00000D29 ds:00000000 es:00000000 fs:00000000 gs:00000000 ss:00007363 esp:0000FEBE esi:0009FC10 edi:AFF9F800 ebp:0000FEFA efr:00003217 cr0:00000010 cr0:00000010 cr0:00000010 cr0:00000010 Activating Replacement Int15H Handler... eax:00000010 ebx:00310000 ecx:F000F859 edx:00000D29 cr0:00000010 cs:00000D29 ds:00000D29 es:00000D29 fs:00000000 gs:00000000 ss:00000D29 esp:0000FFC2 esi:00210100 edi:001EFFFE ebp:003117D6 efr:00003246 cr0:00000010 cr0:00000010 cr0:00000010 cr0:00000010 Continuing..
Dohnuts, Could you also post last page from SLIC_ToolKit.EXE similar ti this one: Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 1.0) RSD PTR DELL 000FC0E1 20Root System Desc.Pointer | |- RSDTDELL M07 7F65CE0E 68Root System Desc.Table | 00 |- FACP DELL M07 7F65DC00 116 01 |- HPET DELL M07 7F65E300 56 02 |- APIC DELL M07 7F65E400 104 03 |- ASF! DELL M07 7F65E000 126 04 |- MCFG DELL M07 7F65E3C0 62 05 |- TCPA DELL M07 7F65E700 50 * 06 |- SLIC DELL M07 7F65E49C 374Software Licensing Desc.Table 07 |- SSDT PmRefCpuPm 7F65CE95 1244 --------- Scan Finished ---------
Sure thing: Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR HP 000F9911 36Root System Desc.Pointer | |- RSDTHP ProLiantAFFB0000 80Root System Desc.Table |- XSDTHP ProLiantAFFB0100 124Extended System Desc.Table | 00 |- FACP HP ProLiantAFFB0290 244 01 |- APIC HP ProLiantAFFB0390 140 02 |- MCFG HP ProLiantAFFB0470 60 03 |- SPMI HP ProLiantAFFB04B0 65 04 |- OEMB HP ProLiantAFFBE040 113 05 |- HPET HP ProLiantAFFB5430 56 06 |- EINJ HP ProLiantAFFB5470 304 07 |- BERT HP ProLiantAFFB5600 48 08 |- ERST HP ProLiantAFFB5630 432 09 |- HEST HP ProLiantAFFB57E0 168 10 |- SSDT HP ProLiantAFFB5890 518
It’s has nothing to do with [non]optimal design. It’s just the combination of technique you (and every other option rom writer) uses not allow to have normal output. That’s why the only way actually to use special add-on card with fixed port address. I can see it a lot in every Dell BIOS. They post messages like – I’m here, doing this, doing that… They didn’t even bother to remove it from release code. It means [advanced] Dell tech might have the card to troubleshot BIOS related problems (a device not initializing properly, bad CMOS (wear-ed out)) I really want to find my old COM port logging code – this way real BIOS time output can be captured. Which might be different from COM file, actually…
See the difference: Ready to Copy RSDP to EBDA: 000F9910 to 0009FC10 RSD PTR HP 000F9911 36Root System Desc.Pointer * David shows 000F9911 instead of 000F9910 It's either David tool or WinSLIC doesn't work properly. We need to see same report(s) from anyone who has working WinSLIC on Dell.
Dohnuts Could you do one more thing? Open WinHEX, open "Physical memory", go to TWO locations: 1. 000F9910 2. 0009FC10 And post smth. like this: From mine 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 Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000FEBF0 52 53 44 20 50 54 52 20 6D 44 45 4C 4C 20 20 02 RSD PTR mDELL . 000FEC00 32 D0 0F 00 24 00 00 00 9A D0 0F 00 00 00 00 00 2Ð..$...šÐ...... 000FEC10 63 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF c...ÿÿÿÿÿÿÿÿÿÿÿÿ I want to see if RSD PTR got overwritten in EBDA.
Yep, that's the logical next step. Also, since I forgot to change the default back before releasing it, in the current versions, WindSLIC is set to 'aggressive' check of the EBDA, which might be using an area that later gets overwritten. To alter the aggressiveness, find this section of code in windslic.asm: Code: ;Start checking at EBDA offset: ;0x010 - to get the most chances to succeed ;0x200 - to be safest about possible BIOS collisions with EBDA usage ertr_check_start = 0x010; start check at offset 0x200 (byte 512d) Change ertr_check_start to the 0x200 setting to lessen the aggressiveness, and maybe move to a region that isn't stomped by the BIOS later in the process. Glacial! -tij-
Ok... One more time: Me (my body) and [very old!] source files CD are physically too far from each other still...