Сборка ядра для ZN5. Compiling your own kernel, Компилим ядро. Мануал. 740 (798) MHz. Разгон Поделиться Опции

[EXL]

На днях поковырялся в ядре и немного повысил частоту работы процессора.
В целом, производительность устройства увеличилась. Это можно судить по тестам:

532 MHz:


636 MHz (изначально неправильно высчитанная частота 665 MHz):


740 MHz (изначально неправильно высчитанная частота 798 MHz):


Кроме того аппарат начал быстрее работать в некоторых меню, к сожалению поднятие частоты процессора конечно же не помогло избавится полностью от глюков и фризов Qt оболочки. Телефон нормально запускается и работает на 798 MHz у меня уже примерно две недели. 798 MHz лишь заменяет 532 MHz при нагрузке, поэтому все утилиты типа zCpu, aiCPU и др. будут работать.
Насчёт продолжительности от работы аккумулятора точно сказать не могу, т.к имею убитый на морозе аккум. Кто протестирует и отпишется о результатах - буду рад. Но скажу точно, денёк у меня держит, если не играть и пользоваться телефоном - как телефоном.
Кроме того, немного повысилась производительность в играх и эмуляторах. Например, pscx4all стал работать быстрее, Picodrive от rock88 вообще выдаёт фуллспид, а в quake 1 разогнался настолько, что играть стало не реально. Подробнее можете посмотреть на видео:

[video]https://www.youtube.com/watch?v=TJLPbUxXoSc[/video]

Ядра собраны под Symbiosis X.2 - 0DR, для ZN5 РСТ 64 Mb RAM. Кто портирует под ZN5 T-mobile - буду только рад. По-моему там просто загрузчик в sbf файлах поменять... P.S. Ядро от стандартного отличается только наличием возможности работы со свапом + другая частота.
665 MHz - Скачать 0DR
798 MHz - Скачать 0DR
665 MHz - Скачать 2CR_128 (ZE 0.9)
798 MHz - Скачать 2CR_128 (ZE 0.9)

Установка - обычная прошивка sbf-файла с помощью RSD Lite.

Изменения в сорцах ядра
Файл hardhat/linux-2.6.x/arch/arm/mach-mxc91231/mxc_pm.c, функция static ap_pll_mfn_values_t opinfo[NUM_DVFSOP_INDEXES], там где комментом отмечено /* 532 */:
значение ap_pll_dp_hfs_op: 0x000000A0 меняем на ap_pll_dp_hfs_op: 0x000000E0 для 798 и на ap_pll_dp_hfs_op: 0x000000C0 для 665.

Напоминаю, что ответственность за ваши действия лежит только на вас.

Полезная информация
Температурные тесты работы процессора ZN5.
Компилируем ядро ZN5. Мануал.

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

[fill.sa]

Появилась мысля попробовать по принципе разгона основного проца - разогнать на IPU

Вот вникаю в принцип работы, может кто еще подключиться к делу.

Заодно буду выкладывать сюда инфу которая может помоч вникнуть в принцип работы.

Начну с файла который уже выкладывал
http://slideplayer.com/slide/9261251/

https://www.digi.com/resources/documentatio...4_cc6/r_ipu.htm

Сообщение отредактировал fill.sa - 17.8.2018, 14:46

[Skrilax_CZ]

Was there some trick to compile VE66 kernel? I'm trying to compile it, but unlike the ZN5, it doesn't boot (stuck on boot logo)?

EDIT: Disregard. Forgot that you have to change "rosec" to "ro" when you disable the SHA checks for CG36/46 in kernel.

Сообщение отредактировал Skrilax_CZ - 18.1.2019, 8:06

[Ant-ON]

Was there some trick to compile VE66 kernel? I'm trying to compile it, but unlike the ZN5, it doesn't boot (stuck on boot logo)?

EDIT: Disregard. Forgot that you have to change "rosec" to "ro" when you disable the SHA checks for CG36/46 in kernel.

I generate SHA hashes same time ago:
Cборка CG36 и CG46 для VE66/EM35

[fill.sa]

Подразобрался тут с разгоном нашего проца. Но для начала предистория.

Вообщем как-то давно EXL захотел разогнать проц и ковырявшись в коде ядра заметил, что меняя значение ap_pll_dp_hfs_op затем на benchmark проверке телефон выдает больше результат. Т.к. EXL менял значение с шагом повторяя другие частоты, он предположил что итоговая частота проца должна получиться 798Мгц.
Затем позже Ant-On чутка поковырявшись сделал заплаточку для ядра, где уже не заменялись прошлые частоты, а добавлялись как новые. А также исправил предположение, высчитав что частота проца получилась 740Мгц.
Но за давностью лет Антон уже не смог вспомнить что да как.
В итоге мне стало интересно разобраться как же считается итоговая частота и полез вникать.


Итого формула расчет выходной частоты PLL (Phase Locked Loop) = 2 * REF_FREQ * ( (MFI + (MFN / MFD)) / PDF),
Где REF_FREQ это исходная частота от кварца как я понял и она у нас 26Мгц
MFN и MFD у нас явно задаются в коде в шеснадцатеричном значении, для расчета все переводим в десятичную.
А вот MFI и PDF берется из ap_pll_dp_hfs_op (последние две цифры), по коментариям это /*OP value (contains MFI) */. Это как раз те значения которые правил EXL .

Затем выходная частота PLL участвует в делителе ARM_AHB_IPG_RATIO_... , где собственно и задатся конечная частоты на нужной шине.

