somebody can help me？

Приступил к восстановлению убитого перепрошивкой i350.
Собрал кабель с 74HC244, H-JTAG процессор определяет.
Скачал OCD Commander, но войти в in-debug так и не получилось.
Осциллографом смотрю на сигналы и сомнения у меня появляются, по правильной ли я схеме кабель собрал.
Например, на втором пине LPT всё время низкий уровень и лишь на время команды reset - высокий.
Такое поведение больше подходит для сигнала nRST, чем на TCK.
Кстати, на одной из схем кабеля есть именно такая комбинация:
pin2 - nRST
pin3 - TMS
pin4 - TCK
pin5 - TDI
pin11 - TDO

После перепайки кабеля по этой схеме, на TDO стали появляться какие-то ответы от i350
Но OCD Commander по-прежнему не входит в in-debug.

Что ещё можно предпринять в этой ситуации?

Могу выложить осциллограммы по всем пинам для анализа.

Какое питание даешь? Землю припаял?

Питание на микросхему даю от 9 пина порта, контроллирую осциллографом.
Питание на i350 - от заряженной батарейки.
Земля припаяна.

Что интересно, H-JTAG определяет тип процессора даже если аппарат обесточен.
Похоже, TAP-контроллеру достаточно паразитного питания, что бы выдать IDCODE

Это нормально для данного проца...

С кабелем вопрос снят. Утилита JTAG Scan Chain Analyzer процессор находит на скорости 8: 4khz
В OCD Commander выставляю эту же скорость, но в IN DEBUG так и не попадаю - таймаут.
Ресет зажимал по-разному - и до старта программы, и до подачи команды Reset, и одновременно.
Результат всегда один - таймаут. На экране аппарата - bootlogo с надписью gigabyte.

