А каковы шансы через этот EOL грузить родную/пропатченную прошивку? С таким количеством оперативки там наверняка XIP из NOR.
Вообще интересный вариант. Вывод *DOP бы прикрутить.
// Личку на osm.org посмотри.
А каковы шансы через этот EOL грузить родную/пропатченную прошивку? С таким количеством оперативки там наверняка XIP из NOR.
Вообще интересный вариант. Вывод *DOP бы прикрутить.
// Личку на osm.org посмотри.
Цифры только по маркировке микросхем.
Надо разобраться, где в адресном пространстве замаплен интеловский NOR, где SRAM, как сконфигурирован MMU с
виртуальной памятью и что ожидает/думает прошивка о своем местонахождении и нахождении SRAM.
В крайнем случае потеснить basemap, на него вроде как 8MB приходится, но это можно будет легко проверить
слив NOR полностью после старта EOL.
В крайнем случае новую прошивку придется прошить.
Все драйвера вроде как есть: lcd, usb, keypad, nor, 2 RS232 порта (sirf3 и гарминовский коннектор)
Ответил. josm отучил туда смотреть.
Оказывается, те альтернативные прошивки существуют только для нувиков. Владельцы всех прочих девайсов негодуют.
нувики и так под линуксом работают, там все гораздо проще.
А вот даже на 60/76Cx (не говоря уже о более примитивных девайсах) нужен моск
Я нашел в архиве стандартные (Европа и Тайвань) и модифицированную русскую прошивки
gpsmap60_76_Cx_CSx_330_rus_full
gpsmap60csx_330.exe
GPSMAP60CSX_TWN.exe
StreetPiloti3_340.exe
к ним gunp.cpp, разбирающий на header.bin, bootseg.bin , loader.bin и fw_all.bin
loader.bin вполне нормальный OMAP’овский код
ROM:00000000 B loc_10
ROM:00000000 ; END OF FUNCTION CHUNK FOR sub_11240
ROM:00000000 ;
ROM:00000004 DCD 0x8015F06
ROM:00000008 DCD 0x80142A6
ROM:0000000C DCD 0x80142A8
ROM:00000010 ;
ROM:00000010 ; START OF FUNCTION CHUNK FOR sub_11240
ROM:00000010
ROM:00000010 loc_10 ; CODE XREF: sub_11240:loc_0Xj
ROM:00000010 MOV R8, R12
ROM:00000014 LDR R0, =0xFFFE1160
ROM:00000018 LDR R1, [R0]
ROM:0000001C BIC R1, R1, #0x17
ROM:00000020
ROM:00000020 loc_20 ; DATA XREF: sub_1049C:off_106A4Yo
ROM:00000020 ORR R1, R1, #6
ROM:00000024 STR R1, [R0]
ROM:00000028
ROM:00000028 loc_28 ; DATA XREF: sub_1049C:off_106A0Yo
ROM:00000028 LDR R0, =0xFFFE1038
ROM:0000002C
ROM:0000002C loc_2C ; DATA XREF: sub_1049C:off_1069CYo
ROM:0000002C ; ROM:off_4E24Yo ...
ROM:0000002C LDR R1, [R0]
ROM:00000030
ROM:00000030 loc_30 ; DATA XREF: sub_1049C:off_10690Yo
RAM где-то в районе 0x08000000, раз указатель стека туда показывает
(MMU скорее всего отключен в это время. хотя и это надо проверять):
ROM:00000334 LDR SP, =0x80A0C30
ROM:00000338 ADR R0, dword_341
ROM:0000033C BX R0
С автоматическим переходом на Thumb моя старая IDA не справляется
Откуда уверенность, что они вообще MMU включают? Нафига он им…
Скорее всего так, но loader.bin все-таки MMU отключает:
ROM:0000029C MOV R1, #0
ROM:000002A0 MCR p15, 0, R1,c1,c0
Надо декодировать конфигурацию MUX и используемые GPIO
(муторное занятие).
2 MB (CS2) → 0x8000000 это до 0x8200000.
loader.bin ссылается на адреса от 0x8002260 до 0x80A0C3C, т.е.
первый мегабайт. Хотя непонятно, куда updater.exe
поместит сам loader.bin (73K)
Начало fw_all.bin похоже по структуре на loader.bin ,
но есть статические ссылки на 0x0c000000 (CS3) сегмент,
а указатель стека уже не вверху первого, а второго мегабайта:
334: e59fd118 ldr sp, [pc, #280] ; 0x454 --> 0x081ec3f0
338: e28f0001 add r0, pc, #1 ; 0x1
33c: e12fff10 bx r0
Так что можно предположить, что NOR находится здесь: 0x0c000000+16MB
Есть и еще один особый адрес: 0x0c020000
6a8: e3a006c0 mov r0, #201326592 ; 0xc000000
6ac: e1a0f000 mov pc, r0
...
708: e59f0000 ldr r0, [pc, #0] ; 0x710 --> 0x0c020000
70c: e1a0f000 mov pc, r0
так же как и начало SRAM
6c8: e3a00680 mov r0, #134217728 ; 0x8000000
6cc: e1a0f000 mov pc, r0
OMAP вообще-то умеет грузиться из CS3 напрямую, но как это все сделано в гармине неясно.
Размер экрана 160x240 (может и наоборот, хотя врядли), но EOL прочитает
это из конфигурационных регистров LCDC.
LCD панель на 60/76Cx 8-битная (?), EOL предполагает только 16бит, надо править.
Вот пока такие мысли.
Перепрошивка базовой карты (и другая полезная информация) с помощью updater.exe
http://www.gps-forum.net/basiskarte-durch-europaische-basiskarte-ersetzen-t661.html
Я разобрал мой 76Cx, чтобы освежить данные о железе.
Процессор OMAP D751623BZHK, такой же как
http://img501.imageshack.us/img501/3282/dsc00159lw5.jpg
вроде бы 300MHz:
http://forums.gpsreview.net/viewtopic.php?t=6842
и 16 МВ intel NOR flash (28F128) и 2MB SRAM (K6F1616R6C).
Получается, что и на всех nüvi до 8xx
стоит тот же самый процессор, но насколько он совпадает с OMAP1623, как пишут здесь
http://www.eetasia.com/ART_8800517624_499488_NP_4ed1e6ad.HTM
непонятно.
В любом случае, можно прошить EOL, или даже uboot для omap на место гарминовского firmware и
задампить NOR полностью, а то гарминовские region ID не дают ясного представления, что же
по каким физическим адресам записано в NOR flash.
Все .rgn с апдейтами состоят из заголовка, и 2 блоков (0xc и 0xe), согласно статье
0C Loader (nicht auslesbar, wird als Zwischenspeicher für das Flashen der
Firmware gebraucht.)
0E Firmware also Gerätesoftware
т.е. загрузчик (почему-то “нечитаемый”) и собственно payload.
В апдейте basemap только заголовок и 1 блок (0x3)
03 Basis-Karte
Так что все это можно смело перепрошивать.
Программа gunp фонты не находит, наверное сигнатура изменилась на более современных девайсах.
etrex.infо об этом молчит, типа разбирайтесь сами, если надо
Со временем разберемся
OMAP nüvi имеют несколько другую конфигурацию, чем 60/76Cx. У них присутствует SDRAM в обычном для него месте
@0x10000000
По моим расчетам 60/76Cx работает на частоте 80MHz (DPLL1_CTL=0x2a50, ARM_CKCTL=0x4006)
Без мануала для OMAP1610 жизнь очень тяжела, так что если у кого завалялся
OMAP1611/12 Multimedia Processor Technical Reference Manual
http://bbs.cnttr.com/archiver/tid-121950.html
выложите его куда-нибудь.
В заголовке и loader и firmware наблюдается единая структура состоящая из
jump’a (b 0x10) и трех адресов
60Cx loader
00000000 <.data>:
0: ea000002 b 0x10
4: 08015f3a stmdaeq r1, {r1, r3, r4, r5, r8, r9, sl, fp, ip, lr}
8: 080142da stmdaeq r1, {r1, r3, r4, r6, r7, r9, lr}
c: 080142dc stmdaeq r1, {r2, r3, r4, r6, r7, r9, CKCTLlr}
60Cx fw
00000000 <.data>:
0: ea000002 b 0x10
4: 0c310502 cfldr32eq mvfx0, [r1], #-8
8: 0c2f68b6 stceq 8, cr6, [pc], #-728
c: 0c2f68b8 stceq 8, cr6, [pc], #-736
nüvi 250 loader
00000000 <.data>:
0: ea000002 b 0x10
4: 10081eb6 strhne r1, [r8], -r6
8: 10061ae6 andne r1, r6, r6, ror #21
c: 10061ae8 andne r1, r6, r8, ror #21
nüvi 250 fw
00000000 <.data>:
0: ea000002 b 0x10
4: 10729012 rsbsne r9, r2, r2, lsl r0
8: 106b3882 rsbne r3, fp, r2, lsl #17
c: 106b3884 rsbne r3, fp, r4, lsl #17
+0xc всегда отстоит от +0x8 на 2 байта,
а +0x4 очень смахивает на relocation address для .text сегмента,
но это еще надо изучать.
Мой большой план состоит в модификации uboot для omap1610 innovator
в духе http://linux.omap.com/pub/documentation/osk/omap5912osk_2.6.pdf
и запуск его как loader.
Маленький план - в тестировании минимальной программы
из комплекта EOL, пишущей
в framebuffer sram тоже через запуск как loader.
2байтный alignment для arm32 кода не катит эту фразу вверху беру назад.
Брутально дизассемблировал loader, не PIC оффсеты портят картину, но
есть много новой информации.
Недавно купил nüvi 860T (ужо с линуксом), и стал разбираться в его
внутренностях, благо есть исходники для загрузчика и ядра.
Сильно портят жизнь цифровые подписи на все и вся, отсутствие у root пароля
в /etc/passwd, / readonly, короче грмн очень сильно постарался, чтобы не дать
ничего перепрошить. У кого есть мысли по поводу эксплоитов для linux-arm ядра 2.6.17,
давайте сюда, то что я нашел - не работает
Самое интересное конечно это сама гарминовская навигационная программа “gnav”:
она написана на c++, использует GTK, и, в ней есть ВСЕ символы вроде
gnav::find_wizard::get_rgn(MDB_gmap_id_type*, int)
(кто-то добрый оставил -g). Прямо хоть подключай дебаггер, и ставь breakpoints на имена функций.
Я собрал много полезной информации о железе, но ее надо куда-нибудь в wiki.
Вот малый кусочек:
mmc0:
---
mmcblk0 -> mbr(512)
mmcblk0p1 -> hw manager, uImage
mmcblk0p2 -> extended_partition (512*5121)+root.ext3(512*388095)
mmcblk0p3 -> (62960rw) /home home.ext3 (root,unpriv)
mmcblk0p4 -> (3656600rw) /mnt/vfat, internal iNAND
mmcblk0p5 -> () splash BMP
mmcblk0p6 -> (188880ro) / root.ext3 (4G)
w1:
---
32-0000002f3301 Dallas/Maxim DS2780 standalone Fuel Gauge IC
34-000000259844 Dallas/Maxim DS2703 authentication IC.
i2c:
---
0-001a WM8753 sound codec
0-005c tvp5150 video decoder
0-0063 Si4711 FM/RDS radio
uart:
---
1 FF aka /dev/ttyS0 -> ANT
2 BT aka /dev/ttyS1 -> Bluetooth Parrot CK5000
3 ST aka /dev/ttyS2 -> TMC ( + blob console ?)
ext_uart_a/b aka /dev/ttySE0, /dev/ttySE1 serial Exar XR16M2551IL32-F -> GPS MTK3318
usb:
utmi SMSC 3280
$ cat /proc/cpuinfo
Processor : XScale3-Monahans L rev 1 (v5l)
BogoMIPS : 411.64
Features : swp half thumb fastmult edsp
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x688
CPU revision : 1
Cache type : undefined 5
Cache clean : undefined 5
Cache lockdown : undefined 5
Cache format : Harvard
I size : 32768
I assoc : 4
I line length : 32
I sets : 256
D size : 32768
D assoc : 4
D line length : 32
D sets : 256
Hardware : Garmin Daisy
Revision : 0000
Serial : 0000000000000000
$ cat /proc/interrupts
CPU0
3: 0 ohci_hcd:usb1
4: 1 Power Switch
8: 157100 serial
13: 0 SSP
17: 3 LCD
18: 3444 pxa2xx-i2c
20: 227770 STUART
22: 553 FFUART
23: 27079 mhn-mci
25: 15386 DMA
26: 5553566 PXA Timer Tick
30: 0 RTC 1Hz
31: 0 RTC Alrm
33: 0 PXA Camera
39: 0 GCU
41: 55 mhn-mci
44: 279897 pxa owr
46: 2324 mhn_u2d
51: 2 Rcomp Calibration
66: 0 MMC card detect
74: 1 USB vbus detect-bl, U2D vbus detect, USB Power Level
133: 0 Ext pwr detect-bl, Ext Power Level
140: 6 microphone
141: 0 headphone
157: 28542 tsc2200 dav
162: 0 VIB Reverse
Err: 0
$ cat /proc/iomem
00000000-0000000f : serial
34000000-3400000f : serial
40301680-403016a3 : pxa2xx-i2c.0
40500000-40500fff : pxa2xx-ac97
40600000-4060ffff : pxa2xx-udc
41100000-41100fff : mhn-mci.0
41100000-41100fff : mhn-mci
41a00000-41a0002b : SSP
41b00000-41b00010 : 1-wire-mp.0
42000000-42000fff : mhn-mci.1
42000000-42000fff : mhn-mci
44000000-4400ffff : pxa2xx-fb
4c000000-4c000fff : pxa-ohci
4c000000-4c000fff : ohci_hcd
54000000-540fffff : m2d
54100000-5410ffff : mhn-u2d
5c000000-5c03ffff : Video RAM
80000000-83ffffff : System RAM
8001b000-80249423 : Kernel text
8024a000-80280d67 : Kernel data
c0000000-c3ffffff : System RAM
у 60csx , мне кажется, флешка промаплена в 0x8000000 . Оттуда и выполнение начинается. Попробуйте в IDA поставить стартовым адресом 0x8000000 - листинг гораздо правдоподобнее.
У меня вот попрос - что за регистр FFFE:1160 ? Не нашел в даташитах. Они его первым делом устанавливают.
0x8000000-0x820000 это SRAM,
NOR flash 0xc000000-0xd000000
и то, что gunp называет fw_all.bin, прошивается по
адресу 0xc020000 (т.е. в первых 128K лежит что-то другое,
а возможность грузиться предусматривается в коде с трех адресов:
0x8000000, 0xc000000 и 0xc020000).
Еще есть SRAM @0x20000000, оно по крайней мере >=64K.
160x240x8 Framebuffer’у столько не надо, но где он начинается,
можно определить экспериментальным способом.
Установки GPIO и MUX я попробую декодировать, но по крайней мере
значения могу сюда запостить.
Еще я занялся разборкой “китайской” прошивки для 60/76C(S)x:
у нее всего 2 “языка”: CJK и English, gunp ее не понимает, т.к. String magic “English\001”
а не “English\0Jan”, английский язык второй, а не первый, а magic2 идентификатор не
0x04e40000, а 0x03b60000.
При этом “иероглифы” кодированы двухбайтово в CP950, я перевел 1 “букву” из названия языка в UTF-16
и посмотрел как она выглядит: также как первый иероглиф для Китая на гугловской карте.
Таким образом, моя оригинальная идея о поддержке UTF-8 на 60/76C(S)x не так уж и утопична:
надо только понять как кодируются CP950 китайские фонты. К сожалению документации об этом нет
даже для однобайтовой кириллицы! Но путем сравнения русифицированной прошивки с оригинальной
ИМХО удастся разобраться и с этим.
Этот регистр используется только 1 раз, и не так важен. Полностью отсутствует информация только о периферийном
устройстве FFFB:6000, это не SPI, не I2C, не UART, не USB, не W1. Даже ума не приложу, что это может быть.
Название китайского языка в прошивке: 0xc163 0xc5e9 0xa4a4 0xa4e5
Моя рабочая гипотеза: Tai-wan Chi-na
0xa4a4 - тот символ, описанный выше. Комментарий синологов приветствуется.
Я разобрал всю прошивку для 60/76C(S)X, постараюсь написать программу,
правильно извлекающую все цветные 8битные пиксмапы иконок и пр.
Указатель +4 - это magic метка ‘0xa55a’, по ней можно косвенно определить базовый адрес
основной прошивки (gunp делает это с помощью оффсета указателя перед ‘English’)
Извлек 546 штук, из них 322 цветные 8битные: там есть весьма забавные, которых никогда “живьем” не видел: серый волк (3 экз.) и какие-то
2 мужика с луками
Проблема: 64+2 цвета палитра, как она задается. В инете нашел только абстрактные рассуждения, но не конкретную
таблицу. Придется сравнивать скриншоты с индексами ??
есть подопытный экземпляр на тестовую перепрошивку, не очень жалко если что…
Эти изменения совсем безобидные, надо только разобраться с какого по какой
байт считается контрольная сумма.
Если RGN_Tool http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=137838
ее считает, то дело сделано.
Вот эта палитра может и правильная в смысле “представимых” цветов:
http://www.alphi.at/daten/gps/garmin-palette.pal
но порядок индексов никак с реальным 60/76C(S)x не совпадает.
Решил перейти на вот эту последнюю версию 4.00
d31d040eb867ae83e85055d86a2d63c4 029201000400.rgn
так как многие оффсеты при смене версии будет автоматически определить
практически невозможно.
Палитра в моем понимании должна быть единая для все color depth: 1,2,4,8
т.е. первые 2 цвета должны быть черный (000000) и белый (ffffff),
далее возможны варианты.
При сравнении со скриншотами получаются в первом приближении такие значения, хотя тут
надо еще многое перепроверять:
0 -> 0 0 0
1 -> 255 255 255
3 -> 0 48 255
4 -> 0 101 213
5 -> 0 101 255
6 -> 0 149 0
7 -> 0 149 255
8 -> 0 202 0
9 -> 0 202 205
10 -> 0 255 0
11 -> 0 255 255
12 -> 57 149 255
13 -> 255 0 0
15 -> 255 0 65
16 -> 255 0 106
17 -> 255 48 32
19 -> 255 48 106
20 -> 255 202 0
21 -> 255 255 0
22 -> 255 255 255
Nüvi 860 все-таки в конце концов хакнули
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=140091
Жаль что на нем чипсет не sirf3