Bios Mods -The Best BIOS Update and Modification Source

There are hidden options but they are not related to CPU thermal throttling at all.

I've tried looking for a BIOS for AMD M780G with a smaller MISER module, but it seems hopeless . The Acer Ferrari 1200, Aspire 5530G all have larger modules. My best bet would be the HP Pavilions, because I have seen a DV5 run this very processor flawlessly, but those are Insyde. I've also tried the Toshiba Satellite A300D, but that doesn't seem to be Phoenix, and I couldn't find a BIOS for the Satellite T110-00C.
Maybe I'll check how the Lenovo X220 got its BIOS repaired (compare the earlier version with the patched one), if it is Phoenix.

EDIT: I had another idea, in the case of the Alienware M17xR1 the throttling issue was solved in BIOS rev A07 with an EC patch. What if my problem is also connected to the embedded controller somehow?

EDIT2: Didn't read through it yet (just skimmed it), but this is interesting too: http://forum.notebookreview.com/asus-gam...ation.html
Especially the wikia link in the first post that mentions a certain MSR tool. If I could find out how to set the registers for my laptop to stop throttling, that would be sweet!
BIOS and Kernel Developer's Guide for AMD Family 11h Processors page 152, "F3x64 Hardware Thermal Control (HTC) Register". Looks promising enough

I went further in investigating the MSR-method, as I have no more ideas left in editing the BIOS. I found this page which has an answer describing an automated way of editing an MSR at boot time using RW-Everything.
The problem I'm facing is that I've been reading the BKDG I've linked in the previous post, and I can't even access all the model specific registers listed there, because I don't fully understand all the mnemonics used. When I'm writing to a register, I can refer to it with its address that can be between 0x0 and 0x7FFFFFFF according to RT MSR Tool. Now how do I translate MSRC001_0061 to the previous format (see page 93 of BKDG that doesn't explain a whole lot)? Accessing the F3x64 register will be interesting too, but there seems to be some section in the BKDG explaining that...

EDIT: This header file from CoreBoot's repository (from the AGESA section too, which is even more interesting. Maybe I'll have to try switch the AGESA modules around too?) contains definitions for MSR registers. For example:
According to this, MSRC001_0061 should have an address of 0xc0010061. Duh!

EDIT2: And it totally works too! I've tried setting the smallest allowed p-state to 0 (2.4 GHz) and I immediately got a BSOD . But that's because that register was read-only hehe , got a little carried away there...
I was also able to set the current p-state via the registers. This might actually be a viable workaround!

I think I have an idea. Please dump all DSDT & SSDT tables using AIDA64 (ACPI Tool). P-states are defined in SSDT tables. If we can modify it, put it in DSDT & overload the modified DSDT in windows, I think we can stop the thermal throttling (like you did: set lowest P-State to 0).

You can find the relevant information on the P-States ACPI object (_PSS) in this post. But I don't know whether this also applied to AMD processor or not.

Great idea ! I say let's try this first, but if we 'hardwire' a constant p-state of 0 into the laptop, then there's no way I'll ever be able to use the power saving power plan on the rare occasion I do use it without an AC source in sight, won't I?.
If this works then at least we'll know of a working method to solve this problem.
I think I've seen that part of the SSDT a year ago when I was learning how to correct at least the syntactical defects of the DSDT for Linux not to behave funny (if I changed the brightness using the Fn keys, then the kacpi module would go nuts and get stuck in a loop using the CPU at a 100%).
Now that I think of it, how do you set the lowest p-state by editing the _PSS object? By modifying the status field of a p-state package in order to fool the computer into believing that it's already at the lowest p-state?

Meanwhile I managed to interpret the F3x64 type mnemonics too, which is actually also a piece of basic IT knowledge in case anyone's interested. Here's the section explaining the mnemonic in the BKDG:

Quote:FYxXXX: PCI-defined configuration space; XX X specifies the byte address of the configuration register
(this may be 2 or 3 digits); Y specifies the function number; e.g., F3x40 specifies the register at function 3,
address 40. See 2.11 [Configuration Space], for details about configuration space. Each processor includes
five functions, 0 through 4