Попробую понастраивать LPT порт в BIOS`е. Компьютер Hewlett Packard, настройки мне непонятны:
В разделе Onboard Devices есть строчка Parallel Port со значениями (показываю только для LPT1):
378-37F, IRQ7, DMA1
378-37F, IRQ7
378-37F

В разделе Device Options есть строчка Printer Mode со значениями Bi-Directional, EPP+ECP, Output-Only

H-JTAG работает в любой комбинации.

После замены dll`ок OCD Commander`а, удалось войти в in DEBUG.
Действия по инструкции к желаемому результату не привели - на последнем этапе выполняю step & go, загорается желтый светодиод, но на экране продолжает гореть заставка и процесс прошивки не начинается.

Перечитал много форумов в поисках подробностей первых фаз загрузки, форматов загрузчиков и т.д.
Обзавёлся IDA Pro 5.5 и начал потрошить прошивку.

У меня в аппарате первые 0x800 байт прошивки видны по адресам 00000 и 20000.
Просмотрев Идой этот кусочек, нашел такой участок:

ROM:00000680 STR LR, [SP,#-4]!
ROM:00000684 BL sub_4CC
ROM:00000688 MOV R0, 0xA0060000
ROM:00000690 BL mov_pc_r0
ROM:00000694 ; ---------------------------------------------------------------------------
ROM:00000694 MOV R0, #0
ROM:00000698 LDR LR, [SP],#4
ROM:0000069C BX LR
ROM:000006A0
ROM:000006A0 ; =============== S U B R O U T I N E =======================================
ROM:000006A0
ROM:000006A0 ; Attributes: noreturn
ROM:000006A0
ROM:000006A0 mov_pc_r0 ; CODE XREF: ROM:00000690p
ROM:000006A0 MOV PC, R0
ROM:000006A0 ; End of function mov_pc_r0
Это подтвердило правильность инструкции о необходимости точки останова в адресе 0xA0060000

В интернете удалось найти файл загрузчика для какого-то аппарата, он тоже начинался с байтов FE 03 00 EA
В прошивке я нашел несколько таких сигнатур, первая из них начинается с адреса 0x800 и до следующей такой сигнатуры занимает 0х80000 байт, что в точности соответствует выложенному файлу загрузчика для i350-го. Я даже вырезал из прошивки этот участок и побайтно сравнил с выложенным - различий нет.
Сразу же вырезал ещё два таких же участка (начинающихся с FE 03 00 EA) , идущих один за другим в прошивке до начала собственно IMGFS.
Если первый занимал 0х80000=524288b, то второй уже имеет размер 0xC0000=786432b, а третий и того больше - 0x3C0400=3932160b.
Беглый осмотр содержимого этих файлов показал, что они все имеют отношение к загрузке аппарата.
Например, в третьем, самом большом файле есть сточка в unicode "- IMAGE UTILITY -", которая и есть часть того, что мы хотим увидеть на экране аппарата.

Не долго думая, выполнил все шаги инструкции, каждый раз загружая новые файлы (сконвертировав их в HEX и задав начальную область 0xA0060000).
step & go при зажатых кнопках на этих файлах не привело к желаемому результату. Даже желтый светодиод не загорелся.

Тогда я сделал файл, содержащий все три части, но и это не помогло...

Делать нечего, взялся за Иду в отношении предполагаемого первого загрузчика. Сгенерировал листинг, поиском нашел все места, содержащие манипуляции с PC и нашел такие любопытные участки:




seg000:A0061238 MOV R1, #0x80000
seg000:A006123C MOV PC, R1

Возможно, это возврат к обычному процессу загрузки (если никакие кнопки не были зажаты).

seg000:A0072468 LDR R2, =0x80072488
seg000:A007246C BIC R2, R2, #0x20000000
seg000:A0072470 CMP R2, #0
seg000:A0072474 MCR p15, 0, R1,c1,c0
seg000:A0072478 MOV PC, R2

Этот участок кода я вообще не могу прокомментировать… Возможно, из таблицы переходов вызывается какой-то адрес, и если это не пустой адрес, то выполняется переход на него. Тогда это вызов какой-то предопределённой процедуры.

seg000:A00613A8 loc_A00613A8 ; CODE XREF: seg000:A0061398j
seg000:A00613A8 ; seg000:A0061410j ...
seg000:A00613A8 LDR R1, =0xBBBB0020
seg000:A00613AC LDR R0, =0xA0120400
seg000:A00613B0 LDR R2, [R0,#8]
seg000:A00613B4 CMP R2, #0
seg000:A00613B8 BNE loc_A00613C4
seg000:A00613BC LDR R1, =0xBBBBE021
seg000:A00613C0 B loc_A00613D4
seg000:A00613C4 loc_A00613C4 ; CODE XREF: seg000:A00613B8j
seg000:A00613C4 LDR R1, =0xBBBB002F
seg000:A00613C8 ADR LR, unk_A00613D0
seg000:A00613CC MOV PC, R2

Тут тоже сложно комментировать, но по крайней мере один вывод я сделать могу: адрес 0xA0120400 ссылается за пределы данного загрузчика, который в этом адресном пространстве занимает место с 0xA006000 по 0xA00DFFFF.

Приложенный файл 0xa00e0000_0xa011ffff.rar почти совпал с началом второго фрагмента. То есть часть областей в начале файлов совпадают, в том числе надписи в unicode вроде "Launch the Update Loader...", но большинство оставшихся частей файлов различны.

Расположение по адресу 0хА00Е0000 тоже не случайно - это сразу за первым фрагментом, занимающим область с 0xA0060000 по 0xA00DFFFF

Файл 0xa0120400_0xa0131C00.rar - самый интересный. В нём есть строчки в unicode вроде "1. LCD Test", "2. LED Test" и т.д.
В прошивке таких строк ни в unicode, ни в других кодировках, нет.

Для начала попробуйте поставить брейкпоинт на 0xA0060000 далее степом попробуйте пройтись и посмотреть куда чего прыгает .
Также найдите даташит на процессор и поглядите его -много снимится вопросов в IDA о непонятных адресах .
Также советую найти у китайцев Bsp от такого же процессора на csdn или pudn и посмотрите инициализацию проца памяти работы с переферией и тд и тп .
Многие производители мало переделывают bsp -привносять только нужные функции .
Поэтому анализ IDA становится более понятным .

27-08-2010
В OCD Commander`е научился делать ENDIAN LITTLE и WORD 0x20000 0x200. Первая команда заставляет правильно дизассемблировать, вторая – выводит пословный дамп.
Обнаружил, что участки кода с адресов 0x00000000, 0x00020000, …, 0x03FE0000 совпадают между собой. Длинна участков 0х800. Так же эти участки совпадают с PRE_HDR, он же XLDR, с небольшими отличиями – в нескольких неиспользуемых константах есть отличия. В коде и используемых данных отличий нет.
Пытался трассировать этот участок кода. С адреса 0х00000000 трассировка зацикливается на адресе 20. С адреса 0х00020000 трассируется нормально.
Обнаружил любопытный участок кода:

