I remember you posted that a while back. I'll take another look at it sometime soon. I don't think there's a spec for reserving memory in the EBDA, unfortunately. Yeah, it's possible other Option ROMs also want to use the EBDA; So far I've been assuming that if they grab a chunk, it won't be all 00s by the time we get to it.. Same way we've been doing it so far, I guess. (Which is to say, I don't know a great way to debug remotely yet). At least Intel tries. AMD probably does, too. If anyone listening knows good sources for Nvidia, SiS, etc, chipset datasheets, let us know. OK. I decided to give your DOS idea a bit of a try. It looks like it can be made to work, with the following notes: #1. In the normal (Option-ROM) situation, we have an area of memory reserved for us that nothing else will touch. We can put an Int15h handler there and it should be safe from being overwritten during DOS execution. In the DOS (DOS .COM file) situation, the memory is not reserved by default, so some form of TSR-style setup must be added in order to do the Int15H handler. #2. You can't easily mix ASM from FASM with anything 16-bit, it turns out. That means this would have to be re-written in NASM or something in order to do that. The documentation for doing ASM/C in the 16-bit DOS (and more-importantly Pre-DOS (aka BIOS Option-ROM)) universe is pretty murky and confusing, if not outright contradictory. I had to find example code just to get the darned far calls working under FASM. FASM has confusing syntax (in my opinion) for calls. Whee. I now have a fatboy DOS TSR version of WindSLIC. It's messy and nasty, but vaguely functional. So, that's something positive, at least, I guess. :: -tij-
I so can't wait till there is already "pre-loaded" roms much like the motherboard bios slic mod, and an installer for the necessary files such as the certificate. I have no confidence in code modification whatsoever. After reading this whole thread, I am dizzy. You guys are too smart for my level. After all my highest job in IT was pre-Geek Squad Best Buy tech and as you all well may know that's not too high. (We just made sure we sounded like we knew what we were doing.)
>I remember you posted that a while back. I'll take another look at it sometime soon. I don't think there's a spec for reserving memory in the EBDA, unfortunately. Yeah, it's possible other Option ROMs also want to use the EBDA; So far I've been assuming that if they grab a chunk, it won't be all 00s by the time we get to it.. Cool. I’ll try to find recommendations too. I, kinda, don’t like those assumptions (grab memory and put non-zeros right away) >Same way we've been doing it so far, I guess. (Which is to say, I don't know a great way to debug remotely yet). See below… >OK. I decided to give your DOS idea a bit of a try. It looks like it can be made to work, with the following notes: >#1. In the normal (Option-ROM) situation, we have an area of memory reserved for us that nothing else will touch. We can put an Int15h handler there and it should be safe from being overwritten during DOS execution. In the DOS (DOS .COM file) situation, the memory is not reserved by default, so some form of TSR-style setup must be added in order to do the Int15H handler. I.e. under DOS, there is no way to reserve memory without Int15h interception? Could you do it another way: execute whatever you need (reserve memory, copy SLIC, modify ACPI tables), don’t exit yet, but run diagnostic/print error messages, show new ACPI tables/locations, than exit! I don’t care if all modifications get lost/overwritten. I need to make sure they executed properly only! I hope DOS doesn’t know/care about any ACPI stuff anyway, even if it hung after – I don’t care! Bottom line – it’s like raw prototype/concept/code proof only. No TSR stuff should be needed. >#2. You can't easily mix ASM from FASM with anything 16-bit, it turns out. That means this would have to be re-written in NASM or something in order to do that. The documentation for doing ASM/C in the 16-bit DOS (and more-importantly Pre-DOS (aka BIOS Option-ROM)) universe is pretty murky and confusing, if not outright contradictory. Ops… What about masm? Does it still alive? I had to find example code just to get the darned far calls working under FASM. FASM has confusing syntax (in my opinion) for calls. I learned about FASM from you. I used tasm/masm only. Used both… in previous century… Whee. I now have a fatboy DOS TSR version of WindSLIC. It's messy and nasty, but vaguely functional. So, that's something positive, at least, I guess. :: Ok. And all we can do with this TSR is run some diag program to see what it did, right? Or does it give us anything else than that?
Bro, This is sorta "work in progress" thread still. If you unclear what you need, better ask "what to do" corresponding mod request thread. >We just made sure we sounded like we knew what we were doing. I wish, I have this skill too
Whats the difference. Actually i was unable to find "add_slic-translated.asm file" mentioned in the first post, so thats why i asked Also want to know one more thing, can we use this method on Ethernet card added to PCI slot in intel motherboard of companies like realtek, dlink etc.
Well, if you find a spec for EBDA usage, I'm interested, but for the moment, grab-the-00s-area seems to work for my code. If not, I'm sure we'll hear about it from any users pretty quickly There's a DOS Interrupt: Int 21H, AH=31H is the 'Terminate and Stay Resident' interrupt. That keeps your process' memory and returns to DOS. If you have hooked interrupts, their memory should be safe. That's mostly how my code works at the moment if compiled in "BS_DEBUG" mode I made four levels of bootsplash verbosity for WindSLIC: BS_MINIMAL - only shows the "WindSLIC, continuing..." messages BS_BASIC - Shows the high level "Finding RSDP, etc" status messages BS_DETAILED - Shows step-by-step status including memory regions, etc. used BS_DEBUG - throws up lots of poorly-formatted debugging messages along the way MASM is still around today, but whether Microsoft really supports it or not is somewhat in question. I bought a copy way back when they still sold it in a box, but I've long since lost all but one of the manuals at this point. Really, from what I've seen, either FASM or NASM seems to be sufficient for just about any Assembler task, with TASM and MASM there if you absolutely have to use them. Well, in BS_DEBUG mode, the TSR prints a lot of status messages as it runs, so that's sort of shows what it did/does. You can then run various diagnostic programs (I have an E820 memory-map lister I wrote and an ACPIDUMP-for-DOS program that is modified from old FDAPM source code, but I've learned from all the testing I've been doing with the WindSLIC COM file that there are some bugs in those that need to be fixed, too. ). Almost there (see next message), -tij-
NEW RELEASE! 2010/01/11 version Greetings all! Here is a new/updated version of WindSLIC!: Edit: v2010.01.11 had a bug in it that is fixed in v2010.01.14, so I have changed the attachment link to download the already-patched version (v2010.01.14.01): View attachment windslic-2010_01_14_01.zip . . . . . This version has the following changes: ;------------------------------------------------------------ 2010/01/11.01 - EBDA Usage now working on physical PCs - Corrected non-saving/restoring of the SEGMENT registers during BEV. This had caused Booting on AMI-BIOS physical machines to fail due to a BIOS bug on AMI's part (author's opinion). - Added BOOTSPLASH_VERBOSITY setting to enable various levels of bootsplash display, from none/hidden all the way to firehose-level debug specifics - Added 'wscomfil.asm' which compiles windslic as a DOS .COM file rather than a ROM binary file. This can be used to test windslic output in a redirect-to-file capturable format. ;------------------------------------------------------------ ;------------------------------------------------------------ 2010/01/06.02 - EBDA Usage - Added "Timely Pauses" to allow the more verbose display settings to be readable (by pausing every so often) - Changed the default behavior to (if possible): -Move RSDP to EBDA -Move RSDT and XSDT to High Reserved Memory This should allow machines like Dells to work with WindSLIC (They normally have those tables in the readonly F000 segment) ;------------------------------------------------------------ Have fun and let me know if you have any issues! -tij- View attachment windslic-2010_01_14_01.zip
Note: The v2010.01.11 version defaults to "Hidden" display, meaning it doesn't say anything at all during bootup, so you'd never notice it was there. Edit the windslic.asm and change the BOOTSPLASH_VISIBLE to 1 to bring back the older "Initializing WindSLIC..." and "Press F5 to Bypass" message display.
Well, I just released a new, more capable WindSLIC yesterday. It's the one you want. As for finding attachments, I figured out the easiest way is to go to the forum page itself, and find this thread there. From there, there's a little "paper-clip" attachments icon, which lists all the attachments that have been added to this thread, including both the newest (windslic-20100111.zip) and the older ones (add_slic-translated.zip) in one easy list. Nothing prevents that, other than possibly these two things: #1. Most NIC vendors other than Intel don't always (or usually at least) include a FlashROM on their cards. You have to have a card that can boot from network/PXE in order to start this. #2. Even if the NIC has a Flash ROM, there has to be a utility for it that can write a binary .BIN file to it. Several vendors have this, several don't (as far as I have researched it, at least). Actually, for this the card doesn't even have to be a NIC. NICs tend to be chosen for two reasons: #1. Because they're (relatively) cheap. For example, EBay pricing for my favorite, the Intel Pro/100+ NIC, is usually less than $10 or $15, with prices falling to $5 if you buy four or five, and (hehe) $3ea if you buy 50. Note: The most important trick for buying Intel cards on Ebay is to verify they actually have a Flash ROM. Some do, some don't. On the Pro/100+ cards, the ROM is down at the inner lower-right edge of the card, and it's easily seen. #2. NICs don't make you cry if one dies. NICs only have to connect to the network, and the PXE ROM is only needed if you're trying to boot something from over the network, which few non-corporate people do. So, the PXE ROM can be overwritten with our code, and no functionality is lost. Even if something screws up and the card gets bricked by a bad flash, it's not so vital that you can't just replace it (unlike doing this mod on a soldered-onto-the-motherboard chip, for example ). Hope that helps, -tij-
Excellent. Thank you for the feedback. The ECS 7050M-M (or similar) was one of my original test platforms, though I didn't test it with the new version, so I'm glad it still works. When I hear back from a few Dell/previously-nonworking people, I'll try to get a list of works/doesn't motherboards together, I guess. So far the only Dell confirmation I have is from a friend of mine that tested it on an antiquated Dell Precision 360. It worked, but that's not a very up-to-date platform. Sure thing. I just do it for the extra clicks of the "Reputation" button. Glad it's working for you! -tij-
Congratulation on your new milestone! IMO - very useful. I haven't seen you code yet, but still want to suggest something. If I need to write tons of debug messages, I have one procedure to output message and count [and timestamp and whatever]. For example, I can request to “press any key to continue” if message number is divisible by 24. Or duplicate messages to COM port. What are they good for? Could you make bigger attachments to your posts or something like this?
hi -tij- I have installed v2010.01.11 on old dell gx 270 and works like charm could not get it to work with winslic older version, this new mem allocation works perfect on dell not going to keep it to slow and too old machine thanks for great and easy to install mod I have bunch of intel pro/100+ management nic cards, super easy to flash thanks
Thanks! A combination of new games, holidays, de-motivation from perceived complexity, and AMI BIOS bugs (Int 18H expects the GS segment register to be the same as it was when Int 19H was called to start the BEV/OS-boot process, but I don't think that's in the spec anywhere) made it take a while, but I'm happy with the new version. It seems to be a monotonic improvement over the old version, so that's always nice. I just added a debug-ish pause function every so often in the code, activated by enabling "USE_TIMELY_PAUSES = 1" or somesuch. It's not guaranteed to stop at or less than 24 lines, but I added enough of the pauses to at least make it possible to see what it's saying to theoretically assist in debugging. Frankly, the text-display part of the code is the ugliest part. I have left it alone as much as I could because it's jagged, and it has never been the biggest focus in getting a working solution. I kept thinking if I switched to C/ASM that I'd have to change all that stuff anyway, so I haven't targeted it (yet). Fancier/proper debugging sounds neat, but I haven't a clue how to implement COM port stepping or anything. Not that I know of, but it is nice encouragement to work harder and continue developing/improving. Speaking of which, I am thinking of making a new thread so that I don't have to bother SirSilentBob with updating the first post. Or, perhaps it would be better to have two new threads?: "WindSLIC: Latest Release Thread" and "WindSLIC: Development/Troubleshooting Thread" Anyone have any thoughts? PS. Subversion merges don't make a lot of sense, -tij-
Another DELL success!!! Confirmed success with INTEL PRO1000MT and a DELL SC440 server. The previous version worked fine on non DELL machine but this version now works 100% The SC440 is currently running Windows Home Server but i believe the next version will use SLIC activation so i am now ready and waiting for WHS V2. Congratulations and a big thank you for all of your hard work.
With updated version of WindSLIC MSI K9N Platinum (AMI) WORKING..........Yes! Finaly BIOS recognizes WindSLIC-v2009.10.20 no problem but after that F5 message follows boot error message...reboot and select proper boot device bla bla...as hard disk is brand new or missing. Now with WindSLIC-v2010.01.11 everything works like a charm. MSI K9N Platinum, AMI BIOS, nForce 570 Ultra for AMD Various Intel PRO/100 all with Vendor ID = 8086 and Device ID = 1229 WORKING Thanx to the skies and back
DSpyder, I don’t have ASM version of “duplicate messages to COM port”. But I’m going to write it actually - I’ll need it to debug Dell non-SLIC bioses mods anyway. Don’t expect too much – it’ll be one-way only, as you can always capture/scroll back on any terminal application. Naturally, “divisible by 24” part is trivial. Will add pauses if I need them later. Sorry for misleading you... BTW: About writing a Slic-OEM driver x64/x86, AFAIR windbg has some COM port based kernel remote debugging. Never did it myself, but IMO, you need to use smth. like writedebugmsg and you will see it on another computer. Or run normal remote debug session.
I do know, these type of bugs are the most discouraging. How did you manage to get a clue about it? Shouldn’t be a problem to write it, if you need. Good debugging support very helpful and reusable … Do you think your solution will work with signed BIOSes too… for a while, until everything will be signed, including option ROMs? Do you have any reports for Intel mobos? IMO, you don’t need stepping. I’m sure, it might be the case where you really need it, but let’s leave it for later. Just posting messages is easy – if you don’t use ANY COM port interrupts – they will only deceive you. Everything has to be synchronous. I would go with two: "WindSLIC: Latest Release Thread" – first post with download links [+ working mobo/nics, but pain in the ass to maintain]. Subsequent posts working/non working reports only. "WindSLIC: Development/Troubleshooting Thread" – exactly as it sounds.