ppro on 440bx

Attempting to read / write non-existent registers in real single-task mode caused this break! After that, in the code of the last BETA BIOS of the P2L97-S board, 3 points were found where the 0x11E register is read without properly checking the CPU type. The plan was this:
    1. Determination of the L2 cache caching area.
    2. Checking that L2 cache is disabled by hardware - that is, for example, an old Celeron is installed on the Covington core.
    3. Checking whether L2 cache has ECC control or not.
    Elsewhere, BIOS read / write register 0x11E is bypassed (conditional jump) if the installed CPU is older than Pentium II Klamath.

    Initially, the problematic sections of the code were simply cut out by an unconditional jump, and Pentium Pro started up, which confirmed the correctness of the general concept. Then it was done more rationally:
    1. A new code was assembled - almost the same as the problematic one, but a bypass code was inserted before execution if the cpuid is less than 0x630 (that is, if the CPU is older than Pentium II Klamath).
    2. Next, there was an unused space in the BIOS (in our case, in the region of ~ 0xEF100 and beyond) and a new code was integrated using the IDA Pro disassembler ("Load Additional File" command).
    3. The first instruction of the old code has been replaced with an unconditional jump to the new code.
    4. At the end of the new code, we put unconditional jump to the first instruction following the old problematic section of the code.



    The main point here is not to confuse the jump offsets, because they have to be calculated manually (all intra-segment jumps and subroutine calls in x86 are relative), the built-in IDA calculator helped a lot in this matter.
    It is also possible to formalize the new code in the form of a subroutine, then the first instruction of the old code is replaced by a call to the subroutine (call), and after the instruction to call the subroutine, we put an unconditional jump to the first instruction following the old problematic part of the code.
    All of the above was done for the Asus P2L97-S and Asus P2L97-DS boards, and on the latter two Pentium Pros successfully worked in dual mode !!! Validation for 2 Pentium Pro L2 = 512 KB and for 2 Pentium Pro L2 = 1024 KB. The code for determining the type of CPU was also improved, and now Pentium Pro is displayed instead of Pentium II-S. Microcodes for Pentium Pro have also been added using cbrom 2.07.
    During this project, a bug was noticed with ASUS Hardware Monitor, which caused an error when installing Pentium Pro or Pentium II OverDrive, although the core voltage (Vcore) was displayed correctly (in the Hardware Monitor section, you can simply set ignore). The cause of the HWM error has been identified on the P2L97-S board. It turned out that the lower and upper limits of the BIOS Vcore code are determined by the CPUID code of the installed processor. In the case of an unknown processor, the limits of the allowable Vcore are taken as for the Pentium II Klamath (nominal 2.8V): the lower one - 2.592V, the upper one - 2.992V.
    Accordingly, if the Pentium II OverDrive (2.5V nominal) is installed, the core voltage turns out to be below the lower limit, and in the case of the Pentium Pro (3.3V nominal), on the contrary, it is higher than the upper limit. So in both cases we have a Hardware Monitor error.
    The solution to the problem was as follows: code was added to set the voltage limits for the Pentium II OverDrive and Pentium Pro. The lower and upper voltage limits for the Pentium II OverDrive have now been specified as 2.32V and 2.67V and for the Pentium Pro 3.07V and 3.52V.
    Then we tested motherboards based on other chipsets, primarily ASUS P2V (VT82C693 + VT82C596A). Validation. The rework of its BIOS was no different from the P2L97-S / P2L97-DS, everything worked. No power off issues were detected - the board was properly powering down in both APM and ACPI modes. All checks were carried out under OS FreeBSD 8.4.

    The next stage of i440BX - the BIOS of the P3B-F board was reworked. Its BIOS is much more complex, but the errors are the same, and many places in the BIOS code are similar to the BIOS of P2B / P2V boards. Known bugs were fixed, the board started up, but stopped at the very end of POST - 0x63. There is nothing processor-dependent on this code, and this stop made me think about its problem. As a result of trial and error, it was decided to place checkpoints in the BIOS code with the issuance of various numbers in port 0x80 (this is the port where POST codes are output) (i.e., on the POST indicator of the card). In the end, it was found out that a halt occurs when the value 0xA4 is written to port 0xB2. To solve this problem, this operation was bypassed, and the board was successfully launched! Validation.
    At the moment, there is one not yet resolved bug with the Pentium Pro: boards do not turn off the power automatically. According to the Intel Datasheet on PIIX4 (south bridge of i440LX / BX chipsets), this is the APMC port through which power management commands (APM) are transmitted between the OS and the SMI handler.
    “This register passes data (APM Commands) between the OS and the SMI handler. In addition, writes can generate an SMI. PIIX4 operation is not affected by the data in this register. "
    Also here was found information that port 0xB2 is used to log into SMI programmatically, which is quite consistent with what is written in the Intel Datasheet.
    Why writing 0xA4 to port 0xB2 turned out to be fatal for the Pentium Pro is not yet clear, but presumably related to the advanced power saving features added to the Pentium II. Most likely, this is the reason for not turning off the power automatically. The VIA VT82C596A bridge does not have an APMC port and, accordingly, there is no problem with turning off the power.
    Then the BIOS of the P2B-D board (dual Intel 440BX) was modified. There was also a problem with stopping at code 0x63, but it was resolved in the same way as with the Asus P3B-F. Unfortunately, however, a hardware problem came to light: the board did not work if you put a Socket8 to Slot1 adapter with a CPU (Pentium Pro or Pentium II OverDrive) in the second slot of the motherboard. An ordinary slot Pentium II works without problems in the second slot. Accordingly, we have failed to launch a pair of Pentium Pro or Pentium II OverDrive.
    A comparison was made between a slot processor and a Socket8 to Slot1 adapter. On the adapter, BSEL # (FSB selection: 0 - 66 MHz, 1 - 100 MHz) and SLOTOCC # (CPU presence signal, if 0) are absent (not connected anywhere). That is, for an Intel 440BX mainboard, this means that the processor "orders" a 100 MHz FSB and there is no CPU.
    There is only one conclusion from all that has been written above - at any alteration of the motherboard to Intel 440BX (as well as others with FSB 100 support), you need to make sure that the motherboard has the ability to set the FSB frequency to 66 MHz forcibly. We also tested another board based on Intel 440BX - ABIT BE6-II.
    With the soft-menu enabled, the board tries to set FSB = 100 MHz, which also puts an end to the experiment with the Pentium Pro. ASUS P3B-F, on the other hand, when installing a new CPU, as well as after any failure during the POST process, at the next start resets the starting FSB frequency to 66 Mhz.