РЕВЕРСИНГ Д500

Версия для печати

Список форумов SAMSUNG-mobile.ru / Программирование для Samsung и реверсинг прошивок / РЕВЕРСИНГ Д500
На страницу Пред.  1, 2, 3, 4  След.
Показать: « Предыдущая тема :: Следующая тема »



speeder
Диспетчер форума

Администратор сайта


Рейтинг: 81% (125 / 30)



В форуме с: 05.2004
Сообщения: 6526
Откуда: Надым
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

SiNoptik писал(а):
Модераторы! Можно всё вернуть обратно? Даже личные сообщения все пропали! Там столько инфы было важной...

Вернуть ничего нельзя. Админ восстановил форум из дампа от 13-го октября, поэтому нет ниччего. Зато форум работает нормально, без тех косяков, которые преследовали нас всю ту неделю.


20.10.2005 08:49

OfflineПрофайл | Отправить л/с | Отправить e-mail


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

speeder, ну тогда давайте снова тему прилепим! Very Happy
И начнем еще раз... В личное тоже ничего пришло. Хотя письмо с уведомлением получил...
AlexeyK, еще раз спасибо огромное! Столько информации ценной на меня обрушил... Долго теперь буду переваривать-разбираться... Только большая часть её пропала вместе с "личным". Хотя самое важное я сохранил отдельно. Решил попробовать сначала посмотреть, то что ты мне показал, для X100. Скачал WK3 и BinEdit.
Цитата:
Грузим прошивку в BinEdit и на вкладке Меню запускаем сканирование меню телефона. Если кто не знает, то это вторая кнопка на вкладке
- это из твоего руководства... А с какого адреса запускать?
А чем команда BLX такая особенная? В Atmel Corporation ARM7TDMITM (Thumb®) Datasheet её описания нету. Калькулятор переходов её не считает...
Хорошая штука Калькулятор переходов в BinEdit'е. А есть в природе конструктор других команд? Вот вводишь MOV R0,#0, а он тебе выдаёт 00 20... Вроде такого простого компилятора... Кто чем пользуется в таких случаях? Неужели все сначала на C++, а потом под ARM компилят? Для "точечного" "исправления" прошивки очень пригодился бы! Может самому заняться этим... Улыбка
Еще один момент: как определить место в прошивке, куда можно сравнительно безболезненно добавить свой код? Для X100 по этому поводу написано много, но у D500 формат MAP-файла несколько другой... Есть ли какие-то общие признаки таких мест? Например наличие сравнительно большого отрезка 00 или FF в прошивке является гарантией того, что это место "свободно"? У кого какие приёмы? Поделитесь!


20.10.2005 09:09

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


AlexeyK

Признанный телефонист


Рейтинг: 93% (108 / 8)



В форуме с: 07.2004
Сообщения: 517
Откуда: г. Александров
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

SiNoptik, У тебя скорее всего старая версия программы.
BLX - переход с изменением режима процессора на противоположный, TRUMB -> ARM и наоборот. Принажлежит набору команд ARM9T и ARM10T, в калькуляторе пока не обрабатывается, но будет. Может будет и простенький компилятор.
Описание можно найти через Yandex по ARM10T. http://ianzag.megasignal.com/ftp/pub/doc/hdw/vendors/ARM/TPCD0603/cores /DVI0015A_ARM10200_PO.pdf

Для выбора места под патчи можно использовать несколько выриантов
1. Использовать картинки которые самим телефоном практически не используются. Так делает большинство народу.
2. Использовать место в конце прошивки до области Flash. Это место сейчас использует только ResMan для добавления ресурсов и чтоб не нарушить его работу туда никто не лезет.
3. Использовать место в самом коде, получаемое за счет оптимизации оригинального кода. Компилятор использовался так себе, куча ляпов. В прошивках также много кода посвящено функциям трассировки, которые можно блокировать и использовать их место. Также есть функции которые не используются в данной модели телефона, например, выдод на второй дисплей в X100 Улыбка
Этот вариант пока редко используется.
4. Произвести реструкторизацию ресурсов для выделения больших блоков. Это извращенческий вариант и теоретически может вызвать кучу глюков, но именно этим я сейчас и занимаюсь Улыбка

PS. В D500, E730 и других новых моделях принцип формирования меню при помощи МСС изменился и сканирование меню в binedit пока для них не работает.

