Полигон-2

KALDYH написал:

[q]

strelec, если у вас получилось вскрыть винт и без особых последствий манипулировать с его внутренностями, можете попробовать снять БМГ и вымыть головки. Хуже этому винту уже точно не будет. Кое-какие инструкции в интернете есть, и по выводу головок с диска, и по жидкостям для мытья. Продувать винт от пыли перед сборкой - резиновой грушей. Изолировать головки от диска и друг от друга можно трубочками для коктейлей. Удачи! Я вам ничем подсказать не смогу, на эту тему я знаю только то, что есть в интернете.

[/q]

Это я и собирался проделать.Но шансы положит. результата очень низки.
Случайным образом наткнулся на команду 1>C(описания этой команды я не нашел) ,выводит пару crc: rom и user area.
В слитом дампе по адресам D8,xxxx;D9,xxxx нет такой crc.Предположил,что ,возможно, это "неправильная " часть флеш памяти.Поэтому и решил попробовать слить память по др. адресам.Но по какой-то причине произошел вышеуказанный казус ,т.е. остановка шпинделя при обращении к памяти.

i8088 написал:

[q]

Так и не должно быть, тк это вычисленная программой CRC

[/q]

Я предполагал,что crc хранится в самом файле(дампе и тп) ,рассчитывается программой жд,сравнивается для определения целостности файла.
Я исходил из того,например :
T>r
Disk Code Revision # .137 CRC ==> 6713
И в файле CERT как раз есть эта crc в 1-ых двух байтах (в обр. последовательности).Причем встречается в данном случае единожды.Что похоже на правду.

i8088 написал:

[q]

А попробуйте поискать эту CRC на скопированных с диска треках

[/q]

Я не знаю ,что это за адресное пространство:
1>Dxx,xxxx.Это гигантский массив.По адресу D8,0000-D9,FFFF ,согласно скрипту лежит ПЗУ.
Причем все эти адреса D00,0000-DFF,FFFF(000000h-FFFFFFh) читаются.
Если даже и найти crc ,алгоритм ее расчета сложно вычислить(как тут говорили,ida вам в помощь )

i8088 написал:

[q]

Если можно переставлять байты в карте голов, и потом работает, может эта CRC не особо и
критична? Те программа имеет возможность подсчитать CRC для ПЗУ, но она возможно и не
испульзуется. Это так, предположения...

[/q]

Вполне возможно,надо пробовать.

В докуметации от BVG есть кое-какое описание команд на уровне A>.

Там встречается термины LPL (logical cyl, physical head, logical sector) и PCHS (здесь все
ясно). Диск вместо PCHS использует LPP (logical cyl, physical head, physical sector)

[q]

Cx,y Convert LBA to LPL and display to screen.
x - upper word of >16 bit address
y - lower word >16 bit address or the 16 bit address
Dx,y Convert LBA to PCHS and display to screen.
x - upper word of >16 bit address
y - lower word >16 bit address or the 16 bit address

[/q]

Диск однако сообщает несколько иначе, так

A>C30,AA
LBA 003000AA = LPL 000002DB.02.027A
A>D30,AA
KBA 003000AA = LPP 000002DB.2.0495
A>


Те, полный физический цилиндр диск не сообщает, но отдает физическую головку и сектор. Функции эти видимо не проверяют корректность ввода, и при вводе запредельных LBA дают
"интересные" номера.

В описании видимо ошибка, так команда >D> конвертирует не LBA->PCHS, а KBA->LPP

Обратные команды:

[q]

cx,y,z Convert LPL to LBA and display to screen.
x – Logical Cylinder
y – Physical Head
z – Logical Sector
dx,y,z Convert PCHS to LBA and display to screen.
x – Physical Cylinder
y – Physical Head
z – Physical Sector

[/q]

Примеры:

A>c2000,1,50
LBA 023A7516 = LPL 00002000.01.0050
A>d2000,1,50
KBA 023A790C = LPP 00002000.1.0050
A>


В описании аналогичная ошибка, по команде >d> конвертируем не PCHS->LBA, а LPP->KBA (или так только у GALAXY?).

Кстати, как правильно расшифровывается KBA - K??? Block Address ?


Если конвертировать LPP в KBA, и если сектор в дефект листе, то преобразование дает один
и тот же KBA для дефектного и соседнего с ним сектора. В случае группы дефектов, это
распространяется на всю группу.

Примеры.

1. В дефект-листе имеем 00107.1.1F0 001 (1 дефектный сектор на треке 107, head 1, sec 1f0)

A>d107,1,1f0
KBA 00117029 = LPP 00000107.1.01F0
A>d107,1,1f1
KBA 00117029 = LPP 00000107.1.01F1
A>d107,1,1f2
KBA 0011702A = LPP 00000107.1.01F2
A>


2. В дефект-листе имеем 0102E.2.28F 003 (3 дефектных сектора на треке 102E, head 2,
начальный сектор блока дефектов 28F)

A>d102e,2,28f
KBA 011200D2 = LPP 0000102E.2.028F
A>d102e,2,290
KBA 011200D2 = LPP 0000102E.2.0290
A>d102e,2,291
KBA 011200D2 = LPP 0000102E.2.0291
A>d102e,2,292
KBA 011200D2 = LPP 0000102E.2.0292
A>d102e,2,293
KBA 011200D3 = LPP 0000102E.2.0293
A>d102e,2,294
KBA 011200D4 = LPP 0000102E.2.0294
A>



Я предположил, что этим можно воспользоваться для проверки, реально ли "работает" наш
перенесенный сектор в дефект листе. Проверим наш перенесенный сектор 10B76.2.228

A>d10b76,2,228
KBA 10D8BAC1 = LPP 00010B76.2.0228
A>d10b76,2,229
KBA 10D8BAC1 = LPP 00010B76.2.0229
A>d10b76,2,22A
KBA 10D8BAC2 = LPP 00010B76.2.022A
A>d10b76,2,22B
KBA 10D8BAC3 = LPP 00010B76.2.022B
A>

Из этого можно предположить, что транслятор работает с нашим "перенесенным" сектором должным
образом.

Почему же появились два дефекта UNC, разнесенные друг от друга?
Один бывший UNC LBA я сохранил, это 282638848, те 10D8BA00

A>D10d8,ba00
KBA 10D8BA00 = LPP 00010B76.2.0167


Почему-то он расположен до сектора 288, даже с учетом съезжания транслятра на один сектор (хотя оно должно быть после сектора 288), мне непонятно.

Ну а второй UNC скорее всего первый годный сектор после бывшего последнего сектора трека, он
как раз должен попасть на первый ранее не использованный резервный сектор на треке, и на нем
видимо верного ECC не было, и необходимо выполнить запись, для правильного расчета ECC.

Таким образом, после выполнения A>P необходимо стирание поверхности.

Интересно проверить команды преобразований с секторами в G-лист, должен быть уход в резервную
зону. С remap-ами у меня осталась одна TONKA2 160GB, когда скопирую с нее информацию,
попробую проверить.