В Telegram-чате MotoFan.Ru у нас с baat'ом и @usernameak'ом было интересное обсуждение разработки ELF-бенчмарка для теста производительности многих P2K-моторолок между собой. Данный проект пока не закончен, но благодаря ему найдена удивительная возможность разогнать программно процессор Neptune LTE SoC (возможно и LTE2 тоже) используемый в Motorola E398 и подобных телефонах со стоковой частоты в 52 MHz до 65 MHz.

Дело было так: листал я утечку и ELF-прошивку в поисках различных методов работы с Neptune SoC и обнаружил там интересную функцию HAPI_CLOCK_mcu_set(), которая по идее задаёт частоту MCU и DSP ядер процессора на базе некой базовой частоты. Немного теории: микросхема процессора телефона Neptune SoC содержит в себе не только ARM7TDMI-ядро на котором выполняются вычисления, но ещё и DSP-ядро и огромную кучу самой различной периферии. Её список можно увидеть тут:


Подробнее см. Elektro255 V0.4 alpha 4 mod (4xR)

Нам тут интересно устройство регулировки частот: Clock Control Module (CCM), регистр hapi_clock_reg которого выведен на адрес 0x24845000, который как раз и используется в этой функции.

Попытка №1

Сама функция HAPI_CLOCK_mcu_set(), точнее её самая интересная часть расположена в трёх case-ветвях у switch, где выставляются нужные делители в регистр hapi_clock_reg и эти делители задают последовательно требуемые частоты: 26 MHz, 39 MHz, 52 MHz.

Нажмите для просмотра прикрепленного файла

К примеру, частота 26 MHz получается делением базовой частоты 260 MHz на 10, 39 MHz делением частоты 156 MHz на 4, а 52 MHz получается при делении 260 MHz на 4.

У меня появилась идея запатчить ветку устанавливающую 39 MHz таким образом, чтобы вместо 39 MHz выставлялось значение в 65 MHz, для этого я придумал следующее:

Нажмите для просмотра прикрепленного файла

Первым делом мы меняем инструкцию CMP R0, #5 на CMP R0, #8, чтобы поток исполнения кода при установке дефолтной частоты падал в case, который будет патчиться далее и в котором нужно просто изменить базовую частоту 156 MHz (0x0A) на 260 (0x0C), после чего делители можно даже и не трогать, они разделят 260 MHz таким образом, что получится 65 MHz на выходе для MCU. А вот вторую общую частоту, которая задаётся через инструкцию MOVS R1, #0x400 по идее следует изменить на MOVS R1, #0x500, поскольку в Thumb-ассемблере команда MOVS составная из двух 16-байтных инструкций, их опкоды выглядят следующим образом:


Это всё удобно находится с помощью online-инструмента https://armconverter.com/ и https://godbolt.org/

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

Попытка №2

Исследование дизасма в IDA Pro показало что данная функция вообще нигде не используется при работе телефона, как кроме для каких-то FOTA обновлений, которые никогда толком не работали. Это была мёртвая функция, которая висела внутри CG1 и не выполнялась при запуске телефона. Появилась следующая идея -- добавить адрес функции HAPI_CLOCK_mcu_set() из прошивки в EP1-библиотеку elfloader.lib, что позволит вызывать её с любыми параметрами.

Адреса функции следующие:


Увы, после добавления функции в библиотеку попытка вызвать её из ELF-приложения приводила к намертво зависшему телефону. Вторая попытка была тоже неудачной.

Попытка №3

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


То есть напрямую читать и писать в регистры различных периферийных устройств, которые отображены на адресное пространство, это делает метод повышения частоты кросс-платформенным в рамках устройств, использующих Neptune SoC.

Через некоторое время функция была портирована и при её вызове из ELF-приложения телефон намертво зависал, как и с оригинальной функцией из прошивки.

Попытка №4

Однако теперь, когда HAPI_CLOCK_mcu_set() была вытащена внутрь ELF'а, появилась возможность её удобной отладки и редактирования. Я просто убрал из этой функции какой-то бесконечный цикл стабилизации частоты и... разгон процессора заработал! Но только на частоте в 65 MHz, частоты в 69 MHz, 78 MHz, 86 MHz и 104 MHz всё-таки наглухо вешали телефон.

Бенчмарки