Из адреса 0х1000 извлекаются полуслова и записываются по адресу 0хА0060000. Далее данные продолжают извлекаться из адреса 0х1000 и записываются в следующие адреса. Скорее всего на адрес 0х1000 отображена область Flash-памяти и при каждом обращении к ней, возвращается полуслово (16 бит) и адрес во Flash увеличивается.
Смысл этого участка кода – загрузить очередной Loader и затем передать на него управление.

Выполнил XLDR (запустил с адреса 0х20000, остановил на адресе 0хА0060000) и посмотрел, что же там загрузилось.
Оказалось, все 512 килобайт с адреса 0хА0060000 полностью совпадают с выложенным здесь загрузчиком.
Продолжаю смотреть, что делается при выполнении этого загрузчика, но это утомительно - кода много, непонятного много, что искать не понятно.
Попробую серию опытов: буду ставить брейки на угад на разные подпрограммы (которые определила IDA) и пытаться выполнять загрузчик с зажатыми кнопками и с отпущенными.
Может быть удастся найти ту ветку алгоритма, которая отвечает за дальнейшую загрузку.
Я думаю, что имеющийся загрузчик инициализирует всё оборудование, обнаруживает зажатые кнопки и подгружает следующий загрузчик.
А вот следующий загрузчик уже сбойный и на нём всё застревает.
К сожалению, в листинке ИДЫ я не нашел таких явных переходов, как в XLDR, искать придётся наугад.
Так же я не нашел кода на подобие приведённого в предыдущем посте. Скорее всего данные из Flash извлекаются каким-нибудь другим способом.

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

Также выкладываю bsp от аналогичного процессора .
Открывай папку bootloader и файл main.c и тд и увидиш кучу совпадений .
Вот смотри
XSBase2700G\Src\Common\Startup\startup.s
начало
ALIGN
PreInit

; Put the CPU in Supervisor mode (SVC) and disable IRQ and FIQ interrupts.
;
ldr r0, =(Mode_SVC (IMG:style_emoticons/default/ohmy.gif) R: NoIntsMask)
msr cpsr_c, r0

; Disable the MMU, caches, and write-buffer and flush.
;
ldr r0, =0x2043 ; enable access to all coprocessors
mcr p15, 0, r0, c15, c1, 0 ;
CPWAIT r0 ;

ldr r0, =0x00000078 ; get a zero to turn things off (must write bits[6:3] as 1s)
mcr p15, 0, r0, c1, c0, 0 ; turn off MMU, I&D caches, and write buffer
CPWAIT r0 ;

;ldr r0, =0x00000000 ; get a zero to turn things off
;mcr p15, 0, r0, c8, c7, 0 ; flush (invalidate) I/D TLBs
;mcr p15, 0, r0, c7, c7, 0 ; flush (invalidate) I/D caches
;mcr p15, 0, r0, c7, c10, 4 ; drain the write buffer
;nop ;
;nop ;
;nop ;


Теперь тоже самое в IDA для i300

EXPORT start
.text:80061000 start
.text:80061000 MOV R11, PC
.text:80061004 MOV R0, #0xD3
.text:80061008 MSR CPSR_c, R0
.text:8006100C LDR R0, =0x2043
.text:80061010 MCR p15, 0, R0,c15,c1
.text:80061014 MRC p15, 0, R0,c2,c0
.text:80061018 NOP
.text:8006101C ADR PC, loc_80061020
.text:80061020
.text:80061020 loc_80061020 ; DATA XREF: start+1Co
.text:80061020 MOV R0, #0x78
.text:80061024 MCR p15, 0, R0,c1,c0
.text:80061028 MRC p15, 0, R0,c2,c0
.text:8006102C NOP
.text:80061030 ADR PC, loc_80061034
.text:80061034
.text:80061034 loc_80061034 ; DATA XREF: start+30o
.text:80061034 MOV R0, #0
.text:80061038 MCR p15, 0, R0,c8,c7
.text:8006103C MCR p15, 0, R0,c7,c7
.text:80061040 MCR p15, 0, R0,c7,c10, 4
.text:80061044 NOP
.text:80061048 NOP
.text:8006104C NOP


