No problem doing that. Of course, video output seems to make the Dells angrier than everything else we try to do. Maybe we need to track down a Dell-friendly assembly routine for outputting text? Hehe, -tij-
Ok. For desktop not changing mode works fine. For mine notebook D430 I cannot find right BIOS setting not to display spash screen... I mean the setting is there, but it doesn't work! Anyway, how do we tackle it? We can try to switch few modes like: Code: change mode, display current mode settings (message string), wait 1-2 sec repeat I hope we will see something!
Wow! Well done. Will look at report when I get home. Interested in the steps you took in the end. Andy
Don't even count on it! IMO, WS is the most universal way of patching! Edit: I meant, it's so much easier to insert oROM, than go into subtle detail of every BIOS...
I'm with ya. If I can keep the size of the WindSLIC down, of course. Right now with your pushf/popf removal, it's down to 0xFF9 bytes in non-detailed mode. (4KB) -tij-
Very nice! I was thinking about inserting SLIC into static BIOS module and handle ACPI corrections with WS. But I guess, since you copy both SLIC and ACPI tables into HMA, it won’t reduce any code, but add some complexity instead. BTW, once you rewrite WS in C++, it’ll pop up 20% at least…
Those (RSDT,XSDT) are the only ones that add_slic.asm did, so I'm guessing that should be sufficient, at least for anything so far. -tij-
I saw andyp do something with DSDT & SSDT, don't know what it's exactly, that's why I asked. Do you know anything... or better ask him?
According to the ACPI specification (if I am remembering correctly), almost all the well-known ACPI tables are supposed to have matching OEMID and OEMTableID information. So far, though, it hasn't been strongly enforced by MS or others, so no one pays a ton of attention to making all the tables match. Right now, activation only seems to require a minimum of matching, so for the moment, it's probably not worth bending over backwards to implement. -tij-
rubbish... There are fields form OEM [ID, TableID and Revision] I don’t remember anything having them match each other – what the point [for ACPI specification to request] to duplicate same info? In fact, Dell RSD PTR is sometimes different from the rest of the ACPI tables. Might be… If something need to be done more than once, do it generically - write procedure | do it recursively | whatever | make sure it’s understandable. Few things I wanted to post early, but keep forgetting 1. Don’t remember where I read it – oROM might not work (on certain BIOSes?) if it’s smaller then 2K (some sources say 8K) 2. That TPM ROM I posted early – it’s ISA oROM (not PCI oROM) doesn’t need to be bound to device, rigth? 3. You posted long time ago about far call in FASM, I want to post early, but forgot… IMO, easiest way to do call far in SAME segment is: Code: pushcs callfar_x ret msg db "Far call........$" far_x: mov dx, msg mov ah, 9 int 21h retf 4. Yeah!!! FASM supports Local labels (I cannot live without them ) Code: sigma: .alpha: ; local label (1) jmp .alpha ; jump to (1) omega: .alpha: ; local label (2) jmp .alpha ; jump to (2) jmp sigma.alpha ; jump to (1) It’s clearly written in manual, but I managed to miss it when looking for them!!! The label whose name begins with dot is treated as local label, and its name is attached to the name of last global label (with name beginning with anything but dot) to make the full name of this label. So you can use the short name (beginning with dot) of this label anywhere before the next global label is defined, and in the other places you have to use the full name. Label beginning with two dots are the exception - they are like global, but they don't become the new prefix for local labels. Didn’t mean to offend, but to share my finding (well known, probably…)
Ah, from re-examining the spec, it's just the RSDT/XSDT has to match OEMIDs with the FADT table. When I read it the very first time, I kept going back and forth between those tables, so I got the idea that a lot of them had to match, I guess. So, it's back to having to ask AndyP what the DSDT/SSDT tables have to do with anything, I guess. Yes, 2K is a more-or-less "official" standard [an offshoot of the fact that the original BIOSes only scanned on 2K boundaries], but things like VirtualBox have 4K requirements (or so various documents say; I've never got the oROM insertion there to work quite right). I've never seen 8K, but it would not surprise me. True, ISA oROMs don't have the PCI Vendor/Device ID, so I guess they don't have hard device requirements. The oROM embedded in VirtualBox seems to be an ISA oROM. Yeah, I have since found posts on the FASM forums that go over the various ways to do that. Local labels are cool. FASM is fairly neat, overall. NASM doesn't seem to be too bad, either. In fact, they seem to be very similar in a lot of respects. Hehe. Well, Google picks up conversations here very quickly, so now the internet has them linked and search-able. By the way, how did you manage to add a second SLIC to the Dell BIOS? Not actually owning a Dell, I haven't been keeping up well enough with the mechanisms involved. -tij-
I’ll PM him. I think he uses DSDT/SSDT space for SLIC (SSDT is huge)… If it’s 8K – it satisfies both 2K and 4K boundaries alignments Have you tried it already, [out of curiosity?] I guess, it’s just few {if confitions}. Am I mistaken? I recall, it was one of the favorite teacher questions (far call using near one) I cannot live without them! I’m just not good in creating different names for init, continue, done steps! In fact you do exactly the thing FASM can do for you – you prefix local labels with global name Code: BEV: ... BEV_skip_replace_ih_call: ... BEV_finish: ... BEV_skip_init: ... BEV_done: Nothing tricky or interesting, except debugging is absolutely painful… Module #1 is static (a library?) – other modules call it for all common functions. It has lots of space and it stays loaded – so I just stick SLIC into it. Module #2 read CMOS, perform various initializations like, COM ports address assignments (that’s why I cannot use it for debugging!), do most of ACPI stuff, like loading SLIC (if it’s enabled in CMOS!), etc. It’s dynamic (it doesn’t stay in memory). So I hooked few bytes of code right after ACPI tables got moved into HMA to create links to new SLIC. To keep track and make sure BIOS got updated I incremented FACP OEMID on every try - last one was “DELL M22”. So I did 0x22 – 0x07 = 0x1B [27] attempts. Extremely boring and time wasteful… And obviously cannot be automated… So I’m kinda wafting for your WS oROM to solve all problems I think, more interesting (then manual mod I did) will be to find out how to unlock some disabled functionality, like SATA oROM for Optiplex models. They have all hardware, but no oROMs and no BIOS menu entries.
I have just had a go at patching the bios of a dell GX280, with promising, but slightly broken results but i think i know how to do it properly now. The bios is an older one with no slic and a static acpi table, as was mentioned in an earlier post. The original RSDT looks like this: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00004BD0 52 R 00004BE0 53 44 54 40 00 00 00 01 00 44 45 4C 4C 20 20 47 [email protected] G 00004BF0 58 32 38 30 20 20 00 07 00 00 00 41 53 4C 20 61 X280 .....ASL a 00004C00 00 00 00 1F CC 0F 00 00 00 00 00 93 CC 0F 00 25 ....Ì......“Ì..% 00004C10 CD 0F 00 4D CD 0F 00 B4 CD 0F 00 F2 CD 0F 00 46 Í..MÍ..´Í..òÍ..F 00004C20 41 43 50 74 00 00 00 01 00 ACPt..... What i tried initially was moving the RSDT a bit further down in the system rom where it was all FF's and updating the length to add an extra 4 bytes for another table entry, then adding the slic directly after the new RSDT and entering the address of this (easy to calculate as the module is loaded to a fixed address in ram) then updating the RSD PTR to point to the new RSDT table. Recompressing this gave a system rom 0x21 bytes larger than the original so i pasted this in place of the original and updated the length byte for that module in the .hdr and cut 0x21 bytes of 0xFF from after the module chain to keep the file the same size, fixed up the CRC's on the .hdr and turned it into a executable flash with Dell client configuration utility. Then with my fingers and toes crossed i flashed patched bios and the machine booted fine, and it now shows a SLIC! However, it is now missing the SSDT the empty slot in the original RSDT is for a dynamically created table and it appears the code that enters the address of the SSDT in the RSDT is hardcoded to use the address of the old RSDT, so it looks like you can easily add a SLIC to the older desktop dells, but i think i will have to move the FACP into some unused space in the system rom and add the slic after that so i can keep the RSDT at its original address and grow it there. Thats what i plan to test now, ill let you know if it works. edit - i just tried what i thought would work and now xp wont boot, ill investigate tomorrow to see what i messed up
Ok. Let me take a look too. Edit: Please do few things: open WinHex and compare “in memory map” with the one you see in file. It looks like there is only one reference to FACP in RSDT – [0FCC1F] I hope – it shouldn’t be a problem to move FACP. Be careful tho, as you can see – checksums are not calculated. And I believe (99%) – FACP offset is hardcoded for checksums calculation. So during calculation sum byte at old FACP place [4C28 in file, 0FCC28 in memory] will be changed. You, probably, don’t care because it shouldn’t affect the place you going to use for RSDT extension. But you need to put FACP with corrected sum already at new location – I bet 99% BIOS won’t do it for you! I have no clue if FACP is updated dynamically or not and what mechanism is used to locate it. I.e. it’s very easy to get a brick. You probably don’t care much as it looks like quite an old PC. I’m absolutely not an expert in modding, so might be better to ask for advice in general mod forum about possible FACP move implications. Good luck!
To TIJ: Did you get what I meant early (about WS oROM) - it’s much safer to use oROM WS (with F5 bypass) to do a mod. If it doesn’t work – do it again. At least mobo won’t get bricked because of most silly mistakes. We can turn off PXE boot or we can bypass by F5 if it doen't work PMed to you too, please read.
I tried moving the FACP last night, that is what resulted in windows not booting, a bit more looking showed there are dynamic elements in the FACP so that cant be moved I have a few ideas left to try one is to try a straight replacement of the entry for MCFG in the RSDT table as apparently having no MCFG shouldn't cause a problem. The other thing i thought about is the possibility of growing the RSDT upwards, there appears to be a string before the RSDT table: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00004BD0 84 C3 2E A1 C0 CB CB 47 58 32 38 30 20 20 00 52 „Ã.¡ÀËËGX280 .R 00004BE0 53 44 54 40 00 00 00 01 00 44 45 4C 4C 20 20 47 [email protected] G Im not entirely sure what the GX280 string is for as it doesn't appear to be part of the acpi tables perhaps 4 bytes can be pinched from that, but i have a feeling that's rather unlikely. At the moment it looks like ill have to teach myself x86 asm and find the code where the RSDT table is patched up and change the address that the SSDT table entry and checksum is written to to allow me to move the RSDT, i think that would be the best bet but rather more involved than just a bit of hex editing. Ill have another bash tonight at replacing MCFG if i can find a usb keyboard and im not too worried about nuking the bios as i do have a willem for when it all goes pear shaped.