Bios Mods -The Best BIOS Update and Modification Source

I believe only _PSV is a valid object. PSV0 & PSVA naming does not follow ACPI specification. Try double-click the PSV0 & PSVA object. Convert the PSV0 & PSVA values (for example; if 3000, it equal to 300Kelvin) to Celsius.

(07-15-2011, 07:17 AM)kizwan Wrote: [ -> ]I believe only _PSV is a valid object. PSV0 & PSVA naming does not follow ACPI specification. Try double-click the PSV0 & PSVA object. Convert the PSV0 & PSVA values (for example; if 3000, it equal to 300Kelvin) to Celsius.

Oh bugger... I've checked them and they don't look good . All zeroes.

I started to dissect the UPDATE0.ROM files, and found that the only difference between the UPDATE0.ROM of PBE and the _C00.PEI of Phoenix tool is that UPDATE0.ROM already has the first 18 bytes cut from the beginning, so it starts right with a microcode section.
Comparing the two UPDATE0.ROMs of the Travelmate and Amilo, I found that only 3-3 2048 byte long sections actually look like microcodes, after that something else is stored in there (AGESA module?).
So I've got 01.bin, 02.bin and 03.bin from each BIOS. 01.bin are completely identical in both BIOSes, 02.bin differ, and 03.bin files are almost identical. 03.bin seems to be shifted two bytes to the right in Sa3650. That's rather odd.

---

OK, I've got some new findings!
I was playing around with the microcodes, and I decided to replace the Travelmate's 3 2048 byte long microcodes with that of the Sa3650's.
Once done, I built a new ROM with PBE with this hybrid UPDATE0.ROM inserted. This was for calculating a correct checksum only. Then, I opened this new ROM file with Phoenix tool, and took the _C00.PEI file with the correct checksum out. After that I opened the original BIOS in Phoenix tool, and inserted the new hybrid microcode module in there. This is what I flashed, and guess what? The laptop booted ! No apparent anomalies either.
I only booted into Linux, because I don't want my legal Win7 to reactivate itself (can do that only 3 times with one license, which I got via MSDNAA).
The exciting thing is that my processor's p-states are altered: instead of 2.4, 1.2 and 0.6 GHz, the middle one is 900 MHz with a maximum 1.2 V. Pretty wierd, so I'll surely revert to the original eventually. I attached the output of a python script (hw_pstate_ctrl.py) that I use for checking the p-states.
Sadly, the thermal throttling is still there, and does its thing at the same place too .
I guess that rules out the microcode update as a solution? Maybe it's the AGESA module that has to be updated?

You can edit _C00.PEI directly & reintegrate it using Phoenix tool. Phoenix tool will correct the checksum for you.

OK, cool . What do you think about the microcode not helping much of anything, though?
Now I'm sure that the AGESA modules are in UPDATE00.ROM after searching for "AMD!GESA" string with success. The Travelmate has version 4.4.0.0 and the Amilo has version 4.1.0.2

(07-15-2011, 06:15 AM)Blasku Wrote: [ -> ]...
BTW, TheWiz had an idea in his first reply to this thread that there might be hidden options in the BIOS regarding trip points, whose settings might override the ones that are set in the DSDT. Do you think that's possible (What PBE shows in the "Setup table" tool includes the hidden menus too?)?.

If I remember correctly, I already look in the BIOS for any hidden option for trip points but they are not available/found in the BIOS. I'm pretty sure since I remember examine the BIOS twice. PBE "Setup Table" only show options/menu that linked to the BIOS menu. It doesn't show the hidden options. In the "Strings" window, you can see available strings in the BIOS, including strings to the hidden options.

---

(07-15-2011, 10:19 AM)Blasku Wrote: [ -> ]OK, cool . What do you think about the microcode not helping much of anything, though?
Now I'm sure that the AGESA modules are in UPDATE00.ROM after searching for "AMD!GESA" string with success. The Travelmate has version 4.4.0.0 and the Amilo has version 4.1.0.2

I'm not sure. Probably the microcode is not properly put in _C00.PEI. I dunno anything about AGESA. What is AGESA?

It's the part of the BIOS in AMD systems that actually recognizes the CPU and loads the proper microcode for it methinks.
There's a rather short article on wikipedia.

(07-15-2011, 10:29 AM)Blasku Wrote: [ -> ]It's the part of the BIOS in AMD systems that actually recognizes the CPU and loads the proper microcode for it methinks.
There's a rather short article on wikipedia.

That is similar to Intel Microcode Update Loader. Intel Microcode Update Loader also initialize the CPU & load appropriate microcode update for that CPU. It just like a detection program, that's all. I shouldn't prevent the CPU from working in it full capability. However, I can't say for sure for AGESA since we don't have AGESA documentation.

Back to microcode. In the _C00.PEI, this is the start of the first microcode update (offset 0x18):-

As you can see, start from offset 0x218, there are a lot of 00. They are only to fill the gap (to make the microcode update maintain the 2048-bytes length).

This is the last part of the first microcode update:-

In the picture above, after the first microcode update, the second microcode update start immediately. Basically, the micorocode updates are append together in _C00.PEI. So, should be easy enough to replace the existing microcode update with new one (or from other computer).

And that's what I did too, with a few twists (unnecessary PBE, and UPDATE00.ROM file that is just a _C00.PEI with the first 18 bytes already cut off).
So I am actually using the Sa3650's microcode now, and it didn't have any effect other than some funky p-states.
A drastic solution could be to figure out how to disable throttling completely if all else fails.
BTW, it's funny how these good people have the same problem: http://forums.lenovo.com/t5/X-Series-Thi...d-p/428879 . They'll soon get a BIOS update from Lenovo though. I'm wondering if the BIOS code itself had to be modified (hope not) for that.

P.S.: Attached the _C00.PEI that's currently flashed, for you to check.

Has anyone heard of the MISER module? I was randomly opening files in DUMP dir of Phoenix Tool with hex editor to see if there are any strings in there that may be interesting.
MISER00.ROM starts with: "Phoenix PowerManagement,Copyright 1985-1998,Phoenix Technologies Ltd.All rights reserved". That sounds rather interesting . Found something about it too: http://www.msc-ge.com/download/pc-system...atures.pdf. The relevant section is at page 20.

Quote:Miser 4.0 provides the following services:

1. Initializes power-management devices and routines during POST.
   
2. Utilizes chipset inactivity timers to monitor specified power-management events, such as keyboard, inactivity timeouts.
   
3. Changes the power-management states of specific devices in response to specified power-management events, for example, by turning off the disk drive in response to a completed period of inactivity.
   
4. Provides a window in Setup in which the end user can specify power-management options.
   

That doesn't say much in itself, but this BIOS changelog that I found has a rather interesting sentence involving the miser module.
Anyway, this is just a suspicion .

(07-15-2011, 11:22 AM)Blasku Wrote: [ -> ]P.S.: Attached the _C00.PEI that's currently flashed, for you to check.

I checked your modified _C00.PEI. I noticed the new microcode is not aligned correctly. (Top is original _C00.PEI, below is yours).


BTW, I only know MISER is power management module. Good finding.