Вот как я установил 16 ГБ ОЗУ на материнскую плату, которая поддерживает только 8 ГБ. | ВесьТоп создание и продвижение сайтов

Поддержка сайта

Высокие позиции в поисковой системе, на прямую зависят от развития вашего сайта.

Продвижение сайтов

Эффективность стратегий продвижения подтверждается сотрудничеством с крупными клиентами и отзывами о нашей работе.

Создание сайтов

Мы делаем сайты быстро, недорого и профессионально. От работы с нами, у вас останутся только положительные эмоции.

Вот как я установил 16 ГБ ОЗУ на материнскую плату, которая поддерживает только 8 ГБ.

Вот как я установил 16 ГБ ОЗУ на материнскую плату, которая поддерживает только 8 ГБ.

Некоторое время назад я установил на одном из своих компьютеров 16 ГБ оперативной памяти. Материнская плата — Foxconn P55MX с Core i5 750. Она могла бы заменить этот старый процессор, но пока она работает хорошо, и ее достаточно для работы, которую я ей поручил.

Но вот что интересно. Эта материнская плата официально не поддерживает 16 ГБ ОЗУ. В спецификации производителя указано, что максимальный объем оперативной памяти для него составляет 8 ГБ. В самом низу два слота ОЗУ и мне показалось, что тайлы на 8 Гб были редкостью на момент его выпуска и, может, что-то можно сделать. В любом случае, я решил попробовать. Во многих случаях материнские платы поддерживают больше памяти, чем заявляет производитель.

Я убедился, что установил последнюю версию BIOS (версия 946F1P06) и установил две платы по 8 ГБ. Затем я загрузил Ubuntu версии 16.04, и все заработало отлично. То есть моя теория о том, что нижняя часть поддерживает больше ОЗУ, чем указано в спецификациях, оказалась верной. Я быстро забыл об этом. Мне понравилось работать с таким большим объемом оперативной памяти, и я был рад, что мои усилия окупились.

Но после нескольких месяцев такой же конфигурации мне пришлось запустить Windows 10. На компьютере в основном работает Linux, но я установил Windows 10 на один из разделов на диске, чтобы протестировать новое программное обеспечение. И тут началось самое интересное.

Когда на экране появился GRUB, я выбрал в меню Windows 10 и нажал Enter. На мгновение появился стартовый экран Windows, а сразу после этого появился синий экран смерти.

Вот как я установил 16 ГБ ОЗУ на материнскую плату, которая поддерживает только 8 ГБ.

Код остановки: ACPI_BIOS_ERROR. Я поискал в гугле и выяснил, что это проблема с таблицами ACPI в BIOS. Кстати, именно таблицы ACPI сообщают операционной системе, как работать с конфигурационным оборудованием. Попытка начать установку Windows 10 с флешки привела к той же ошибке. Понятно, что Foxconn правильно указала в спецификациях, что эта материнская плата поддерживает только 8 ГБ оперативной памяти. Я удалил одну плату ОЗУ на 8 ГБ, и это сразу привело к успешной загрузке. Тесты RAM также прошли отлично, и стало ясно, что мои платы памяти работают нормально.

Я пытался связаться со службой технической поддержки Foxconn для получения обновлений BIOS, но не получил ответа. Адрес электронной почты указан на сайте компании, но не работает. Возможно, Foxconn больше не занимается материнскими платами и не имеет поддержки.

Другой на моем месте, вероятно, сдастся и смирится с 8 ГБ ОЗУ или купит новый компьютер. Но я знаю, что эта материнская плата долгое время отлично работала с 16 ГБ в середине Linux. Я решил углубиться в ACPI и попробовать некоторые настройки BIOS.

Нашел в BIOS интересную опцию, позволяющую менять некоторые настройки памяти. Одним из этих параметров является активированная функция «Memory Remap Feature». В документации BIOS указано, что этот параметр позволяет скрыть память, необходимую для PCI, в области над общей физической памятью. Поиск в Интернете показал, что эта опция должна быть включена при использовании 64-битной операционной системы. Просто из-за эксперимента отключил эту опцию. Винда загрузилась сразу. Но он сказал, что он может использовать менее 4 ГБ оперативной памяти. Но это также приятно: я нашел способ войти в Windows, не открывая компьютер и не удаляя одну плату RAM.

