cmp50hx-unlock

Руководство по разблокировке CMP 50HX / CMP 90HX 610.43.03

Инструкция для 20 ГБ · English 20 GB guide

Этот репозиторий собирает и устанавливает патченные открытые модули ядра NVIDIA 610.43.03 для CMP 50HX (TU102) и CMP 90HX (GA102). Патчи для 50HX разработаны и доказаны здесь; путь для 90HX — это перенос линии rejoin16 из репозитория jdowning100/cmpunlocker (GPL-2.0), построенный поверх бандла pearlfortune/cmpunlocker v0.1.28 90hx-stockflow.

Установка в одну команду

Скачайте последний релиз со страницы GitHub Releases — по одному файлу на ОС, одна команда для разблокировки:

ОС Скачать Установка (одна команда)
Linux cmp50hx-unlock-linux.run chmod +x cmp50hx-unlock-linux.run && sudo ./cmp50hx-unlock-linux.run
Windows cmp50hx-unlock-windows.zip распаковать, правый клик на 50HXInstaller.exe → Запуск от имени администратора → Установить

Оба архива содержат одинаковую UEFI-разблокировку вычислений (доказано на железе: FP32 31.7× и DP4A 28.4× относительно залоченного стокового драйвера — см. A/B-матрицу) и разблокировку PCIe Gen2. Патчи ядра не нужны. В Windows установщик также выставляет EnableGpuFirmware=1, чтобы состояние EFI дожило до драйвера ОС. На Linux .run автоматически собирает и устанавливает патченный модуль ядра; это эквивалентный путь, но нужен только если вы хотите и патченный модуль (сама UEFI-разблокировка работает и со стоковым модулем).

Собрать оба архива локально: make release (нужны toolchain’ы Linux и Windows — см. Makefile).

UEFI-разблокировка вычислений (работает, патчи ядра не нужны)

efi-unlock/ — перенос UEFI-приложения CMP40HX-Unlock v3.0.0 (MIT) на 50HX. Приложение открывает SS0/SS1 до загрузки ОС тем же эксплойтом V67 canary/Booter, что и stockflow, а затем передаёт управление загрузчику Linux без единого POST — поэтому для разблокировки вычислений не нужен патченный модуль ядра вообще.

Доказано на живом железе 2026-09-10 (хост .224): эксплойт срабатывает (*** UNLOCKED (SS0=0x88888888 SS1=0x8) ***), состояние доживает до Linux без единого Xid, а A/B-тест на стоковом, непатченном драйвере 610.43.03 дал FP32 0.427 → 13.512 TFLOP/s (31.7x) и DP4A 1.689 → 47.984 TIOP/s (28.4x) против залоченного базлайна — GSP-загрузка стокового драйвера принимает pre-OS-состояние без ошибок. Полная матрица: efi-unlock/runs/20260910-ab-stock-vs-efi.md.

ReBAR, Gen2 и отчёт 56 RT-ядер остаются за патчами ядра (таблица возможностей — в README каталога). Инструкция по установке, требования к прошивке, проверка и откат: efi-unlock/README.md (англ.).

Далее — рабочая запись о пяти патчах CMP50HX в каталоге patches/cmp50hx/. В ней описаны цепочка выполнения, причина каждого изменения, подтверждающие проверки и границы доказательств. Серия предназначена для официального исходного кода открытого модуля NVIDIA 610.43.03 и проверенной PCI-идентичности CMP50HX:

Field Packed RM value Linux PCI value
device 0x1E0910DE vendor 10de, device 1e09
NVIDIA board 0x155410DE 10de:1554
MSI board 0x371F1462 1462:371f

Упакованные значения используются кодом RM/GSP. Модуль Linux использует разделённые поля vendor, device и subsystem. При создании нового патча эти две формы нельзя смешивать.

Поддержка CMP 50HX 20 ГБ

