Полигон-2

К счастью, я анализирую микроконтроллер без сегментной организации, там обо всём что связано с сегментами можно забыть как страшный сон. Перемещение кода в ОЗУ на этом этапе не требуется - я работаю непосредственно с дампом адресного пространства. А вот работа с однотипными прошивками, я думаю потребуется. Попробую написать скрипт для автоматического поиска строк, автоматической подстановки меток и автоматического поиска цепочек подпрограмм, завершающихся call, jmp или rti.

i8088 написал:

[q]

Под функцией понимается подпрограмма возвращающая значения в регистре, под процедурой нет?
Я просто привык к Си, где только функции, а термин процедура отсутствует (это просто функция,
возвращающая void), ну а в ассемблере все это подпрограммы.

[/q]

Ну тут по сути тоже разделение чисто формальное. Я просто вижу, что подпрограммы в начале и конце заметно различаются по структуре, это должно что-то да значить.

i8088 написал:

[q]

upd. Я забыл спросить - WD ROYL, это уже цветная серия, GREEN/BLACK/BLUE ? Процессор там уже не Marwell?

[/q]

Граница довольно размыта. Некоторые серии могли иметь как старую, так и новую наклейку, например Atlantis, Pinnacle, Kermit. Процессор там Marvell, отличия чисто программные и они не слишком велики.

Для Caviar Cyl32 есть немного утилит от NazYura: http://nazyura.hardw.net/000006.htm
Дома у меня ещё что-то было, поищу.

Просматривая форумы, нашел упоминание, что у GALAXY вроде как появилась
команда A>P для переноса дефектов из G в P.

На недавно приобретенном GALAXY2D (250GB, PATA) есть один remap, решил проверить.


Age=50 Type=27 MxCyl=21C77 MxHd=2 MxSct=355 BSz=008M TCode=04040400 ThermFlts=0000

T>GALAXY2D - 2_Disk    3.AAE  08-31-06_10:00 AAE,GX_2D_4H_P,3A
Built for GALAXY2D,PITKIN,Redback,TI1810 PreAmp,Agere7531 PreAmp,McKinleyDT,2Disk,220 Servos,7200RPM,8Pole,133MHz,RwFeat=0002,VBAR

T>Eng Rev = .0G2
Compat/Hardware = .6D0
GALAXY2D - 2_Disk    3.AAE  08-31-06_10:00 AAE,GX_2D_4H_P,3A
CERT Rev = .0B5
.0B5
Mask Rom Rev = S-6B  
Orig Code = AAE3A0 TONKA2_GX_3A0.0G2.0B5        

T>V1
User Slip Defect List
Num Entries = 16C8    Checksum = 4508
Hd 0        Span Hd 1        Span Hd 2        Span
00000.0.000 000
                 00102.1.1F0 001
                 00103.1.1F0 001
....
....
                                  219F8.2.25B 001
                                  219F9.2.25B 001
SLIPPED = 176854 ALLOWED = 1800000
SLIPPED at Hd00 = 42691 Hd01 = 48086 Hd02 = 86077
T>V2
Reserved Slip Defect List
Num Entries = 0000    Checksum = 02FE
T>V4
Alt Defect List
Num Entries = 0001    Checksum = 5861
Hd 0      Offset     Hd 1      Offset     Hd 2      Offset    
                                          10B76.2.228 0000 Alt
T>/A
A>P
A>/
T>V4
Alt Defect List
Num Entries = 0000    Checksum = 23FD
T>V1
User Slip Defect List
Num Entries = 16C9    Checksum = 522A
Hd 0        Span Hd 1        Span Hd 2        Span
00000.0.000 000
                 00102.1.1F0 001
                 00103.1.1F0 001
....
....
                                  10B76.2.228 001
                                  10DEC.2.2E3 001
....
....
                                  219F8.2.25B 001
                                  219F9.2.25B 001
SLIPPED = 176855 ALLOWED = 1800000
SLIPPED at Hd00 = 42691 Hd01 = 48086 Hd02 = 86078
T>


Осталось проверить, нужен ли пересчет транслятора/форматирование после этого, завтра
поставлю на чтение всей поверхности.

Вчера перед сном ставил чтение (я специально не стирал поверхность перед этим), и у меня возникли вопросы.

Я ожидал IDNF или UNC (UNC, если LBA номер учавствует в расчете ECC, как я встречал упоминание на форумах),
по крайней мере до конца трека.

Однако встретились два UNC (почему два?), примерно в месте предполагаемого дефекта, причем не подряд.
Один номер LBA я запомнил, второй к сожалению забыл сохранить. UNC исправились после записи, новых remap-ов
не появилось (Alt Defect List остался пустым).

Появилось подозрение, что remap был ложный, из-за сбоев, а бед был софтовый, и исправился записью, а для реального
добавления нового дефектного сектора нужно пересчитать транслятор и может быть отформатировать UA.

У новых F3 для этого команда есть команда m с правильными ключами, но здесь вроде нет такого (?). Может-быть
проанализировать логи тестов дефектоскопа заводского SS, и запустить предполагаемый тест(ы) где делается
форматирование UA с пересчетом транслятора?

Мне думается, у более ранних barracuda должна быть команда ручного занесения CHS дефекта в P-list (У U серии по моему есть),
если есть то можно организовать такой перенос и в ранних Seagate Barracuda. Скриптовый язык ST_MEM для автоматизации
такой операции ограничен, но вполне можно написать программу, которая будет делать это, главное команды раскопать.

В отличие от WD, у Seagate после очистки (переноса) G-list, в SMART остается запись об этом remap, надо разобраться как
очищать SMART remap-ы без сброса SMART (хочется сохранить счетчик времени работы и количество start/stop циклов).

При сливании через скрипт стмем
дампа памяти (level 1,команда D) на адресе D1,EC00
произошла остановка двигателя hdd по непонятной причине(все тот же hilo).При повторном включении двигатель не запустился.ЖД издавал легкий гул.
Вскрыл корпус(в максимально "чистой комнате" ).Головки залипли на поверхности.Аккуратно приподнимая головки и подкладывая под них
тонкий пластик ,вывел их в зону парковки к центру диска.Собрал ,подключил.Диск прошел рекалибровку.Естественно ,параметры чтения резко ухудшились.Запись не особо.Повторил процедуру чтения памяти.И опять на том же адресе останов двигателя.Похоже,эту процедуру надо делать,предварительно остановив шпиндель.
Поверхность без видимых повреждений(речь только о верхней пластине,другие сложно определить).Головки тоже.Т.к. плотность записи еще не столь высока (3гб/пластина) и полет головки измеряется не в нескольких нм над поверхностью ,а еще в мк,то винт поэтому и не умер сразу после таких экспериментов.И даже жив после второго залипания ))Естественно,частицы пыли теперь ушатают его через несколько часов)
Фото головки:



К головкам подходит четыре цветных провода (витая пара),чтение -запись.Их хорошо видно на фото.