А нормально что ASRock Timing Configurator показывает режим Single, а не двухканал? И напряжения VDD/VDDQ там рандомные программа показывает, перезапуск помогает, иногда по несколько раз и контроллеры тоже не всегда определяет верно.. Обратил внимание что количество перезапусков для точной информации отличается, взависимости от выставленных напряжений(возможно совпадение). AIDA64 DUAL показывает, и тесты, соответственно, подтверждают. Может в эту сторону покопать, планки переставить, например..

Добавлено спустя 4 минуты 30 секунд:

К сожалению коробочные 7200 и другие коробочные значения ХМР, судя по данной теме, никем не гарантируются.. и подбор напряжений предстоит с огромной долей вероятности, ибо ХМР режим, по ходу дела, все-таки разгон

Ну вы бы версию написали.
4.1.7 имеет баги. Да и другие версии тоже имеют баги.
Самая норма - это 4.1.4 (но она не для Z8xx чипсетов).

согласен!

Добавлено спустя 2 минуты 42 секунды:


ну так то 6400 тоже, только я его воткнул выставил хмп профиль ужал тайминги и получил плюс 10 процентов к цифрам по умолчанию, было 91-92 тысячи стало 101-102

Добавлено спустя 1 минуту 32 секунды:
а напряжения даже и не трогал, просто помучался с разгоном памяти по частоте гемор с этими напряжениями танцевать, ддр 4 проще было а тут неделями 0.01 выщемлять с которой будет стабильно

SH@RK снял несколько дампов, меняя значения rtt и group A/B ca/cs/ck odt в настройках bios. В названия дампов добавил значения rtt и group A/B ca/cs/ck odt (5 значений для rtt и 6 для group A/B ca/cs/ck), с которыми снял дампы, в том порядке как эти значения выставляются в настройках bios. Для обоих каналов выставлял одинаковые значения.
Знаниями для того, чтобы понять где в дампах конкретные значения этих настроек, не обладаю.

Вот брату на нем и собрали, но правда с гарантией за 17 в 28бит. Итого комплект вышел 17+17+15, 49к.
И для 2к просто топчик. Еще можно юыло не брать кинги 8400 тогда вообще от силы 45 вышло бы

ну каждому свое;)

Это потому, что ODT - функция самих чипов памяти. К контроллеру памяти в процессоре она, по сути, не имеет никакого отношения.
Да, код в биосе имеет возможность изменять значения этих сопротивлений - либо напрямую, используя заданные пользователем значения, либо по результатам тренировки, если таковая разрешена пользователем. В любом случае, полученные значения записываются в регистры чипов памяти (Mode Registers, MRs).
Насколько я понимаю, значения всех MRs пишутся в память "скопом", все сразу. И читаются подобным образом, все сразу. Для этого биос содержит в своей памяти массив всех этих значений. Судя по всему, Ваш mrs_data - как раз и есть такая штука. И Ваша функция get_mrs_storage() возвращает содержимое именно этого массива, а не собственно регистров памяти. Насколько эти данные реально засинхронизированы друг с другом (данные в чипах равны данным в массиве), по большому счёту непонятно, т.к. неизвестно, когда и при каком условии происходит синхронизация - запись содержимого массива в регистры чипов.

К сожалению, как именно происходит сам процесс чтения/записи этих регистров, я не знаю. Конечно, было бы полезно научиться это делать, чтобы получать действительно актуальные данные - и не только относящиеся к ODT. На самом деле, здесь первый вопрос - даже не "как", а "можно ли вообще". Можно ли уже активно работающий с памятью контроллер "попросить" прочитать регистр из чипа памяти без перерыва работы? На первый взгляд - нет.
Теоретически известно, что есть команда MRR. Параметры её тоже известны. Но это команда такого же уровня, как "боевые" ACTIVATE, READ, WRITE, PRECHARGE и подобные. Те, которые непрерывно передаются в память по CA-интерфейсу во время работы системы, десятками/сотнями миллионов штук в секунду. Как в этот поток "вставить" MRR? Понятное дело, что это должен сделать контроллер, т.к. внешнего доступа к CA-интерфейсу нет. В регистрах контроллера даже специальные тайминги для работы MRR задаются - например, tMRR, tMRRMRW, tPREMRR. Но как попросить контроллер отправить в память эту команду с нужными параметрами?

