How to squeeze 16 GB of memory onto a motherboard that does not support such a volume
Some time ago I put 16 GB of memory on one of my computers. It has a motherboard Foxconn P55MX with Core i5 750. It would be possible to replace this old CPU, but it still works fine and does everything that I need.
That's what's interesting. The motherboard does not officially support 16 GB of RAM. The specifications on the above page indicate that a maximum of 8 GB is supported. There are only two slots on the board, so I suspected that the 8 GB bars were just rare when the motherboard came out. I decided to try anyway. In many cases, motherboards support more RAM than the manufacturer officially claims.
I made sure that the latest BIOS version (version 946F1P06) was installed and inserted two of my 8 GB slats. Then I downloaded Ubuntu 16.04, and everything worked fine. I decided that my theory that the board supports more memory than stated in the documentation turned out to be correct, and forgot about it. I liked working with extra RAM and I was happy that the game paid off.
But a few months later, I tried to load Windows 10. Basically, the computer runs on Linux. Only sometimes you need to load Windows to check something. That's when the fun began.
')
When GRUB appeared, I selected Windows 10 in the menu and pressed Enter. The Windows boot screen appeared briefly, and then I was immediately greeted by the blue screen of death.
Stop code: ACPI_BIOS_ERROR. I googled a lot and found out that the essence of some kind of problem with ACPI-tables in the BIOS. Among other things, ACPI tables tell the operating system how to configure hardware. Attempting to boot from the Windows installation USB drive resulted in the same error. So, I think, Foxconn did not lie. This computer really does not support 16 GB of RAM. Returning to 8 GB led to a successful download. RAM tests also went great, so it's not a bad memory bar.
I tried to contact Foxconn support for a BIOS fix, but I didn't get an answer. The email address is listed on their website, but it does not work. Perhaps Foxconn no longer deals with motherboards. It seems that they also do not provide support.
At this point, an ordinary person would simply give up, accepting 8 GB of memory or buying a new computer. But I did not want to give up so easily. I knew that theoretically a computer could use 16 GB, because it worked perfectly in Linux. So I started learning ACPI and experimenting with BIOS settings.
I found an interesting BIOS section where you can play with some memory settings. One of the parameters was the “Memory Remap Feature”. She was on. The BIOS documentation states that the option allows "overlapping PCI memory" for mapping above total physical memory. An Internet search indicated that it should be turned on when downloading to a 64-bit OS. Just for the sake of experiment, I turned it off, and Windows really booted! However, she said that she could use less than 4 GB of RAM. But it was nice: I had a way to get into Windows without having to physically remove the memory bar.
Ubuntu is the same. With the memory remapping feature disabled, it limited me to less than 4 GB of RAM. At the moment I was sure that there was some kind of memory mapping problem. I decided to study the ACPI_BIOS_ERROR error and its causes in more detail - and came across this excellent debugging document for Microsoft drivers, which explains ACPI_BIOS_ERROR error checking.
According to the document, it was necessary to find four error parameters that were previously displayed on a blue screen in older versions of Windows. Windows 10 by default hides all information, but you can re-enable the display of additional error information by adding an entry to the registry. Here is a great answer to superuser.com, which showed me the right direction .
After the corresponding editing of the registry, I again enabled the memory reassignment function in the BIOS and loaded Windows. BSOD now showed four additional codes in the upper left corner:
Perfectly! Thus, parameter 1 is 0x0000000000000002. The Microsoft documentation says that parameter 1, equal to 0x02, means a problem with processing the list of resources for root busses PCI. Since parameters 2, 3, and 4 look like crazy values, these are probably pointers. And if there are only pointers here, Microsoft says that the problem is that the PCI decoding area overlaps with the list of memory areas returned by the BIOS E820 interface.
Okay. There is a lot of information, but you can start a study from something. I found information on how to call the E820 BIOS provides information on memory areas. Then I returned to Linux and looked at all the information about kernel startup using the dmesg command, paying particular attention to the E820 and ACPI. Here is what was found:
Later I saw this:
Yeah! See the conflict warning? I would not notice it, but after installing the memory Linux began to display this message with each boot. I tried to boot into Linux with the BIOS memory remapping feature disabled. In this case, the last e820 area disappeared from 0x100000000 to 0x42fffffffff, and thus the conflict message also disappeared, and another “bus root resource” appeared in the list with the main bridge window from 0x400000000 to 0xfffffffff.
So what happens? Linux works with 16 GB because it notices a conflict and ignores the conflicting PCI range provided by ACPI, while Windows raises its hands in disgust and spits out the blue screen: “Your BIOS has a problem!” I can't blame Windows. Indeed, there is an overlap, so it can be understood that it is confused.
At that moment I was not sure whether to continue. The last 768 MB of memory from 0x400000000 to 0x42fffffffff is mapped to the beginning of a huge area of ​​memory space that the motherboard uses for PCI. It is clear that if a motherboard expects a PCI there, something really bad can happen. So the motherboard only supports 15.25 GB of RAM, right?
But ... on Linux, everything works just fine, without the support of this additional PCI matching area! What if you somehow change the ACPI tables so that a large PCI range starts with 0x430000000 instead of 0x400000000, that is, immediately after the end of the physical RAM. Then the conflict would disappear, and most of the PCI matching window still remained available.
Challenge accepted.
I started digging through the ACPI tables. Fortunately, Linux makes it very easy to make dumps. There are special tools for this, but the tables can be easily found in sysfs:
Here they are. I was also pleased that GRUB has the ability to replace your ACPI tables with new versions. Therefore, if you find out which table is involved, you can install a new version of this table using GRUB. Theoretically, Windows would be happy with this.
Among other tools, I used iasl to parse various ACPI tables and find the value 0x400000000 for replacement. Most likely, this value is in byte order (little-endian) and 64 bits in size, so I ran binwalk to search all table files:
One result was found in the OEMB table. The next 64-bit word after it was 0x1000000000, slightly more than the final address in the conflict message of the main bridge window. Very promising clue. The OEMB table is special because it is not a standard table according to the ACPI specifications. Linux complains about an invalid checksum, but I don’t think it matters. I guess you guess what I did next.…
I made a copy of the OEMB table, replacing byte 0x00 immediately before byte 0x04 with 0x30 to change the value to 0x430000000 (remember that this is the reverse of the order). I put this modified copy in the /boot/oemb.dat file. Then I used GRUB to replace the OEMB table with my copy, temporarily inserting the following command into the list of boot commands (entering the letter 'e' in GRUB after selecting Ubuntu):
The idea is that it tells GRUB to load all the ACPI tables except for the OEMB table, then load the contents of /boot/oemb.dat and add it as an additional table. This effectively replaces the old OEMB table with the new OEMB table.
Well, I downloaded Linux and ...
. WTF? , PCI - , , . , OEMB , .
iasl DSDT. , DSDT
.dsl _CRS, PCI, . DSDT , . _CRS . , _CRS , 0xCF78E064. Linux dmesg :
! OEMB. . OEMB?
dmesg OEMB. , , , GRUB , OEMB, . , DSDT 0xCF78E064 OEMB. - , - . .
DSDT, OEMB, , , GRUB , OEMB.
. GRUB
. GRUB:
0x00 0x04 0x30, 64- PCI 0x0000000430000000. OEMB, Linux , , , , .
Linux dmesg PCI.
! 0x430000000-0xfffffffffff , . , Linux , Windows .
! Windows 16 RAM, GRUB write_byte. Windows 10, , . - Windows, , RAM, . !
GRUB, /etc/grub.d/00_patchbios :
, . PCI - . , RAM. Linux 16 RAM, . , PCI/PCIe - , , , , . , , , ACPI BIOS .
, , ! , - . , .
That's what's interesting. The motherboard does not officially support 16 GB of RAM. The specifications on the above page indicate that a maximum of 8 GB is supported. There are only two slots on the board, so I suspected that the 8 GB bars were just rare when the motherboard came out. I decided to try anyway. In many cases, motherboards support more RAM than the manufacturer officially claims.
I made sure that the latest BIOS version (version 946F1P06) was installed and inserted two of my 8 GB slats. Then I downloaded Ubuntu 16.04, and everything worked fine. I decided that my theory that the board supports more memory than stated in the documentation turned out to be correct, and forgot about it. I liked working with extra RAM and I was happy that the game paid off.
But a few months later, I tried to load Windows 10. Basically, the computer runs on Linux. Only sometimes you need to load Windows to check something. That's when the fun began.
')
When GRUB appeared, I selected Windows 10 in the menu and pressed Enter. The Windows boot screen appeared briefly, and then I was immediately greeted by the blue screen of death.
Stop code: ACPI_BIOS_ERROR. I googled a lot and found out that the essence of some kind of problem with ACPI-tables in the BIOS. Among other things, ACPI tables tell the operating system how to configure hardware. Attempting to boot from the Windows installation USB drive resulted in the same error. So, I think, Foxconn did not lie. This computer really does not support 16 GB of RAM. Returning to 8 GB led to a successful download. RAM tests also went great, so it's not a bad memory bar.
I tried to contact Foxconn support for a BIOS fix, but I didn't get an answer. The email address is listed on their website, but it does not work. Perhaps Foxconn no longer deals with motherboards. It seems that they also do not provide support.
At this point, an ordinary person would simply give up, accepting 8 GB of memory or buying a new computer. But I did not want to give up so easily. I knew that theoretically a computer could use 16 GB, because it worked perfectly in Linux. So I started learning ACPI and experimenting with BIOS settings.
I found an interesting BIOS section where you can play with some memory settings. One of the parameters was the “Memory Remap Feature”. She was on. The BIOS documentation states that the option allows "overlapping PCI memory" for mapping above total physical memory. An Internet search indicated that it should be turned on when downloading to a 64-bit OS. Just for the sake of experiment, I turned it off, and Windows really booted! However, she said that she could use less than 4 GB of RAM. But it was nice: I had a way to get into Windows without having to physically remove the memory bar.
Ubuntu is the same. With the memory remapping feature disabled, it limited me to less than 4 GB of RAM. At the moment I was sure that there was some kind of memory mapping problem. I decided to study the ACPI_BIOS_ERROR error and its causes in more detail - and came across this excellent debugging document for Microsoft drivers, which explains ACPI_BIOS_ERROR error checking.
According to the document, it was necessary to find four error parameters that were previously displayed on a blue screen in older versions of Windows. Windows 10 by default hides all information, but you can re-enable the display of additional error information by adding an entry to the registry. Here is a great answer to superuser.com, which showed me the right direction .
After the corresponding editing of the registry, I again enabled the memory reassignment function in the BIOS and loaded Windows. BSOD now showed four additional codes in the upper left corner:
Perfectly! Thus, parameter 1 is 0x0000000000000002. The Microsoft documentation says that parameter 1, equal to 0x02, means a problem with processing the list of resources for root busses PCI. Since parameters 2, 3, and 4 look like crazy values, these are probably pointers. And if there are only pointers here, Microsoft says that the problem is that the PCI decoding area overlaps with the list of memory areas returned by the BIOS E820 interface.
Okay. There is a lot of information, but you can start a study from something. I found information on how to call the E820 BIOS provides information on memory areas. Then I returned to Linux and looked at all the information about kernel startup using the dmesg command, paying particular attention to the E820 and ACPI. Here is what was found:
BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x00000000cf77ffff] usable BIOS-e820: [mem 0x00000000cf780000-0x00000000cf78dfff] ACPI data BIOS-e820: [mem 0x00000000cf78e000-0x00000000cf7cffff] ACPI NVS BIOS-e820: [mem 0x00000000cf7d0000-0x00000000cf7dffff] reserved BIOS-e820: [mem 0x00000000cf7ed000-0x000000ccfffffff] reserved BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved BIOS-e820: [mem 0x0000000100000000-0x000000042fffffff] usable
Later I saw this:
acpi PNP0A08: 00: ignoring host bridge window [mem 0x400000000-0xfffffffff window] (conflicts with System RAM [mem 0x100000000-0x42fffffff]) PCI host bridge to bus 0000: 00 pci_bus 0000: 00: root bus resource [io 0x0000-0x0cf7 window] pci_bus 0000: 00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000: 00: root bus resource [mem 0x000a0000-0x000bffff window] pci_bus 0000: 00: root bus resource [mem 0x000d0000-0x000dffff window] pci_bus 0000: 00: root bus resource [mem 0xd0000000-0xdfffffff window] pci_bus 0000: 00: root bus resource [mem 0xf0000000-0xfed8ffff window] pci_bus 0000: 00: root bus resource [bus 00-ff]
Yeah! See the conflict warning? I would not notice it, but after installing the memory Linux began to display this message with each boot. I tried to boot into Linux with the BIOS memory remapping feature disabled. In this case, the last e820 area disappeared from 0x100000000 to 0x42fffffffff, and thus the conflict message also disappeared, and another “bus root resource” appeared in the list with the main bridge window from 0x400000000 to 0xfffffffff.
So what happens? Linux works with 16 GB because it notices a conflict and ignores the conflicting PCI range provided by ACPI, while Windows raises its hands in disgust and spits out the blue screen: “Your BIOS has a problem!” I can't blame Windows. Indeed, there is an overlap, so it can be understood that it is confused.
At that moment I was not sure whether to continue. The last 768 MB of memory from 0x400000000 to 0x42fffffffff is mapped to the beginning of a huge area of ​​memory space that the motherboard uses for PCI. It is clear that if a motherboard expects a PCI there, something really bad can happen. So the motherboard only supports 15.25 GB of RAM, right?
But ... on Linux, everything works just fine, without the support of this additional PCI matching area! What if you somehow change the ACPI tables so that a large PCI range starts with 0x430000000 instead of 0x400000000, that is, immediately after the end of the physical RAM. Then the conflict would disappear, and most of the PCI matching window still remained available.
Challenge accepted.
I started digging through the ACPI tables. Fortunately, Linux makes it very easy to make dumps. There are special tools for this, but the tables can be easily found in sysfs:
/ sys / firmware / acpi / tables
Here they are. I was also pleased that GRUB has the ability to replace your ACPI tables with new versions. Therefore, if you find out which table is involved, you can install a new version of this table using GRUB. Theoretically, Windows would be happy with this.
Among other tools, I used iasl to parse various ACPI tables and find the value 0x400000000 for replacement. Most likely, this value is in byte order (little-endian) and 64 bits in size, so I ran binwalk to search all table files:
binwalk -R '\ x00 \ x00 \ x00 \ x00 \ x04 \ x00 \ x00 \ x00' *
One result was found in the OEMB table. The next 64-bit word after it was 0x1000000000, slightly more than the final address in the conflict message of the main bridge window. Very promising clue. The OEMB table is special because it is not a standard table according to the ACPI specifications. Linux complains about an invalid checksum, but I don’t think it matters. I guess you guess what I did next.…
I made a copy of the OEMB table, replacing byte 0x00 immediately before byte 0x04 with 0x30 to change the value to 0x430000000 (remember that this is the reverse of the order). I put this modified copy in the /boot/oemb.dat file. Then I used GRUB to replace the OEMB table with my copy, temporarily inserting the following command into the list of boot commands (entering the letter 'e' in GRUB after selecting Ubuntu):
acpi --exclude = OEMB /boot/oemb.dat
The idea is that it tells GRUB to load all the ACPI tables except for the OEMB table, then load the contents of /boot/oemb.dat and add it as an additional table. This effectively replaces the old OEMB table with the new OEMB table.
Well, I downloaded Linux and ...
acpi PNP0A08: 00: ignoring host bridge window [mem 0x400000000-0xfffffffff window] (conflicts with System RAM [mem 0x100000000-0x42fffffff])
. WTF? , PCI - , , . , OEMB , .
iasl DSDT. , DSDT
_CRS, .iasl -d DSDT
.dsl _CRS, PCI, . DSDT , . _CRS . , _CRS , 0xCF78E064. Linux dmesg :
ACPI: Early table checksum verification disabled ACPI: RSDP 0x00000000000F9820 000014 (v00 ACPIAM) ACPI: RSDT 0x00000000CF780000 000044 (v01 012110 RSDT0821 20100121 MSFT 00000097) ACPI: FACP 0x00000000CF780200 000084 (v01 012110 FACP0821 20100121 MSFT 00000097) ACPI: DSDT 0x00000000CF780460 006FE7 (v01 946F1 946F1P06 00000000 INTL 20051117) ACPI: FACS 0x00000000CF78E000 000040 ACPI: APIC 0x00000000CF780390 00008C (v01 012110 APIC0821 20100121 MSFT 00000097) ACPI: MCFG 0x00000000CF780420 00003C (v01 012110 OEMMCFG 20100121 MSFT 00000097) ACPI: OEMB 0x00000000CF78E040 000082 (v01 012110 OEMB0821 20100121 MSFT 00000097) ACPI: HPET 0x00000000CF78A460 000038 (v01 012110 OEMHPET 20100121 MSFT 00000097) ACPI: GSCI 0x00000000CF78E0D0 002024 (v01 012110 GMCHSCI 20100121 MSFT 00000097) ACPI: DMAR 0x00000000CF790100 000090 (v01 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0x00000000CF7917C0 000363 (v01 DpgPmm CpuPm 00000012 INTL 20051117)
! OEMB. . OEMB?
dmesg OEMB. , , , GRUB , OEMB, . , DSDT 0xCF78E064 OEMB. - , - . .
DSDT, OEMB, , , GRUB , OEMB.
. GRUB
write_byte, write_word, write_dword read_. GRUB OEMB? BIOS' . , RAM, .. GRUB:
write_byte 0xCF78E0B5 0x30
0x00 0x04 0x30, 64- PCI 0x0000000430000000. OEMB, Linux , , , , .
Linux dmesg PCI.
PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff window] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xdfffffff window] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff window] pci_bus 0000:00: root bus resource [mem 0x430000000-0xfffffffff window] pci_bus 0000:00: root bus resource [bus 00-ff]
! 0x430000000-0xfffffffffff , . , Linux , Windows .
! Windows 16 RAM, GRUB write_byte. Windows 10, , . - Windows, , RAM, . !
GRUB, /etc/grub.d/00_patchbios :
# This file patches the BIOS in my Foxconn P55MX motherboard to work # properly when I have 16 GB of RAM installed. It's a nasty hack. # Basically, the BIOS is hardcoded in the OEMB ACPI table # to have a PCI address range from 0x400000000 to 0xfffffffff, but # that overlaps with 16 GB of RAM being installed, because the RAM # uses up (among other ranges) 0x100000000 to 0x42fffffff. # This patch changes the table to actually list a PCI range of: # 0x430000000 to 0xfffffffff echo "write_byte 0xCF78E0B5 0x30"
sudo update-grub. GRUB., . PCI - . , RAM. Linux 16 RAM, . , PCI/PCIe - , , , , . , , , ACPI BIOS .
, , ! , - . , .
Source: https://habr.com/ru/post/449940/
All Articles