То же самое произошло в Ubuntu. С отключенной функцией переназначения памяти система ограничила меня 4 ГБ. Решил подробнее изучить ошибку ACPI_BIOS_ERROR и причины ее возникновения. Я наткнулся на отличный документ конфигурации драйверов Microsoft, в котором объясняется, как выполнять проверку ошибок ACPI_BIOS_ERROR.

Согласно этой инструкции, вам нужно найти четыре параметра ошибки, которые когда-то появлялись на синих экранах смерти в предыдущих версиях Windows. В новой Windows 10 по умолчанию используется вся информация, но это можно изменить, внеся небольшое изменение в реестр. Вот отличный ответ от superuser.com, который показал мне, с чего начать.

После добавления новой записи в реестр я снова включил функцию переназначения памяти в BIOS и запустил Windows 10. На этот раз BSOD показал четыре дополнительных кода в верхнем левом углу экрана:

Вот как я установил 16 ГБ ОЗУ на материнскую плату, которая поддерживает только 8 ГБ.

Большой! Это именно то, что мне было нужно. Таким образом, параметр 1 равен 0x00000000000000002. В документации Microsoft указано, что если параметр 1 равен 0x00000000000000002, это означает проблему со списком ресурсов для шин PCI. Параметры 2, 3 и 4 ничего не говорят и, вероятно, являются указателями. Microsoft заявляет, что проблема в том, что область декодирования PCI перекрывается со списком областей памяти, возвращаемым интерфейсом BIOS E820.

Хорошо. Информации много, кое-где не совсем понятно, но с чего-то начнем. Я нашел данные о том, как вызов BIOS E820 предоставляет информацию об областях памяти. Затем я вернулся к Linux и использовал dmesg для просмотра всей информации о загрузке и загрузке ядра, уделяя особое внимание E820 и ACPI. Вот что я нашел:

BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] используемый BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] зарезервирован BIOS-e820: [mem 0x00000000000e0000-0x0000000000ffff008] зарезервирован 0x00000000cf780000-0x00000000cf78dfff] Данные ACPI BIOS-e820: [mem 0x00000000cf78e000-0x00000000cf7cffff] ACPI NVS BIOS-e820: [mem 0x00000000cf7d0000-0x00000000cf7dffff] зарезервировано BIOS-e82000000000-0x00000000cf7dffff] зарезервировано BIOS-e82000000000: [0x0000fex] зарезервировано BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] зарезервировано BIOS-e820: [mem 0x0000000100000000-0x000000042fffffff] можно использовать

А потом я увидел это:

acpi PNP0A08: 00: игнорирование окна моста хоста [mem 0x400000000-0xfffffffff window] (конфликтует с системной RAM [mem 0x100000000-0x42fffffff]) Мост хоста PCI к шине 0000: 00 pci_bus 0000: 00: ресурс корневой шины [io 0x0000-0x0cf7 окно ] pci_bus 0000: 00: ресурс корневой шины [io 0x0d00-0xffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0x000a0000-0x000bffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0x000d0000-0x000dffff окно] pci_bus 0000: 00 : ресурс корневой шины [mem 0xd0000000-0xdfffffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0xf0000000-0xfed8ffff окно] pci_bus 0000: 00: ресурс корневой шины [шина 00-ff]

АГА! Вы видите предупреждение о конфликте? Я бы этого не заметил, но после вставки памяти Linux начал отображать это сообщение каждый раз при запуске. Я попытался загрузить Linux с отключенной функцией переназначения памяти. В этом случае исчезла последняя область e820 — от 0x100000000 до 0x42fffffffff. Сообщение о конфликте исчезло, но появился новый аппаратный ресурс с окном памяти от 0x400000000 до 0xfffffffff.

Что мы наконец выяснили? Linux использует 16 ГБ, потому что он игнорирует конфликт и игнорирует проблемный диапазон PCI, предоставляемый ACPI, в то время как Windows с отвращением поднимает руки и запускает синий экран с надписью «У вас проблема с BIOS». Мы не можем винить Windows, потому что действительно существует совпадение и возможна путаница.

Вот уже думал сдаться. Последние 768 МБ памяти по адресам от 0x40000000000 до 0x42fffffffff отображаются в начало огромной области памяти, которую материнская плата использует для PCI. Понятно, что если материнская плата ждет там PCI, то дело может пойти очень грубо. Но это означает, что эта материнская плата поддерживает 15,25 ГБ оперативной памяти. Правильно?