Патч 01-cmp50-stockflow.patch поддерживает исходную схему 10 ГБ и схему 20 ГБ. Старый вариант использовал фиксированные адреса WPR2 для 10 ГБ и мог завершаться ошибкой NVIDIA Booter 0x8d на карте 20 ГБ. Обновлённый патч читает диапазон WPR2 после штатного FWSEC отдельно для каждого GPU, принимает только известный размер 0xe00 и сохраняет low/high в состоянии каждого BDF для последующих проверок загрузки.

Путь 20 ГБ проверен на четырёх картах 10de:1e09 / 10de:1554, каждая с 20480 MiB, на NVIDIA Open 610.43.03. Порядок установки, проверки и ограничения хоста описаны в инструкции для 20 ГБ.

Карты CMP 50HX на 10 ГБ и 20 ГБ можно устанавливать в одной системе. Состояние WPR2 привязано к адресу bus/device каждой PCI-карты, поэтому диапазон памяти одной карты не используется для другой. Такая смешанная конфигурация заложена в дизайн; после первой холодной загрузки проверьте каждую карту.

Разделение является механическим, а не новым путём выполнения: патч 01 — это 5 файлов и 24 фрагмента, патч 02 — 1 файл и 1 фрагмент, патч 03 — 1 файл и 4 фрагмента, патч 04 — 1 файл и 3 фрагмента. Старый монолитный патч и эта упорядоченная серия изменяют одни и те же восемь исходных файлов.

Патч 05 (05-cmp50-auto-pstate.patch) намеренно не собирается. Холодный A/B-тест 2026-08-26 доказал, что он не включает native-переключение простой/нагрузка: карта закрепляется в P8 645/405 даже при 100% нагрузке (примерно в 22 раза меньше пропускной способности памяти, в 2,9 раза меньше производительности), и он ломает idle governor — освобождение P16 больше не возвращает полные частоты. Файл оставлен на диске только для исследований. Native автоматический выбор P-State исследован до конца и недостижим со стороны хоста: включение закрыто барьером готовности внутри подписанного GSP-RM, поэтому решением по энергопотреблению в простое является необязательный idle governor ниже.

Быстрая установка (Ubuntu/Debian)

На чистой системе Ubuntu или Debian с установленной CMP 50HX (10de:1e09):

curl -fsSL https://xrip.github.io/cmp50hx-unlock/install.sh | sudo bash

Установщик добавляет инструменты сборки, устанавливает пользовательскую часть NVIDIA 610.43.03 из официального пакета .run, собирает патченные модули для текущего ядра, устанавливает их с резервной копией, блокирует nouveau, пересобирает и проверяет initramfs и запускает depmod. Он не перезагружает систему и не выгружает загруженный драйвер. В конце он выполняет проверку карты в работающей системе, если это возможно.

Когда установщик выводит PASS_CMP_INITRAMFS, перезагрузите систему, чтобы патчированный модуль загрузился при старте:

sudo reboot

Откат: sudo /opt/cmp50hx-unlock/install-initramfs.sh --rollback восстанавливает предыдущий initramfs; резервные копии модулей находятся в /opt/cmp50hx-unlock/backups/.

На CMP 90HX (10de:220d) карта указывается явно (установщик также определяет её автоматически, если это единственная карта CMP):

curl -fsSL https://xrip.github.io/cmp50hx-unlock/install.sh | sudo bash -s -- --card cmp90hx

Сборка для 90HX дополнительно скачивает закреплённый бандл pearlfortune v0.1.28 90hx-stockflow (с проверкой SHA-256) и устанавливает загрузочный сервис cmp90hx-gen2. После перезагрузки дождитесь завершения сервиса (см. ниже), затем проверьте:

sudo /opt/cmp50hx-unlock/cmp90hx/verify.sh    # PASS_CMP90HX_ALL_LIVE

Примечания:

Необязательный userspace-патч pipeline bind

Каталог userspace-patch/ создаёт отдельную копию libnvidia-eglcore.so NVIDIA 610.43.03 и убирает проверенную задержку Vulkan pipeline bind на CMP50HX. Инструмент ищет ровно два совпадения байтового шаблона, не изменяет /usr/lib и содержит launcher для native ELF, который использует --library-path системного загрузчика без LD_LIBRARY_PATH. Решение основано на исследовании Cyridd/cmpunlocker и не заменяет патчи модуля ядра. RT-core и общий unlock шейдеров этим не доказаны.

