Bios Mods -The Best BIOS Update and Modification Source

VICTORY!!!!
F3xDC register's 10th to 8th bits stand for the P-state maximum value. Which means the p-state with the largest value ID number is: P2 (600 MHz). Upon setting this value to P0 (2.4 GHz) the little rascal was unable to downthrottle! I could even block the vent and it went straight up till 85 °C and k10stat didn't show the slightest flinch in the p-state, it remained rock-steady at 2.4 GHz.
What's even better in this work-around is when I'm done playing/watching HD movies/whatever I re-set this value to 010b from 000b and all is back to normal . No need to reboot, anything.
I don't even know how to thank you kizwan for all your help , of course that doesn't mean that I'll just leave this thread as this isn't exactly a final solution, but it can be used as fallback.

EDIT: I almost got a stroke when this stopped working, until I realized that I put the lappie into sleep just before that. So going into standby resets the register (obviously).

Good job Blasku! Actually that is the same idea I want to do but in SSDT table instead.

On Intel chipset, PCI registers can be configured using CONFIG_ADDRESS (Configuration Address Register). For example Intel 945 Express Chipset:-

If there is similar function use to configure F3xDC register, we can figure out how the register set in BIOS. However, if we mod this in BIOS, the CPU will always running at highest P-State. I think the RW-Everything method is most suitable solution at the moment.

What I've found in my decompiled DSDT are the

Quote:OperationRegion(NBRV, PCI_Config, 0x8, 0x1)

type commands, according to this nice presentation's 14th page, this might be the way to set ACPI registers, including the F3xDC. What just this command does is point to an address which can then be manipulated by the commands that follow it.
So I also looked this up in the ACPI 4.0 specification, and in section 20.5.89 it is explained in more detail.
BTW, according to the BKDG for family 11h AMD processors, section 2.4.2.3: the OS uses the MSRC001_0062 (P-State Control Register) for switching between p-states. I have no idea if this helps in identifying all parts of the BIOS code which touch the p-states. I guess the DSDT might not contain the section that's causing the problem, otherwise this would've been solved by your correcting my DSDT already.

EDIT: Here's a very promising thread about looking for sections of the BIOS code that modify a certain MSR register: http://www.wimsbios.com/forum/topic9326.html
I'm able to decompile the BIOSCOD00.ROM type modules with ndisasm, it'll be interesting to see how many rdmsr and wrmsr commands I'll find.

---

I've attached all the BIOSCOD modules decompiled. I've found a total of 82 occurrences of wrmsr in 4 of these files: 01, 02, 05 and 06. It won't be an easy read...

