The range is definitely fine (same on plain install & again with Daz loader) But mine does not really match with yours - there are quite few differences ACPI page below is after Daz loader: PHP: Table Name OEMID&TableID Address Lenth Description Table (ACPI 2.0)RSD PTR DELL 0009FC11 36 Root System Desc.Pointer | |- RSDT DELL WN09 0009FAD2 68 Root System Desc.Table | | | 00 |- FACP DELL GX620 000FD2DB 116 | 01 |- SSDT DELLst_ex FFFD8815 170 | 02 |- APIC DELL GX620 000FD443 114 | 03 |- BOOT DELL GX620 000FD4B5 40 | 04 |- ASF! DELL GX620 000FD4DD 103 | 05 |- MCFG DELL GX620 000FD544 62 | 06 |- HPET DELL GX620 000FD582 56 |* 07 |- SLIC DELL WN09 0009F92B 374 Software Licensing Desc.Table | |- XSDT DELL WN09 0009FB5B 100 Extended System Desc.Table | 00 |- FACP DELL GX620 000FD34F 244 01 |- SSDT DELLst_ex FFFD8815 170 02 |- APIC DELL GX620 000FD443 114 03 |- BOOT DELL GX620 000FD4B5 40 04 |- ASF! DELL GX620 000FD4DD 103 05 |- MCFG DELL GX620 000FD544 62 06 |- HPET DELL GX620 000FD582 56 * 07 |- SLIC DELL WN09 0009F92B 374 Software Licensing Desc.Table--------- Scan Finished ---------
Actually it’s all right here: First RSDT table is FACP and it should be at 000FD2DB On your dump FACP is at 0001D2DB - i.e. the dump is shifted down 000E0000 Edit: Was writhing my message too long You post has confirmed everything
All matches now, except RSD PTR and RSDT/XSDT Here is what "Daz loader" does: Inserted SLIC to 0009F92B Copied RSD PTR/RSDT/XSDT to 0009FC11/0009FAD2/0009FB5B Added SLIC table to both RSDT & XSDT * 0009FC11/0009F92B/0009FAD2/0009FB5B belongs to EBDA area I.e. since there are empty slots and some unused space in ACPI module – we can do exactly the same!
I’ve fiddled with D430 notebook BIOS (it has SLIC already) I have found code part fixing up ACPI tables sums and then moving them (tables) to upper memory. I'm planning to use it to test dynamic SLIC insertion method. I think the easiest way will be: Code: add new code to the end of the same module replace call to moving ACPI tables to call to new code in the new code call old function add SLIC, correct RSDT/XSDT sums And since D430 has SLIC – that module need to be renamed something else (like SLAC) Anybody sees problems/pitfalls with this approach? I guess I better take a little vacation before I dive into that project.
I guess, you meant to post to some other thread, right? I saw quite few "unrelated" post in other thread too. Is there a bug in portal engine?
The admin was on the ball & already deleted the user (and his/her spam messages) Hance it looks out of place sebus
I was comparing Dimension 9100 vs OptiPlex GX620 PCs - both has ICH7 "chip". I was wondering why there is no any SATA RAID in GX620? For 9100 RAID features can be enabled in the BIOS menu, while for GX620 those menu entries are missing. 9100 BIOS has Intel SATA RAID modules, GX620 doesn’t. GX620 has Broadcom LOM and Remote wakeup configurable in BIOS, and 9100 (with Intel LOM) doesn’t. I have a feeling that missing features could be added. BIOS menu change CMOS values. Based on those values modules got loaded and might be some initialization executed too. Or, hopefully, initialization is done as part of module execution. Hopefully again, the binding between menu item and “code to change CMOS values” is similar to AWARD BIOS. And might be menu/submenu/items hiding is similar too. If I’m right, it shouldn’t be a problem to add SATA RAID to OptiPlex for example. As the first step, I need to find a program to read whole CMOS, and save to file. Change a value – (enable Remote wakeup) – read CMOS again and compare with previous state. Than get a program to change CMOS, and change same value (and update checksum!) Observe effect. If it works – need to change some common values (wake up time) and compare between models to have CMOS map. Than try to add missing modules to BIOS. Interestingly, GX620 BIOS menu binary has all SATA RAID related settings already: RAID Autodetect / AHCI AHCI RAID Autodetect / ATA ATA RAID On RAID Off But 9100 doesn’t have "Remote wake up" one menu item! Strange... P.S. This post is not meant to tease anybody!
I think the only way to know is to try! This is exactly the approach that Middleton used on the EFI BIOSes - although that involved patching the PE image of the module as well. The only theoretical pitfall is if any module offsets need to be preserved/are hardcoded. For example, some modules in Award BIOSes appear to need to be at a fixed offset in the image. Approaches like the 0+2 method then try shrinking one module (by altering text areas) to compensate for the increase in others etc.... Nice work! Andy
>The only theoretical pitfall Theoretical? It's very real I've skipped whole post about Dell BIOS load sequence. Anyway - back to the problem - those intermodule calls is done as "far calls" If there any reliable scanning method to detect them quickly?
Theoretically, you can look for certain opcodes to find far calls, but the combined code/data nature of x86 assembly means you might find some false positives in certain 'data' areas. This doesn't sound like an easy task, unfortunately. On the other hand, I finished a WindSLIC that ought to work on Dells, so you should be able to try that. Hopefully it will work. Assuming it works as a replacement for the PXE rom, we might be able to get it to load piggybacked on the VGA rom so that it always gets loaded. Or, depending on how Dell BIOSes work, we might be able to hook Int 19H to get an always-load scenario working. Lots of fun! -tij-
Right. That would be front attack - most obvious and hard way… IMO much better way will be to employ Hex-Rays Decompiler and IDA Pro… Not to find far calls only but do everything. Anybody got good experience with it? >we might be able to get it to load piggybacked on the VGA rom so that it always gets loaded [to continue our previous discussion] Do you mean modify existing VGA rom or introduce completely new Option ROM? I cannot check right now, but I think VGA rom is practically the same for all [Dell?] models. It’s Intel copyright anyway. Although, it might get disabled if add-on graphic card is installed… If you want to try option rom – you don’t need to uncompress/compress any modules. You can simply find FF area big enough and put it right there. I’ll try once I get home. Or anybody in “manual BIOS mod” thread can do it easily. It’ll be a hit for old Dell notebooks!
I'm not very good at disassembly work, though I am getting a little better after tracking down the goofy "GS-bug" on Int18H. I wish there was an IDA Pro version for hobbyists. I could never bring myself to spend the $540 on a "Standard" version. It's a really great program, but that's too much. I meant modify the existing ROM. It's risky, but it might be the most direct path to an always-loaded option-rom. As for disabling the onboard ROM when a secondary video card is inserted... That's a good question; I'm not sure how VGA Option-ROMs are handled in the "more than one graphics card installed" case. VGA is the most "special-case" technology that I can recall. It has specific addresses, chipset and memory-controller mechanisms, and even buses (AGP!) based around its goofy requirements. I think I remember that only the primary VGA card gets its BIOS loaded, so that might be a vote against even trying the VGA-mod path. I dunno. Neat. Let me know how your tests go. -tij-
I guess, you not going to use IDA Pro for something you going to sell, right? IMO, IDA Pro is unique in a way it has more “non-paying users”, than legitimate ones. One more one less won’t change anything. Ok. Do you want me to dump few different [Dell] VGA ROMs? In case Dell has add on card and monitor is plugged into onboard one – it won’t boot. Just show message – re-plug monitor. Never checked what module does it. Could you write really small option rom (i.e stripe WindSLIC) just to show two messages for init and BEV phases? I’ll try to compile/bind it to different devices and insert into BIOS. I guess, I could do it myself, but you are the expert there, right? Remember that TPM driver? Was it bound to any device actually?
OK folks, this morning tij has provided a beta version of his WindSlic that works in a Dell XPS 400 / Dimension 9150 (ironically enough, on a Compaq-branded NIC) -- confirmed by me. Now for the fun -- and into an area in which I have zero familiarity, I'm a hardware guy -- figuring out if it's possible to add this as an option ROM in the BIOS either by tagging the code onto another piece of always-executed code, or replacing the Intel PXE option rom that is already embedded (for the 99%+ of us that don't use network boot).
xp051a07 has more than 64K unused space – more than enough for WinSLIC. The only problem – if we made a mistake – there is no any built in recovery mechanism for XPS 400 / Dimension 400/9150 - i.e. mobo will be bricked… So when we ready, we will be testing on notebooks first. Although Intel PXE option rom might be somewhat “easy” to replace – there is a BIOS option to disable it. Not 100% sure what happens if PXE oROM is disabled [and there is a bug in it] – it depend which part of BIOS handles it. TIJ, do you have any clue how it’ll work for embedded NICs (i.e. if PXE oROM is disabled in main BIOS menu)? Would init phase be executed still? I guess, the only way to find out is to test on really simple oROM.
Sigh. I'm surprised Dell wouldn't have some form of recovery mechanism, but I guess that's just too intelligent and non-greedy to expect it out of them. Also, I'd be interested to know if the option defaults to Disabled or Enabled if you clear the CMOS. Hrm. I dunno. What does it do normally when you disable it? Do you see any sign of "Intel PXE..." stuff on boot when you disable it? The safe way to bet is that it will screw up as annoyingly as it can.. At the least, I wouldn't count on being able to Press F5 to bypass the WindSLIC activation. More than likely, the keyboard won't be accessible at that point for whatever Dell reason. If I were feeling gutsy enough to try this, I would at least make the WindSLIC bypass *unless* you pushed F5. That way, at least if the keyboard is not functional, it will just skip. Frankly, without a recovery mechanism, I would want a stiff drink first. I think I would re-work the WindSLIC bypass mechanism to look at some non-keyboard trigger. Perhaps have it look at some memory-condition or hardware condition that is controllable... (which is?): Possibilities I've been thinking of to tell WindSLIC to bypass without using the keyboard: #1. Have WindSLIC walk the PCI bus and exit if a device *isn't* there. Sort of a reverse-PFA check. #2. In general, I thought about having WindSLIC auto-skip if the BIOS CMOS checksum is invalid on boot, but that isn't really usable, since the BIOS probably won't boot if it isn't correct, or will correct it *before* calling the Option-ROM. #3. Read the current date from the system and auto-bypass if it is before a certain date. I'm sure getting the date out of the hardware is pesky and annoying, but that might let the system have a shot at skipping when the CMOS is cleared. muddled, -tij-
>Sigh. I'm surprised Dell wouldn't have some form of recovery mechanism, but I guess that's just too intelligent and non-greedy to expect it out of them. They have it for notebooks, so I guess, for desktop (i.e. easy to reach flash by hand) they either have SPI programmer or able disable BIOS using some pins, insert PCI/ISA card with another BIOS and boot from it? Shouldn’t be that difficult to implement, right? >Also, I'd be interested to know if the option defaults to Disabled or Enabled if you clear the CMOS. Disabled >Hrm. I dunno. What does it do normally when you disable it? Do you see any sign of "Intel PXE..." stuff on boot when you disable it? The safe way to bet is that it will screw up as annoyingly as it can.. No any signs. >At the least, I wouldn't count on being able to Press F5 to bypass the WindSLIC activation. More than likely, the keyboard won't be accessible at that point for whatever Dell reason. Right. >If I were feeling gutsy enough to try this, I would at least make the WindSLIC bypass *unless* you pushed F5. That way, at least if the keyboard is not functional, it will just skip. Frankly, without a recovery mechanism, I would want a stiff drink first. Right... >I think I would re-work the WindSLIC bypass mechanism to look at some non-keyboard trigger. Perhaps have it look at some memory-condition or hardware condition that is controllable... (which is?): >Possibilities I've been thinking of to tell WindSLIC to bypass without using the keyboard: >#1. Have WindSLIC walk the PCI bus and exit if a device *isn't* there. Sort of a reverse-PFA check. We need it for notebooks too, right? So it’s better be some device on USB bus… like USB flash drive Not sure about USB state during oROM execution though… >#2. In general, I thought about having WindSLIC auto-skip if the BIOS CMOS checksum is invalid on boot, but that isn't really usable, since the BIOS probably won't boot if it isn't correct, or will correct it *before* calling the Option-ROM. >#3. Read the current date from the system and auto-bypass if it is before a certain date. I'm sure getting the date out of the hardware is pesky and annoying, but that might let the system have a shot at skipping when the CMOS is cleared. Although you probably know better than I do… I would look into CMOS time (#3) and CMOS bit responsible for PXE enable/disable (#2) I have a feeling it’s the same for all Dells. To confirm we need a simple program to dump CMOS. Problem – it looks like they have at least two of them (CMOSes)… Sorry for asking same question – could you create dummy oROM which display two messages only on init and BEV so we can start fiddling with it?