Полигон-2

KALDUH, я заранее извиняюсь, если вопрос глупый, я вот что хотел узнать.

Можно ли на Seagate (конкретно серии 7200.9 и 7200.10) просто перенести сектора из G в P list
и пересчитать транслятор, не выполняя полный комплекс self-scan (даже с N4)?

Иногда попадаются диски с небольшим количеством remap (нерастущим длителеное время,
и в целом в хорошем состоянии). Собственно из-за плохой эксплуатации предыдущим
владельцем (плохой БП, контакты итп) эти remap-ы могут быть и ложными.

Просто хотелось бы избавиться от задеожек, связанных с позиционированием в резервную
зону, не делая полный комплекс тестирования.

KALDYH, большое спасибо!

Да, есть смысл попробовать очистить G list, тк есть вероятность, что remap-ы
ложные (диски скорее всего работали ранее с ужаснами блоками питания).
Подготовлю тестовый стенд с терминалом и проверю!

Позавчера приобрел Quantum AS 20.5 (я давно искал рабочий AS) с дикой
наработкой, было 2 записи в Glist и заметные задержки на них, при чтении
(точнее верификации) в MHDD. Но сканирование по физическим
параметрам не нашло проблем в них. Ну я просто средствами PC3K добавил
один из них в дефект лист, в результате все бывшие в Glist записи оказались
в Plist. Сделал erase, сейчас диск тестируется.

PS. Попутно выяснилось, что ASUS TR-DLS умеет UDMA на встроенном
IDE под DOS (те через int13), что редкость для плат Pentium3. Она еще и
LBA48 тоже поддерживает.

KALDYH написал:

[q]

Теоретически, её можно было бы найти, изучив часть скрипта селфскана, отвечающую за дефектоскопию, но это выше моих навыков.

[/q]

i8088, зато я нашёл подсказку, как найти неописанные команды: http://nazyura.hardw.net/Part02.htm (во 2 половине заметок)
Попробуйте, может, у вас получится.

Не могу не похвастаться: выпросил в дар Maxtor D740X-6L квантумообразный. Изрядная редкость в наше время - они давно попередохли... Будет теперь на основе чего статью по квантумам дополнить.

Переходим к практической части.

Дано: Maxtor Diamondmax Plus 8 6E040L0, на гидродинамических подшипниках
процессор Ardent, фирмварь NAR61590, s/n E1DW42QE, материалы K,M,C,A
168 реаллокейтов в смарте и куча ещё не скрытых бэдов.
Задача: 1) изучить структуру микропрограммы и дополнить статью, 2) прогнать на нём селфскан

Действия:
1) Загружаем PC-3000, выбираем "N40P", "Стандартный режим"
2) Смотрим и сохраняем G-List и P-List
3) Проверяем структуру служебной информации - проблем не обнаружено. Сохраняем по F2.
4) Читаем все модули
5) Читаем все группы модулей
6) Читаем ПЗУ
7) Создаём лоадер

Изучаю слитую служебку:
Служебная зона является первой в таблице зон, расположена в начале диска и имеет пониженное число секторов.

  # Start Cyl  End Cyl  SPT
---------------------------
  1       352      411  540
...


Модули разбиваются на группы, расположенные одна за другой. PC-3000 сохраняет их как *.SMB. В порядке возрастания UBA:

Имя	Начало	Длина в секторах
ULIST (копия 1)	0000	0008
DATA (копия 1)	0008	04B0
OVL (копия 1)	04B8	1140
Selfscan	15F8	1770
SWAP1	2D68	0CE4
SWAP2	3A4C	0B54
Defect log	45A0	0190
DATA (копия 2)	48C6	04B0
OVL (копия 2)	4D76	1140

(не знаю, заводские ли это наименования или их так условно назвала Acelab)
Дальше пустое пространство и в самом конце служебной зоны, с адреса 7E6F - вторая копия ULIST (8h секторов). Кроме того, по адресу 5EB6 обнаруживается модуль PN=AD с заголовком TRACER, длиной 529h секторов, ася про него не знает.

---

После длительного изучения слитых модулей и групп было установлено, что PCMX_PKR показывает таблицу модулей с ошибками. Часть модулей пропущена, у некоторых не соответствуют длины. HDD Repair, однако, обрабатывает её верно (нумеруя, правда, с единицы и размер показывает десятичный), но в нём не работает групповое сохранение модулей и сохранение списка, поэтому бэкапить служебку им неудобно. Здесь и далее - нумерация по верной таблице, начиная с нуля. А теперь поищем эту самую таблицу, опираясь на следующую цитату:

