BIOS editing - General Question.

[Qinsp]

This is for cheap FAH machines, used servers.

Am I correct in understanding that the BIOS has a table of CPU ID's in it along with the clockspeed, multiplier, etc?

Is there something other than common sense stopping me from trying to edit that table using a hex editor, then reflashing the result? ie - copy the data from a 2.4ghz chip model into the 2.0ghz model entry? This assumes the only difference is rated speed. Like an Opteron 8356 > Opteron 8389? Or 6128 > 6140?

How do you know if the BIOS is compressed, and is there a tool to uncompress it?

Or is this just plain dumb?

 

[Qinsp]

DOH! I think I see the problem. The multiplier is locked at the CPU. The performance would not change?

 

[tear]

Am I correct in understanding that the BIOS has a table of CPU ID's in it along with the clockspeed, multiplier, etc?

Unfortunately, not. Multipliers, voltages, and other "critical" operational parameters are stored inside the CPU itself.

In production CPUs, these parameters cannot exceed preprogrammed values (they are "locked").

In certain preproduction CPUs (aka ES), they are freely adjustable and can be adjusted by software
at either boot-time (if BIOS supports it) or run-time (from the OS, using tools such as TPC).

There are two top level "BIOS" formats:
- legacy (format depends on BIOS vendor)
- UEFI (next generation firmware, based on open standards)

Legacy BIOS requires proprietary tools. Some of them leak every now and then;
at times someone reverse engineers parts of BIOS and posts custom tools.

UEFI is (conceptually) easier to modify but I haven't researched it thoroughly just yet.

To answer your question, some parts of legacy BIOSes are compressed, others are not.

The only option of overclocking production (locked) CPUs is adjusting reference clock
(nominally 100, 133 or 200 MHz, depending on CPU).
Adjusting reference clock proportionally changes effective CPU frequency.

First challenge is accessing clock synthesizer (usually I2C-driven) chip that's responsible
for generating reference clock.

Next -- caveat: adjusting reference clock very frequently affects not only CPU frequency but also
clocks of many of the peripherals, e.g. northbridge, DRAM, HT/QPI links, SATA phy.

Said peripherals are usually less "tolerant" to frequency bumps == they give out long before
CPU cores. Many of said peripherals have own 'multipliers' so can frequently be dialed down
accordingly (at least theoretically).

Another important aspect -- certain interfaces (HT, QPI, DRAM) are calibrated/tuned boot-time
== you can't adjust them from the OS, need to do it from the BIOS.

And so on, and so forth...

 

[tear]

Stuff related to hacking C32/G34 AMD boards w/legacy AMI BIOSes:

- AMD BKDG for Family 10h CPUs (AMD pub #31116)
- AMD BKDG for Family 15h CPUs (AMD pub #42301)
- AMI BIOS tools (esp. MMTOOL)
- Coreboot project (with emphasis on AGESA code)
- documentation for clock synthesizer that's used by the board

 

[Qinsp]

Thanks! Sounds like I need to do a LOT more research first.

These are dirt cheap 4P Opteron systems, so if I brick a couple, I won't cry.

 

[tear]

You can start with something simple.

Here's how OCNG was created (from memory):

1. Clock synthesizer identification/programming method (done by sfield)

2. Programming the synthesizer from Linux (run-time) -- just that can give you ~5-8%
  and is completely non-invasive [!]

3. Reflashing memory SPD (artificially extending timings) to compensate for overclock

4. Dropping HT frequency by a notch and manipulating HT tuning
  (XmtRdPtr) a bit to, again, compensate for OC (small BIOS mod)

5. All of the above gave us ~12.5% OC

6. Integrating (1) and (2) with BIOS code as well as performing memory timing extension
  (from 3, no SPD reflash req'd any more) with several add'l memory tweaks resulting
  from, again, increased relative memory frequency