Но подождите, в Linux все работает нормально, без этой дополнительной области отображения PCI. А что, если мы как-то изменим таблицы ACPI таким образом, чтобы большой диапазон для PCI начинался с 0x430000000 вместо 0x400000000, то есть сразу после окончания физической RAM. В этом случае конфликт исчезнет, ​​и большая часть блока памяти, необходимого для PCI, останется доступной.

Перчатка брошена

Я покопался в таблицах ACPI. К счастью, Linux очень упрощает дамп, и для этого есть даже специальные инструменты. А таблицы легко увидеть в sysfs:

/ sys / прошивки / acpi / таблицы

Вот они все. Я был очень рад узнать, что GRUB позволяет заменять таблицы ACPI другими версиями. Поэтому, если мы точно поймем, какая таблица используется, мы можем поместить ее измененную версию в GRUB. Теоретически таким образом Windows будет работать без проблем.

Среди различных программных инструментов я решил использовать iasl, чтобы просмотреть различные таблицы ACPI и найти значение 0x400000000 для замены. Я предположил, что используется запись с прямым порядком байтов (64-битная), поэтому я запустил binwalk, чтобы найти следующее во всех таблицах:

binwalk -R ‘x00x00x00x00x04x00x00x00’ *

Вышел матч в OEMB. Следующим после него 64-битным словом было 0x1000000000, что немного больше, чем конечный адрес в сообщении о конфликте. Чрезвычайно многообещающий. Таблица OEMB особенная, потому что согласно спецификациям ACPI это не стандартная таблица. Linux отображает сообщение о неверной контрольной сумме, но я не думаю, что это имеет значение. Думаю, вы поняли, что я сделал дальше.

Я сделал копию таблицы OEMB и заменил байт 0x00, непосредственно перед байтами 0x04, на 0x30, чтобы изменить значение на 0x430000000 (помните, что мы работаем с прямым порядком байтов). Я сохранил эту измененную копию в файле /boot/oemb.dat. Затем я использовал GRUB для замены исходной таблицы моей копией, временно вставив соответствующую команду в качестве элемента из меню «Пуск», используя следующую строку:

acpi —exclude = OEMB /boot/oemb.dat

Идея состоит в том, что эта строка указывает GRUB загрузить все таблицы ACPI, кроме таблицы OEMB, а затем загрузить файл /boot/oemb.dat, тем самым заменив старую таблицу OEMB новой.

Хорошо, я загрузил Linux и…

acpi PNP0A08: 00: игнорирование окна моста хоста [mem 0x400000000-0xfffffffff window] (конфликтует с системной RAM [mem 0x100000000-0x42fffffff])

Чертов сообщение осталось. Какого черта? Я предположил, что диапазон PCI был установлен где-то еще, но нигде не нашел конкретных адресов. Я проверил, что новая таблица OEMB успешно загружена, и продолжил исследования.

На этот раз я решил использовать iasl для декомпиляции таблицы DSDT. Опрос показал, что DSDT должен содержать метод с именем _CRS, который отвечает за создание этой таблицы.

iasl -d DSDT

В файле .dsl я нашел метод_CRS, связанный с шиной PCI, но все это было слишком сложно. Таблица DSDT содержит код, и найти требуемые значения непросто. Я интерпретировал этот код, насколько мог, и увидел, что метод the_CRS загружает информацию из другой таблицы в памяти, которая начинается с 0xCF78E064. Я снова посмотрел на загрузочный логотип Linux и обнаружил следующее:

