По пробую, отпишусь. что лучше пошло

Да. ODT, Vref, RTT, tRTP, tWR и т.п. считываются из MRS.


Это не предположение. По коду могу судить, что это так и есть.

Но через предложенный вами механизм MMIO не получилось непосредственно обращаться к IMC, т.к. почти весь MCHBAR защищён от записи. Intel оставила в MCHBAR только пару регистров для PCODE BIOS MAILBOX. Только туда удаётся записайть байтики.

в упор не вижу 11↓, до кучи поставил в биосе WR=80 в проге стало 48(вместо 40 при 60=авто в биосе)
а чего у тебя tWRPRE ≠ tWRPDEN ? может потому tWR=48 отображает вместо моих tWR=49 ... неее, поставил tWRPRE/tWRPDEN=88/89 и все равно tWR=49 в pihwinfo

аналогично RTP 14

Решение не нашёл? Я ещё не за компом, но за информацией слежу

Я понял.
Только что исправил очень существенный баг в коде, который мне через PR прислали.
Спасибо.
Можете проверить новую версию. Там всё ок.

И обратите внимание на значение tWR/WriteRecoveryTime в JSON файле (я в GUI вывожу расчётный tWR, а не WriteRecoveryTime)

Значение WriteRecoveryTime непосредственно используется IMC. Но я его не рискнул в GUI вывести...


Про значения ODT ещё раз повторю: тут верьте pyhwinfo, а не тому что в BIOS. Считываю ODT данные практически "из под рук" IMC.

Странный лаг монитора #18019095 как вариант те
всё может быть, но у меня(на ГИГЕ) так:
ODT WR=20 в биосе = 0 в проге
ODT WR=40 в биосе = 34(RZQ/7) в проге
ODT WR=60 в биосе = 40(RZQ/6) в проге
ODT WR=80 в биосе = 48(RZQ/5) в проге
ODT WR=100 в биосе =60(RZQ/4) в проге
ODT WR=120 в биосе =80(RZQ/3) в проге
ODT WR=140 в биосе =120(RZQ/2) в проге
ODT WR=160 в биосе = ?240(RZQ/1)? =незагрузка системы(экспериментил на 7600 частоте по памяти) но в итоге то, получается, что ваша прога действит(в отличии от биоса) отображает ODTреальность
качай последнюю версию и будет норм с tRTP

Shark
А почему не вывести WriteRecoveryTime?

Откуда у вас 100?
Согласно jedec допустимы только такие значения:


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

Дублировать не хочется.
А по хорошему нужно собрать статистику из данных json и решить что лучше показывать: расчетное значение или значение из MRS области.

пока не занимался. Чет кажется, что есть связь с rdpden и CR. Но это только кажется, скорее всего

Очень похоже, что GIGABYTE в этом вопросе не соблюдает JEDEC, т.к. выкатил свой набор сопротивлений для ODT переменных.

Надо показывать и расчетное значение , и MRS, так будет верно.

Я, по-моему, уже замечал ранее, что значения RTT Nom не сильно похожи на реальные.
Я и сам смотрел значения этих величин, отображаемые pyhwinfo на нескольких разных материнских платах, с разными процессорами, и на скриншотах других исследователей обращал внимание на эти числа. Во всех случаях получается, что они просто однозначно отражают установки, заданные в биосе. Но в биосе значение 0 соответствует автоматическому выбору/тренировке, тогда как в соответствующих полях MR35 0 означает полное отсутствие терминирования, бесконечное сопротивление.
Нет, потенциально может быть так, что в процессе тренировки выбираются именно такой вариант, с отключенным терминированием в этом режиме. Но может ли быть такое во всех наблюдаемых многочисленных случаях? На мой взгляд, не может. Тем более, что если вручную задать для этих RTT Nom максимально возможные значения, т.е. RZQ/1, то память не работает, платформа не запускается.

Меня интересует что pyhwinfo пишет при наведении курсора на VDDQ_TX ? Какое там второе значение для VDDQ_TX ?
И что для VDDQ_TX показывает датчик Nuvoton в HWINFO64 ?

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


Ну это если читать документацию.
А по факту человек чуть выше написал, что у gigabyte своё видение стандартов и он по своему трактует доки.
Вот у гигабайта 0 соответствует 20 Омам

эти значения одинаковые при переключении MC# CH# в pyhwinfo?

да(если поставил на оба канала) или нет↓(если токо на один)

Запрошенное 1.39, реально используемое 1.152
Нувотон не видит Тх, только в разделе процессорного мониторинга, но там тупо считывание установки в биос. Реального мониторинга, конечно, там нет

Вот это фигово. На моём Asrock так же. Не могу проверить, т.к. нувотон не обучили.


Зато на ASUS Z690 HERO оба значения одинаковые. И датчик "ASUS EC" там показывает такое же значение.

Поэтому к Asrock у меня есть вопросики....


на ASUS'ах датчик "ASUS EC" обучили снимать показания с VDDQ_TX



На этом скрине можно наблюдать аж 4 двуранга!
И только в этом случае в MSR все ODT-параметры содержат по 4 значения!
Я конечно не буду в GUI такое рисовать. И двух прямоугольников хватит.
А такой случай (с 4-мя двурангами) очень редкий. На этот случай можно и внутрь JSON глянуть.