Ну как ничего не подсказывает ?
Многие функции можно найти

или вот листинг


а вот кусок в ida

С EBOOT вроде разобрался:

Судя по тому, что у меня туда грузится и запускается, IPL тоже живой. По моему мнению, именно IPL рисует bootlogo и грузит ULDR.
В моём случае скорее всего именно ULDR сбойный.
Беглый осмотр IPL на предмет запуска ULDR показал следующее:

Здесь 0xA0000000 - адрес загрузки, 0x3C0000 - размер ULDR, в точности соответствует размеру файла - 3 932 160 байт.

Продолжаю исследование...

ULDR не то что тебе нужно -это режим загрузчика при обновлении WM (есть такой режим в WM позволяющий обновлять ROM при помощи пакетов ).
Про UDLR есть кое какиe данные на xda-developers а также на msdn .


В данном случае тебе нужно понять что есть три вида загрузчиков .Тебе нужно запустить девайс в режим прошивки а не запуска системы.
Так называемы x-loader -нужный для инициализации железа и тд и в зависимости от комбинации кнопок , потом два загрузчика .
IPL (если не ошибаюсь )грузит девайс в режим бута (прошивки ).
А MSSPL это загрузчки необходим для запуска самой WM -но она должна быть рабочая и находится во flash .
Но опять же вариации могут быть разные .
например первым (всегда грузится x-loader ) -если в нем нет проверки на нажатие кнопок -то далее может грузится IPL и в нем уже идет проверка нажатия кнопок и зпгрузка MSSPL или тестовой проги .

Девайс восстановлен!
В листинге из IPL буквально одной строчки не хватило, что бы понять, что адрес загрузки ULDR не 0xA0000000, а 0xA0180000
Посследовательность восстановления была такая:
pc 20000
hbr 0x0A0180000
- зажимаю красную и зелёную, держу, выполняю go
- после останова (загорелся желтый светодиод) гружу ULDR, выполняю step, опять зажимаю красную и зелёную кнопки, опять go - и запустилась IMAGE UTILITY, пошел процесс прошивки.

А возможно ли выложить сам файл ULDR? или он аналогичный 350-му? спасибо за помощь в восстановлении

Выполнял данную последовательность действий с данным телефоном - так же висит заставка гигабайта и никаких дальнейших действий не происходит

Загрузчики i350 - 23 Мб.

Содержимое архива:

модуль - начало - окончание - размер hex - размер decimal
xldrh3.pdb 0x00020000 0x000207FF 0x800 2 048
eboot.pdb 0xA0060000 0xA00DFFFF 0x80000 524 288
ipl.pdb 0xA00E0000 0xA019FFFF 0x80000 524 288
ULDR 0xA0000000 0xA03BFFFF 0x3C0000 3 932 160

XLDR:
00000000-000007FF.bin
00000000-000007FF.idb
00000000-000007FF.lst

XLDR:
pre_hdr.bin
pre_hdr.idb

EBOOT (pre1 - в физическом адресном пространстве, 0xA0060000; pre1x8 - в виртуальном адресном пространстве 0x80060000):
pre1.bin
pre1x8.bin
pre1.hex
pre1.idb
pre1x8.idb
pre1.lst
pre1x8.lst

IPL:
pre2.bin
pre2.idb
pre2.lst

ULDR:
pre3.bin
pre3.hex
pre3.idb
pre3.lst

Если есть вопросы, попытаюсь ответить, ICQ # 165781121

Восстановление i300