ACPI: ранняя проверка контрольной суммы таблицы отключена ACPI: RSDP 0x00000000000F9820 000014 (v00 ACPIAM) ACPI: RSDT 0x00000000CF780000 000044 (v01 012,110 RSDT0821 20100121 MSFT 00,000,097) ACPI: FACP 0x00000000CF780200 0001280000 0x00000000CF780200 00012800000 MSPI: FACP 0x00000000CF780200 000128000 08460000 (версия) 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 002 024 (V01 012110 GMCHSCI 20100121 MSFT 00000097) ACPI: DMAR 0x00000000CF790100 000 090 (V01 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0x00000000CF7917C0 000 363 (V01 DpgPmm CpuPm 00000012 INTL 20051117 )

Вот! Загружает информацию из таблицы OEMB. Мое предположение было правильным с самого начала. Но тогда почему с заменой OEMB ничего не произошло?

Я снова посмотрел журнал загрузки ядра. Оказалось, что если вы попытаетесь изменить эти таблицы, GRUB, кто знает, зачем перемещает их (включая OEMB) в другую область памяти. Проблема в том, что адрес 0xCF78E064, где должен быть OEMB, зафиксирован в таблице DSDT. И система не видит мою новую таблицу.

Я мог легко изменить DSDT, чтобы он указывал на новую таблицу OEMB. Но это плохая идея, потому что может быть выпущена новая версия GRUB, в которой было изменено расположение таблицы OEMB.

Я остановился на другой идее. GRUB имеет встроенные команды для чтения и записи байтов, слов и двойных слов. А что произойдет, если GRUB самостоятельно изменит свою таблицу OEMB во время загрузки? В настоящее время все BIOS сжаты, и, скорее всего, эти таблицы распакованы в ОЗУ и теоретически возможно изменить их значения.

Я так и сделал. В качестве временной проверки добавьте в GRUB следующую команду:

write_byte 0xCF78E0B5 0x30

Он заменяет байт 0x00, который находится непосредственно перед байтом 0x04, значением 0x30, тем самым делая исходный 64-битный адрес 0x0000000430000000. Я не обновлял контрольную сумму, потому что Linux уже выдавал сообщения о том, что это неверно, и на этом остановился.

Я перезапустился в Linux и с тревогой проверил логи dmesg для PCI:

Мост хоста PCI к шине 0000: 00 pci_bus 0000: 00: ресурс корневой шины [io 0x0000-0x0cf7 окно] pci_bus 0000: 00: ресурс корневой шины [io 0x0d00-0xffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0x000a0000- 0x000bffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0x000d0000-0x000dffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0xd0000000-0xdfffffff окно] pci_bus 0000: 00: ресурс корневой шины [mem 0xf0000000-0xfed8ffff окно] pci_bus : 00: ресурс корневой шины [mem 0x430000000-0xfffffffff window] pci_bus 0000: 00: ресурс корневой шины [bus 00-ff]

Полный успех! Окно RAM 0x430000000-0xfffffffffff оказалось действительным, и предупреждение о конфликте исчезло. Проведя необходимые тесты и убедившись, что Linux работает безупречно, я попытался загрузить Windows, используя тот же прием.

Прекрасно работает! Теперь я могу загрузить Windows 10 с 16 ГБ ОЗУ на этой материнской плате, если я использую GRUB, в котором я помещаю команду write_byte, описанную выше. Загрузчик Windows 10 явно не работает. Понятно, что если я решу переустановить Windows, придется вынимать одну карту памяти. Но теперь все работает и меня устраивает!

Чтобы мои временные изменения оставались постоянными, я создал файл /etc/grub.d/00_patchbios со следующим содержимым:

# Этот файл исправляет BIOS на моей материнской плате Foxconn P55MX, чтобы # работать правильно, когда у меня установлено 16 ГБ ОЗУ. Это мерзкий взлом. # По сути, BIOS жестко запрограммирован в таблице OEMB ACPI #, чтобы иметь диапазон адресов PCI от 0x400000000 до 0xfffffffff, но # это перекрывается с установленной 16 ГБ ОЗУ, потому что ОЗУ # использует (среди других диапазонов) от 0x100000000 до 0x42fffffff . # Этот патч изменяет таблицу, чтобы на самом деле перечислить диапазон PCI: # от 0x430000000 до 0xfffffffff echo "write_byte 0xCF78E0B5 0x30"

Затем я сделал исполняемый файл скрипта и запустил sudo update-grub. Затем патч автоматически запускался при запуске GRUB.

Может, это не совсем безопасно. Но я вижу, что абсолютно все тесты ОЗУ проходят без проблем. Поскольку Linux отлично работает с 16 ГБ ОЗУ, эти проблемы меня не особо беспокоят. Возможно, если будет установлено несколько карт PCI / PCIe и еще что-то, могут возникнуть проблемы, но в моем случае все в порядке. Очевидно, ваша система будет другой, и этот конкретный взлом нельзя будет использовать напрямую. Но способ будет тот же.

Я думаю, что это было интересное исследование, которым стоит поделиться. Надеюсь, вы что-то поняли из этого поста. И я многому научился из всего этого, и я буду использовать полученные знания в своей работе.

Читайте так же:
Not found

Нам доверяют

Интернет магазин