Вот, у меня откуда-то взялся такой микроновский документ - DDR5 SDRAM Product Core Data Sheet. В нём подробно описаны команды чипов DDR5, MRs и прочие подобные вещи. Есть там и отдельный раздел, посвящённый организации ODT (см. On-Die Termination на стр. 303). Возможно, Вы найдёте там что-нибудь полезное.

Спасибо за такой подгон!


Да. Так и есть. В сорцах ICE_TEA_BIOS можно посмотреть весь список MRs, с которыми работает BIOS. И видимо только MRs из этого списка будут переданы чипам (такой код я там не нашёл).
Если лень смотреть эти сорцы, то я для питона эту структуру сдампил: https://github.com/remittor/pyhwinfo/bl ... #L290-L358
Но эта версия структуры MRS уже утарела даже для биоса 2023 года для Asus Z690 MAXIMUS.

Поэтому нужно для конкретного биоса искать месторасположение каждого MRx. И нужно будет как то определять какой шаблон использовать в каждом случае.


А это мне пока не интересно.
Просто мой BIOS вообще не отображает значения ODT, если выставить Auto.
А ведь интересно же посмотреть, что именно BIOS туда записывает при Auto. Вот для этого и изучаю данную проблемму.


Спасибо за тесты.
У вас прям таки странный mrs_data - уж очень короткий. Есть вероятность что ручки MSI туда залезли (но это не точно).

Здесь важна последовательность расположения значений регистров в массиве. Если, например, MR0-MR69 всегда записывались бы в 70 последовательных байтов массива, то никаких проблем с идентификацией нужных значений не было бы. Но, насколько я понимаю, это совсем не так - всё зависит от фантазии разработчика вендорского кода из команды производителя материнской платы.

На многих платах не отображает. Но разве нельзя вручную последовательно задать, например, три значения какого-нибудь сопротивления и посмотреть, в каком байте того mrs_data "проявятся" изменения после перезагрузки?

Именно этим я вчера вечером и занимался.
Сегодня продолжу после написания заявления в суд (этого только не хватало на голову).
Выяснить то расположение не большая проблема. А вот выяснить какой шаблон применять и годность самого шаблона для конкретного BIOS - задачка намного сложнее.


Именно так. Под саму область MRS Intel зарезервировала 240 байт, но список MrcModeRegisterIndex состоит всего из 67 байтов максимум (для Tiger Like там вообще меньше 25 было).
Поэтому странное решение они выбрали. Зачем эти байтики экономить, коли их аж 240....

Добавлено спустя 8 минут 50 секунд:

Я вас понял )))
Вы говорите о том, что бы пользователь через GUI сам мог указать положение нужного MR.
Идея здравая, учитывая сколько разных вариаций биосов.

Китайская поделка: https://ruexe.blogspot.com/

Все китайцы очень жопят сорцы выкладывать. Ну прям очень жопят.

Я всё же сумел найти способ, при котором все значения ищутся динамически.
Это стало возможно, т.к. Intel для MpcMRX значений проставляет у байтиков префиксы специфичные.

Скачивайте pyhwinfo и смотрите какие у вас ODT значения.

------------------------------------
В стоке mrs_data между значениями RttCK_A...RttCA_B и RttParkDqs есть ещё 2 неизвестных параметра. Даже в сорцах ICE_TEA_BIOS под эти 2 параметра ничего не подходит.
Т.е. это какие-то 2 именно новых параметра (относительно времени релиза Alder Lake конечно).
И в CMOS BIOS под них ничего пока не нашёл....

