openocd имеет функции чтения nand кодом внутри. Но он ожидает контроллера без буфера и читает данные с одного адреса.

В этом девайсе есть буфер, и читать надо с адресов последовательно, но большого смысла для скорости в этом нет.
Потому что итак используется функция зачитать кусок памяти.

jlink подключен на 12Mbps, а вот TAP подключен TDI на страшно торчащих проводочках.
Так что быстрее вряд ли получится. К тому же TAP должен как то успевать разгребать приходящие данные. А это значит надо после ресета иметь быстрое ядро.
Или уметь его инициализировать.
А доков то нет.

этот док давно тут пасется - в нем есть ошибки на сколько помню ..
на счет 4 чанков (фреймов или сектор или как там его)
так вот для нанда 64 этих чанков 1 в каждой странице а вот в нанде 128 - их четыре
-они читаются последовательно .. ну с этим наверное уже разобрались. ну и замечательно - если это адрес регистра у меня так и сделано.один регистр для передачи\пириема и один для управления.
на счет байтов - ниче не пойму пока - лучше куском файла бинарного.. этот вопрос решаемый, но через задницу к сожалению- приходится заливать первый блок директом ,рестартовать и получаем нужные настройки во всех регистрах.
по поводу кривых байтов -делайте теже конфиги что в моем сорце для raw -они точно работают как надо но не забывайте о том что они чуть разные для длинной и короткой страницы (1-и 4 чанка)

в аттаче код быстрого raw драйвера для большой страницы//Flash.c гляньте там все что нужно вроде видно хорошо.

Chunk приходится делать потому, что контроллер имеет буфер на 512 байт данных и 16 байт oob. Обычно в контроллере нет буфера, и все данные читаются из одного регистра данных с фиксированного адреса.

"Конфиги" т.е. данные в регистрах управления контроллером заливаются в ваших исходниках из файла. Файла нет.
Драйверы можно делать универсальными просто передавая параметры через регистры или память.

За исходники спасибо.
В целом всё уже понятно, ввиду нахождения исходников под win для использования J-link и его адаптации под мой 6290 и hynix 128MB думаю что моя личная проблема решена.

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

Стоит ли доделывать код в openocd для возможности записи я не знаю.
Без последующей публикации нет наверное.

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

ваши дампы дампами, но формат их мне неизвестен, да и девайсы и флеши там могут быть иные

дампы из под местного флешера - самые обычные -буфер+спар 200h+10h и так последовательно фрейм за фреймом.
для тех моделей что вы назвали они покрывают все возможные нанды
- в смысле от всех производителей что поставляли хуваю
остается только соблюсти размер при заливке и не спутать 64 метра и 128.
но хозяин - барин (с)
ps дампы из под рифф бокса отличаются тем что - последовательно складывают все пространство данных и уже после всех данных (почти в самом конце файла) складывают все спары тоже последовательно. конвертилка есть в соседнем треде.

Да не обычные дампы.
Full Flash_E173Eu-1_Unlock_128mb.bin оказался 2048 + 64 и эти 64 байта сплошные FF
Так что толку с него как с козла молока.

RawFull_E173_Unlocked.bin 512 + 16, но у него байт 523 копия 522, а не FF.

Писалка под винду оказалась без write raw, сделал по аналогии - ничерта не пишет.
Оказалось надо сделать сброс и убрать бутор с проверкой статусов - на запись они не работают. После этого стало писать пургу. Методом научного тыка выяснилось, пишет чётные слова буфера и 4 раза в первые 512 байт страницы - в результате получается мусор.
Вывод оказался очевиден: ресет сбросил регистры конфига в 16 битный нанд с 512 байтовыми страницами.

Ладно, залил. Ничерта не завелось.
Или копия 522 в 523 мешает, либо что-то где-то плохое совсем.
Сделал конвертер и писалку с верификацией.
Запись с верификацией показала 2 плохих блока.
Притом в начале 0015E800 и 0017F000 флешки.
Вокруг место пустое.

Возникает прикладной вопрос, как помечать блоки плохими и как их переназначать?

О, это не бады, это erase глючит, видимо адрес то тоже сдвигать надо.
Остаётся в блоке мусор и с ним AND делается

про писалку директ китайскую - предупреждал -глюкавая ..точнее не рабочая она.
по поводу фуллов - еще раз скажу что они бывают на местном аплоаде двух типов-
из под местного флешера и из под риффбокса..
на счет особенностей "некоторых разделов" в части того что данные залезают на спар - тоже предупреждал.. ты просто видимо не хочешь поверить на слово ;-) и пытаешся пройти путь который я уже прошел и при этом не скрываю подробностей..