Потребление в простое: необязательный регулятор

В простое карта потребляет 62–64 Вт и никогда сама не понижает запрос P-state: даже явная блокировка диапазона min,max приводится к максимуму. Приватный NVAPI-контроль P-state может принудительно перевести карту в P8, примерно на 1,8 Вт.

idle-governor/ автоматически подаёт этот запрос: переводит карту в P8 в простое и возвращает P16 при появлении нагрузки:

  Простой Под нагрузкой
без регулятора 62–64 Вт полные частоты
с регулятором 1,8 Вт (P8) полные частоты, восстановление за один опрос

Примерно −61 Вт на каждую простаивающую карту. Компонент необязательный, не связан с разблокировкой и хранит только состояние времени выполнения (остановка снимает все ограничения). Включить при установке через --idle-governor или позже:

sudo systemctl enable --now cmp-idle-governor

Компромисс: задача, начавшаяся при зажатой частоте, работает на низкой частоте до одного интервала опроса (по умолчанию 5 с, настраивается). Подробности, замеры и настройка: idle-governor/README.md.

Тюнинг: необязательные профили

tuning/ добавляет cmp-tune — утилиту с профилями для лимита мощности, VF-оффсетов ядра и памяти и диапазона фиксированной частоты ядра. Работает напрямую с NVML (через ctypes, без сборки), потому что nvidia-smi не умеет выставлять VF-оффсеты.

cmp-tune list                    # профили
cmp-tune status                  # текущее состояние + диапазоны вашей карты
cmp-tune show efficient          # без применения
sudo cmp-tune apply efficient
sudo cmp-tune reset

Профили лежат в /etc/cmp-tune.conf, все ключи необязательны:

[efficient]
power_w = 170
core_offset = 225
mem_offset = 1000
clock_max = 2100

Главное:

Настройки живут только до перезагрузки — так задумано.

Поддержка CMP 90HX

Путь для 90HX архитектурно отличается от 50HX и является переносом линии rejoin16 из репозитория jdowning100/cmpunlocker (GPL-2.0), где она была проверена на холодной загрузке 2026-08-16 (полный цикл из 35 перезагрузок модуля, 5 GT/s, полная скорость вычислений). Этим репозиторием путь ещё не перепроверен на железе 90HX.

Что открывается на CMP 90HX (10de:220d):

Возможность Механизм
Полная скорость SM (~26x FP32) патчи stockflow 0014+0015 из закреплённого бандла pearlfortune
PCIe Gen2 x4 (5.0 GT/s) rejoin16: открытие PLM + конфигурация скорости в ядре + retrain моста
Полный gfx-бин скорости (19x fill rate) GFX_SPEED_SELECT 0x823830 = 0x4 после открытия его PLM (0x823b04)

JTAG (Host2Jtag) на GA102 не решён (адреса PJTAG PLM от GA100 не подходят, а расположение блока PJTAG на GA102 публично не задокументировано); слово «jtag» в имени патча относится к таблице открытия PLM, а не к рабочему пути JTAG.

Замеры на карте исходного проекта (10de:220d, подсистема 10de:1555): FP32 0.72 → 18.78 TFLOP/s, TF32 41.13, FP16→FP32 80.47 TFLOP/s; обмен по PCIe 1.0 → 1.7 ГБ/с на Gen2 x4.

Структура и порядок работы:

Входные данные сборки закреплены и проверяются по SHA-256 скриптом build.sh --card cmp90hx: архив NVIDIA-kernel-module-source-610.43.03.tar.xz и бандл pearlfortune cmpunlocker-v0.1.28-linux-x64-90hx-stockflow.tar.gz.

Ограничения и предостережения:

Новые результаты производительности