Похоже, что сама идея о том, что mrs_data содержит значения, записываемые в регистры чипов - не совсем верная. Как минимум, не для всех значений.
Например, для NOM-сопротивлений там, скорее всего, хранится не реальный код значения сопротивления, а копия биосовской переменной NVRAM со значением установки.
То есть, если задано "Auto", то в соответствующем битовом поле получается 0. Что при этом записано в MR памяти, мы не знаем.
Возможно, конечно, что биос на моей плате всегда (в режиме Auto) устанавливает все RttNOM в состояние "отключено" (значение 0), но выглядит это явно подозрительно. Или так оно и должно быть по умолчанию?
Думаю, что для прояснения ситуации нужно посмотреть результат на платах, которые показывают в интерфейсе биоса автоматически установленные значения RttNOM. У меня сейчас таких плат под рукой нет.

Как бы то ни было, значение 0 в битовых полях, содержащих код Rtt, соответствует совсем отключенному терминированию. То есть, в поле GUI, отображающем значение сопротивления, в этом случае должно быть написано не "0", а "∞" (или "off").
Нулевым это сопротивление не может быть физически, т.к. это обозначало бы короткое замыкание терминируемой линии на шину источника питания.

Кстати, в исходниках того самого ICE_TEA_BIOS несложно найти методику непосредственного чтения и записи регистров памяти. Возможно, с ними всё-таки можно работать даже в среде загруженной ОС. Посмотрите, например, функцию MrcIssueMrr() из Intel/AlderLake/ClientOneSiliconPkg/IpBlock/MemoryInit/Adl/LibraryPrivate/PeiMemoryInitLib/Source/McConfiguration/MrcMaintenance.c и вызываемую из неё MrcRunMrh() из Intel/AlderLake/ClientOneSiliconPkg/IpBlock/MemoryInit/Adl/LibraryPrivate/PeiMemoryInitLib/Source/MemoryTypes/MrcDdrCommon.c . А главное, что там, в Intel/AlderLake/ClientOneSiliconPkg/IpBlock/MemoryInit/Adl/LibraryPrivate/PeiMemoryInitLib/Source/Include/MrcRegisters/Alderlake/MrcMcRegisterAdlExxx.h, есть адрес используемого для работы с MRs регистра контроллера MC0_CH0_CR_DDR_MR_COMMAND_REG, описать который в интеловской публичной документации "забыли".
Насколько я понимаю "на глаз", работать со всей этой конструкцией несложно. Сначала дождаться готовности контроллера принять команду, читая в цикле значение из этого регистра и анализируя значение бита занятости. Потом сформировать 32-битовую команду, содержащую определённую комбинацию битов адреса и данных чипа памяти, формирующих, в том числе, код команды, номер читаемого регистра, и записать всё это дело в тот же регистр. Потом дождаться готовности ответа аналогичным ожиданию готовности к приёму команды способом и прочитать ответ - всё из того же регистра.

У Вас в pyhwinfo уже есть вся необходимая "инфраструктура" для быстрой реализации этой схемы, хотя бы в качестве эксперимента. Как Вы понимаете, получение информации непосредственно из регистров памяти вместо непонятных структур данных биоса - это совсем другой уровень детализации и, главное, достоверности.

Идея здравая. Поглядел сорцы более пристально.
Наверное стоит попробовать это реализовать.


Да многих функции для работы через mmio ещё нету в коде.
Вот сейчас гляжу внутренности MmioRead32 и других.

Насколько я понимаю, биос на этих платформах всегда программирует адрес MCHBAR равным 0x00000000fedc0000.
Соответственно, тот MC0_CH0_CR_DDR_MR_COMMAND_REG будет доступен по адресу 0x00000000fedce414.

Наверно так tREFI9=(tREFI+1)/1024?

В сорцах ICE_TEA_BIOS другая формула:

tREFIx9 = (tRefi * 89) / (1024 * 10)

Так там tRefi используется какое-то другое, а не то, что мы выставляем в биосе.

Ну это вам так кажется.
Я перепроверил. Этот именно то значение, которое задаёт пользователь.
Да и если глянуть AsusMemTweakIt или pyhwinfo, то можно сразу понять, что используется формула: tREFIx9 = (tRefi * 89) / (1024 * 10)