Я тут же прогнал JBenchmark и собственный Benchmark в виде ELF-приложения с портированными внутрь BogoMIPS и Dhrystone и был очень приятно удивлён результатам. Слева как было на стоковой частоте, справа как стало при разгоне MCU:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Производительность телефонов ROKR E1 и SLVR L6 увеличилась на 20%, прямо пропорционально частоте MCU которая тоже увеличилась на 20%! Кроме того, немного увеличилась скорость передачи файлов по USB, а отзывчивость GUI стала заметна глазу.

YouTube: https://www.youtube.com/watch?v=IO8aktssBo8

Забавный факт: если изменять референсную общую частоту 26 MHz, воспроизведение звуков ускоряется или замедляется в зависимости от понижения или повышения. К счастью, этот баг обходится фиксированием общей частоты в 26 MHz при разгоне частоты MCU до 65 MHz.

А вот баг с периодическим пропаданием сети на частоте 65 MHz, к сожалению, пока не удалось забороть.

Эльфы

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

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Скачать их можно ниже в прикреплённых файлах, но следует помнить, что они всегда могут обновиться и измениться, поэтому хорошим тоном было бы выложить их исходный код:

1. https://github.com/EXL/P2kElfs/tree/master/Benchmark
2. https://github.com/EXL/P2kElfs/tree/master/Overclock

Итоги

Несмотря на проблемы с сетью, в целом это довольно-таки интересный опыт небольшой поднятии частоты процессора "народного" телефона E398. Спустя 20 лет нашлась-таки эта интересная особенность и разгон CPU стал возможен. Если я найду в имплементации GSM-стека задержки, которые базируются на частоте MCU, я попробую исправить эту проблему тоже.

Помимо разгона до 65 MHz я попробовал следующие значения:


К сожалению на них телефон моментально зависает.

В будущем было бы интересно протестировать приложения на телефонах, которые работают на Neptune LTE2, такие как V360, L7, V3r, V3i, L7e, K1 и некоторые другие. К сожалению таких у меня пока нет.

Прикреплённые файлы:

Народный любимец Gravity Defied взлетит теперь?

Потрясающе)

Так, поступила кучка вопросов, постараюсь ответить на них все.

1. Увеличивается ли скорость работы Bluetooth как USB и вообще работает ли он после разгона?

Ответ: увы, после разгона он включается но не хочет ни с чем соединяться.

2. Тормозит ли после разгона при воспроизведении MP3 320 kbps в меню?


Ответ: посмотрите ролик выше, мне кажется или тормоза немного стали меньше? В любом случае, разгон от этой проблемы полностью не избавляет.

3. Тормозит ли после разгона народный любимец Gravity Defied?


Ответ: посмотрите ролик выше, это обычная необлегчённая версия которая тормозит на стоковых 52 MHz с невозможностью проходить игру. На 65 MHz раздражающие тормоза уходят, игра становится играбельной и проходимой, хотя и довольно медленноватой.

4. Пропадает ли сеть во время разговора, если включить разгон?

Ответ: да, сеть телефон при разгоне теряет моментально.

5. Увеличилась ли производительность портированной технодемки Yeti3D после разгона?

Ответ: да, заметно как "на глазок", так и по замерам FPS. Позже продемонстрирую это подробнее.

6. Восстанавливается ли сеть при сбросе частоты с 65 MHz до 52 MHz?

Ответ: увы, нет. Приходится перегружать телефон.

7. Что будет если выбрать частоту 13 MHz и сильно замедлить телефон?


Ответ: посмотрите конец выдео выше, сильно замедляются даже звуки. А вот на 26 MHz и 39 MHz телефон просто работает медленно.

Прикреплённые файлы:

И вот ещё хорошая новость, baat подтвердил и протестировал метод разгона до 65 MHz на Neptune LTE2 телефонах, таких как Motorola V360 и Motorola SLVR L7:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Производительность которых так же возросла. Проблемы, к слову, остались всё теми же.

А вот Motorola SLVR L7e, который как бы тоже телефон на Neptune LTE2, разогнать увы не получилось, он зависает при выборе частоты в 65 MHz, хотя умеет замедляться на 26 MHz и 39 MHz.

