Ваша правда ... там много лишнего применительно к j-link
например не нужно трогать вообще DСC регистры и "быстрые режимы" соответственно - жилинк директ способом получит скорость обмена
выше чем может делать перемещение данных в буфер сам контроллер.
посмотрите только медленные функции - такие как
nand_read(
nand_blockerase(
nand_write(
этого будет достаточно что бы увидеть последовательность отправки данных
и в какие регистры что конфигурить и в какой последовательности
отмечу еще раз -ввиду того что нет обработки функции завершения перемещения данных из нанд в буфер (не отслеживается регистр статуса) -обязательно нужно использовать задержки гарантированно перекрывающие это время.
так же скажу что если вы планируете свой драйвер то не парьтесь с reg режимом и используйте только raw вариант чтения и записи.. долго объяснять почему это не приводит к успеху для всех разделов -скажу просто что это причуды файловой системы квалкома- там изврат для некоторых разделов
в таблице это отражено атрибутами раздела - просто копирование данных которое позволяет сделать клон памяти нужно делать именно заливая сырые данные (бит управления механизмом коррекции за это отвечает) соответственно количество байт читаемых\записываемых буфер должно быть чуть больше - это видно в коде .

Я уже ревью этого кода сделал.
Текущий вопрос для интеграции с openocd, в коде все чтения/записи с контроллер NAND 32-битные. А openocd имеет поддержку только 8 и 16 битную запись.

Запись в командный регистр можно победить легко. Ну приходит байтик, транслируем команду openocd в команду этого контроллера и пишем 32бита.

А вот с регистром адреса сложнее. openocd пишет в него либо от 1 до 5 раз 8битными словами. Либо 2 раза 16 битными. И интерфейс к драйверы разбил на части. Либо чтение страниц (как это будет делаться - проблема драйвера и можно намутить что угодно). А есть часть разбирая на запись команды, записи адреса, чтение/запись данные (пользовательские и/или/только oob).

В частности через этот механизм идёт идентификация производителя, чипа, и определение его характеристик типа битности, размера, размера страницы и блока.

openocd умеет читать писать и с oob и без.

В openocd есть существующие драйверы, часть из них ECC считают по алгоритмам для верификации. Есть которые считают ECC прямо на чипе если он такое умеет

есть данные по битам статусного регистра?

в этом и проблема что в области oob оказываются не коды, а данные!!
-это результат упоротой китайской файловой - по этому для того что бы восстановить модем нужно обязательно читать и писать с отключенным
движком рассчета\коррекции.
дата щита в глаза не видел на сабжевый чип - но он явно наследник более ранних на которые есть описание софтваря интерфейса вот такой док может пролить свет 80-V6968-2 MSM6280 Software Interface.pdf -под рукой нет но гуглем найти можно .. если не сложится разыскать чуть позже вылью..

кстати если Вы так неплохо разобрались в строительстве дров для open -а
может сделате доброе дело - напишите драйвер для mdm6600 - очень многие его спрашивали - я не смог набраться сил его сделать под вигглер - там камень арм11 а код вигглера у меня есть только под арм9.

скодил автоопределялся и читалку, сторону записи не делал.
openocd периодически глючит, и приходится частоту ставить на 3kHz
и как следствие
dumped 2112 bytes in 313.623322s (0.007 KiB/s)


но можно и
> nand device $_CHIPNAME.nand msm62XX $_TARGETNAME
> adapter_khz 128
adapter speed: 128 kHz
> nand probe 0
NAND flash device 'NAND 128MiB 1.8V 8-bit (Hynix)' found
> nand list
#0: NAND 128MiB 1.8V 8-bit (Hynix) pagesize: 2048, buswidth: 8,
blocksize: 131072, blocks: 1024
> nand dump 0 e173_dead_dump_raw_ecc_first_block_3.bin 0x0 0x20000 oob_raw
dumped 135168 bytes in 42.444626s (3.110 KiB/s)

и всего то 12 с небольшим часов нужно чтобы слить 128MB
Проще наверное флешку сдуть, в другое место запять и обратно припаять.

mdm6600 надо торговать, это же не копеечный модем, это же ай-фоны, ай-пады :)

> adapter_khz 2048
adapter speed: 2048 kHz
> nand dump 0 e173_dead_dump_raw_ecc_first_block_8.bin 0x0 0x20000 oob_raw
dumped 135168 bytes in 4.732867s (27.890 KiB/s)
4 мегагерца не умеет, а RTCK в нём нет, да и оторвался этот проводок.

я делал 6600 под жилинк - работает как положено и без проблем вроде..
точно проверить просто неначем -тот мопед что у меня есть на этом контроллере мертв изначально а дампа под него нигде не сыскал.. - но что записываю то и читаю- свиду все путем.. былбы дамп под e321 хувай - стало бы понятно что подпилить нужно - но по моему и так все путем .. кстати под этот контроллер кутулс пакет работает хорошо -но не совсеми нандами- под свой нанд не сумел нарыть загрузчик аварийный- но люди пользуют с другими(не со всеми оптьтаки )
на счет скорости полученной вами минус два поста -жуть какая то - я на вигглере больше скорость получаю в несколько раз. правда загружая и исполняя драйвер внутри модема-быстрый режим - иначе не получается -дофига трафика управляющего приходится передавать -а если грузить и запускать программу внутри и потом уже только принимать.передавать инфу скорость даже на вигглере получается очень даже.. -эту же схему использует h-jtag -кстати и для него писал все драйверы тоже- но не стал их публиковать ввиду некоторых проблем..да и мой кад немного быстрее все равно получился.
а в последнем уже ничо так - хотя думаю все же можно и быстрее на жилинке даже без rtck // хотя что бы это подтвердить или признать ошибочность догадки нужно самому попробовать нашкодить..

нашёл я нечто типа 63760377qualcomm_nand_jtag_direct_jlink.rar
в нём исходники читалки, писалки, очищалки.
но под 6280.
Добавил 6290 и флешку hynix_h8acs0pl0mcr
начало читать, писать не пробовал.
пишет raw 512 + 16
а openocd хочет 2048 + 64 т.е. на странице 4 чанка буферных.
конвернул из одного в другое. В одном байта на чанк в данных oob не совпадают.

код в openocd написан по мотивам sources_wiggler_6246_90_jtag2.rar

отличия в NAND_FLASH1_CFG1
в sources_wiggler_6246_90_jtag2 при чтении ECC_DISABLE = 0
а вот в 63760377qualcomm_nand_jtag_direct_jlink
если читам raw то ECC_DISABLE = 1 а есть не raw а только данные то ECC_DISABLE = 0

может в этом причина отличия одного байта.
байты это
524 301 377
1052 367 377
1580 234 377
2108 317 377
и есть это не FF то это копия предыдущего байта
Есть конечно вероятность и программной ошибки.
но не на 523 смещении же, это OOB данные - старший байт третьего слова.