Полигон-2

strelec написал:

[q]

Но модели младше wn310820 вроде нет:

[/q]

В этом и дело, я помню архив старой эхи читал, там это обсуждали,
решили что не стоит эта младшая модель ковыряния микропрограммы.
Ну и вторая сложность - ПЗУ там одноразовое и не сильно распространеное.

ATauenis, отладочные порты - они на всех практически устройствах с ТТЛ уровнями, исключения очень редки.

XPOHOMETP написал:

[q]

Вот, TTL он и в Африке TTL

[/q]

Короче, есть целое семейство стандартов на логические уровни: 5V TTL, 3.3V LVTTL, 2.5V и 1.8V CMOS (а по факту есть и 1.5V и 1.05V шины). На практике я обычно кладу на согласование с датакабелем болт.

Burn(полная версия) на Samsung WN-310820A пройден
успешно.Как минимум,получен опыт настройки Freedos,а также ,
что при подключении адаптера к неизвестным выводам желательно
измерить уровни напряжений)
Положил на полочку,пускай хранится для потомков

KALDYH, в online документации Scribd, по Вашей ссылке, есть упоминания весьма полезных
команд, кстати я нашел эту документацию в нормальном pdf здесь:
http://files.hddguru.com/downl...0commands/

Методика ручного добавления дефектов в дефект-листы, в процессе изучения, пока проверялсь
на не сильно нужном barracuda-образном U5 и вышеупоминавшейся PATA ALPINE 80GB, возможны
возможны ошибки в описании. На U5 странности есть (не всегда правильно пишется номер
дефектного сектора (со смещением), но я на нем пока не восстановил ATA overlay, может-быть
из-за этого?).

Есть команда F на уровне 2>, выполняющая форматирование заданного трека или сектора
(она похожа на команду F на уровне 9, которая была у non-barracuda накопителей, U series).
Излагаю в своем переводе, с исправлением ошибки. Дополнения/поправки/замечания приветствуются!

Заданный физический трек заранее нужно выбрать, позиционируя на уровне 2, команда s. Для
7200.9 и новее может понадобиться ключ подтверждения 22, проверяйте правильность
позиционирования по команде >.> Текущий сектор после этого может быть разным, но мы явно
указывем нужный сектор в последующих командах.

Формат команды
Fx,Op,,a

где x - номер сектора, если не введено, форматируем трек (просто F без ничего).
Op - операция (ABDEF)
a - если отсутсвует, то ввводим логический сектор, иначе, если >a> введено (проверял
с 1 и 22), то физический.

Команда 2>F без ключей типа операции и номера сектора форматирует заданный трек (на который
мы позиционировались). При этом slip сектора остаются на своих местах. Происходит ли при этом
частичный пересчет транслятора?

Команда 2>F с отсутствующим ключем операции, но с номером сектора (Fx,,,a) форматирует
сектор x и отмечает его как good (заносит в поля данных сектора правильную ECC?). Удаления
из slip-list этого сектора при этом не происходит.

Команды F с ключами операций:

Op A -> Fx,A,,a Форматируем сектор x и добавляем его в Alt list

Op B -> Fx,B,,a Форматируем сектор x и отмечаем его как плохой (makebad?)

Op D -> Fx,D,,a Форматируем сектор x и добавляем его в slip list (только для UA)

Op E -> Fx,E,,a Форматируем сектор x и добавляем его в slip list (только для SA)

Op F -> Fx,F,,a Форматируем сектор x и убираем все записи о нем в slip и alt list


При занесении дефектов в slip-list смежные дефекты объединяются в списке.

При этих операциях может возрасти количество ErrCtl, но после передергивания питания
снова 0000.

Я из логов решил попробовать ввести вручную alt-list (который я сбросил, но логи остались)
в slip-list, и на всякий случай после ввода дефектов на одном треке давал форматирование
трека F (точнее я под конец прошелся F по всем трекам, где добавлялись дефекты, хотя думаю,
это не нужно). Правильность занесения проверял сравнением логов T>V1 до и после модификации
slip-list, сохраняя логи в файлы и сравнивая их командой "diff -u".


2>s87ff,1
2>F240,D,,1
2>F241,D,,1
2>F242,D,,1

2>s8801,1
2>Pgm=00 Trk=087FD(08801).1(1).003(138) Zn=4 Err=00 ErCt=0000 Hlth=0000 CHlth=0000 Ready LBA=04348987
2>F2ec,D,,1
2>F2ed,D,,1
2>F2ee,D,,1

T>V1
User Slip Defect List
Num Entries = 069A    Checksum = 028E
Total number of Defects = 077F
Hd 0        Span Hd 1        Span
....
....
                 087FF.1.240 0003
                 08801.1.2EC 0003
08840.0.076 0001
                 0893E.1.27B 0001
                 08B07.1.1CC 000A
....
....


Одна странность - после Fx,D,,1 по следующей команде >.> видно что сдвигаемся на следующий
трек (только на один, последующие команды F его не меняют), но смежные сектора заносятся
тем не менее верно, даже без промежуточных sx,y.

Еще интересный момент - у меня был подключен и терминал, и IDE кабель, а ALPINE питалась
от отдельного БП. Так вот, после передерга питатния по интерфейсу чтение и верификация OK,
а при записи я получил просто зависание, причем и под FreeBSD, и под DOS (MHDD).
Предполагаю, диск критичен к должному сбросу по интерфейсу, хотя сперва подумал на южный
мост ServerSet CSB5 (ASUS TR-DLS).

Как считаете, правильно ли сделано? Нужен ли дополнительный пересчет транслятора?
У этих семейств он статический или динамический? Если идея правильная, подумаю о
программе, которая будет делать это автоматически. Может быть полезно для дисков 7200.7
с небольшим количеством remap, которые не растут, при общем хорошем состоянии поверхности
(чтобы не гонять долгий SS). Remap-ы эти могут быть зачастую и ложными, от сбоев разных,
но все же надежнее записать их в slip-list...