Так что теперь можно более тонко дозировать необходимую частоту.
Из ограничений есть
MFI может принимать от 5 до 15. Если MFI меньше 5, DPLL будет использовать 5.
PLL не менее 160Мгц
Делитель AHB:IPG должен 1:2 быть.
А еще нашел Максимально допустимый общий коэффициент умножения MF (MFI + MFN / MFD) равен 15. Следовательно, если значение MFI равно 15, значение MFN должно
быть нулевым.


Для более детального понимания обновил комит в fillsa ядре
https://github.com/fillsa/motomagx-kernel_l...c91231/mxc_pm.c

Если кому интересно, то переключение происходит достаточно просто, выше указанные параметры просто пишутся в HFS регистры проца через _raw_writel(); и все.

Также стоит заметить что есть 2 выходных частоты PLL: MCUPLL и USBPLL, видимо в режиме усб все работает по другому.

Единственное что мне непонятно, так это могут ли эти параметры MFI, MFN, MFD, PDF принимать любые знаяения или они задействованы еще в каких-то функциях и от болды не поставишь.
Т.к. например во всякой литературе на этот проц значения эти все такие другие, вплоть то отрицательных чисел, нежели у нас в телефоне
- MPCTL: PD = 1 (0000) | MFD = 52 (0000110011) | MFI = 10 (1010) | MFN = 12 (0000001100)
- MCPTL Multiplication Factor: 20,46153
- mpl-dpdgck-clk = 20,46153 * 26MHz = 532 MHz
——————————
- SPCTL: PD = 1 (0000) | MFD = 520 (1000000111) | MFI = 8 (1000) | MFN = -170 (1101010110)
- SCPTL Multiplication Factor: 15,3461538
- spl-dpdgck-clk = 15,3461538 * 26MHz = 399 MHz

Ах, да, На плате есть контрольная точка для замера частоты. Так что у кого осцилограф, можно прям точно померять что там выходит.

Также нашел относительно качественную отрисовку arm11 платформы внутри нашего SOC SCMA-A11. Можно детально посмотреть какие шину куда задействованы.

Сообщение отредактировал fill.sa - 25.9.2021, 13:40

[EXL]

fill.sa, круто, молодец!

Так что теперь можно более тонко дозировать необходимую частоту.

А верхний предел в "ap_pll_dp_hfs_op: 0x000000E0" (740 MHz) всё-таки остаётся, верно? Или теперь благодаря точному дозированию можно как-то вылезти за его пределы?

а как назывался то benchmark sdl который ты использовал на магиксе?

Это GPMark: https://exlmoto.ru/gpmark-multiplatform-benchmark/
Не помню, выкладывал ли его где-либо здесь.

[fill.sa]

Цитата(fill.sa @ Вчера, 18:42)
Так что теперь можно более тонко дозировать необходимую частоту.

А верхний предел в "ap_pll_dp_hfs_op: 0x000000E0" (740 MHz) всё-таки остаётся, верно? Или теперь благодаря точному дозированию можно как-то вылезти за его пределы?

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

Так что да, вылезти можно, но не ясно не навредит ли это еще чему-то.

Кстати, итоговую частоту по факту можно видеть в файлах ядра
root# cat /proc/cpu/clocks
MCUPLL: 728000000
CPU_CLK: 728000000

А вот файла который ранее смотрели /sys/mpm/op это скорее выбраный режим, а не итоговая частота.

Это GPMark: https://exlmoto.ru/gpmark-multiplatform-benchmark/
Не помню, выкладывал ли его где-либо здесь.

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

Сообщение отредактировал fill.sa - 25.8.2021, 16:04

[fill.sa]

Сделал пересчеты и поднял частоту до 780

Код

root# cat /proc/cpu/clocks
MCUPLL:         780000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        780000000
AHB_CLK:        195000000

Сделал замер скорости через sysbench, в сравнении с этим Консольные приложения скорость чутка подросла, атрефактов особых не заметил.

замер sysbench

root# /mmc/mmca1/.bin/sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Random number generator seed is 0 and will be ignored


Prime numbers limit: 20000

Initializing worker threads...

Threads started!


General statistics:
total time: 1423.1868s
total number of events: 10000
total time taken by event execution: 1423.0366s
response time:
min: 140.99ms
avg: 142.30ms
max: 174.53ms
approx. 95 percentile: 146.43ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 1423.0366/0.00

[close]

Замеры через gpmark тут Сборка ядра для ZN5. Compiling your own kernel

К слову, если кто не заметил, мы разгоняем выходную частоту PLL, а соответственно это разгоняет не только частоты шины проца, но и других шин.
Так например подымается частоты шины AHB и соответственно видяхи. И с учетом делителя divider_ratio: ARM_AHB_IPG_RATIO_148, становится

Код

IPU_CLK:        195000000

Сообщение отредактировал fill.sa - 29.8.2021, 16:34

[VINRARUS]

fill.sa, память гониться?

атрефактов особых не заметил.

Особых?

[fill.sa]

fill.sa, память гониться?

А хз, у нее так то своя шина отдельная, смотри картинку выше добавил.
Поидее нужно поискать в исходниках как там для нее значения задаются. Но тут еще момент, что по литературе чип памяти поддерживает только 133Мгц и если например поднять частоту шины, как на это сама память отреагирует хз.

Особых?

Просто я погонял минут 30 тел и все, потому и особых, может оно вылезет через время.

VINRARUS,
ты мне еще проверь как меняться скорость при увеличении оперативки для видяхи.

Сообщение отредактировал fill.sa - 25.8.2021, 18:04

[EXL]

Так например подымается частоты шины AHB и соответственно видяхи.

Тогда результаты benchmark'а GPMark на SDL HW C4 должны показывать хороший прирост по скорости. Там как раз IPU задействован.