Разгон процессора в 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 и некоторые другие. К сожалению таких у меня пока нет.

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

[cherr]

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

[EXL]

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



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

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



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

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

[EXL]

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