New Development Version: WindSLIC v2010.02.04.02 I found/fixed a couple of bugs in my latest development version, so it's worth a try. Other than the relatively minor bug-fixes, though, it's also been pretty heavily modified (mostly to make it compile smaller), so it has only been tested by me. View attachment windslic-2010_02_04_02.zip As for the bug I'm talking about. Yep. It's an exact repeat of the 'mini-patch' situation that happened with v2010.01.11. So, I'll also be posting another (actually almost the same) mini-patch to fix (the same) problem as was with the 2010.01.11 version [The bug got back into the v2010.01.20.02 version too. ] -tij-
Mini-Patch for v2010.01.20.02 Hi all, The good old ACPI table positioning/reservation bug that was in WindSLIC v2010.01.11 managed to end up in WindSLIC v2010.01.20.02 as well, sort of. To fix WindSLIC v2010.01.20.02, apply the following mini-patch: In the file windslic.asm, find the line that looks like this: Code: ACPI_RESERVE_SPACE = (rsdt_table_resvd_offset + xsdt_table_resvd_offset) and replace it with: Code: ACPI_RESERVE_SPACE = (rsdt_table_resvd_len + xsdt_table_resvd_len) NOTE: This bug has been also been fixed in the new test version: View attachment 5774 (v2010.02.04.02) so feel free to try it instead. Thanks, -tij-
Tij, Could you share this piece of code (or both), please? I’m not smart enough (as you noticed already) for find it on my own… I mean, I can certainly try, but the problem is “if I made a mistake I got a brick“. I better start with proven working code…
Still on my to do list. I was hoping you can give some "blank code" first - I asked you early... I guess I’ll try it anyway. BTW: Any reason you stick with PCI ROM 2.0 version? 3.0 looks very promising
That explains it Crap, I was looking in 2010_01_15_02 folder exactly for code int 1Ah, but you have it as int 0x1a! And you use int 10h everywhere!!! int 1Ah is good - thanks a lot! …Do you still have code using direct registers access? I can't find it... again...
Yeah, I'm a bit inconsistent with the 0x and H methods of defining hex numbers. I don't trust leading 0s, but the H method seems to sometimes need it, so I've started leaning more towards 0x, I guess. Yes, I do like to (try and) display a lot of output. I don't exactly trust Int10H to work in all situations, but with the exception of that Dell Video workaround, it's seemed to work so far. It does, of course, require that the code be loaded as an Option-ROM, rather than as a part of the BIOS before the Int10H handlers are even installed. Hm. That's a very good question. I'll have to dig around in the attic, so to speak. -tij-
IMO, “int 21h“ is “classic style”, not “int 0x21“ My bad to think “classic never dies” Yeah, you cannot write “number ten” as AH (or Ah), but rather as 0Ah (or 00AH)… Funny thing, hex number (in fact any base numbers) has to start with a decimal digit! I not blaming for extra Int 10H, I was talking about consistency! One day you will try to find all yours Int 10H and you will miss those written as Int 0x10! Well if it’s a big attic... I guess, I can live without it.
Thank you I will try when I have a chance and let you know RS Edited: I try the new version already and sad thing to say it's not working. (V2010.02.04.02) Appreciated your help RS
Dagnabit! I haven't ever been able to determine exactly why XP is so brittle when it comes to booting, when DOS, Linux, and Windows 7 don't seem to care. Currently the version I released works on WinXP-32bit both in my VM and on my main physical PC. If anyone has any idea why XP is having trouble, I'm all ears. Yeah, int 18h didn't matter during my testing. Historically, I defaulted to int18h, but I switched to retf because it makes it easier to glue two ROMs together. My super secret end goal is to make a VGA rom that includes the WindSLIC functionality. Thanks, I do as well. I figured that if the user was trying to make the ROM as small as possible, short messages would be better, but if space is no issue, long messages are more clear/informative/etc. Yeah, that was because I wasn't quite done testing the changes I had made in the non-default case. I've hopefully corrected those bugs for the next release. Thanks for the feedback, -tij-
Oh man! If you compare benefit against (usefulness + implementation problems)… does it really worse it? I was about to throw in an idea to fork another Extension ROM for PCI BIOS 3.0 (I thought, you’ll do it before me!) Cool thing to add is a configuration ROM – once loaded it can dump all current ACPI stuff, memory statuses, etc. (you can still have it for 2.X too) Or even add simple memory explorer to it – you give it memory address – it’ll show content ;-) The good thing with 3.0, you can keep your current 2.0 image and add completely independent 3.0 image. Another cool feature – use PMM (not sure if you tried it already). It might simplify code a bit. And definitely needed thing – could you print PCI BIOS version right before or after “Initializing WindSLIC vX.Y.Z…” line It’s really interesting to know if there is any 2.X out there still, capable to run W7? BTW: Do you have a command line tool to easily inject WindSLIC image into VMware BIOS for testing?
I don't know if there's a standard, but the first thing the QEMU BIOS does is : Code: F000:AD28 B8FEFF mov ax,0xfffe F000:AD2B 89C4 mov sp,ax F000:AD2D 31C0 xor ax,ax F000:AD2F 8ED0 mov ss,ax F000:AD31 BBF09F mov bx,0x9ff0 F000:AD34 8EDB mov ds,bx F000:AD36 8B1E8200 mov bx,[0x82] F000:AD3A 43 inc bx F000:AD3B 891E8200 mov [0x82],bx F000:AD3F 8ED8 mov ds,ax F000:AD41 53 push bx F000:AD42 EB17 jmp short 0xad5b F000:AD44 55 push bp F000:AD45 89E5 mov bp,sp F000:AD47 B8FEFF mov ax,0xfffe F000:AD4A 89C4 mov sp,ax F000:AD4C 31C0 xor ax,ax F000:AD4E 8ED0 mov ss,ax F000:AD50 BBF09F mov bx,0x9ff0 F000:AD53 8EDB mov ds,bx F000:AD55 A38200 mov [0x82],ax F000:AD58 8ED8 mov ds,ax F000:AD5A 50 push ax F000:AD5B E8D5F7 call word 0xa533 F000:AD5E CD18 int 0x18 F000:AD60 CF iretw So, from what I can see, Int18H nukes the stack pretty effectively. -tij-
If you're asking if combining a VGA rom with WindSLIC is worth it, I don't know, but I feel like it's worth trying at least once. The Nvidia SLI guys might enjoy it, since they could load the Nvidia SLI SLIC with it instead, I believe. Nothing wrong with doing that, except that I've been focusing on increased compatibility, trying to get WindSLIC to work as-is on as many machines/models as possible, and a PCI Firmware 3.0 ROM isn't as universally-compatible as a 2.X ROM, at this point, I think. Sure. The idea of making a PCI diagnostic card has been in the back of my mind several times. Actually, what's even more interesting than that is an article I ran across once about using one of the Prism-chipset wireless cards and reprogramming its firmware, since it has an onboard CPU that can do PCI-mastering in order to not have to run code on the PC CPU to get memory, in theory at least. That wouldn't be a problem, but what memory addresses are that important to need to search? Most you could just get by going ahead and booting DOS and using a util there, I suspect. Maybe if WindSLIC were smooth enough to use the fact that it's on a NIC to open a TCP connection to another PC and dump the memory, perhaps... Right. It is on my to-do list to make at least an attempt to do the PCI FW 3.0 style ROM header when I try to combine it with a 3.0-Based Option ROM. (Assuming I can find one of those; The only one I know of for sure so far is the Nvidia 8300 on-board BIOS on my development PC motherboard). Yes, PMM (as listed in PCI FW 3.0 at least) looks great. I think there was a version of PMM that pre-dated PCI FW 3.0, but it wasn't very good, from what I can remember (only supported temporary/during-boot memory allocations?). Technically, on any Core i3,i5,i7 machine, you should be able to use PMM and also the Core iX-built-in-memory-controller to do direct F000 read-write access. But, for right now, I don't have a Core-i7 machine to play/develop with. I believe there are plenty of PCI v2.X systems that run Windows 7 okay. You have a point with regard to displaying the PCI BIOS/PCI Firmware version. Maybe I'll add it to the DETAILED/DEBUG mode on WindSLIC. I'm having trouble tracking down the part of the specifications where it says what option-rom-type PCI-Express uses. I suspect it is either PCI BIOS 2.1 or PCI Firmare 3.0, but PCIe first 1.0 specification is right between the two BIOS/Firmware specifications, so I don't know. Nope. I haven't ever done too much with VMWare and WindSLIC. It should theoretically work, but every time I update any Fedora kernel modules, both VMWare and VirtualBox break until I (at best) recompile their kernel-mods, or (at worst) until VMWare releases an updated version [feh]. At least QEMU is all User-mode. Sure it performs terribly, but it runs. -tij-
Oops, I know nothing about it… Will take a look what’s done there! Might be, but still worse to get some statistics, right? Coool! Is there any work done already in this direction? I.e. some kind of template you can start with? I was wondering if it can be used on bricked mobos too? Wow, another brilliant idea! UDP Broadcast will be somewhat easier to implement – no handshaking, just dumping. If WindSLIC piggybacks on PXE ROM, WS might be able use PXE code. Still lots of work, I guess… But looks way cool! Really? I thought all Intel stuff is 3.0. I mean only 3.0 supports more than one dev_id, so SATA RAID ROM has to be 3.0, right? Even WindSLIC can benefit a little from dev_id list. You are absolutely right. POST Memory Manager Specification Version 1.01: All memory allocated by the PMM will be automatically zeroed and freed just before INT 19h is executed. Haven’t found any PMM 2.0 spec – is there any? Me neither, but I hope it’ll change soon I thought PCIe was 100% software compatible with PCIx. That was the whole point. Even hardware part – only add-on card PCI controller chip need to be replaced, but everything else stays the same. I might be very well mistaken about it Gee, man. Every time I ask something (for myself!), you manage to slip away… gracefully! I do have couple more questions, I better post in separately… This post is way too long already
Silly question – if XP loader is not used, i.e. XP is loaded by grub or W7 loader – does the problem persist?
Here we go: 1. What about BEV memory model? I haven’t seen any references in BIOS Boot Specification (BBS)… BTW, I don’t think BBS is Phoenix specific. Have you seen any other BBSes? 2. Resizing of Expansion ROMs During INIT You do resize to zero if something goes wrong. If not – you don’t change it. Why do you need to copy SLIC somewhere else, if WinSLIC ROM (with SLIC) stays in memory? Can't you reference it there? 3. Does WinSLIC work on Intel mobos with signed BIOSes? Does WinSLIC work with EFI BIOSes (or it’s same question)? One more idea about Extension ROM code configuration part: NIC has its own configuration EEPROM. You can store some flags there and use them during BEV execution to enable/disable diag messages on certain feature. I.e. I know e820 alloc works fine – I want to disable its messages without recompilation. Or enable/disable diag messages completely. Or chose different execution path… I.e. use it as you own CMOS Actually, you don’t even need “Extension ROM configuration code”. You can fiddle bits with eeupdate program, but you have to remember what offset if used for.
Yes, I think so. My main dev/test PC uses a FAT32 partition as a grub bootloader partition. From there, it has menu options to boot to the XP partition or the Fedora partition (both chainloaded). If WinXP is selected, it is chainloaded and executes. If Fedora is selected, it chainloads to its partition, which just summons *another* GRUB, to present the Linux options. I recently added a third boot option to load (hd1,0), which lets me plug in a USB flash drive and boot to that without having to futz with the BIOS boot order. -tij-
As far as I know everyone uses the Phoenix BBS. They don't all do it in quite the same way, though. AMI, for example, seems to take shortcuts when resuming from hibernate. It boots directly to whatever BBS device it booted from last time. Most importantly, it totally bypasses the BEV of any *other* device. Yes, the SLIC is referenceable from there. If I were modifying the F000 region instead of bypassing it, I would probably reference it there. Older versions did that, in fact. I generally prefer to move it out of that region, because I'm slightly paranoid, and if I can ever get, say, compression working on the WindSLIC ROM, it wouldn't be directly accessible from that location. It works on at least one Intel motherboard that "supports" UEFI, though I don't enable UEFI on the board, so I don't know if it works with UEFI *enabled*. Yes, I've considered the Intel NIC eeprom a lot. If someone magically provided assembly code to access (read/write) it, I'd be all over that. Lunchtime! -tij-