[off] Альтернативные прошивки для garmin

Моя профессиональная деятельность не связана с реверс инженерингом и перепродажей чужой интеллектуальной собственности под своим именем.
…Был один любитель перепродавать программу Навител (с небольшим изменением кода), взяли его довольно быстро. Правда это было в России…

Ну мы же не получаем зарплату за наполнение OSM. :slight_smile:

Это энтузиазм :wink: Лично я вот рисую карту, по которой сам езжу. Это инвестиция! :slight_smile:

В мире много чего не законно и есть рыбы покрупнее. Не стоит этому уделять столько внимания. Главное, что нашелся человек, который способен удовлетворить спрос пользователей, ибо гармин уже плюнул им в лицо(прошивка 2.10 убивает насовсем), слава богу хоть выходящие из строя 1xxx бесплатно меняет.

Пример неуместен. Потому что навител в этом случае не становился лучше или хуже.

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

Надо было иначе оформлять
Не продовать готовое, а тюнить девайс заказчика. тогда все в порядке. и главное все законно

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

Тут приобретается не продукт, а ПО для него. Другое бы дело, если бы он торговал гарминами, со своей прошивкой. И навиком зная это вообще никак не реагирует.

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

В данном случае ПО это часть продукта. Я не говорю что это законно и всё такое. Я говорю про то что человек молодец, что делает из 1xxx конфетку. Лучше заплатить нашему соотечественнику, чем гармину, который наплевал на пользователей и выпустил подобие китайского навигатора.

Хрен с ним с паразитирующим.
Давайте теребить прошивки сами и обсуждать результаты.
Меня вот интересуют параметры железа 60/76Cx (насколько я помню 2MB SRAM и 16MB NOR flash)
и как загрузить EOL
http://vivien.chappelier.free.fr/typhoon/index.html
через updater.exe
Процессор очень похож на OMAP730/850, судя по этой странице:
http://webcache.googleusercontent.com/search?q=cache:cGwa252VSSIJ:wiki.xda-developers.com/phpwiki213/index.php%3Fpagename%3D60Cx_registers+60Cx_registers

Научить прошивку хотя бы рисовать utf8 (latin1+cyrillic) тоже было бы здорово.
На utf8 поиск не надеюсь, это скорее всего нереально.

А каковы шансы через этот EOL грузить родную/пропатченную прошивку? С таким количеством оперативки там наверняка XIP из NOR.
Вообще интересный вариант. Вывод *DOP бы прикрутить.

// Личку на osm.org посмотри.

Цифры только по маркировке микросхем.
Надо разобраться, где в адресном пространстве замаплен интеловский NOR, где SRAM, как сконфигурирован MMU с
виртуальной памятью и что ожидает/думает прошивка о своем местонахождении и нахождении SRAM.
В крайнем случае потеснить basemap, на него вроде как 8MB приходится, но это можно будет легко проверить
слив NOR полностью после старта EOL.
В крайнем случае новую прошивку придется прошить.
Все драйвера вроде как есть: lcd, usb, keypad, nor, 2 RS232 порта (sirf3 и гарминовский коннектор)

Ответил. josm отучил туда смотреть.

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

нувики и так под линуксом работают, там все гораздо проще.
А вот даже на 60/76Cx (не говоря уже о более примитивных девайсах) нужен моск :slight_smile:
Я нашел в архиве стандартные (Европа и Тайвань) и модифицированную русскую прошивки


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 не справляется :wink:

Откуда уверенность, что они вообще 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о об этом молчит, типа разбирайтесь сами, если надо :wink:
Со временем разберемся :slight_smile:

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 кода не катит :wink: эту фразу вверху беру назад.
Брутально дизассемблировал loader, не PIC оффсеты портят картину, но
есть много новой информации.