Technically, the 0009FC10 address could be different by the time Windows is loaded. DOS, at least, moves the EBDA down from 0x9Fxxx (the end of the 640K region) to the 0x20xx region in some/most/all? cases. It keeps the RSDP data added intact, but moves the whole EBDA, and updates the pointer at 0x40E-0x40F, so using WinHex to check that area for the updated? pointer to the EBDA might be advisable. they say the memory is the first thing to go, -tij-
Ok. My bad! I actually want to see memory content at two addresses: 1. RSD PTR reported by SLIC_ToolKit / RwErything (000FEBF1 in log below) Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR DELL 000FEBF1 36Root System Desc.Pointer | |- RSDTDELL B9K 000FD032 68Root System Desc.Table 2. Current EBDA content: Get EBDA pointer – go to offset 40E Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9B ...............› I got 00 9B there reverse order to get segment address - 9B 00 and add one zero - 9B000 goto 9B000 And post first 1024 bytes – (400 hex) Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0009B000 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B020 00 00 00 00 00 00 00 42 00 00 AA FA 00 00 00 00 .......B..ªú.... 0009B030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B0A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B0B0 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ÿÿÿÿ............ 0009B0C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0009B0E0 00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 ..........ÿÿÿÿ.. TIJ – please correct if I’m wrong.
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 Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000F9910 52 53 44 20 50 54 52 20 1D 48 50 20 20 20 20 02 RSD PTR .HP . 000F9920 00 00 FB AF 24 00 00 00 00 01 FB AF 00 00 00 00 ..û¯$.....û¯.... 000F9930 31 00 00 00 96 5A FB AF 10 29 FD AF 00 00 04 00 1...–Zû¯.)ý¯.... 000F9940 2E F6 06 05 F6 20 74 0C 80 FC 88 0F 84 89 00 3D .ö..ö t.€üˆ.„‰.= Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000400 F8 03 02 E0 00 00 00 00 00 00 00 00 00 00 C0 9F ø..à..........ÀŸ C0 9F -> Reverse value -> 9FC0 -> add a zero = 0009FC00 Is that correct? Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0009FC00 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC10 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC20 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC30 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC40 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC50 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC60 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC70 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC80 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FC90 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCA0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCB0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCC0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCD0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCE0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FCF0 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FD00 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE 0009FD10 55 4E 52 45 41 44 41 42 4C 45 20 20 50 41 47 45 UNREADABLE PAGE
Yes, in fact it’s same as you posted early: It’s unlikely, but it might be WinHex problem still. I do have similar problem on D430 when access memory close to upper boundary. But EBDA “by design” is just below 640K and should be always accessible... Could you double check with HWDIRECT, please. You cannot save dump with it (I don’t have registered version, mine doesn’t let me do it), but you will be able to see if it’s readable at least.
Not at all. It means, we (me!) don't understand, what's going on with EBDA area. Might be TIJ has better idea what to try next. You run those tests on WinXP, right?
Hm. I'll try it on my test PC with XP and let you know if I see the same problem. Does this also happen if you don't use the 0x200, but use the older 0x010 setting? Sounds like maybe something in the EBDA is getting stomped on when used with the 0x200 setting. That doesn't surprise me, but it is frustrating. Hehe. If that didn't work, we'd have a much bigger problem. one step forward, two steps back, -tij-
Confirmed. My VM WinXP works fine, but the physical box does not boot WinXP with the newest version of WindSLIC. I'll see if I can figure out what change caused the issue. Thanks, -tij-
I run out of ideas, why your EBDA area is unreadable. I have a feeling, once TIJ fix current boot problem, you might still need to resolve EBDA one. To TIJ: Could you add an option to dump ~64-128 EBDA bytes? 1. Would be nice to see how many pages is allocated. 2. If WS run as DOS COM, it’ll show if EBDA is readable (in DOS at least) Absolutely wild question - could BIOS disable EBDA somehow?
He just sent me a new version v1.4.6. Now it loads both sets of ACPI tables (F000 and EBDA), and displays a window-tabset for each. I'm not sure when he'll post it to his main page, but it should be there before too long, I'd expect. Thanks Jeff! -tij-
New Release: WindSLIC v2010.01.20.01 Hi all, Well, I wasn't able to devote the time to track down the change that made XP non-bootable (seems to be a perennial occurrence when making WindSLIC changes), but I took the last known working version: 10.01.11 and pulled in the meat of the changes from the 10.01.14/10.01.15 stuff, but didn't keep the size-reduction stuff, which I wasn't terrifically satisfied with anyway. So, here's the newest version: View attachment windslic-2010_01_20_01.zip I think it's good, but go ahead and try this and let me know. It boots on my Physical AMI/ACPI2.0/XP PC and it appears to load the RSDP/RSDT/XSDT stuff correctly. Another day, another click -tij-
Phew. I'm still not entirely certain what XP is choking on, but then, I manage to make partition tables that combine WinXP, Win7, Ubuntu, and Fedora on one drive that choke the XP installer almost instantly on my machines, too, so ... As am I. Well, XP at least. I don't even have Win7 on my primary machine since I swapped HDDs and couldn't ghost it (actually, Linux 'dd' it) across properly yet. Another day, another silly lesson about NTFS MFT formats. Having used Windows 7 for several weeks, I still like XP better. I figured it was about time to display the version info. At least now it should be possible to tell what version a machine is on without dissecting the ROM. I've decided to go with fat-boy ROMs until there's a need to do otherwise. Apokrif will probably need/want a smaller version for his Dell rom-hacking wizardry, but that's a bridge to cross as we come to it. Sure thing! I have implemented a new version (see next message) with your suggested SLIC info displayed as well. Have fun, -tij-
New Release: WindSLIC v2010.01.20.02 [More Informative] Here is a new release of WindSLIC. View attachment windslic-2010_01_20_02.zip Changelog: ;------------------------------------------------------------ 2010.01.20.02 - Added SLIC Display and IBAUtil Vers Display ;------------------------------------------------------------ - Added SLIC OEMID and OEMTable ID to the INIT display - Added internal pointers to make IBAUTIL display pretty version info, instead of the usual misleading "Flash Not Programmed" statement. - Changed the INIT return value because it was off by one bit. Bits 5:4 set to 10 should give: 0x20 instead of 0x10. ;------------------------------------------------------------
Hey, glad to hear that! Sure thing. Glad to help. It's interesting that the address comes back as 0009FC11. I'm guessing that's just an artifact of whatever program you're using to get the ACPI tables. By the ACPI spec, it should have to be on a 16-byte boundary (0x10). Also I enjoy that the particular SLIC you've chosen looks like like a l33t version of "PESCE", which sounds like "Pesky" when you say it. Good to hear also! What utility is used to flash those NICs? Have fun, -tij-
Request for any new/old-unaddressed WindSLIC bug reports Hi all, With the latest version, WindSLIC v2010.01.20.02, the WindSLIC Option-ROM seems to be working on just about every PC. So, if you know of any outstanding issues with WindSLIC on your PC, please let me know again so I can address them. Thanks, -tij-