Разгон процессора в Motorola E398, Motorola RAZR V3i и подобных, 52 MHz => 65 MHz, +20% Performance Boost! Поделиться Опции

[EXL]

В 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-ядро и огромную кучу самой различной периферии. Её список можно увидеть тут:

Огромный список адресов периферийного железа внутри Neptune LTE SoC и подобных

Код

********** Peripherals map *********

mdpi = 0x23800000
aipi_psr0 = 0x24840000
aipi_psr1 = 0x24840004
hapi_gpio_reg = 0x24841000
MCUPBDIRREG = 0x24841020
MCUPBALTINREG = 0x2484102C
MCUPCDIRREG = 0x24841038
MCUPCALTINREG = 0x24841044
MCUPBDATAREG = 0x24841084
MCUPCDATAREG = 0x24841088
MCUPDDATAREG = 0x2484108C
hapi_rtc_reg = 0x24843000
tcm_reserved = 0x24844000
tcm_mtcr_reg = 0x24844008
hapi_clock_reg = 0x24845000
a2digl_reserved = 0x24846000
HAPI_GPADC_reg = 0x24846010
HAPI_AMARB_reg = 0x24847000
egpt = 0x24848000
epit = 0x2484801C
hapi_watchdog_reg = 0x24849000
rtr = 0x2484A000
hapi_dsm_reg = 0x2484B000
hapi_ext_interrupt = 0x2484C000
hwi_uart1_prim_rx_reg = 0x2484D000
hwi_uart1_regs = 0x2484D000
uart1_base_address = 0x2484D000
hwi_uart1_prim_tx_reg = 0x2484D040
hwi_uart1_prim_ucr1 = 0x2484D080
hwi_uart1_prim_ucr2 = 0x2484D082
hwi_uart1_prim_ucr3 = 0x2484D084
hwi_uart1_prim_ucr4 = 0x2484D086
hwi_uart1_prim_usr1 = 0x2484D08A
hwi_uart1_prim_usr2 = 0x2484D08C
hwi_uart1_prim_ubir = 0x2484D092
hwi_uart1_prim_ubmr = 0x2484D094
hwi_uart1_prim_ubrc = 0x2484D096
kpp = 0x2484E000
sim_reserved = 0x2484F000
hapi_ic_id_reg = 0x24850000
neptune_uid_memory_map = 0x24850000
qspi_reg = 0x24851000
usb_regs = 0x24852000
l1timer_reserved = 0x24853000
hapi_display_reg = 0x24854000
hapi_one_wire_reg = 0x24856000
uart2_base_address = 0x24857000
hacc = 0x24858000
gem_reserved = 0x24859000
io_mdi_reg_address = 0x2485BFF2
io_mdi_shared_ram = 0x2485C800
ahb_reserved = 0x28000000
hapi_ext_interface_reg = 0x28880000
main_external_interface = 0x28880000
CS0_PRIM_CFG = 0x28880010
CS0_SEC_CFG = 0x28880014
CS0_WS_CTRL = 0x28880018
CS0_BCLK_CTRL = 0x2888001C
CS1_PRIM_CFG = 0x28880020
CS1_SEC_CFG = 0x28880024
CS1_WS_CTRL = 0x28880028
CS1_BCLK_CTRL = 0x2888002C
itc = 0x29890000
awpt_regs = 0x2A8A00B4
awptsr = 0x2A8A0208
mtcl_reserved = 0x2B8B0000
msu = 0x2C8C0000
monitor = 0x2D8D0000
sec_ram = 0x2E8E0000

[close]

Подробнее см. 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-байтных инструкций, их опкоды выглядят следующим образом:

Код

MOVS    R4, #0xA
MOVS    R1, #0x400
|
MOVS R1, #1
LSLS R1, R1, #0xa

24 0A 21 01 02 89 <= Original code

MOVS    R4, #0xC
MOVS    R1, #0x500
|
MOVS R1, #5
LSLS R1, R1, #0x3

24 0C 21 05 02 09 <= Result for Patch

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

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

Попытка №2

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

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

Код

# Pattern
B5 F8 1C 04 21 01 04 C9  20 01 F0 03 FC 3D 1C 20

# R373_49R (ROKR E1)
0x10C11C48 T HAPI_CLOCK_mcu_set

# R3443H1_0BR (SLVR L6i)
0x10CF7244 T HAPI_CLOCK_mcu_set

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

Попытка №3

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

Код

#define HAPI_CLOCK_REG_ADDRESS    0x24845000
#define HAPI_CLOCK_RATE_ADDRESS   0x03FC3600

/* Clock Control Module (CCM) peripherals address. */
HAPI_CLOCK_REG_T *hapi_clock_reg = (void *) HAPI_CLOCK_REG_ADDRESS;
/* Current MCU clock rate address. */
HAPI_CLOCK_RATE_T *hapi_clock_rate_mcu = (void *) HAPI_CLOCK_RATE_ADDRESS;

*hapi_clock_rate_mcu = HAPI_CLOCK_RATES_52_MHZ;
hapi_clock_reg->div_factor = /* 0x0002  (260 / 4) = 65 MHz      */
                (hapi_clock_reg->div_factor & ~MCU_DPLL_DIV_MASK) | (DPLL_DIVIDE_BY_4  << MCU_DPLL_DIV_SHIFT);

То есть напрямую читать и писать в регистры различных периферийных устройств, которые отображены на адресное пространство, это делает метод повышения частоты кросс-платформенным в рамках устройств, использующих 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 я попробовал следующие значения:

Код

208 MHz / 3 = 69.3(3) MHz
156 MHz / 2 = 78 MHz
260 MHz / 3 = 86.6(6) MHz
208 MHz / 2 = 104 MHz

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

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

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

[FEAR4ik]

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

[javelin67]

Потрясающе)

[EXL]

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

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 телефон просто работает медленно.

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

[EXL]

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





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

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

[Lexa_64]

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

[EXL]

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

[EXL]

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.

[EXL]

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

Motorola SLVR L7:



Motorola V360:



Motorola RAZR V3i:



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

[EXL]

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



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



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



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