[q]

циферки эти макстор придумал и на них сам лично ссылается, более того карта посторена на основе цифирок, а названия типа DISK и MFIT это всего лишь дополнение к циферкам и проверка валидности модуля и не более, тем более что макстор сам читает модули по циферкам
тем более что если взять особо старый накопитель и открыть там модуль 1F то мы увидим там GMAP а не DISK, названия 33-го также менялось, про 18-й я вообще молчу, у него версий немеряно

А вообще - ПЗУ знает координаты СА, и знает координаты кое-каких модулей, и проверка заголовка и кс на валидность... причем взимосвязь загрузки модулей при старте очевидна, и к позиционным номерам действительно не имеет отношения ПЗУ знает координаты очень маленького числа модулей
А далее вступаент в дело дискром и оверлеи.
Когда разработаете собственную концепцию - возьмите сектор служебки на калипсе, начинающийся дампом 4D 4F 0E 00
Прибавьте к нему 1Bh секторов. Считайте пару секторов. Зная (из глупой концепции глупых пацанов) что pn1F - это ДИСК, зная что лежит он на УБА 0008 и длиной он 0001 - поищите в считанных секторах цифирки 08 00 01 00... Понимая, что на запись об одном модуле у глупого вендора, нифига не понимающего в концепциях, отводится 4 байта... умножте 1F на 4...
От смещения, где вы нашли 08 00 01 00 отнимите получиненное - и по этому смещнию, продолжительностью пару секторов увидите кучку интресных цифирок

Sable
внушаеть
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

0004F640                                  3E 3C 02 00 40 3C             >>..@>
0004F650   02 00 F2 3C 00 00 42 3C  01 00 44 3C 78 00 D2 3C   ..o>..B>..D>x.O>
0004F660   01 00 D3 3C 00 00 D3 3C  00 00 D3 3C 01 00 D5 3C   ..O>..O>..O>..O>
0004F670   01 00 D6 3C 01 00 D7 3C  01 00 D8 3C 01 00 56 1F   ..O>..?>..O>..V.
0004F680   03 00 59 1F 08 00 61 1F  01 00 62 1F 02 00 65 1F   ..Y...a...b...e.
0004F690   01 00 7C 20 E8 08 67 1F  08 00 2C 20 0B 00 2C 20   ..| e.g..., ..,
0004F6A0   00 00 58 20 10 00 68 20  00 00 29 00 39 01 90 01   ..X ..h ..).9.?.
0004F6B0   01 00 91 01 01 00 AA 02  32 00 A5 01 02 00 A8 02   ..‘...?.2.?...?.
0004F6C0   02 00 8E 01 01 00 08 00  01 00 DC 02 02 00 62 01   ..Z.......U...b.
0004F6D0   0B 00 A3 01 01 00 00 00  00 00 16 32 74 41 00 00   ..?........2tA..


чето это напомнило...

Ааа!!!

   1 00 3C3E 0002  ы    ы                  
   2 01 3C40 0002  ы    -    * Tbl_55AA    
   3 03 3C42 0001  ы    ы    * Tbl_55AA    
   4 04 3C44 0078  ы    -    * Tbl_55AA    
   5 05 3CD2 0001  ы    ы                  
   6 08 3CD3 0001  ы    ы    * Tbl_55AA    
   7 09 3CD5 0001  ы    ы                  
   8 0A 3CD6 0001  ы    ы                  
   9 0B 3CD7 0001  ы    ы                  
  10 0C 3CD8 0001  ы    ы                  
  11 0D 1F56 0003  ы    ы    * Tbl_55AA   MX_ST_CFG3
  12 0E 1F59 0008  ы    ы    * Tbl_55AA   MX_ST_SCRIPT
  13 0F 1F61 0001  ы    ы    * Tbl_55AA    
  14 10 1F62 0002  ы    ы                  
  15 11 1F65 0001  ы    ы    * Tbl_55AA   MX_ST_CFG1
  16 12 207C 08E8  ы    -    * Tbl_55AA    
  17 13 1F67 0008  ы    ы    * Tbl_55AA    
  18 14 202C 000B  ы    -    * Tbl_55AA   STRS
  19 16 2058 0010  ы    ы    * Tbl_55AA    
  20 18 0029 0017  ы    ы    ы AT_PDL 1   AT_PDL - P-List
  21 19 0190 0001  ы    ы                  
  22 1A 0191 0001  ы    ы    ы SECU       SECU - ¬®¤г«м б Ї а®«п¬Ё
  23 1B 02AA 0032  ы    ы    - AT_POL 1   AT_POL - G-List
  24 1C 01A5 0002  ы    ы                  
  25 1D 02A8 0002  ы    ы    ы DMCS   1   DMCS - в Ў«Ёж  ЄниЁа®ў Ёп
  26 1E 018E 0001  ы    ы    ы SRV6       SRV -  ¤ ЇвЁўл Є «ЁЎа®ўЄЁ
  27 1F 0008 0001  ы    ы