_________________
Patch & Hex редактор, ARM Debuger & Compiler: http://forum.samsung-mobile.ru/viewtopic.php?t=22518


20.10.2005 20:25

OfflineПрофайл | Отправить л/с | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

Цитата:
BLX - переход с изменением режима процессора на противоположный, TRUMB -> ARM и наоборот.
- с самого начала так и подумал Улыбка Но всё равно, спасибо, разобрался с этим вроде...
Действительно, неудобно, что в D500 байты наоборот идут... Постоянно путаюсь! Есть еще вопрос, но он как-то больше уже непосредственно по ARM-ассемблеру. Но для этого форума всё равно будет полезно, т.к. ничего подобного здесь не нашел... Есть такая команда LDR:
00486660 13 49 LDR R1, =0x109A564E
Загружает в регистр адрес. Это так отображает IDA. На самом деле чуть далее идет:
004866B0 4E 56 9A 10 dword_4866B0 DCD 0x109A564E
Т.е. на самом деле в команде LDR закодированно смещение до 004866B0. Это я думаю понятно всем. Улыбка А от ЧЕГО это смещение? Какая то база должна быть... От начала блока? От начала сегмента? Как его(начало смещения) узнать? Оно ведь не в регистре на этапе выполнения хранится? В документации написано: "0-7 bits:PC-relative offset". Т.е 13 - это смещение... 4866B0-13=48669d. Это что за адрес? В общем, как считать!?
Просто неудобно с этими перевернутыми байтами разбираться... Улыбка


24.10.2005 11:36

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


AlexeyK

Признанный телефонист


Рейтинг: 93% (108 / 8)



В форуме с: 07.2004
Сообщения: 517
Откуда: г. Александров
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

SiNoptik, всё очень просто от содержимого регистра R15

LDR R1,[PC,0xXX] по другому, а если ещё точнее, то смещение равно: второй байт *4 +4 + (PC and 0xFFFFFFFC)

0x4866B0=13*4 + 4 + 0x486660 and 0xFFFFFFFC

_________________
Patch & Hex редактор, ARM Debuger & Compiler: http://forum.samsung-mobile.ru/viewtopic.php?t=22518
Редакт. AlexeyK
24.10.2005 12:06


24.10.2005 11:58

OfflineПрофайл | Отправить л/с | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

AlexeyK писал(а):
SiNoptik, всё очень просто от содержимого регистра R15

LDR R1,[PC,0xXX] по другому, а если ещё точнее, то смещение равно: второй байт *4 +4 + (PC and 0xFFFFFFFC)

Так а как узнать значение в PC? Улыбка Я просто глубоко в этом не разбирался... Это же регистр. Откуда IDA в статическом состоянии знает его значение на этапе выполнения? стоп... понял... PC- это адрес следующей команды? я наверное просто забываю на 4 умножать... Улыбка Щас посмотрю, спасибо... Уже 4 листа исписал этими нулями-единицами....


24.10.2005 12:05

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

AlexeyK, действительно! А я уже себе всю голову сломал... Улыбка Да... "Ручной" компилятор просто необходим! Надо придумывать интерфейс и начинать делать... Кстати, AlexeyK, после непродолжительного использования BinEdit'a родилось такое пожелание по интерфейсу: в окне HEX-редактора было бы неплохо где-нибудь в строке состояния отображать адрес, на котором установлен курсор(как это сделано в WinHex). А то приходится каждый раз отсчитывать вручную от начала строки... Хотя может это уже реализовано... У меня версия 2005.2.20.
Редакт. SiNoptik
02.11.2005 09:02


24.10.2005 12:23

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