Path Result
RM issue-rate and core-count gate PASS_CMP50HX_ISSUE_RATE_AND_COUNTS
DP4A 2782.422981 G thread-instructions/s
DP2A pair 4435.776603 G thread-instructions/s
FFMA 2584.518335 G thread-instructions/s
FMUL + FADD 4404.996610 G thread-instructions/s
FP16 Tensor WMMA 106.819293 TFLOPS, correct
OpenCL FP64 0.419 TFLOPS
OpenCL FP32 13.501 TFLOPS
OpenCL FP16 26.872 TFLOPS
OpenCL INT64 3.479 TIOPS
OpenCL INT32 13.055 TIOPS
OpenCL INT16 11.398 TIOPS
OpenCL INT8 48.272 TIOPS
OpenCL coalesced read/write 504.98 / 474.54 GB/s
OpenCL misaligned read/write 419.44 / 124.30 GB/s
OpenCL PCIe send/receive 1.70 / 1.70 GB/s
OpenCL PCIe bidirectional 1.69 GB/s
Pinned CUDA PCIe H2D/D2H 1.701960 / 1.708828 GB/s, correct

Правила доказательств

В руководстве используются следующие обозначения:

База IDA находится в файле gsp_tu10x_610.43.03.elf.i64, SHA-256 бинарного файла: c10c2866e360154e822087957bc4269168e44f8d45922110e67fd751355806f9. Это прошивка GSP, а не хост-драйвер Linux. Поэтому она может подтвердить штатную поверхность управления прошивки, но не может подтвердить изменение C в kernel-open/nvidia/*.c. Отладчик не использовался. Работа в IDA выполнялась с использованием xrefs, значений операндов, ограниченной дизассемблизации и декомпиляции; имена и комментарии являются заметками, а не первичным доказательством.

A: серия была проверена через dry-run и применена к чистому официальному архиву с SHA-256 9df87d753cd9c05aa0eedc462af9b35debb549a657136e863282f94c96ee2640. Сборщик повторяет проверку хеша исходников и применяет четыре файла в порядке, показанном в build.sh.

1. 01-cmp50-stockflow.patch

Назначение

Это патч прошивки/RM. Он сохраняет штатный поток NVIDIA Booter и GSP-RM, но добавляет ограниченную транзакцию только для CMP50 вокруг подписанного образа Booter. Полезный результат — обычное состояние полной issue-rate SM. Это не разблокировка RT-фьюза и не самостоятельная перенастройка хостового PCIe.

Файлы и роли

File Role
generated/g_kernel_gsp_nvoc.h Stores a private copy of the stock signature and its size.
kernel/gpu/gsp/kernel_gsp.c CMP50 gate, signature allocation/replacement, stock-signature restore, and boot-state logs.
arch/turing/kernel_gsp_booter_tu102.c Falcon/SEC2 checks, native Booter launch, WPR/FECS readback, and cleanup.
arch/turing/kernel_gsp_falcon_tu102.c Per-BDF exploit-mode state and a Booter-only bounded halt wait.
arch/turing/kernel_gsp_tu102.c Retry state, fresh WPR metadata, GSP-ready checks, and the TU102 PCIe policy gate.

Пошаговое поведение

  1. Проверка карты. Каждый специальный путь проверяет упакованный device и один из двух приведённых выше упакованных subsystem ID. Остальные GPU идут по штатному пути.

  2. Сохранение копии для восстановления. При создании signature-memdesc патч сохраняет исходную подпись прошивки в KernelGsp::pStockSignatureData и записывает stockSignatureSize. Обычный размер выделения изменяется на фиксированный размер 0xFA00 только для цели CMP50.

  3. Подготовка синтетической подписи. Новый буфер сначала заполняется значением 0x00000CBD. Затем выбранные dword формируют ограниченную транзакцию Booter. Важные значения:

    Signature offset/value Meaning used by the patch
    0x0000 = 0x00020001, 0x0880 = 0x344, 0x0884 = 1 stock-looking header and LS metadata
    0xF974 = 0x00409650 FECS feature-override protection register
    0xF988 = 0x88888888, 0xBB20 = 8 full-speed SM selector values
    0xF9A4 = 0x00409664, 0xBB38 = 0x0040966C FECS SM selector addresses
    0xBB4C = 0xFFFFFF8F final FECS protection mask
    0xBB98 = 0x8E1B0, 0xBBC8 = 0x8E110, 0xBBF8 = 0x8E12C, 0xBC28 = 0x8E11C TU102 XP3G policy writes
    0xBC58/0xBCB8 = 0x1FA828/0x1FA824 WPR2 high/low state
    0xBC88/0xBCE8 = 0x8403C4 SEC2 reset-protection register

    Патч называет эти значения guard, pivot, writer, PLM, WPR2 или хвостами очистки. Эти имена объясняют назначение, но сами по себе не доказывают безопасность произвольной полезной нагрузки прошивки.

  4. Использование свежих метаданных WPR. _kgspCmp50ExecuteBooterFreshMeta выделяет новую страницу метаданных размером 4 КиБ, копирует в неё канонические метаданные WPR, запускает штатный kgspExecuteBooterLoad_HAL, копирует изменения Booter обратно и освобождает временную страницу. Это не позволяет SEC2 повторно использовать устаревшую DMA-страницу метаданных при втором запуске.

  5. Запуск Booter только в exploit-режиме. kernel_gsp_falcon_tu102.c хранит режим по стабильному индексу шины/устройства. kgspExecuteHsFalcon_TU102 использует более длительное ожидание остановки в 250000 единиц только тогда, когда точная плата CMP50 находится в exploit-режиме, а ucode является образом загрузки Booter. Все остальные запуски Falcon сохраняют тайм-аут по умолчанию.

  6. Проверка передачи управления и очистка SEC2. Путь Booter требует точного состояния перед возвратом успеха: FECS PLM 0xFFFFFF8F, селекторы FECS 0x88888888 и 0x00000008, WPR2 опущен (HI=0, LO=0x1FFFFE00), PLM сброса SEC2 0xFF и очищенный mailbox. Значения mailbox1 0, 1 или 4 допускаются только после успешного прохождения всех остальных проверок. Путь очистки SEC2 ждёт остановки, проверяет PLM сброса, один раз сбрасывает SEC2, проверяет оба mailbox и обнуляет DMEM SEC2 в диапазоне [0, 0x10000).

  7. Восстановление штатной подписи после завершения транзакции. kgspCmp50RebuildStockSignature отображает исходный signature memdesc, очищает его, копирует обратно сохранённые штатные байты, обновляет метаданные WPR, сбрасывает кэши CPU и записывает физический адрес и заявленный размер. Сохранённый буфер освобождается в обычном пути очистки.

  8. Применение политики Gen2 на стороне GSP в двух точках. s_cmp50ApplyGen2Policy запускается после транзакции Booter и ещё раз в состоянии gsp-ready. Сначала требуется, чтобы чтение XP3G PLM вернуло 0xFFFFFFFF, затем сохраняются старые значения, записывается политика TU102, каждое значение читается обратно, а при несовпадении выполняется откат. Проверенная политика включает:

    • приватные биты включения/значения Gen2 в 0x8841C;
    • иерархию VSEC в 0x88610;
    • очистку бита 2 CYA в 0x8C2C0;
    • поле политики соединения 2 в 0x8C040;
    • поле скорости соединения 0x40000 в 0x8C1C0;
    • значение LTSSM 6 в 0x8872C.

    Это только половина политики GSP. Запись конфигурации PCI endpoint/bridge и retrain находятся в патче 04.

Доказательство в IDA для штатных поверхностей управления

IDB прошивки даёт сильные свидетельства для двух штатных поверхностей, которые повторно использует этот патч:

IDA подтверждает штатную политику и соединение callback. Она не доказывает, что жёстко заданная синтетическая подпись безопасна или что хостовая сборка её примет. Для этих утверждений нужны проверки исходников, точное чтение значения во время работы и тест отказа/отката.

Результат на карте и ограничения

L: установленный пакет сообщает полные поля issue-rate и переживает холодную загрузку. Матрица производительности содержит PASS_CMP50HX_ISSUE_RATE_AND_COUNTS, P0 на частоте 1905 МГц, отсутствие новых ошибок NVRM/Xid/AER/PCIe и полезную производительность CUDA/Tensor. См. artifacts/cmp50-performance-matrix-20260817/VERIFY.md.

Результат доказывает, что проверенная карта достигла нужного вычислительного состояния. Он не доказывает, что каждое слово синтетической подписи нужно на каждой плате TU102. Поэтому проверка BDF, точные чтения значений, восстановление штатной подписи и ветви с безопасным отказом являются частью патча, а не необязательной очисткой.

2. 02-cmp50-rt-core-count.patch

Назначение и путь кода

Это небольшой патч отчётности хоста/RM. В kgraphicsLoadStaticInfo_KERNEL, после обычного копирования статической информации графики, он проверяет точные упакованные ID устройства и подсистемы CMP50 и устанавливает NV2080_CTRL_GR_INFO_INDEX_RT_CORE_COUNT в 56.

Изменение влияет на значение, возвращаемое RM, и на проверку хостового API. Оно не меняет декодирование SM, RT-фьюз, dispatch, частоты, питание или путь инициализации GR прошивки. В частности, «RM сообщает 56» нельзя записывать как «56 физических RT-ядер исполняемы».

Доказательства

3. 03-cmp50-rebar.patch

Назначение

Этот патч изменяет конфигурацию TU102 XVE ReBAR достаточно рано в ходе проверки PCI Linux, чтобы Linux мог создать большое ресурсное окно BAR1. Он не изменяет образ GSP и не позволяет плате с недостаточно большим хостовым мостом использовать большую область адресов.

Пошаговое поведение

  1. Параметр модуля только для чтения выбирает размер: 0 отключает путь, а 1..8 выбирают 128 MiB..16 GiB; значение по умолчанию — 8.
  2. Проверяется точный BDF CMP50. BAR0 должен быть отображён в память и иметь длину не менее 0x89000 байт.

  3. Функция отображает страницу XVE размером 4 КиБ по смещению BAR0 0x88000 и читает:

    XVE offset Role
    0x724 CYA unlock register; write 0x30
    0xBBC ReBAR capability readback
    0xDCC ReBAR configuration; bit 31 enables, low nibble is the selector
  4. Все остальные биты конфигурации сохраняются, старый размер в младшей тетраде очищается, устанавливаются включение и выбранный размер, затем записываются CYA и CFG, после чего оба значения читаются обратно.
  5. Выполняется проверка pci_rebar_get_possible_sizes() с использованием BIT(selector + 6). Если чтение XVE или маска возможностей PCI не поддерживает выбор, старые значения CFG и CYA восстанавливаются, а probe завершается ошибкой.
  6. При успехе включается существующий путь изменения размера ReBAR NVIDIA, а в журнал записываются селектор, маска возможностей, старые/новые значения и итоговый размер BAR1.

Код сравнивает при чтении CFG обратно только биты включения и размера. Чтение CYA сохраняется и записывается в журнал, но отдельно не проверяется; это реальная точка для проверки в будущем патче усиления защиты.

Доказательства и ограничения

4. 04-cmp50-pcie-gen2.patch

Назначение

Патч 01 подготавливает и проверяет политику TU102 на стороне GSP. Этот патч завершает работу на стороне хоста: он настраивает PCIe endpoint и его вышестоящий мост, просит мост выполнить retrain и ждёт активного соединения на 5.0 GT/s.

Пошаговое поведение

  1. nv_cmp50hx_is_supported() применяет точную проверку разделённых Linux BDF.
  2. nv_cmp50hx_retrain_gen2() находит вышестоящий мост и отображает первые 0x90000 байт BAR0 GPU.

  3. Перед изменением пространства конфигурации PCI требуется, чтобы зеркало политики GSP показывало:

    • CYA 0x8C2C0, бит 2 очищен;
    • конфигурацию соединения 0x8C040, биты [19:18] == 2;
    • скорость PL-соединения 0x8C1C0, поле скорости 0x00040000.

    Если сторона GSP не прошла проверку, хостовая сторона пропускает retrain.

  4. После запуска GSP/RM состояние зеркал BAR0/XVE и PCIe endpoint/upstream до и после каждого важного этапа записывается с префиксом CMP50_PCIE_DIAG_V1.
  5. В BAR0 0x8872C записывается LTSSM 6, значение читается обратно, затем выполняется ожидание 50 мс.
  6. На GPU и мосте устанавливается PCI_EXP_LNKCTL2_TLS_5_0GT, на мосте устанавливается PCI_EXP_LNKCTL_RL, после чего состояние соединения GPU опрашивается до 20 раз с интервалом 100 мс.
  7. Для успеха активный класс состояния соединения должен быть не ниже PCI_EXP_LNKSTA_CLS_5_0GB; драйвер записывает RETRAIN_PASS mode=normal.

Проверенный путь CMP50HX не использует цикл Link Disable. Живой отрицательный результат описан в docs/CMP50HX-PCIE-LINK-DISABLE-AUDIT.md.

Доказательство IDA и результат на карте

I: pcie_apply_link_speed_policy по адресу 0x4CB25B8 — штатная причина, по которой эти зеркала выглядят правдоподобно. Дизассемблирование напрямую записывает 0x880A8, 0x8841C, 0x8C040, 0x8C1C0 и 0x8C2C0, а его xrefs RMPcieLinkSpeed ведут к тем же ветвям политики, которые перечислены в патче. IDB показывает штатную поверхность политики; для записей Linux и retrain всё ещё нужны доказательства из исходников хоста и работающей системы.

L: проверенный пакет достигает активного соединения 5.0 GT/s x4 на endpoint и вышестоящем мосте, со скоростями передачи PCIe около 1.70--1.71 GB/s и без новых ошибок PCIe/AER. См. указанную выше матрицу производительности.

Патч намеренно не добавляет OPT только для GA100 и не связанные с ним записи регистров XP3G. Дополнительная политика XP3G в патче 01 защищена точным чтением CMP50/TU102; её нельзя переносить на другую архитектуру без нового доказательства через IDA и во время работы.

Как повторно использовать эту работу

Для будущего патча CMP50HX сохраняйте такой порядок:

  1. Подтвердите точную проверку BDF в целевых исходниках и на работающем хосте.
  2. Классифицируйте изменение как firmware/RM, host PCI, host reporting или их сочетание.
  3. В IDA начинайте с xrefs и формирования операндов/непосредственных значений. Подтвердите путь вызовов, владельца регистра, направление чтения/записи и близкое поведение отката или сброса. Не используйте совпадение строки как единственное доказательство.
  4. Вносите наименьшее изменение исходников. Держите чтение обратно и откат рядом с каждой записью. Неподдерживаемая плата должна оставаться на штатном пути.
  5. Сначала применяйте патч к чистому дереву исходников с проверенным хешем, используя patch --dry-run. Затем собирайте проект и проверяйте строки модуля, ABI и маркеры исходников.
  6. На оборудовании записывайте значение регистра или API до и после, активное состояние соединения или ядер, изменение dmesg и результат холодной загрузки. Одного журнала успеха без чтения значения обратно недостаточно.
  7. Записывайте и отрицательные доказательства: отсутствующий writer в IDA, регистр только для чтения, физический отказ фьюза или неподдерживаемая возможность — полезные данные проекта.

Сборщик пакета применяет именно такой порядок:

  1. stockflow и политика GSP;
  2. отчёт количества RT-ядер RM;
  3. настройка ReBAR хоста;
  4. retrain PCIe endpoint/bridge хоста.

См. build.sh и docs/CMP50HX.md, где описаны операционные ограничения и ограничения времени выполнения.

This site is open source. Improve this page.