Нет что просто сказать, что PN - позиционый номер в карте модулей, во базару развели

[/q]

Проверяем сказанное и расшифровываем этот ребус. "сектор служебки, начинающийся дампом 4D 4F 0E 00" - это оверлейный модуль MO номер 03 (первый по порядку). "Прибавьте к нему 1Bh секторов" - попадаем в тело оверлея 0E. "Зная что pn1F - это ДИСК, зная что лежит он на УБА 0008 и длиной он 0001 - поищите в считанных секторах цифирки 08 00 01 00..." - обнаруживается в теле оверлея 0F. "Понимая, что на запись об одном модуле у вендора отводится 4 байта, умножте 1F на 4,
от смещения, где вы нашли 08 00 01 00 отнимите получиненное" - действительно, находим начало таблицы модулей. Итак,

Таблица модулей
Таблица модулей (у N40P) находится в оверлейном модуле 0F по смещению 26D8h и состоит из 4-байтовых записей: первое слово - UBA начала модуля, второе - длина в секторах. Соответственно, PN модуля - его номер в этой таблице. Не забываем, что порядок байт в слове - от младшего к старшему.

---

Группа модулей ULIST состоит из 4 копий RCT0 длиной 1 и за ними - 4 копии U_LIST00 длиной 1. Все копии идентичны. RCT0 не имеет отношения к своему "тёзке" из группы данных - скорее всего, это адаптивы служебной зоны. Структуру U_LIST разобрать не получится, т.к. он у меня не содержит дефектов и сравнивать его не с чем.

---

В начале группы оверлеев идёт ПЗУ, длиной 100h секторов. Заголовка оно не имеет. За ним идут программные оверлеи, которые делятся на модули длиной 20h секторов, всего 30 штук. В заголовке каждого - буквы MO, далее байт 3 - номер (от 03h до 20h) , байт 4 - 00, байты 5-6 - контрольная сумма ПЗУ - по этой контрольной сумме определяется соответствие версий.

[q]

Мало того, что КС (как и положено) записывается в конце (последние 2 байта) модуля-образа ПЗУ, она еще есть и в каждом оверлее. Стандартно любой оверлей начинается с MO (2 байта), далее 2 байта - номер оверлея и следующие 2 байта - искомое.

[/q]

Итого ПЗУ с модулями занимает 4A0h секторов. Далее - заполненный нулями промежуток в 400h секторов, с сектора 8A0h от начала группы (D58 от начала зоны) пошли вторые копии ПЗУ и модулей и в конце - ещё 400h пустых секторов.

PC3000 показывает это в меню "структура служебной информации" (без учёта копий)

Оверлеи
  #  UBA Rd Id ChkSum
---------------------
03 05B8  √  √   √
04 05D8  √  √   √
05 05F8  √  √   √
06 0618  √  √   √
07 0638  √  √   √
08 0658  √  √   √
09 0678  √  √   √
0A 0698  √  √   √
0B 06B8  √  √   √
0C 06D8  √  √   √
0D 06F8  √  √   √
0E 0718  √  √   √
0F 0738  √  √   √
10 0758  √  √   √
11 0778  √  √   √
12 0798  √  √   √
13 07B8  √  √   √
14 07D8  √  √   √
15 07F8  √  √   √
16 0818  √  √   √
17 0838  √  √   √
18 0858  √  √   √
19 0878  √  √   √
1A 0898  √  √   √
1B 08B8  √  √   √
1C 08D8  √  √   √
1D 08F8  √  √   √
1E 0918  √  √   √
1F 0938  √  √   √
20 0958  √  √   √

