Posts Tagged ‘Retail BIOS unlocking’
As we continue our quest to enhance users BIOSes, a new general technique has emerged that has proven more successful than previously thought. Coined Retail BIOS matching, many of us here at BIOS-Mods have had great success unlocking motherboards that share similar characteristics to other retail boards. This concept is a rather new approach, as people were advised against it because the odds were so little of a successful flash.
So what has changed that is redefining this technique? The first major change is that BIOS developers are now programing in languages such as C over the traditional ASM model. This is true especially in CPU Upgrading, where AMD AGESA is written in C and contains a wrapper for vendor written code. This is a significant change because now we are seeing a new scope of coding where manufacturers simply tie their code into a wrapper or a DLL. As the source code becomes more universal, manufactueres simply concern themselves with the details, while the underlying source stays the same. With the evolution of coding in C, DLLs have also made their way into the BIOS. Looking at the bigger picture, with developers merging to a common middleground it has made modding even more realistic as certain BIOS ROMs have become more “compatible” and interchangable with others. Referring back to the AGESA module as an example, versions 3.x and up are now upgradable from almost any other BIOS, which means upgrading to future versions of Phenom on older BIOSes has become quite a reality.
The second major component that has made retail matching more realistic is the ability to recover. With BIOS chips availible online along with EEPROM programers, as well as built in recovery methods, the chances of permanently destroying your motherboard as a result of testing have been significantly reduced if done with the proper equimpment and knowledge.
Retail BIOS matching is really a simple proccess in the beginning. The motherboard in question is compared to a list of other motherboards to see if their compatible, a simple idea. The first rule of thumb is that a donor MUST have the same chipset as the motherboard in question. Once you gather a list of same chipset boards, you then can seperate them by Award and AMI and their BIOS sizes. Finally, go ahead and look at the specifics, and scrutinize every single detail in comparison to the motherboard in question. By running through this quick checklist, you have systematically determined realsitic BIOSes that can be used to upgrade your own motherboard.
Once this proccess is completed, you normally have two options. The first one is simply replace one or two modules in the BIOS that are needed to upgrade something such as a RAID ROM or a CPU microcode table. If you are fortunate enough to be dealing with a motherboard that is supported by the manufacturer, this is the reasonable conclusion. Yet in a considerable amount of cases, we have to go beyond what is expected and do the “reverse proccess”
What I am about to explain will most likely require some homework and study time on your part, but think of this as a history lesson for now. In early 2008 the Award BIOS platform took a new turn, incorporating a new module known as MEMINIT. This radically changed the traditional format of award BIOSes. The modding community was faced with a new beast that no one really had a grasp on. We soon learned moving the ROM out of order, modifying it, or tampering with it in any way resulted in a bad flash. This ROM became the new platform for memory management in the BIOS, and several months later came the new code written in C and the DLLs being incorporated along with MEMINIT. Now that we know how they function we have also learned what this means for BIOSes before 2008, they simply aren’t upgradable to the new standard. Sure you could spend months reverse engineering all the changes that took place when MEMINIT struck, but it would most likely be futile without considerable knowledge in assembler and the award platform. Retail mathching though has changed the playing field in this situation as well. While some manufactueres kept to a high standard and upgraded their older chipsets to the new platform, some simply left their boards to die in the year they were manufactured. As a result, we have been able to upgrade old boards to the new code by flashing the retail roms of boards that were upgraded, and then of course modding them further to run stable on the new board. Many people don’t realize that their boards aren’t limited as a result of their BIOS, they instantly assume that manufacturers deem the hardware too old. The change to the new platform though clearly demonstrated that not only are the chipsets capable, but their level of capability is determined by the BIOS chip that boots it. Don’t believe me? Go to AsRock and look up an nforce3 motherboard, which is one of the only nforce3 motherboards to support the altest AMD CPUs to date. By flashing retail ROMs on older boards and reinserting the LAN/RAID/VGA ROMs, we have breathed life into these boards once again and have enabled the community to use the most up to date proccessors on the market. The best example of this is currently the NFORCE 570-SLI motherboards for both ASUS and ABIT, which are both close to full support as mentioned.
The final case is the perfect match, which is hard to come accross but has been done before. The MCP61 chipset is a perfect example. Not only has it proven to be a versatile chipset, but we have unlocked over 10 different MCP61 boards with ONE bios, which is not only a perfect fit but again proves that the source code is compatible in many different situations.
As we continue to refine this technique in our daily work, it is important to remember that the BIOS is changing. New EFI standards made BIOSes almost merge into their own OS cattegory, and while it may be many years down the road before the compatibility reaches a new level, remember that in the BIOS dev community, nothing ever stays the same for too long. Check out the forums to see this new line of work in action.