Eric, I assume, Dell 200 is AWARD also. Did you you replace SATA ROM? Have you found a way to enable WoL? Yes, the Dell 200 is AWARD. I replace the Raid rom and insert the SLIC2.1. Using eeupdate 503 and seems can enable WOL, eeupdate /gui, then format eeprom, at the bottom have the option for WOL, mini is enabled.
>Yes, the Dell 200 is AWARD. >I replace the Raid rom and insert the SLIC2.1. I did same thing >Using eeupdate 503 and seems can enable WOL, >eeupdate /gui, then format eeprom, at the bottom have the option for WOL, mini is enabled. I gotta try this. On mine the NIC light always lit, but none of WoL packets wake up computer...
Checked on different PC - Dell 9100 run eeupdate -gui -> it shows WOL enabled. When power is connected AND PC is off - one light lit on motherboard, but NIC light is off. If I unplug power cable and plug it back – if NIC light goes on for 1 second, than goes off again. WHF? (NIC cable is always plugged in) If I put PCI card – it’s light is always on (if its WOL is enabled), but there is no wake up connector on motherboard, so it cannot wake it up either. I guess that’s the way motherboard is designed… BTW: On BIOS menu there is PXE enable option, but no any WOL options. Any way around? Will check 530 when later. At least NIC light is always on there and it can wake PC from S3 mode.
Just to reiterate, to update ACPI tables there are two ways only: Either chipset specific “write projection” fiddling, Or “quite complex” EBDA memory allocation, but it supposed to be universal. I.e. no any other universal way around, right? But, Via,SiS, nVidia, etc – they are used quite in a some OEM mobos. I.e. documentation supposed to be available AND manipulations should be in form of PCI bus/dev/fn command on a high level… Or I’m mistaken again? I need a vacation... (C)
More or less, I guess. I'd probably divide the first "write protection fiddling" into the "Before-BIOS" stage (mucking with Dell modules before the write-protection ever takes place), and the "chipset-specific" Option-ROM or Boot-Loader ("During/After-BIOS") stage. The EBDA method isn't necessarily "ultra-complex"; I mean, it's used in the Daz loader, etc., so obviously they've figured out how to do it. I'm just not good at working with it yet. Documentation has to be available to someone, but that could just be to Phoenix/Award/AMI/etc. I've always assumed that any manipulations would be in the form of PCI bus/dev/fun twiddling, but as with anything x86, there are at least three ways to do any task.
"Before-BIOS" stage means also, ACPI tables have to be built already – I guess, locking is done right after that (or very close) I.e. it requires pinpointing exact location in the code AND it cannot be universal therefore, right? He doesn’t use ASM, but C/C++, I guess – do you know the Daz loader size? Hopefully, it's not that scary, i mean EBDA stuff. Exactly
That sounds correct, although I don't know what module does what in the Dell scenario. Maybe one module creates the ACPI tables, another locks the F000 region? Wishful thinking, I suppose.... I think the work in that loader was done during the GRLDR phase by zsmin, but I haven't kept up with the loaders' state of the art since we talked about that back when.
I know how find "module creates the ACPI tables" and exact code inside it. But how do I recognize "memory region locking code"? Common! Should be a problem to a grand like yourself! And you need only EBDA piece, actually. Although, everything else is quite easy.
run eeupdate -gui -> it shows WOL enabled. Send magic pocket - it worked! Started W7 Hibernated W7 Send magic pocket – didn’t work… Turn on (Press power button) Go into BIOS Turn Off (Press power button) Send magic pocket - it worked Checked NIC properties | Power management | Allow this device to wake up was unchecked. One below is also checked – only allow magic pocket to wake up Hibernated W7 Send magic pocket - it worked I seemed to remember – I did disable it myself, otherwise the sequence Run (10 min timeout) Sleep (S3) (20 min timeout) Hibernate didn’t work Instead it did: Run (10 min timeout) Sleep (S3) (20 min timeout) Run (10 min timeout), etc. I.e. instead of Hibernate it did Run and Sleep and never goes to Hibernate. Will check how it works and write again. Sorry for off topic – just don’t know where else to post…
How is the dimension e510 bios? Working with SLIC 2.1? Apokrif, Any luck with the BIOS of "Dell Dimension e510"? Can it be modded? Thanks.
Congrats/Bummer about your vacation/timing. I just got a preliminary version of WindSLIC written that moves the RSDP to the EBDA, and moves RSDT and XSDT to High-Address-Memory. This version will hopefully work with Dells or any other machine that currently has an 000Fxxxx value for the RSDT/XSDT tables. I have not released the new version on MDL yet, however. I'd like someone with a Dell to try it before I make it generally available. One thing I noticed is that Windows7 prefers the EBDA [new/created-by-windslic] RSDP to the F000 [old/BIOS-built-in] RSDP, and thus activates just fine with the new alpha version of WindSLIC, but RW-Everything only looks at the F000 RSDP, so it gets confused and displays only the F000 stuff, so what it shows is different than what Windows is using to determine activation. So, that'll be annoying in the future with helping users with issues with the new version, but ... oh well. I have emailed the author of the RW-Everything utility to mention this discrepancy, but have not heard anything back just yet. Looking up, -tij-
Wow. He contacted me back very quickly. He acknowledged the issue, said he hadn't been aware that it was a problem since most system BIOSes don't use that area for the ACPI RSDP table, and that he would try and get the RW-everything utility updated to work with the EBDA. Very cool! -tij-
Oh, sorry… I thought all the games you bought during Christmas sale will last you couple month at least… Are you done with them already? I gotta look at your EBDA allocation routine – did you follow all recommendation? Actually, WinSLIC is, probably, the first who makes alloc, so requirements might be easier? >prefers the EBDA Cool. I didn’t tell ya, I actually read ACPI 1.0b standard. RSD PTR is first searched in EBDA, then in hi-mem area. I.e. M$ just follows it. Seriously – I’m really looking forward to test your new WinSLIC
There are recommendations? All zsmin said was that it had to be in the first 1K of the EBDA, and on a 16-byte boundary, and that somewhere closer to the beginning was the most likely spot. I sort of just punted, and wrote a function that starts at (or configurably-near) the start of the EBDA, and walks up every 16-bytes, looking for a 36-byte set of all zeroes. The BIOS itself is the main user of the EBDA, with usage that varies (seemingly wildly) between BIOSes and BIOS manfacturers. There are lots of non-zero areas other than the well-known/official "PS2-Mouse" area. The only real guess-at-a-memory-map list I found showed the first 0x1__ range of bytes as being reserved for various things by various BIOSes, so I start after 0x200 (of the total 0x400). So far, that seems to work, except for a bug somewhere in my code that causes it to corrupt some area of memory (still working out where the bug resides) when used with the only ACPI 2.0 board I have. Hehe. That's more than I've ever attempted. I mostly use the ACPI 1.0 and 4.0 specifications for reference, but I grabbed ACPI 2.0 recently just to see for sure what it said. As soon as I work out where the ACPI 2.0 (I'm guessing it's in the XSDT stuff) bug I've got is, I will get you a copy to try with your Dell mod stuff. Sigh. Assembly. I'm more and more amazed that computers manage to boot almost reliably at all. -tij-
>There are recommendations? Yeah… Or I hope so… I saw a post from some guy asking for help related to EBDA & BSOD The answer was to follow recommendation strictly… >All zsmin said was that it had to be in the first 1K of the EBDA, and on a 16-byte boundary, and that somewhere closer to the beginning was the most likely spot. “on a 16-byte boundary” is written in very same ACPI 1.0b standard >I sort of just punted, and wrote a function that starts at (or configurably-near) the start of the EBDA, and walks up every 16-bytes, looking for a 36-byte set of all zeroes. Ouch… What if some other program reserved that memory already? >The BIOS itself is the main user of the EBDA, with usage that varies (seemingly wildly) between BIOSes and BIOS manfacturers. There are lots of non-zero areas other than the well-known/official "PS2-Mouse" area. Yep. Mainly all sorts of Option ROMs use EBDA. Or it might be true BEFORE ACPI come into scene? It’s really not my area of expertise. >The only real guess-at-a-memory-map list I found showed the first 0x1__ range of bytes as being reserved for various things by various BIOSes, so I start after 0x200 (of the total 0x400). So far, that seems to work, except for a bug somewhere in my code that causes it to corrupt some area of memory (still working out where the bug resides) when used with the only ACPI 2.0 board I have. Scary… And if it doesn’t work for some guy from middle of nowhere, how do you propose to debug? >Hehe. That's more than I've ever attempted. I mostly use the ACPI 1.0 and 4.0 specifications for reference, but I grabbed ACPI 2.0 recently just to see for sure what it said. IMHO, Intel standards very well thought over AND well written (but quite bulky) >As soon as I work out where the ACPI 2.0 (I'm guessing it's in the XSDT stuff) bug I've got is, I will get you a copy to try with your Dell mod stuff. That’s (XSDT stuff) exactly I was about to suggest. BTW, you should be able to run WinSLIC as DOS cmd/exe and debug easily (almost without any size limitation due to extra messages) right? Did you give up on rewriting it in C++ already? You can mix easily ASM / C, and just to start use C for debugging mostly. Not sure, if VS can still compile DOS projects… >Sigh. Assembly. I'm more and more amazed that computers manage to boot almost reliably at all. I actually liked it a lot long time ago. Although, looking at Dell BIOS code I agree with you 100% IMO, it has about 10% or less ASM code and the rest is C/C++. Haven’t seen any objects yet. And linking (i.e call from one module) to another is complete madness, IMO. I don’t even understand how do they link different modules together reliably… Neither how to detect dependencies between modules… Ops… I guess I better stop writhing another essay