а сохраняет, группируя в модули следующим образом:

• Модуль 39 - оверлеи 03-07
• Модуль 3A - загружаемое ПЗУ
• Модуль 50 - оверлеи 08-1F
• Модуль 97 - оверлеи 03-07 второй копии
• Модуль 98 - второе загружаемое ПЗУ
• Модуль 99 - оверлеи 08-1F второй копии
  

Оверлей 20 в модуль не сохраняется, его можно извлечь только из группы модулей.

А что же лоадер, который создала PC-3000? Изучение показало, что внутри всё то же самое - пустой сектор вначале, за ним ПЗУ, еще один пустой сектор, и далее все (включая 20h!) оверлеи.

Вот что ещё имеет сказать Sable по поводу кодовых оверлеев:

[q]

В данном повествовании я не буду говорить о назначении каждого модуля и оверлея. Но на 2-х моментах акцентирую внимание.
1-й: Внимательно смотрим в smb-файл, тот в котором собраны DATA. Строчка «HOST DISK ROM» иногда встречается ДВАЖДЫ в каждой копии, ладно запускаем WinHex и выдергиваем оба блока, по 128 килобайта каждый. Получаем 2 образа загружаемого ПЗУ.
Один NAR6159Z, второй NAR61EAZ. Вот тут внимание! Вышеописанное встречается НЕ НА ВСЕХ дисках. Т.е. альтернативная загружаемая ПЗУ присутствует не на всех дисках, а NAR61590 может превращаться NAR61EA0 и наоборот.
2-й момент: в КАЖДОМ диске N40P и ARES присутствует модуль 422F0064 (UBA 422F, длина 64h секторов). В заголовке A0 4F 00 00 … Ну так вот, данные в этом модуле (примерно 40 килобайт) – с нулевой избыточностью, т.е. практически не сжимаемые архиваторами. Беглый взгдяд показывает, что это банальное LZW-Tree. Буду пробовать распаковать. Результаты доложу. И в догонку – этот модуль пытается считать оверлей 0E.

[/q]

Т.е. в первом пункте он говорит о второй микропрограмме (которая НЕ альтернативка). Надо проверить, есть ли она у меня. UPD: Проверил - нету. Обе копии идентичны.
Ещё о назначении отдельных оверлеев от Sable и Zong:

[q]

Цитата: Есть такое предположение, что загрузкой УБА-секторов, критичных для работы винта и подсчетом их КС занимается модуль #0F (в случае с N40P).
Первым кто указал на этот факт был Sir_Manyak
ACE использует описатель(каталог) модулей (или сектор конфигурации)при входе в стандартный режим,но следов использования $06 на нормально стартанувшем винте нет.Именно про это я и говорил.

[/q]

[q]

#06 в моем понимании это своего
рода "command extender" именно после его загрузки и появляется
возможность работать с помощью обычных вендор-специфических

[/q]

[q]

Тока что проверил, без загрузки #06 нормальной загрузки не получается.

[/q]

[q]

Команды работы с памятью появятся после загрузки MO3...6.

[/q]

---

Имена модулей данных, как выяснилось, местами хранятся в формате big-endian, соответсвенно, для просмотра текстовых фрагментов байты должны попарно меняться местами. "MO" читается как "OM" (Overlay Module), "ZRBT L1 " читается как "RZTBL 1" и т.д. Возможно то, что часть имеет заголовок big-endian, а часть - заголовок little-endian, связано с архитектурой DualWave. Кстати, лог проверки служебной информации неправильно отображает версию загружаемого ПЗУ - забывает перевернуть байты.

Группа модулей данных навскидку разбивается следующим образом (все координаты - в секторах, в hex):

UBA	Длина	Заголовок	Описание
8	1	DISK	Описание диска (см. выше). Заголовок не перевернут.
9	20	RZTBL 1	Таблица записями по 14 байт, разбор ниже
29	12?	AT_PDL 1	Таблица из записей длиной 4 байт, без КС.
162	11	RCT0	PC3000 ошибочно указывает длину 12
1A6	1	SRV6	Заголовок не перевернут
1A9	1	SECU
1AA			Модули SMART. Не имеют заголовка и контрольной суммы, в связи с чем их границы навскидку неразличимы.
1BB	1	ATAF	Заголовок не перевёрнут
1BF	1	ARREH_01	О его назначении - ниже. Первый сектор - заголовок, всего 5-6 байт данных, далее записи по 26 байт примерно до сектора 1E5
2BF	1		Текстовая информация о компонентах. Порядок байтов прямой.
2C0	2	DMCS 1	Записи длиной 14 байт
2C2	19	AT_POL 0	Записи длиной 8 байт, разбор ниже
2DE	1	MAXATG	Заголовок не перевернут. Возможно, длина - 14h секторов.
2F6	81	EVTLG_00	Записи длиной 16 байт
376	1(2?)		Записи длиной 12 байт
3A0	1	FW	Заголовок не перевёрнут (?)
3F3	2