AlexeyK, не мог бы рассказать вкратце, как определить кто и что возвращает? Вот есть у меня вот такой код:
    ROM:0048635E E0 88 LDRH R0, [R4,#6]

    ROM:00486360 01 28 CMP R0, #1

    ROM:00486362 01 D1 BNE loc_486368

    ROM:00486364 63 F7 70 EB BLX goto_set2_7Get_Greetmsg

    ROM:00486368 loc_486368
    ROM:00486368 CF 48 LDR R0, 0xF0C

    ROM:0048636A 59 F7 9A E9 BLX goto_hfd2_30ReadBlockNameInRamImage3

    ROM:0048636E 04 1C ADD R4, R0, #0

    ROM:00486370 CB 48 LDR R0, =0x18A8BE89 ; gv_eep_backlight_color

    ROM:00486372 20 23 MOV R3, #32

    ROM:00486374 22 1C ADD R2, R4, #0

    ROM:00486376 60 21 MOV R1, #96

    ROM:00486378 93 30 ADD R0, #147

    ROM:0048637A 63 F7 6C EB BLX goto_UTF8toUCS2byLen

    ROM:0048637E 00 04 LSL R0, R0, #16

    ROM:00486380 00 0C LSR R0, R0, #16

    ROM:00486382 00 23 MOV R3, #0

    ROM:00486384 40 00 LSL R0, R0, #1

    ROM:00486386 23 52 STRH R3, [R4,R0]

    ROM:00486388 21 1C ADD R1, R4, #0

    ROM:0048638A C7 48 LDR R0, 0xF0C

    ROM:0048638C 59 F7 9A E9 BLX goto_hfd2_31SaveBlockNameInRamImage2

    ROM:00486390 62 E4 B loc_485C58


Это процедура записи Greeting Message. Я так понял, что сначала это сообщение берётся из редактора (set2_7Get_Greetmsg). Потом из ПЗУ считывается блок 0xF0C(hfd2_30ReadBlockNameInRamImage3). Потом не совсем понятно что, но что-то из этого(либо сохраняемое сообщение, либо считанное из ПЗУ) преобразовывается из юникода в UCS2. Улыбка А затем происходит сброс всего блока(0xF0C) в ПЗУ(hfd2_31SaveBlockNameInRamImage2). Что происходит между этими вызовами я еще не совсем понимаю... Но тем не менее. ReadBlock и SaveBlock возвращают и получают в R0 GreetingMessage? Я так понял, что это стандартный способ. А где обычно может храниться длина этой строки? Наверное тоже в каком-то регистре? И вообще как узнать, для чего в данной ситуации используются регистры? Их здесь R0,R1,R2,R3,R4. Какой подход к этому?


25.10.2005 13:44

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


AlexeyK

Признанный телефонист


Рейтинг: 93% (108 / 8)



В форуме с: 07.2004
Сообщения: 517
Откуда: г. Александров
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

всё вроде верно.
1. если значение байта по адресу R4+6 равно 1, то выполняется goto_set2_7Get_Greetmsg (видимо заполнение буфера по адресу 0x18A8BE89+147)
2. читается блок с идентификатором 0xF0C (функция в R0 возвращает адрес в памяти, куда был считан блок, его значение сохраняется в R4)
3. строка с адреса в R0=0x18A8BE89+147 в формате UTF8 (это не Unicode, размер кода символов 8 или 16 бит) преобразуется в строку UCS2 (размер кода символа 7 бит) по адресу R2=R4 (начало считанного блока) R1=96 и R3=32 - видимо длины буферов для строк соответственно. При помощи функции goto_UTF8toUCS2byLen , которая в R0 возвращает длину получившейся строки
4. Затем по завершению строки принудительно выставляется завершающий символ 0x0
5. функция goto_hfd2_31SaveBlockNameInRamImage2 сохраняет в блок с идентивикатором 0xF0C с адреса в R1=R4.

вот вродебы и всё

_________________
Patch & Hex редактор, ARM Debuger & Compiler: http://forum.samsung-mobile.ru/viewtopic.php?t=22518


26.10.2005 17:11

OfflineПрофайл | Отправить л/с | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

AlexeyK писал(а):

1. если значение байта по адресу R4+6 равно 1, то выполняется goto_set2_7Get_Greetmsg (видимо заполнение буфера по адресу 0x18A8BE89+147)

То ли это компилятор такой "умный", то ли кто ещё... По адресу 0x18A8BE89 находится gv_eep_backlight_color размером в один байт и которая, вероятно не имеет никакого отношения к рассматриваемому процессу. Смещение на 147 ведет куда-то в туманные дали... Для чего это сделано именно так, а не по непосредственно по адресу 0x18A8BE89+147 непонятно... видимо компилятор "шалит"Улыбка

Цитата:
3. строка с адреса в R0=0x18A8BE89+147 в формате UTF8 (это не Unicode, размер кода символов 8 или 16 бит) преобразуется в строку UCS2 (размер кода символа 7 бит) по адресу R2=R4 (начало считанного блока) R1=96 и R3=32 - видимо длины буферов для строк соответственно. При помощи функции goto_UTF8toUCS2byLen , которая в R0 возвращает длину получившейся строки

Действительно... Улыбка это не совсем юникод... Просто все ссылки, выводимые яндексом на запрос "UTF8" дают что-то типа encode UTF8 бла-бла... А я "разглядел" в encode юникод... Хотя символы и занимают по два байта...
И кстати!AlexeyK, я как-то пропустил твое сообщение:
Цитата:
Скорее всего действительно макросы. от себя могу добавить, что большинство из них только заполняют разные структуры данных и запускают системные события. МСС оканчивающиеся на _S - это обработчики системных событий. Например в MCC_EDIT_START_S происходит обработка следующих событий
7019 - APPI_EDP_INIT_EDITOR_CNF (конфигурирование поля ввода)
701A - APPI_EDP_INIT_EDITOR_ERR (закрытие всех окон редактирования)
7053 - APPI_EDP_KEY_INFO_IND (ввод в буфер ввода EditString цифровых символов 1-9, 0, *, # по кодам 1-12 соответственно из gv_DigitValue при gv_KeyInfo=3)

что есть gv_KeyInfo=3? Уж не тот ли "способ ввода" о котором я спрашивал? Цифровой ввод? Улыбка


27.10.2005 14:18

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

А кто что знает о функции __rt_memclr? Вроде бы память очищает(судя по названию). Работает в ARM режиме. Вызывается при любых операциях, связанных со считыванием данных из памяти(не только из ПЗУ) и с записью в память... Чем вызвана такая необходимость? Кто в особенностях ARM процессоров разбирается? Может Hexx подскажет? Улыбка


31.10.2005 14:04

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


AlexeyK

Признанный телефонист


Рейтинг: 93% (108 / 8)



В форуме с: 07.2004
Сообщения: 517
Откуда: г. Александров
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

SiNoptik, это не особенность ARM процессора, а особенность С компилятора. Он так подготавливает буферы для данных, грубо говоря гарантия от мусора.
SiNoptik писал(а):
что есть gv_KeyInfo=3? Уж не тот ли "способ ввода" о котором я спрашивал? Цифровой ввод?

насколько я понял, то это ввод цифр при наборе номера.

_________________
Patch & Hex редактор, ARM Debuger & Compiler: http://forum.samsung-mobile.ru/viewtopic.php?t=22518


02.11.2005 01:52

OfflineПрофайл | Отправить л/с | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

Небольшой вопросик непосредственно по ARM-ассемблеру(но в контексте работы с Самсунгом) Улыбка Если процессор находится в режиме THUMB, значит он выполняет двухбайтные команды. Но в любой момент может встретиться команда BLX или BX. Они, как я понял производит переключение с THUMB режима в ARM. А команда BL - она тоже выполняют такое переключение(я говорю про их 4х байтные варианты)? И, собственно, может кто подскажет как эти команды составляются? Спасибо AlexeyK, научился я переделывать команды BL, составленные калькулятором переходов в BinEdit, в команды BLX. А вот составлять их самому... Никак этого не могу понять! Есть в документации схемы, но они совершенно не подходят... В чем здесь секрет? Вот например:
в документации написано
XXXX YYY L RRRRRRRRRRRRRRRRRRRRRRRR

X-condition field
Y-постоянное значение 101
L-link bit (по сути, определяет какая это команда - B или BL)
R-offset

имеем в жизни:
486396 03 F0 1B F8 BL 4893D0
После "разворота" байтов имеем F8 1B F0 03
смещение: ((4893D0-486396)-4)/4)= C 0D(ну или C 0E)
двоичное представление:
11111000 00011011 11110000 00000011
Ну и как тут смотреть? где постоянное значение 101?
Или я снова перепутал THUMB и ARM команды? А есть ли в THUM режиме переходы дальше 2048 байт? И какую команду лучше использовать, при переносе отрывка стандартной функции в другое место(что бы добавить туда что-то своё)? Или в таких случаях лучше всего делать такой вынос в виде функции? Тогда чем лучше делать вызов этой функции: BL или BLX? В общем, поделитесь опытом! Улыбка


04.11.2005 09:43

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


SiNoptik

Участник форума


Рейтинг: 100% (1 / 0)


В форуме с: 10.2005
Сообщения: 35
Откуда: Tomsk
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

AlexeyK, а ты сам хоть раз пробовал читать данные из ПЗУ? Ну т.е. через функцию set1_0read_eeprom или напрямую через hfd2_30_ReadBlockInRamImage? Допустим я нашел то место в прошивке, которое мне нужно модифицировать и переношу в другое место несколько операторов
Например:
Код:
000E3A84    10 B5                       PUSH    {R4,LR}         
000E3A86    08 4C                       LDR     R4, =0x18A8BF1C ; gv_GreetMsg
000E3A88    61 21                       MOV     R1, #97
000E3A8A    20 1C                       ADD     R0, R4, #0
000E3A8C    5F F7 70 EF                 BLX     __rt_memclr
000E3A90    01 20                       MOV     R0, #1
000E3A92    65 F7 1E EE                 BLX     goto_lk3_1SetEditBufferPosition1
000E3A96    65 F7 22 EE                 BLX     goto_i_lk3_3ReadEditBuffer
000E3A9A    01 1C                       ADD     R1, R0, #0     
000E3A9C    60 22                       MOV     R2, #96       
000E3A9E    20 1C                       ADD     R0, R4, #0   
000E3AA0    64 F7 88 EB                 BLX     goto_strncpy1
000E3AA4    10 BD                       POP     {R4,PC}

Заменяю на
Код:
00E3A84     10 B5                       PUSH    {R4,LR}
000E3A86    08 4C                       LDR     R4, =0x18A8BF1C
000E3A88    61 21                       MOV     R1, #0x61
000E3A8A    20 1C                       ADD     R0, R4, #0
000E3A8C    5F F7 70 EF                 BLX     __rt_memclr
000E3A90    01 20                       MOV     R0, #1
000E3A92    65 F7 1E EE                 BLX     goto_lk3_1SetEditBufferPosition1
000E3A96    65 F7 22 EE                 BLX     goto_i_lk3_3ReadEditBuffer
000E3A9A    25 F0 89 FA                 BL      0x108FB0
000E3A9E    C0 46                       NOP
000E3AA0    C0 46                       NOP
000E3AA2    C0 46                       NOP
000E3AA4    10 BD                       POP     {R4,PC}

Т.е делаю перход на адрес 108fb0
А там:
Код:
00108FB0    FF B4                       PUSH    {R0-R7}
00108FB2    03 20                       MOV     R0, #3
00108FB4    12 4E                       LDR     R6, =0xF0C
00108FB6    07 1C                       ADD     R7, R0, #0
00108FB8    30 1C                       ADD     R0, R6, #0
00108FBA    35 1C                       ADD     R5, R6, #0
00108FBC    0A 3D                       SUB     R5, #0xA
00108FBE    56 30                       ADD     R0, #0x56
00108FC0    31 1F                       SUB     R1, R6, #4
00108FC2    72 1C                       ADD     R2, R6, #1
00108FC4    0F 4C                       LDR     R4, =0x18A8BFB8
00108FC6    FF 20                       MOV     R0, #0xFF
00108FC8    01 30                       ADD     R0, #1
00108FCA    D6 F2 69 EB                 BLX    goto_hfd2_30ReadBlockNameInRamImage2
00108FCE    04 1C                       ADD     R4, R0, #0
00108FD0    FF BC                       POP     {R0-R7}
00108FD2    01 1C                       ADD     R1, R0, #0
00108FD4    60 22                       MOV     R2, #0x60
00108FD6    20 1C                       ADD     R0, R4, #0
00108FD8    D5 F2 C6 E8                 BLX    goto_strncpy1
00108FDC    DA F7 62 FD                 BL      0xE3AA4

Т.е. ложу все регистры в стэк. Потом пытаюсь вызвать функцию hfd2_30ReadBlockNameInRamImage2 также как это делает функция set1_0read_eeprom(в том месте, про которое мы говорили(для WK3: bf55e - само чтение, для D500 - немного по другому, но это не суть ). Суть в том, что я делаю всё с точностью до оператора. И вроде бы перед этим вызовом все регистры подготовлены также, как и в оригинале.
После этого вызова я беру все регистры из стека продолжаю прерваные действия. А потом делаю переход назад, туда от куда я сюда залез. Вопрос: по идее вызов hfd2_30ReadBlockNameInRamImage2 не должен никак проявляться, так как я после него восстанавливаю все регистры. Но с таким кодом - телефон виснет. А если убрать вызов hfd2_30ReadBlockNameInRamImage2(только его) - всё работает также, как и изначально. В чем может быть проблема? При любой попытке самому вызвать hfd2_30ReadBlockNameInRamImage2 происходит зависание. Даже если я просто беру и переношу этот вызов в бругое место!
Например:
Код:
00486368 CF 48                       LDR     R0, =byte_F0C   
0048636A 59 F7 9A E9                 BLX     goto_hfd2_30ReadBlockNameInRamImage3
0048636E 04 1C                       ADD     R4, R0, #0     
00486370 CB 48                       LDR     R0, =0x18A8BE89
00486372 20 23                       MOV     R3, #32         
00486374 22 1C                       ADD     R2, R4, #0     
00486376 60 21                       MOV     R1, #96         
00486378 93 30                       ADD     R0, #147       

беру и делаю так(примерно):
Код:
00486368 CF 48                       LDR     R0, =byte_F0C   
0048636A                             BL      XXXXXXXX
0048636E 04 1C                       ADD     R4, R0, #0     
00486370 CB 48                       LDR     R0, =0x18A8BE89
00486372 20 23                       MOV     R3, #32         
00486374 22 1C                       ADD     R2, R4, #0     
00486376 60 21                       MOV     R1, #96         
00486378 93 30                       ADD     R0, #147       


Код:
XXXXXXXX                              BLX goto_hfd2_30ReadBlockNameInRamImage3
XXXXXXXX+4                            BL 48636E

Т.е никаких регистров кроме LR не меняется, но телефон снова виснет! Какая здесь проблема? Можно ли, зная нужный набор параметров, в любой момент взять и вызвать эту функцию? Или для этого нужны какие-то сильно определенные условия? Я может просто чего-то не учитываю? Подскажите кто понял то что я здесь написал! Улыбка


04.11.2005 15:15

OfflineПрофайл | Отправить л/с | Отправить e-mail | ICQ


AlexeyK

Признанный телефонист


Рейтинг: 93% (108 / 8)



В форуме с: 07.2004
Сообщения: 517
Откуда: г. Александров
Re: Вопрос ветеранам прошивок! Цитировать | Ответить

SiNoptik писал(а):
в документации написано
XXXX YYY L RRRRRRRRRRRRRRRRRRRRRRRR

Да перепулал. Для BL THUMB
1111 H RRRRRRRRRRRRRRR

This format specifies a long branch with link.
The assembler splits the 23-bit two’s complement half-word offset specifed by the
label into two 11-bit halves, ignoring bit 0 (which must be 0), and creates two THUMB
instructions.
Instruction 1 (H = 0)
In the first instruction the Offset field contains the upper 11 bits of the target address.
This is shifted left by 12 bits and added to the current PC address. The resulting
address is placed in LR.
Instruction 2 (H =1)
In the second instruction the Offset field contains an 11-bit representation lower half of
the target address. This is shifted left by 1 bit and added to LR. LR, which now contains
the full 23-bit address, is placed in PC, the address of the instruction following the BL
is placed in LR and bit 0 of LR is set.
The branch offset must take account of the prefetch operation, which causes the PC
to be 1 word (4 bytes) ahead of the current instruction

H THUMB Action
0 BL label LR := PC + OffsetHigh << 12
1 temp := next instruction address
PC := LR + OffsetLow << 1
LR := temp | 1

Это из документации

попробуй использовать вместо BL команду B или BX
Для THUMB режима действие B ограничено (-1024 - +1024)
Чаще всего для дальних переходов используется вариант с BX

Ldr Rx, =Adres+1
Bx Rx
.word Adres+1

а для функций вызываемых через BL

Push {R0,R1}
Ldr R0, =Adres+1
str R0, [SP,#4]
POP {R0,PC}
.word Adres+1

Сам я данные из EEPROM не использовал, но в патче мелодии на абонентов VadikS-а функция hfd2_30ReadBlockNameInRamImage часто используется для работы с параметрами группы абонентов и вроде работает

_________________
Patch & Hex редактор, ARM Debuger & Compiler: http://forum.samsung-mobile.ru/viewtopic.php?t=22518


04.11.2005 21:57

OfflineПрофайл | Отправить л/с | ICQ

Список форумов SAMSUNG-mobile.ru / Программирование для Samsung и реверсинг прошивок
На страницу Пред.  1, 2, 3, 4  След.

Переход в другой форум
Страница 2 из 4
Форум Samung-mobile.ru — сотовые телефоны Samsung