A quick check on wikipedia to see how PCI config spaces actually work: http://en.wikipedia.org/wiki/PCI_configu...nformation. Y as a function number fits in with the bus/device/function notation. But which bus and device number do we need? Since each processor must include 5 functions, that shall give us a clue.
Now if we open our trustworthy RW-Everything and go to the PCI Devices section, from the drop down menu we see that only one device has 5 functions. In my case that is Bus 00, Device 18 - AMD Host Bridge.

For the "F3x64 Hardware Thermal Control (HTC) Register" we need Bus 00, Device 18, Function 03. Now, F3x64, 0x64 = 100 is the offset where we should look for our 4-byte register:

Starting with the highlighted byte on the picture above, those 4 bytes make up the HTC register. One shouldn't forget that little-endian is used. The actual contents of the register on the picture for example: 1E 42 00 00 where 1E contains bits no. 31..24 and so on.
In binary form: 00011110 01000010 00000000 00000000 . HTCPstateLimit is read from bits 30 to 28 => the p-state limit of all cores when in HTC state is 001 which would be 1.2 GHz in the case of the ZM-87. That's odd...
And that's pretty much it, I haven't tried yet, but if I set some bits according to the BKDG just at the right place, I can change the HTC temperature limit, or disable HTC altogether.

EDIT: OK, made several errors writing this post, the first of them was forgetting that the offsets given in the mnemonic are hexadecimal, the second is that the offsets aren't counted after the first 64 standardized bytes of the PCI config space, but from 0 (no idea why I made the assumption). Hopefully this post makes sense now.

Right, so now that I really understand what I'm doing with RW-Everything, I could do some experiments.
I've set the topmost bit of F3xE4, alias SwThermtp. This is write-only, and when set to 1 it induces a THERMTRIP event. What that did was immediately restart the computer. I guess that makes sense if the critical temperature is reached...
Now I'm really able to enable/disable HTC, but it has no effect on the thermal throttling/passive cooling phenomenon.
I can also read the temperature directly from the register, not that it helps much other than verify that I'm not mixing things anymore.
So I think I'll need to keep reading the BKDG for a truly useful register.

Good job Blasku. Please keep post any of your finding here.

Your post make me understand better on the PCI configuration & registers. For weeks now I tried to figure out how to modify PCI space (32-bit vs. 36-bit space) & modify other PCI register like TOLUD (Top of Low Usable DRAM)

OK, sure thing . BTW, in my system all of the registers that have something to do with DRAM are in Function 2 config space. Pages 115 through 138 in BKDG, I don't know how much this might differ (a lot?) in an Intel system.

I've decided to clear up the remaining register mnemonics (X and Y are hexadecimal digits):

• SMMXXX: System Management Mode registers, used for system control activities and are transparent/available to the OS. These activities include power management, too. These aren't something one can just simply modify/read though. This will also be the case with IOXXX registers. This means that there are only a handful of registers that have to be loaded with some data and most importantly the ID of a function, and when the function is executed, then some other registers will contain the result. Not exactly manageable by RW-Everything, but if one's willing to write a program for this in assembly, then it's usable.
  
• IOXXX: Also a pain in the [censored] to use outside program code...
  
• FYxXXX: See post #49
  
• APICXX: First, the APIC address base register has to be read in order to find any of the APIC registers. That would be MSR0000_001B. Bits 39 to 12 will contain the memory base address. This is very often 0xFEE00 for both cores, as in my case too. Only 2 other information stored in this register: whether APIC is even enabled, and which core is BSC (that will have this set to 1 obviously).
  Now, in the Memory Dump section of RW-Everything, you should enter 0xFEE00 + 0xXX for the address, and the required register will be at offset 0. For example: APIC20 would be 0xFEE00 + 0x20 = 0xFEE20 . Then the same drill for reading the registers (little-endian, 4 byte long etc.).
  I think this is the correct way to access these registers, but I may be dead wrong since I don't have an application like k10stat to verify the data that I read from these parts of the memory...
  
• CPUID FnXXXX_XXXX: Not very interesting, since these are read-only and only provide information about the CPU that we can get with a ton of programs already written just for this purpose.
  
• MSRXXXX_XXXX: See post #45
  

Now, all I've got to do is read through section 2.4 (Power Management) and maybe 2.3 (Processor Initialization) of the BKDG, then I might have some more ideas .

EDIT: Well, after reading those 10-12 pages from the document it seems that what's truly interesting is the F3xDC register, where I can actually set the lowest p-state without having to worry about a general protection fault (i.e. it's not read-only). Will give that a try...