Sable написал:

[q]

Тапок - часть транслятора...
аррех - глист.
приближенная аналогия - сводная_33/ат_падла
я аналогию к тому и привел, что из Раера восстанавливается "Глист" (ат_пол)... а не наоборот, сам-же раер как таковой в трансляции не участвует

Наблюдая за тапком мы видим реальные LBA с флагами,т.е не сжатый
формат как в др. элементах транслятора...

[/q]

Это всё, что найдено в этой группе. Как видно, структура соответствует описанной в доках на PC3000. Также, если посчитать, видно, что между многими модулями и от последнего модуля до конца есть пустые промежутки. Они заполнены нулями. PC-3000 сохраняет их как модули различной длины (не соответствующей фактическому расстоянию), возможно, у других семейств на их месте что-то было, позже разберусь. Также пц3к не находит и не сохраняет ARREH, FW и EVTLG.

---

Далее, разберём структуру AT_POL.

• Байты 00-07 - имя модуля
• 08-0B - адрес начала служебной зоны (порядок слов также обратный)
• 0C-0D - кол-во дефектов
• Назначение байтов 0E-0F установить не удалось.
• Начиная с 10h идут записи о дефектах по два 4-байтных слова: первое двойное слово - LBA дефекта, второе двойное слово - LBA замещения. У всех адресов дефектов бит 30 установлен в 1. У кандидатов в дефекты адрес замещающего сектора равен адресу дефекта и бит 31 установлен в 1.

Разбираем структуру RZTBL
00-07 - имя модуля
0C - кол-во головок (выяснено не мной)
08-0B, 0D-0F - не установлено
Начиная с байта 10h идут записи длиной 14 байт:

• 0-1 - число дефектов в диапазоне дорожек
• 3 - номер зоны. 6 бит - признак трекового дефекта.
• 6-9 - начальный цилиндр
• A-D - конечный цилиндр
• 2,4,5 - не установлено, возможно, битовые карты
  

Каждая запись описывает до 918 дорожек

Структура AT_PDL:
В начале и в конце - некие дескрипторы 2*4 байт.
С адреса 4Ch - записи по 4 байт, организованные в группы.
00-01 - возрастающая последовательность байт. Старшие 4 бита в слове - некая битовая карта.
02-03: возрастающая последовательность 16-битных слов. Деление на группы - по их переполнению.
Группы записей разделяются последовательностями FE FF FF FF 00 00 00 00

---

Группа модулей Selfscan состоит только из HLUTL и цепочки HUSR.

Заглянул в группу модулей SWAP1. Выяснено, что там заголовок (0x55 0xAA) и контрольную сумму имеет каждый сектор, таким образом представляя собой "модуль". Ещё установлено, что многие модули несут в себе текстовые строки, предположительно комментарии к тестам.

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

Группа модулей Defect log включает в себя модули 00-0С, 2A-2D, 4D-4E, 5A-5F, 74-76, 79, 82-8F, 9D, 9F, A2. По большей части там пусто (нули). Заполнены модули:

• 01 - cодержит строки apost21, a5_stz76670_xmit, rdtaz_sh
• 03 - содержит строки apmt27, apomt02 apo_mt27670_xmit
• 04 - бинарная таблица
• 08 - содержит строки aposw06, a5_sw8wc670_xmit, sm_vx05a
• 2C - бинарная таблица
• 82
• 83 - информация о компонентах
• 9F, A2 - Factory Process map
• 8A-8B - там 4 модуля по сектору, содержат байты DE AD

Также наблюдаются заголовки и КС нескольких пустых модулей (например, после 08-го, длиной 1)

---

Пока я экспериментировал, винт ушёл в стук. Что я там говорил про надёжность "тонких"? Ничего страшного - буду на нём отлаживать загрузку лоадера, потом устрою ему вивисекцию...