HTC Athena тоже работает по умолчанию на NMEA/57600, и тоже после переключения
в internal boot mode после MID148 или же с помощью соответствующего GPIO
на sirfmemdump не реагирует. Тут что-то не так, видимо какой-то нетривиальный баг
в sirfmemdump. Я еще раз посмотрел на перепрошивку GPS из SPL, о котором писал ранее.
Проблема с SHA1+RSA (по-блочная цифровая подпись) пропала после перепрошивки на SPL-1.20Olipro, но
остается проблема с “security level”. По какой-то причине он равен 0x32 (48)
Level = 32
а должен быть =0.
Эта проблема гораздо проще RSA, и была решена на других телефонах HTC
с помощью т.н. goldcard, т.е. шифрованного блока из 128 байт в начале SD карты
создаваемого из SD CID с помощью DES. Сам ключ для DES находится в SPL,
и для многих моделей присутствуют в знаменитом файле typhoonnbfdecode.pl
Но Athena там нет, и я что-то пока не понял как их найти.
GPS модуль Telit JN3 с ПАТЧ-антенной 15х15мм параллельной плоскости экрана.
А софт эхолота судя по всему поддерживает и SIRF и U-blox модули, ибо на разъём к которому можно подцепить внешний ЖПС модуль эхолот порой посылает строки инициализации типа
$PUBX,41,1,0007,0003,38400,0*20
для U-blox-модуля
Я скачал наугад 3 прошивки (786, 798 и ONIX) с сайта Humminbird.
786 поддерживает только ublox, 798 и ublox и sirf, а на ONIX вообще песня:
полный дистрибутив Linux для TI814x, с xserver-kdrive и qt-4.7 http://arago-project.org/wiki/index.php/Main_Page
Edit
У 898/998/1098/1198 тоже Linux на OMAP3530 с 512MB RAM и 24MB VRAM и
В конце концов удалось успешно перепрошить sirf3 на HTC Athena через SPL с помощью HTCFlasher.
Проблема была в том, что .nbh файл должен быть 512 bytes aligned (CurLen=0x200, так считает
встроенный алгоритм CRC32). Я добавил в конец к созданному с помощью yang .nbh
файлу нулей, чтобы первая цифра в команде wdata делилась на 512, и все заработало.
(FSEND: [wdata 4ae00 1ee74382])
Тут дается неправильная информация http://forum.xda-developers.com/wiki/Hermes_BootLoader
по команде wdata: ее формат на новых устройствах (в том числе и HTC Hermes)
не wdata [[Len [StartAddr]]], а wdata block_Len block_CRC32, при этом должно быть
выполнено условие block_Len mod 512 = 0, чего HTCFlasher не делает (баг!).
В HTCFlasher похоже есть еще один баг, что он не дожидается пакета -GPS_Firmware_Update (%d)
а после последнего посланного блока говорит Done! FSEND: [ResetDevice],
так что такой способ перепрошивки не для слабонервных
Видимо целесообразно уменьшить константу RUUBLOCK с 1 MB на значительно меньшее
значение, ведь UART на 115200 не так быстр, как встроенный flash,
для которого был написан HTCFlasher, а SREC файл все-таки ~1.5MB.
Но такой метод работает, а sirfmemdump в современном виде нет.
Еще раз перепрошил телефон для чистоты эксперимента.
Теперь думаю в плане железа вернуться к старому (т.е. до октября 2013 года)
трекеру Globalsat TR-600GLONASS. После этой даты из них выкинули изделие NVS-CSM
и заменили на дешевый китайский MT3333. Хотя разводка на плате осталась,
и “старый” модуль можно впаять выкинув MT3333.
andru8, после внимательного прочтения Release Notes у меня есть пара вопросов:
работает ли теперь RXM-SFRBX всегда по умолчанию,
и есть ли на ваших приемниках RXM-RAWX ?
TRK-MEAS/TRK-SFRBX похоже из прошивки убрали, и также UPD-UPLOAD, UPD-DOWNLOAD и UPD-EXEC
(последние три под полунадуманным предлогом),
а после каждого UBX сообщения идет сообщение 27,0 с хешем.
За 5 минут моего тестирования новой прошивки затрекались 2 спутнега Galileo: E26 (operational)
и E24 (In commissioning) https://en.wikipedia.org/wiki/List_of_Galileo_satellites
Декодера I/NAV subframes в rtklib не имплементировано:
2 ubx rawsfrbx galileo nav not supported sat=80
2 ubx rawsfrbx galileo nav not supported sat=82
Нет возможности модифицировать RAM, адреса же лежат рядом с идентификаторами,
их искать не надо. Официальный путь, как я понимаю, это изменение LLC,
но там можно нарваться на серьезную криптографию, а не на дедский сад
как в CFG-LIC. Можно конечно прямо во флеше поменять адрес какого-нибудь
левого сообщения на адрес raw, и пользоваться потом этим левым сообщением
после перепрошивки. Fletcher64 остался как и был, но не исключена еще
какая-нибудь цифровая подпись текста (как в старой доброй гисруссо )
Раз они считают SHA в железе, то я бы не удивился.
Не зря там есть такая фраза
INCOMPATIBLE HARDWARE -> NO GNSS OPERATION
Меня интересует опыт других людей, т.к. у меня raw и так работает out of the box.
Кстати в новом мануале по ublox-m8 тоже
почему-то правильный LLC (страница 3 внизу), хотя официально
так быть не должно. Акционеры должны настучать автору по голове.
На самом деле все обстоит несколько не так. Сообщение RXM-SFRBX доступно всем и везде.
Сообщения RXM-RAWX, TRK-MEAS, TRK-SFRBX тоже в прошивке, но в зависимости от
битов LLC выдаются в нормальном виде, или в виде недокументированного
шифрованного контейнера (0x2700).
Алгоритм естественно неизвестен, но так как само кодированное сообщение известно,
то это интересная тема для дипломной работы по криптоанализу
Из 9 “видимых” спутников Galileo (E11, E12, E14, E19, E20, E22, E24, E26, E30)
я (но это может сделать любой с NEO-M8N и совместимыми как Navilock NL-8*)
уже отследил E12, E22, E24, E26, E30. Интересно будет поглядеть на E14 с его эллиптической
орбитой, где эксцентриситет не помещается в битовое поле альманаха.
Правильно шифрованное сообщение от мусора статистически неотличимо.
УЦентр выдает такую последовательость пакетов
2700(68 байт) 0213 (48 байт) 2700(68 байт) 0213 (48 байт) … 2700(68 байт) 0213 (48 байт)
Для 0215 (в представлении 2700) байтов естественно больше, но длина всех пакетов кратна 16.
Внутреннюю структуру надо более внимательно изучать, но они вроде все начинаются с 2
(версия пакета?) и остальное выглядит скорее как заголовок + простой XOR, так как многие позиции
не меняются во времени.
Все парсеры UBX сообщений находятся в UBX.dll, и для
0x2700 там ничего нет.
Ну чтобы попытаться разгадать, надо как минимум сплиттер и два девайся с грязным хаком, или на худой конец с 7/6 версии. Хотя для начала можно проверить CRC считается для этого сообщения правильно, а то вдруг оно считается для правильного содержимого
To avoid any misunderstandings by google translate, i will write it in english.
I have got full raw Galileo datastream with the 3.01 firmware on NEO-M8N, but it is a special hardware setup
which i don’t want to disclose. This data is not yet validated.
The proper generic solution should consider dissecting the SEC-0 packet contents (0x2700).