Жаль, что при разгоне часть функционала теряется... А ещё, было бы интересно посмотреть, как бы работал телефон e770 если немного разогнать (понятно, что проц другой и т.п., просто рассуждения). Он итак был сравнительно шустрый среди p2k моторол, и тянул даже 3D игры =).

Lexa_64,
Да, Motorola E770v весьма шустрый и проц там чистокровный мотороловский, на их собственной архитектуре M*CORE, а не ARM. В теории по этому методу можно попробовать, но на практике непонятно есть ли там подобный CCM-модуль.

Limows проверил этот метод разгона на Motorola RAZR V3i, там частота "65 MHz | 26" не стала работать, зато "65 MHz | 32" -- заработала!

Результаты разгона такие:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Как видно, задержки к памяти тоже становяться чуть меньше, а ещё поднимается нижняя граница FPS в тесте GPU, где идёт максимальная нагрузка на камешек MCU.

Из интересного стоит отметить такую информацию по герцовке дисплеев:

1. Motorola L2, L6 и, подозреваю, что V235 имеют cSTN-дисплей работающий на частоте 51 Hz.
2. Motorola E398, L7, V360 и L7e имеют TFT-дисплей работающий на частоте 60 Hz.
3. Motorola RAZR V3i и RAZR V3r имеет TFT-матрицу на 81 Hz.
4. Motorola KRZR K1 сильно удивил, там TFT-матрица на 90 Hz и операционкой выдаются все 90 FPS!

Наборы GPU-ускорителей:

1. L2, L6, V235, V360, L7 -- используют ATI Imageon W2240 в котором 192 KB внутренней видеопамяти.
2. V300, V600, V80, E398, E1, V3, V3r -- используют ATI Imageon W2250 в котором 192 KB внутренней видеопамяти.
3. V635, V3i -- используют ATI Imageon W2260 в котором 384 KB внутренней и 2048 KB внешней видеопамяти.
4. L7e, K1, L9 -- используют ATI Imageon W2280 в котором 192 KB внутренней и 2048 KB внешней видеопамяти.

Интересно, что в V360 и L7 используется более старый GPU, чем в E398 или даже V300.

И вот ещё результаты JBenchmark, которые любезно прогнали Limows и baat на своих мобилках.

Motorola SLVR L7:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Motorola V360:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Motorola RAZR V3i:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

V360 и L7 взяли почти 2000 попугайчиков!

Bs0Dd затестил разгон у себя на Motorola RAZR V3r, там работает вариант "65 MHz | 26".

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Из интересного -- матрица дисплея там тоже 81 Hz как и у V3i, при этом при разгоне достигается вся эта герцовка выводом картинки через ATI Imageon.

Нажмите для просмотра прикрепленного файла

А вот в Java по какой-то причине RAZR V3r оказался ну очень слабый. Не чета тому же V360, к примеру.

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

В других тестах результаты у него отличные, проблема видимо в имплементации Java-машины в конкретной прошивке.

Очень круто, ничего не скажешь!
Сколько же еще недокументированных таинственных возможностей хранит родная Е398
А второй JBenchmark кто-нибудь пробовал? А ещё какие-нибудь тяжелые игры? Хотя даже и не помню, были ли такие вообще, основным камнем преткновения была уже протестированная Gravity Defied...

Как показала дальнейшая практика, у некоторых Motorola RAZR V3r при разгоне пропадает подсветка экрана и выключается ATI Imageon W2250, что переводит телефон в текстовый режим. Телефон в таком режиме работает так, как если бы он был без флипа в котором и находится этот самый графический чип.

Нажмите для просмотра прикрепленного файла

Спасибо за фотографию @NickNickerYT.

Тем не менее, разгон MCU всё же даже в такой ситуации работает. А вот другие V3r разгоняются более-менее нормально.

Нажмите для просмотра прикрепленного файла

Спасибо за фотографию woiaw.

При этом по ревизиям GPU чипов они одинаковые, поэтому в чём там проблема -- загадка.

cherr,
JBenchmark 2 вроде кто-то тестил, там тоже прирост на 15-20% есть, но смысла в этом не так много. У E398 как и у многих ARM7TDMI P2K телефонов Motorola довольно куцая Java-машина, в которой по части того же 3D нет многих классов, поэтому тяжёлые и красивые игры даже несмотря на разгон запускаться не будут.