Скачал прошивку EJ1RUS20230.nb0
Выполнил команду osnbtool.exe -sp EJ1RUS20230.nb0
В результате получил файл EJ1RUS20230.nb0.PRE - в нём хранятся все загрузчики:
xldr.pdb - занимает 2 килобайта (0х800)
eboot.pdb - начинается с сигнатуры FE 03 00 EA, до следующей такой сигнатуры, 512 килобайт
ipl.pdb - начинается с сигнатуры FE 03 00 EA, до следующей такой сигнатуры, 768 килобайт, хотя последние 256 килобайт не от него, реально он занимает 512 килобайт
uldr.pdb - начинается с сигнатуры FE 03 00 EA, до конца файла

Дизассемблировал ИДой все загрузчики:
Сначала xldr, он не большой, прошелся по коду, нашел место:

ROM:00000614 LDR PC, =0xA0060000

Значит, следующий загрузчик, eboot запускается с этого адреса.
По опыту ковыряния аналогичной прошивки от i350 знаю, что основная работа в eboot ведётся в виртуальном адресном пространстве, поэтому в ИДу гружу eboot со смещения 80060000 - тогда ИДА правильно определяет строки и нужный нам код.
Нахожу строку "Read IPL and Jump to it!!", нахожу место, где эта строка используется:

ROM:8006B298 LDR R0, =aReadIplAndJump ; "Read IPL and Jump to it!!\r\n"
ROM:8006B29C BL sub_800750F8
ROM:8006B2A0 BL sub_800A6600
ROM:8006B2A4 MOV R0, 0xA00E0000
ROM:8006B2AC BL sub_80071F64

Значит, следующий загрузчик, IPL грузится с адреса 0xA00E0000
Гружу в ИДу ipl со смещения 0xA00E0000, дизассемблирую, ищу строки ULDR, нахожу место, где эти строки используются:

ROM:A00E58E0 LDR R0, =aLoadUldrImageF ; "\r\nLoad ULDR Image from flash memory\r\n"
ROM:A00E58E4 MOV R5, 0xFFFFFFFF
ROM:A00E58E8 BL sub_A00E6240
ROM:A00E58EC LDR R1, =aUldr ; "ULDR"
ROM:A00E58F0 MOV R6, #0xA0000000
ROM:A00E58F4 MOV R3, #1
ROM:A00E58F8 MOV R2, #0x3C0000
ROM:A00E58FC MOV R0, #0x20
ROM:A00E5900 ORR R6, R6, #0x180000
ROM:A00E5904 BL sub_A00EAB4C

Здесь небольшая тонкость - тут надо учесть две команды:

ROM:A00E58F0 MOV R6, #0xA0000000
ROM:A00E5900 ORR R6, R6, #0x180000

Тогда получим правильный адрес загрузки ULDR - 0xA0180000

На этом анализ заканчивается и начинается подготовительная работа.
Файлы загрузчиков уже есть, их нужно сконвертировать в формат HEX для указания адреса загрузки.
Если есть HJTAG, там есть соответствующая утилита. У меня уже нет, всё в архиве, но, думаю, это будет не сложно.

Ну и собственно восстановление:
Переход на начало xldr:
ocd> pc 0x20000
Установка точки останова на начало eboot:
ocd> hbr 0x0A0060000
Запуск xldr:
ocd> go
Загрузка eboot:
ocd> dowload eboot.hex
Установка точки останова на начало ipl:
ocd> hbr 0x0A00E0000
Запуск eboot (кнопки должны быть зажаты):
ocd> step
ocd> go
Загрузка ipl:
ocd> dowload ipl.hex
Установка точки останова на начало uldr:
ocd> hbr 0x0A0180000
Запуск ipl (кнопки должны быть зажаты):
ocd> step
ocd> go
В результате должно появиться изображение logo
Загрузка uldr:
ocd> dowload uldr.hex
Запуск uldr (кнопки должны быть зажаты):
ocd> step
ocd> go
Должна запуститься - IMAGE UTILITY -

После запуска каждого загрузчика необходимо какое-то время подождать (около 10 секунд за исключением uldr и запущенной IMAGE UTILITY)
При загрузке файлов нужно следить, что бы ocd не выдавал ошибок.
После успешного запуска и выполнения загрузчиков ocd переходит в режим inDEBUG на заданном адресе.

Здесь находится архив со всеми рабочими материалами.