(^^Sorry, I didn't look in the disassembled file yet. Got problem with my internet connection. I can access & write this post after several retry.)

I found an alternative to the MSR register. F3xDC register is configured using IO-Space Configuration Address Register (BKDG - page #95).

Bits description:-

• Bit 31
  • ConfigEn: configuration space enable. Read-write. 1=IO read and write accesses to IOCFC are translated into configuration cycles at the configuration address specified by this register. 0=IO read and write accesses to IOCFC are passed to the appropriate IO link and no configuration access is generated.
    
• Bits 30:28
  • Reserved.
    
• Bits 27:24
  • ExtRegNo: extended register number. Read-write. ExtRegNo provides bits[11:8] and RegNo provides bits[7:2] of the byte address of the configuration register. ExtRegNo is reserved unless it is enabled by MSRC001_001F[EnableCf8ExtCfg].
    
• Bits 23:16
  • BusNo: bus number. Read-write. Specifies the bus number of the configuration cycle.
    
• Bits 15:11
  • Device: bus number. Read-write. Specifies the device number of the configuration cycle.
    
• Bits 10:8
  • Function. Read-write. Specifies the function number of the configuration cycle.
    
• Bits 7:2
  • RegNo: register address. Read-write. See IOCF8[ExtRegNo].
    
• Bits 1:0
  • Reserved.
    

F3xDC - Bus 0 : Device 18 : Function 3 : Register DC = 80001BDC

So, we should look for "mov ecx,0x80001BDC" opcode then.

EDIT: 80001BDC is wrong. Please see post #58

(07-26-2011, 09:13 PM)kizwan Wrote: [ -> ]F3xDC - Bus 0 : Device 18 : Function 3 : Register DC = 80001BDC

So, we should look for "mov ecx,0x80001BDC" opcode then.

Quote:ExtRegNo provides bits[11:8] and RegNo provides bits[7:2] of the byte address of the configuration register. ExtRegNo is reserved unless it is enabled by MSRC001_001F[EnableCf8ExtCfg].

It took me a little while to understand how the register address is given . Now I see why you don't need address bits [1:0], those will always be 00b anyway. And since 0xDC = 11011100b => 110111b is all you needed to put into RegNo and you didn't even need ExtRegNo so you could leave it all zeros.
But there's one part I still don't get:
I came up with 0x800093DC because the device number is a little different for me?
1000 0000 0000 0000 1001 0011 1101 1100
The bold part is the device number in my case, because 10010b is 18d.
For you it is:
1000 0000 0000 0000 0001 1011 1101 1100
device no. 3?

Anway, I'll try to search for both addresses in the BIOS code.

Device no. in RW-Everything already in hexadecimal, not decimal. Please observed my RW-Everything:-


I'm wrong too. 0x80001BDC is not correct. So, I look again:-

Oh bugger, I always mistake hex numbers when there are no larger digits than 9 involved . My only excuse is that I didn't have any device IDs that has an alphabetical digit in them.
The other problem is that my BIOS code is probably obscured because I don't find a mention of any of these addresses there, so the addresses must be loaded into ECX with some trickery.
I've also searched through BIOSCOD01 and ..02 and found some MSR register addresses that I have no idea what they might be: 0x1f, 0x1a, 0x102a. I can't find them in the BKDG. I've still got ..05 and ..06 to browse through.

My assembly/disassembly skill still at beginner level but I believe I unable to find it too because I don't know the start location of the CODE section is. I found out that we need to load it in IDA & adjusted it to get the correct offsets. To get the actual offsets will require forcing the memory locations when loading in IDA. How to do that (I mean how to find the correct offset)? NASM/NDISASM is great tool but they not always accurate because they can't differentiate between CODE & DATA section (I read this in some forum. Is this correct?).

(07-27-2011, 10:11 PM)kizwan Wrote: [ -> ]My assembly/disassembly skill still at beginner level but I believe I unable to find it too because I don't know the start location of the CODE section is. I found out that we need to load it in IDA & adjusted it to get the correct offsets. To get the actual offsets will require forcing the memory locations when loading in IDA. How to do that (I mean how to find the correct offset)? NASM/NDISASM is great tool but they not always accurate because they can't differentiate between CODE & DATA section (I read this in some forum. Is this correct?).

Yes, you're right... That makes decompilation really tedious (I'm not yet used to IDA), plus how do I differentiate a data section from a code section? If I force IDA to analyze it, it will come up with some code even if it doesn't make sense (a la ndisasm). BTW, what options do you recommend for IDA? I've always selected the processor to be Athlon, but I'm not sure that's a good idea.

I found several Function register but F3xDC is not found.

It make sense F3xDC register is not found. This is because F3xDC register is for setting maximum P-State & VID which the value are not the same for different processor. P-States & VID package are defined in SSDT table (ACPI) which I believe derived from Microcode.

In IDA, I set to Intel (metapc). Since you mentioned that you use Athlon, I start thinking why I didn't use it. LOL. BTW, regarding disassembled BIOS using IDA, I got help from aascut@mydigitallife. The part we need to disassembled is the last 64kB of the ROM.
(EDIT->SEGMENTs->Create segment->)
For 512kbit .rom: last 64 kB->address is from 00070000 to 0007FFFF; base is 70000/10 =7000
or for 1 Mbit .rom: last 64 kB is from 000F0000-000FFFFF; base is F0000/10=F000
or for 2 Mbit .rom: last 64 kB is from 001F0000-001FFFFF: base is 1F0000/10=1F000