Hello all! The charger for my Dell Vostro 1015 died recently. So I bought an universal power adapter, which was twice as cheap than the official one which is too expensive for me at the moment. It outputs out a near-perfect 19,5 V for the laptop, but the laptop refuses to charge its battery with this charger. The BIOS outputs: Code: The AC power adapter wattage and type cannot be determined.\r\n The battery may not charge.\r\n The system will adjust the performance to match the power available.\r\n Please connect a Dell 65W AC adapter or greater for best system performance. etc... I'm a beginner with BIOS hacking, but I've investigated some x86 code in the past. Some of the tools posted in these forums have also been handy. I think it was AndyP's PhoenixTool which helped me split the 1015_a06.hdr file from the 1015_a06.exe BIOS updater executable. In the last 3-4 days I have browsed through thousands of posts on MDL reading about Dell BIOS modding. But I still haven't been able to figure out whether it is possible to work around this issue by modifying the BIOS. My problems are mostly due to lack of documentation on BIOS coding. My list of questions about such BIOS images grows as I investigate: Does 'out 74h, A; in V, 75h' read a byte V from offset A from some kind of memory (CMOS)? Does 'out 74h, A; out 75h, V' write the value V to offset A to the same memory? What are I/O ports 0B2h and 84h? Why is the same value always output to both of these by consecutive x86 out instructions? What are the semantics for this? Is this SMI/SMBUS? Where can I find documentation for this? Do x86 'out' instructions sometimes modify contents of the registers? (SMI?) If I get a bunch of *.ROM files unpacked from a *.HDR file then how do I properly load them to an IDA freeware 5.0 so that IDA could properly process all those cross-segment jumps? How do I recompress all those *.ROM files to something valid (*.HDR or *.EXE) I can use for flashing the BIOS. Or perhaps most importantly: Is it even possible to do some BIOS modding to archive proper compatibility with non-Dell power adapters? If no, then why not? Are there some other software workarounds? Key combinations at startup? If yes, then any information about how to do it would help. Thank you!
Charging controll as far as I know is on EC (embedeed controller) EC act as a SMBUS transition between battery and charger IC. Battery and charger IC talk using SMBUS. Is not main BIOS file role of that, but krom file . Most of them are based on 8051 MCU but no datasheet available.
Ok. Since the laptop has ICH9, I found some answers from the "Intel I/O Controller Hub 9 (ICH9) Family Datasheet" available online (can't paste link yet because I'm new member on forums. Please use Google instead). As I suspected, 74h is the RTC standard RAM index register, 75h is the RTC standard RAM target register. There might be required some reading magic from 74h before writing to 74h because the highest bit (7) must to be preserved. RTC standard RAM memory from 0Eh to 7Fh doesn't have fixed semantics for ICH9 so the BIOS can use these for itself. B2h is a the Advanced Power Management (APM) Control Port Register (or APM_CNT for short), which is used to issue APM commands to the SMI handler. Output to port B2h stores data to the APMC register and might also generate an SMI# interrupt when the APMC_EN bit is set in the SMI Control and Enable Register (SMI_EN). Port 84h is a programmable port in the DMA controller which either gets directed to PCI or LPC (low pin count interface version 1.1). Given that writes to port B2h might trigger an SMI# interrupt, is it possible for the interrupt handler to modify registers at the context of the x86 out instruction?
From what I've deduced, the battery voltage is about 11V nominal (actually 3.65V x 3). The charger voltage is 19V. Therefore, a buck converter is used to transfer energy from the charger to battery. Using PWM, a buck converter can monitor power delivery and precisely control charge rate. The actual (physical) control for the power converter is handled by a dedicated microcontroller with local firmware. This microcontroller authenticates the charger by identifying the digital signature. Once authenticated, the microcontroller allows the power converter to operate. If authentication fails, the power converter will supply power to the laptop, but disallow battery charging. The system BIOS (most likely) does not have the authority to override the local microcontroller and authorize battery charging, and I welcome somebody to prove that hypothesis wrong.
That's the way. What you called dedicated microcontroller is EC (embedeed controller) which send a signal to carger IC to disable charging. Firmware of EC could be extracted on somne models with -writekromfile parameter . (something like BIOSfilename.exe -writekromfile ) Modding of that firmware is dangerous since you can brick your laptop and no recovery mode will work for that (except replacing EC from other board,no other way to reprogram it)
The charger (power adapter) only delivers 19V (inner and outer sleeve) and digital signature (center pin). My tests reveal the adapter does not recieve signals or make decisions. The power routing is performed inside the laptop by the EC using local firmware. There are two directions for incoming power: to the laptop motherboard and to the battery. If the EC authenticates the adapter's signature, battery charging is allowed. The power controller EC is located on the laptop motherboard. The firmware may be accessible through BIOS, but probably not. Mostly, EC firmware is only available by accessing pins directly on the EC, which means you need to disassemble your laptop to locate the chip and access the pins. Even if you find the pins to the EC, the embedded firmware may be encrypted or not accessible. I've seen hackers who remove the digital signature chip from a discarded adapter and solder the chip onto the motherboard to make the digital signature permanently available. This may be the only solution.