Hi there. Have done my full text search, but still don’t know what to begin.
Have to apologize, first, my bad English, second, I am pretty much a newbie in windows driver world, I self learned windows kernel driver for about 2 months, if I do or say something wrong, I am sorry.
As a BIOS engineer, I am always troubled with the lacking of OS side observation / debugging tools, WinDBG is nice, but sometimes debugging a small issue using a checked ACPI.sys is really not that cost efficient, and sometimes doesn’t that handy if I’m in a field debug or an on-site debugging process.
Also, BIOS code nowadays has some specific WMI / customized ACPI method, evaluating them is always hard.
I also use “RW everything” to debug, but it is not flexible enough. I begin to think about writing my own tooling, and I’m also very interested in building wheels, see how things work.
I make a list for my tooling, most of my problems are on the kernel (ring0) driver side, which the problems are:
-
Access physical memory, for modifying GPIOs / IO ports / PCIe registers on the fly which are usually memory mapped these days.
-
Be able to evaluate customized ACPI method / events / WMI interfaces, e.g. To debug an ACPI method just by giving the method name and arguments, or evaluate EC _Q event on the fly, just feed the needed arguments. I don’t have any idea now, from BIOS perspective, we usually using find RSDT pointer first, then find other ACPI tables, which, needs physical memory access, too. And I usually debug ACPI using “ACPINVS memory debug” method, which is, I would allocate a chunk of ACPI memory in some operation region in any ACPI table, then boot into windows, using RW everything or any memory viewing software to observe that particular memory address, then I’ll put my ACPI debug message there. (Which is pretty neat) I think my driver would have to be able to do the same thing, but smarter.
-
Be able to access PCI IO and regular Port IO, such as EC or port 80 (I’ve completed this, relatively easy comparing to requirement 1 and 2…)
The most of my concern is, that I knew physical memory access is pretty much “illegal” from OS perspective, but it is sometimes the only way to probe BIOS functions. Is there a safe way or a safer mechanism to access physical memory?
Second, any suggestion for me to study on? I’m now reading “Programming the Microsoft Windows Driver Model” and “Windows Internal 6th Edition”.
I know very well that I am now still to rookie to do the tasks above, but I’m still trying. Hats off for you guys, windows driver is really tough to learn.