Комментарии 22
Кстати, а структуры просто для наглядности или это реальные куски кода? Если реальные, то как обстоят дела с выравниванием и паковкой полей?
А за статью — спасибо! Всегда интересно почитать про форматы на железе — подучивает нейронную сеть в мозгу, потом помогает при анализе каких-то данных или просто отладки. Но из статьи я не понял: как была построен сам процесс разбора? Т.е. результат вижу: такой-то формат, такие-то данные, а как происходило понимание какие поля чему соответствуют, какие флаги ставятся в полях флагов и так далее.
Про выравнивание переменных я упоминал, там его нет во всех случаях, кроме гипотетического IA64, но я реальных образов с таких машине не видел, только сборки QEMU + TianoCore, там выравнивание есть и оно по восьмибайтовой границе. По упаковке — все пакуется наиболее плотно.
Разбор происходит следующим образом: если есть доступ к машине, то можно получить имена, GUIDы, аттрибуты и данные переменных, просто читая их последовательным вызовом UEFI runtime — функций GetNextVariableName и GetVariable. В итоге половина данных уже есть и их можно затем найти в дампе, остается угадать формат заголовков и значения некоторых аттрибутов, тут помогает открытый код проектов TianoCore, CHIPSEC, плюс некоторые добрый люди в сообществе, вроде тов. xvilka, иногда делятся своими соображениями или даже кодом.
Если же доступа нет, то либо стоит им разжиться, либо просишь дампы прошивки и вывод команды dmpstore и играешь в угадайку по ним.
P.S. По поводу опечаток заметил в начале:«я написал ПАРУ статей о форматах данных», правильно будет «написал НЕСКОЛЬКО статей», так как ПАРА применяется преимущественно «Две штуки чего-либо», а 3 — уже «несколько».
У меня тоже мое увлечение (переросшее потом в работу) началось со сломанной материнской платы, прошивка которой просто перестала стартовать после очередного обновления. Пришлось покупать прошитый чип на Ебее, но оказалось, что в этом чипе нет данных SMBIOS, и некоторый достаточно дорогой софт после замены отказался признать систему своей. Пришлось разбираться с восстановлением данных, по результату была написана утилита FD44Editor, потом пришлось соорудить комплект для прошивания (FTK), т.к. стандартные утилиты ASUS меня не устраивали, потом я устал от сложностей с PhoenixToot и сел писать собственный велосипед, и все заверте…
Софт этот называется HxD, это один из самых простых и маленьких хекс-редакторов для Windows с GUI. Есть гораздо более продвинутые редакторы вроде 010 Editor или WinHex, но мне хватало и этого всегда.
UINT8 State; // Состояние переменной
Какой физический смысл у поля "состояние переменной"? Зачем это? Как интерпретировать? Какие там допустимые значения?
#define VAR_IN_DELETED_TRANSITION 0xfe ///< Variable is in obsolete transition.
#define VAR_DELETED 0xfd ///< Variable is obsolete.
#define VAR_HEADER_VALID_ONLY 0x7f ///< Variable header has been valid.
#define VAR_ADDED 0x3f ///< Variable has been completely added.Физический смысл: отделить валидные переменные от тех, которые пока еще не валидные (запись еще не закончена или была прервана по каким-то причинам) и тех, которые перестали быть валидными (в переменную было записано новое значение, а старое еще не убрали).
Как интерпретировать: https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableParsing.c
Каков, собственно, алгоритм, который из SPI- NOR Flash делает NVRAM?
Что про это можно почитать?
Не понял вопроса такой постановке. По поводу того, какие дополнительные фичи простого Non-Volatile Storage сделают его полноценной NVRAM - вот здесь писал.
Неужели чтобы выполнить GetVariableByName(Name) надо просканировать все 16MByte SPI NOR Flash чипа, чтобы найти самый актуальный заголовок с Name?
Нет, конечно, под переменные выделяется несколько блоков и драйвер NVRAM получает информацию об их адресе и размере из Platform Configuration Database (PCD). Вот эти конкретные значения во время работы машины не меняются, и потому могут быть типа PcdsFixedAtBuild, т.е. фактически константами, которые сборочная система захардкодит прямо в сам драйвер при сборке.
Внутри нынешнего хранилища - да, каждый раз надо проходить с первой переменной до последней, поэтому на некоторых платформах еще и в оперативной памяти заводят копию, чтобы оттуда значения возвращать, а не читать их каждый раз с медленного флеша. Писать же приходится сразу, потому что никаких возможностей отложенной записи у UEFI нет (и слава яйцам!).
Вот подали питание. Как прошивка найдёт конец NVRAM? Всю SPI NOR Flash память с конца просмотрит что ли?
Всё 16MByte байтик за байтиком на 0xFF проверит?
Зачем искать конец NVRAM? Он задан константой в прошивке при сборке.
Зачем искать конец NVRAM? Он задан константой в прошивке при сборке.
Я имел в виду конец заполненной части NVRAM.
Однако я уже разобрался и написал про это отдельный текст
NVRAM Поверх off-chip SPI-NOR Flash
https://habr.com/ru/articles/732442/
поидее это надо делать лишь при старте контроллера, само значение и адрес свободной ячейки хранятся в RAM и при сбое питания могут быть восстановлены, то что это делается достаточно долго, это может быть не столь заметным на фоне времени сброса и инициализации, а дальше всё необходимое хранится в RAM и не надо каждый раз искать свободное место.
У меня вопрос в том как из SPI-NOR flash микросхем сделать программный интерфейс как у SD-карт?
В SD-картах можно спокойно читать, писать, стирать блоки фиксированной длинны по 512 байт, обращаясь по номеру блока.
Хоть один блок писать 1000k раз подряд. В SD-картах на аппаратном уровне выполняется механизм равномерного износа Flash.
Если есть интерфейс SD-карт, то можно спокойно пристегивать FatFs и создавать текстовые файлики как на PC.
Очень просто - добавить контроллер. Только вот ньюансы.... контроллер может писать, стирать блоки по 512 байт, а вот flash-чип нет, он умеет стирать скажем только страницами по 12кБ, поэтому контроллеру надо как-то выкручиваться и ИГНОРИРОВАТЬ команды стирания блоков, до тех пор пока не освободится целая страница.
Насколько я знаю, равномерный износ ячеек придумали только с развитием SSD-дисков, а флеш-карты гораздо более примитивны, и системы выравнивания износа там нет - собственно это причина того что удалённые/поврежденные данные с карт памяти можно восстановить, а вот с SSD-диска через несколько часов ваши "свободные данные" могут быть оптимизированы алгоритмами равномерного износа(сектора с актуальной информацией могут быть перегруппированы в другие страницы без изменения их виртуального адреса) и от них не останется и следа. По этой причине, область FAT на флеш-картах выполнена по старой SLC-технологии, выдерживающей износ в 100К-1М перезаписей, а остальной объем по более тонкой технологии с гораздо меньшим ресурсом. Быввают ещё разного рода резервы, с закрытой прошивкой контроллеры, которые иммитируют многие функции за счет увеличенного объема - например карта памяти на 1Гб если разобрать будет состоять из контроллера и ДВУХ чипов по 8Гбит, что нетрудно догадаться их суммарный объём будет составлять - 2Гб, а карта на 1... и одному китаю ведома как там работает прошивка и как используется этот объём для увеличения ресурса, а может и чипы битые и из двух едва наскребли на половину их суммарного объема рабочих страниц.
Устройство NVRAM в UEFI-совместимых прошивках, часть первая