Сборка ядра для 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 задействован.

[VINRARUS]

А хз, у нее так то своя шина отдельная, смотри картинку выше добавил.

Ну в ПК если щыной гнать то всё ростёт, включая память.

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

Тайминги повысь.

[Воха]

Ну в ПК если щыной гнать то всё ростёт, включая память.

В ПК проще современное железо поставить и не заниматься непонятно чем на калькуляторе

[VINRARUS]

В ПК проще современное железо поставить и не заниматься непонятно чем на калькуляторе

Ну покупай новое железо каждый год, пока умные люди добывают бесплатную производительность из имеющегося.

[fill.sa]

Ну в ПК если щыной гнать то всё ростёт, включая память.

ПК У тебя совсем другая архитектура и по другому устроена. Ни arm ни ahb Ни ipg шины как ты понимаешь там нету и в помине.
Хотя на пк тоже свои шины отдельные есть и способы разгона тоже разные, обычно в биосе кнопачками множитель крутят и все.
А под капотом там много чего происходит .

[VINRARUS]

ПК У тебя совсем другая архитектура и по другому устроена. Ни arm ни ahb Ни ipg шины как ты понимаешь там нету и в помине.
Хотя на пк тоже свои шины отдельные есть и способы разгона тоже разные, обычно в биосе кнопачками множитель крутят и все.
А под капотом там много чего происходит .

Тайминги оперативки везде есть.

[Воха]

бесплатную

вот я лошара, потратил бабло, а мог же бесплатно разогнать шину и у меня появились бы современные инструкции у процессора и аппарратная поддержка 4K-кодеков во всех видеоредакторах

Добавлено позже (25.8.2021, 21:32):

Тайминги

только там нет графической оболочки UEFI и кнопочки OC Profile

Сообщение отредактировал Воха - 25.8.2021, 18:33

[VINRARUS]

вот я лошара,

Добавлено позже (25.8.2021, 20:39):

только там нет графической оболочки UEFI и кнопочки OC Profile

А зачем тебе, если ты каждый раз новое поколение чего-нибудь покупаеш: телефонов, ПК, штанов?

Сообщение отредактировал VINRARUS - 25.8.2021, 18:40

[fill.sa]

Цитата(fill.sa @ Сегодня, 0:28)
Так например подымается частоты шины AHB и соответственно видяхи.

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

Да поднялось, все параметры по немного выше чем на твоих снимках.

[EXL]

Да поднялось, все параметры по немного выше чем на твоих снимках.

При простом изменении ap_pll_dp_hfs_op как у меня IPU_CLK тоже менялась?

[fill.sa]

Цитата(fill.sa @ Сегодня, 1:48)
Да поднялось, все параметры по немного выше чем на твоих снимках.

При простом изменении ap_pll_dp_hfs_op как у меня IPU_CLK тоже менялась?

Скорее всего да.
Тут нужно смотреть на делитель ARM_AHB_IPG_RATIO_... , т.е. при всех стандартных вариантах всегда 133 получается.
Например
399Мгц , делитель 1:3:6 , 399 /3 = 133
532Мгц , делитель 1:4:8 , 532/4 = 133

В моем и твоем случае делитель был 1:4:8, но вот частота уже выше 532, значит например 740/4 = 185
и у меня 780/4 = 195


Добавлено позже (25.8.2021, 20:04):
Значения делителей к слову предустановлены в железке. И не знаю, извините как свои делители сделать.
Т.к. в ядре дефайн
#define ARM_AHB_IPG_RATIO_112 0x00000812
#define ARM_AHB_IPG_RATIO_124 0x00000824
#define ARM_AHB_IPG_RATIO_136 0x00000836
#define ARM_AHB_IPG_RATIO_148 0x00000848
#define ARM_AHB_IPG_RATIO_224 0x00000024
#define ARM_AHB_IPG_RATIO_248 0x00000048
#define ARM_AHB_IPG_RATIO_212 0x00000012

А дальше число пишется в свой регистр. Как угадаь какое число например для делителя 3:1:2

Так бы можно было сделать проц 133, а видяха по идее 399 станет.

Добавлено позже (25.8.2021, 20:22):
Странно там все таки эти делители считаются
Вообщем взял родные 532 и делитель 2:4:8

В итоге pll 532 как положено , но проц стал 266 , а ahb и видяха соответственно упали на 66,5

Код

root# cat /proc/cpu/clocks
MCUPLL:         532000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        266000000
AHB_CLK:        66500000
IPG_CLK:        33250000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        66500000
SDMA_CLK:       33250000
SDHC1_CLK:      0
SDHC2_CLK:      48000000

Добавлено позже (25.8.2021, 20:50):
И так,коли я уже добрался до телефона, нужно было проверить видяху уже на норм частотах.
Поднял до 266, а проц тоже на 266 чтобы не грелось и заодно делитель подощел родной.

Код

MCUPLL:         266000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        266000000
AHB_CLK:        266000000
IPG_CLK:        133000000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        266000000

Итог замеров, не особо впечатляет.
Некоторые показатели примерно как на стандарте с процем 532, некотрые заметно меньше. Видать все таки без проца только на одной видяхе далеко не уехать.
Так то по сути с видяхой вырвались в перед 3,4,5 показатели, видимо они прям за графику отвечают.


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

[EXL]

fill.sa,
Итак, похоже что явное дросселирование тактов (throttling) лежит где-то между 780-790 MHz, было бы интересно узнать эту цифру точнее и нащупать чёткую границу. Вполне возможно что CPU (MCUPLL) отдельно от других частот можно разогнать даже и повыше, а в throttling SOC падает, например, из-за предела по частоте IPU или любой другой.

Ещё мне интересно было бы сравнить USBPLL на разных прошивках, например, на официальной стоковой 05R и на 7FR. Раз вот тут SanchoNT говорит про увеличение скорости передачи данных по USB на 7FR в сравнении с другими прошивками, значит эта частота должна быть выше: Сборка ядра для ZN5. Compiling your own kernel. А раз её выкатили в релиз, то она скорее всего должна быть безопасной. Есть ли у нас исходники ядра 7FR, чтобы проверить то, какие именно значения частоты там и как они отличаются?

С этой частотой USB вспоминается мне один забавный факт из мира P2K-телефонов. Была такая интересная багофича в Motorola E398: когда подсоединяешь телефон к компу USB-шнурком в режиме накопителя, скорость записи на карту памяти и вообще очень медленная. Файл размером 5 МБ заливался примерно минуту-полторы. Но стоит зайти в обычный стандартный видеоплеер, включить любой ролик и поставить его на паузу — скорость передачи данных по USB существенно увеличивается. Кажется даже в несколько раз. Разница в скорости была настолько существенной, что люди вот так вот заморачивались и делали подобные 3GP-видеоролики с говорящим названием и просто чёрным экраном крошечного размера на пару секунд, чтобы места в телефоне не занимал. И включали это видео при загрузке какой-нибудь музыки по шнурку:



Интересна техническая сторона такого хака, наверное при запуске видеоплеера частота USB или даже самого процессора уходит в какой-то буст.

Добавлено позже (26.8.2021, 10:51):
fill.sa, ты вроде как ковырял исходники множества ядер, в т. ч. и от последних телефонов на MotoMAGX -- Motorola VE66/EM35. не замечал ли там каких-нибудь различий в тех константах из которых высчитывается USBPLL? Вообще попробуй поиграться с этой частотой и попробуй замерить скорость передачи данных по USB на её разных значениях. В теории можно сделать модуль ядра и deamon который бы автоматически повышал эту частоту при подключении USB-кабеля и возвращал дефолтные значения после его извлечения. Или просто приложение, которое бы делало это в ручном режиме.

[VINRARUS]

Напряжение на каких частотах повышается?

тут SanchoNT говорит про увеличение скорости передачи данных по USB на 7FR в сравнении с другими прошивками

На 7FR просто скорость работы с флешкой в несколько раз выше. Сделано для возможности записи видео в 240х320, по моему мнению.

ftp по USB показывает аналогичные скоростя с другими прошами, но в режыме USB флеэшки 2 Мб/с даёт (на других прошах 1,5 Мб/с гдето).

Есть ли у нас исходники ядра 7FR, чтобы проверить то, какие именно значения частоты там и как они отличаются?

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

[fill.sa]

Ещё мне интересно было бы сравнить USBPLL на разных прошивках, например, на официальной стоковой 05R и на 7FR. Раз вот тут SanchoNT говорит про увеличение скорости передачи данных по USB на 7FR в сравнении с другими прошивками, значит эта частота должна быть выше:

нее, это две не связные вещи. USBPLL как я понял используется в режиме карты памяти и это связано с особенностью usb который требуется жесткие значения частоты. И чтобы нужную частоту через делитель получить можно было всю систему заганять в определенные рамки. На скорость это никак невлияет. В плане скорость записи то не измениится от этого.

Теперь касаемо скорости, я уже как-то описывал как это работает.
т.к. у нас усб ему и все данные в проц прогоняются через схему атласа, получается ограничение скорости т.к. атласе только usb1.1.
Но хитрость в том, что в режиме карты памяти тел использует отдельную микросхему, которая прогоняет данные через себя напрямую в проц и тут уже получается поддержка usb2.0 и соответствующая скорость.
Так что по фтп и самбе скорость гарантирваная маленькая будет(хотя я помню как то умудрился в режиме тул переключить усб на работу через эту микруху)
Другое дело почему скорость в режиме карты разнится, тут нужен долгий анализ. Может какой драйвер улучшели. хз.

Добавлено позже (27.8.2021, 3:52):
на ve66 такие же частоты. Да и как я говорил, скорость явно связана с другим.
Если как винрарус пишет, что обычная скорость записи на карту памяти на 7FR выше, то вот и ответ почему по усб быстрее пишется.
Нужно копать в эту сторону, поидее драйвер mmc и sdhc смотреть. Но драйвер идет встроенный в ядро, так что ничего там не посмотришь.
Но можно замутить проверку, обычную прошу и ядро от 7fr и проверь скорость, если взлетит хотябы будет понятно что дело точно в ядре и его драйверах.

[EXL]

Напряжение на каких частотах повышается?

133-399: 1.2 V (LO_VOLT)
532-780: 1.6 V (HI_VOLT)
Не знаю, возможно ли повысить напряжения питания CPU из ядра Linux. Посмотрел в исходники ядра и нашёл там функцию mxc_pm_chgvoltage(), похоже что установка вольтажа там осуществляется простым переключением регистров:

Код

>>> bin(0x00000000 | 0x00000004)
'0b00000000000000000000000000000100'

>>> bin(0xFFFFFFFF & (~0x00000004))
'0b11111111111111111111111111111011'

Где 0x00000004 это MXC_DSM_CRM_CTRL_DVFS_VCTRL. Третий бит с конца отвечает за то, какой вольтаж (LO_VOLT или HI_VOLT) будет использоваться. То есть сырых значений напряжений по сути нет, они похоже просто в железе. Насчёт частот/таймингов/делителей памяти, нужно курить всё связанное с SDRAM в ядре.

fill.sa или VINRARUS можете сделать таблички cat /proc/cpu/clocks для всех частот:

1. 133 MHz
2. 266 MHz
3. 399 MHz
4. 532 MHz
5. 740 MHz (по методу из стартового поста темы)
6. 780 MHz (по методу fill.sa)

Интересно как именно там всё будет меняться.

[fill.sa]

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

fill.sa или VINRARUS можете сделать таблички cat /proc/cpu/clocks для всех частот:
133 MHz
266 MHz
399 MHz
532 MHz
740 MHz (по методу из стартового поста темы)
780 MHz (по методу fill.sa)
Интересно как именно там всё будет меняться.

А что ты тменно там хочешь увидеть? Оно в принципе и так просчитывается какие значения будут.

[EXL]

fill.sa,
Да это было бы полезной информацией для сравнения. Вручную высчитывать каждый раз определённую частоту и делители сверяясь с исходниками времязатратно.

[VINRARUS]

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

Как будто в linux есть альтернативы.

EXL,

cat /proc/cpu/clocks

Код

// 133 MHz
mcupll:         266000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        133000000
ahb_clk:        133000000
ipg_clk:        66500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        133000000
sdma_clk:       66500000
sdhc1_clk:      0
sdhc2_clk:      48000000

Код

// 266 MHz
mcupll:         266000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        266000000
ahb_clk:        133000000
ipg_clk:        66500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        133000000
sdma_clk:       66500000
sdhc1_clk:      0
sdhc2_clk:      48000000

Код

// 399 MHz
mcupll:         399000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        399000000
ahb_clk:        133000000
ipg_clk:        66500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        133000000
sdma_clk:       66500000
sdhc1_clk:      0
sdhc2_clk:      48000000

Код

// 532 MHz
mcupll:         532000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        532000000
ahb_clk:        133000000
ipg_clk:        66500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        133000000
sdma_clk:       66500000
sdhc1_clk:      0
sdhc2_clk:      48000000

Код

// 636 MHz
mcupll:         636000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        636000000
ahb_clk:        159000000
ipg_clk:        79500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        159000000
sdma_clk:       79500000
sdhc1_clk:      0
sdhc2_clk:      48000000

Код

// 740 MHz
mcupll:         740000000
usbpll:         240000000
dsppll:         156445989
cpu_clk:        740000000
ahb_clk:        185000000
ipg_clk:        92500000
nfc_clk:        0
usb_clk:        0
uart1_baud:     0
uart2_baud:     0
uart3_baud:     0
i2c_clk:        13000000
ipu_clk:        185000000
sdma_clk:       92500000
sdhc1_clk:      0
sdhc2_clk:      48000000

780

fill.sa в помощь.

[close]

[close]

[fill.sa]

Как будто в linux есть альтернативы.

ну у тебя то не голый линукс, а встраиваемая система с кучей всякого.

[fill.sa]

Что-то пошло не так, значения которые я записал и вставил на форуме, по факту не 780, видимо не то скопировал. По факту то я смотрел в телефоне и было 780 и видяха там тоже до 195 подымалась, так что проц точно был 780.
Но сейчас что-то не получается посчитать нормально 780Мгц, получаются не делимые числа. Вообщем беда.
Затем я посидел и вспомнил, я брал для mfn ноль.

Код

        /* 780Mhz */ {
                       ap_pll_dp_hfs_op:    0x000000F0, // Writing 0 to PDF(divide by 1) and F to MFI(MFI = 15)
                       ap_pll_dp_hfs_mfn:   0x00000000, // Writing MFN as 0
                       ap_pll_dp_hfs_mfd:   0x01FFFFFE, // Writing MFD as 33554430

Теперь о хорошем, попробовал поиграться с видяхой.
Во первых пересчитал частоту на 665Мгц чтобы она ровно через 133 была и тем самым удобно делителем получать 133Мгц частоты.
А во вторых так же удобно делать разгон видяхи.
Значения вот, вроде нужные скопировал )) Вернее там почти 665, лень было прям до милионных долей высчитывать.

Код

/* 665Mhz */ {
                       ap_pll_dp_hfs_op:    0x000000C0, // Writing 0 to PDF(divide by 1) and C to MFI(MFI = 12)
                       ap_pll_dp_hfs_mfn:   0x0193B139, // Writing MFN as 26456377
                       ap_pll_dp_hfs_mfd:   0x01FFFFFE, // Writing MFD as 33554430

Сделал разгон видяхи для режимов проца 532 и 665, итоги ниже
532Мгц проц, 177Мгц видяха 665Мгц проц, 221Мгц видяха

532Мгц проц, 177Мгц видяха

Код

root# cat /proc/cpu/clocks
MCUPLL:         532000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        532000000
AHB_CLK:        177333333
IPG_CLK:        88666666
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        177333333
SDMA_CLK:       88666666
SDHC1_CLK:      0
SDHC2_CLK:      48000000

[close]

665Мгц проц, 221Мгц видяха

Код

MCUPLL:         664999999
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        664999999
AHB_CLK:        221666666
IPG_CLK:        110833333
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        221666666
SDMA_CLK:       110833333
SDHC1_CLK:      0
SDHC2_CLK:      48000000

[close]

Смутила что разбежка прям большая, решил сделать замер на родных значениях видяхи с процем 532Мгц и 636Мгц.
532Мгц 636Мгц

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

Но все таки радует что видяха гонится и прилично так заметна разница. Есть еще идея поиграться с размером памяти для видяхи, как оно повлияет.


Ну и нужно вспомнить как я 780Мгц насчитал ))

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

[VINRARUS]

fill.sa, ты хоть фиксируеш частоту ЦП?

Код

pmtool -d 0

[fill.sa]

fill.sa, ты хоть фиксируеш частоту ЦП?

ясен красен, толку от замера с плавающей частотой.

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

Если смотреть на замеры строго с частотой проца растет один параметр, а второй наоборот падает.

Это стандартные так сказать замеры : 636(это частота как вы понимаете подымает и видяху) 532 399 266

Код

root# cat /proc/cpu/clocks
MCUPLL:         636000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        636000000
AHB_CLK:        159000000
IPG_CLK:        79500000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        159000000
SDMA_CLK:       79500000
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 13.44 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 5.21 seconds
root# ./.bin/fb_sierpinski
Segmentation fault

Код

root# echo 532 > /sys/mpm/op; cat /proc/cpu/clocks
MCUPLL:         532000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        532000000
AHB_CLK:        133000000
IPG_CLK:        66500000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        133000000
SDMA_CLK:       66500000
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 11.25 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 6.24 seconds
root# ./.bin/fb_sierpinski
Segmentation fault

Код

root# echo 399 > /sys/mpm/op; cat /proc/cpu/clocks
MCUPLL:         399000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        399000000
AHB_CLK:        133000000
IPG_CLK:        66500000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        133000000
SDMA_CLK:       66500000
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 8.39 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 8.32 seconds
root# ./.bin/fb_sierpinski
Segmentation fault

Код

root# echo 266 > /sys/mpm/op; cat /proc/cpu/clocks
MCUPLL:         266000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        266000000
AHB_CLK:        133000000
IPG_CLK:        66500000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        133000000
SDMA_CLK:       66500000
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 5.57 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 12.56 seconds
root# ./.bin/fb_sierpinski
Segmentation fault

[close]

Это с разогной видяхой и процем 665

Код

MCUPLL:         664999999
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        664999999
AHB_CLK:        221666666
IPG_CLK:        110833333
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        221666666
SDMA_CLK:       110833333
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 14.09 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 4.97 seconds

Код

root# echo 532 > /sys/mpm/op; cat /proc/cpu/clocks
MCUPLL:         532000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        532000000
AHB_CLK:        177333333
IPG_CLK:        88666666
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        177333333
SDMA_CLK:       88666666
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# cd /mmc/mmca1/
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 11.23 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 6.23 seconds

Код

root# echo 399 > /sys/mpm/op; cat /proc/cpu/clocks
MCUPLL:         399000000
USBPLL:         240000000
DSPPLL:         156445989
CPU_CLK:        399000000
AHB_CLK:        133000000
IPG_CLK:        66500000
NFC_CLK:        0
USB_CLK:        0
UART1_BAUD:     0
UART2_BAUD:     0
UART3_BAUD:     0
I2C_CLK:        13000000
IPU_CLK:        133000000
SDMA_CLK:       66500000
SDHC1_CLK:      0
SDHC2_CLK:      48000000
root# ./.bin/fb_rectangle
Rectangle frame buffer test bench
Benchmarking 60x80 size: 8.39 MPixels/second
root# ./.bin/fb_mandelbrot
Mandelbrot frame buffer test bench
Benchmarking 48 iterations: 8.37 seconds

[close]

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

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

[VINRARUS]

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

Работающий з IPU?

[fill.sa]

аботающий з IPU?

и ?

fill.sa или VINRARUS можете сделать таблички cat /proc/cpu/clocks для всех частот:

EXL,
cat /proc/cpu/clocks

В свзяи с тем, что мои расчеты потерялись. Решил тогда уже поискать границу до куда гонится проц.
по всей видимости 780 предел, на 782 уже падает моща.
замеры gpnark и sysbench

название

oot# ../.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: 1475.1902s
total number of events: 10000
total time taken by event execution: 1475.0572s
response time:
min: 145.78ms
avg: 147.51ms
max: 160.58ms
approx. 95 percentile: 151.74ms

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

root#

[close]

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

[VINRARUS]

И всё таки, 798 МГц на началах было правдой?

gpnark и sysbench

Код

7z b

лучшый бенчмарк, в связи в отсустсвии полноценного winrar.

[fill.sa]

И всё таки, 798 МГц на началах было правдой?

Да блин ты что за темой не следил
Вот же все писал Сборка ядра для ZN5. Compiling your own kernel
780Мгц вот он предел для проца. Жди обновление комита с новым разгоном на гите
https://github.com/fillsa/motomagx-kernel_l.../commits/master

Дальше уже буду заниамться разгоном видео(частично я уже кидал раньше замеры) и если повезет оперативки.

Код
7z b
лучшый бенчмарк, в связи в отсустсвии полноценного winrar.

Сильно сомневаюсь что он хоть как-то задействует графические вычисления.
И что в твоем понимании полноценный winrar, winrar это гуева прога под виндой. А в консоли что на винде что в лине там unrar и rar. rar проприетарный и исходников никогда не будет. unrar пользуй на здоровье. Я даже вроде собирал под магикс его.

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

[EXL]

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

Не забывай, у меня ZN5 РСТ тогда был с 64 MB RAM и на другой прошивке вообще. Результаты и должны быть разными, GPMark слишком много различных сложных операций на IPU (если используется SDL HW) делает, вроде поворота и масштабирования картинки, так что их точность всегда будет приблизительна, как и в любых графических бенчмарках.

И всё таки, 798 МГц на началах было правдой?

Нет, всё как писал fill.sa в этом посте, я просто менял значение с шагом повторяя другие частоты и предположил (неверно), что итоговая частота CPU должна получиться 798 MHz.

лучшый бенчмарк, в связи в отсустсвии полноценного winrar.

Относительную скорость архивации на CPU он должен показать, но что-то как я ни просил тут, так никто и не сделал это, например: Софт для ZN5 и прочих MotoMAGX: MGX и PEP

Ну может с частотами проверить у кого-нибудь интерес будет.

[VINRARUS]

и ?

Много где есть IPU, но нет GPU?
Я к тому шо именно бенчмарк должен проверять.
ПС: может java бенчмарк какой подойдет? Вроде бы у java машыны наилучшая поддержка железа должна быть.

Да блин ты что за темой не следил

Там не уточнивается расщот при чтении или при записи (/sys/mpm/op например).
Уточнение №2: 740 МГц по старому методу какой реальной частоте соответствует, раз она щитается, а не отображаєтся?

780Мгц вот он предел для проца.

Я правильно понял шо предел этот заложен намеренно производителем, а не фактический предел кремния?

Сильно сомневаюсь что он хоть как-то задействует графические вычисления.

rar проприетарный и исходников никогда не будет.

Об этом.

но что-то как я ни просил тут, так никто и не сделал это

Я ж когдато шото компили с этими О2 и О3 и писал шо разницы небыло. Кто то удалил?

Сообщение отредактировал VINRARUS - 29.8.2021, 19:00

[EXL]

780Мгц вот он предел для проца

А вдруг 781 MHz?

Сильно сомневаюсь что он хоть как-то задействует графические вычисления.

Конечно не задействует, но 7z b 3 проверит прикладную задачу -- относительную скорость распаковки и запаковки при разгоне. А единственный бенчмарк который сейчас задействует IPU это GPMark и только на SDL HW библиотеке. Если есть ещё какие-нибудь бенчмарки на SDL, можно тоже их портировать и они тоже будут использовать IPU. Но что-то я таких не знаю и не помню.

Можно извратиться и без SDL попробовать написать приложение-бенчмарк по типу GPMark для IPU, но вряд ли это будет оправданным.

Много где есть IPU, но нет GPU?

Да, есть такие устройства. На тех же древних Freescale i.MX или вот была помнится портативная консолька GP2X, там подобие нашего IPU тоже имеется и SDL-библиотека тоже его там использовала для тех же самых фич, что и наша SDL HW, вроде аппаратного скейлинга 640x480 => 320x240, эх жаль Ant-ON её релизнул когда ZN5 уже стал устаревшим, а не в годы его популярности.

ПС: может java бенчмарк какой подойдет? Вроде бы у java машыны наилучшая поддержка железа должна быть.

Нужно смотреть, задействуется ли в Java-машине kvm этот IPU, грепать бинарь kvm и все либы, которые он использует (см. ldd `which kvm`) на предмет наличия там строк связанных с IPU, вроде alt_mxc_ipu_pp.

Для Java я с исторических времён использовал JBenchmark 1, его можно попробовать ради интереса, мне помнится он давал очень интересные результаты, из которых был сделан вывод, что производительность Java-машины как-то зависит от ленга. Помните всякие там турболенги? Так вот, помню что на стандартной прошивке этот бенч показывал 4500-5000, а на Симбиозисе с турболеном-- 8500-9000.

Уточнение №2: 740 МГц по старому методу какой реальной частоте соответствует, раз она щитается, а не отображаєтся? Я правильно понял шо предел этот заложен намеренно производителем, а не фактический предел кремния?

По старому методу 740 MHz соответствует 740 MHz, неправильно расчитанными были только частоты из моей первой попытки. А правильные всегда можно посмотреть в cat /proc/cpu/clocks, графа cpu_clk. Насчёт предела, это просто частота с которой начинается тротлинг и вместо дальнейшего прироста производительности получается снижение. А вот какой именно компонент SOC падает в тротлинг или вообще всё -- неизвестно и нужно экспериментальными методами выяснять. Например, как-то попробовать снизить частоту IPU, оставив частоту CPU выше предельной. Если это вообще возможно. А предел сейчас лежит между 780-781 MHz включительно.

Я ж когдато шото компили с этими О2 и О3 и писал шо разницы небыло. wacko.gif Кто то удалил?

Я точно не видел, а разница пусть даже незначительная по идее должна была быть.

[EXL]

fill.sa, Идея для следующего эксперимента с поднятием только частоты IPU. Ты ведь уже делал 266 MHz CPU @ 266 MHz IPU? По дефолту без разгона на 266 MHz CPU у IPU будет 133 MHz.

1. Снимаем результаты GPMark на SDL HW, частоты 266 MHz CPU @ 133 MHz IPU.
2. Снимаем результаты GPMark без разгона IPU на обычной SDL, частоты 266 MHz CPU @ 133 MHz IPU.

3. Разгоняем IPU до 266 MHz.

4. Снимаем результаты GPMark на SDL HW, частоты 266 MHz CPU @ 266 MHz IPU.
5. Снимаем результаты GPMark без разгона IPU на обычной SDL, частоты 266 MHz CPU @ 266 MHz IPU.

Цель: выяснить какая будет корреляция между разогнанным IPU и нет и проверить теорию. В теории результаты бенчмарка на обычной SDL-либе не должны давать существенного прироста производительности при разгоне IPU. В процентном соотношении результаты по SDL HW между разогнанным IPU и нет должны быть выраженны более ярко.

Обычную SDL-либу взять можно в этом архиве.

И проверь ещё пожалуйста JBenchmark 1 на Java из поста выше. При 780 MHz там кажется должно быть больше 10К

[fill.sa]

Цитата(fill.sa @ Сегодня, 20:38)
и ?

Много где есть IPU, но нет GPU?

Ну все imx по 8 версию с ipu идут. А imx достаточно популярная платформа, просто у них своя ниша. Тот же наш imx3 мнгого где применялся, начиная от корманных проигрывателей и заканчивая телефонами нокия и блэкбэри.

ПС: может java бенчмарк какой подойдет? Вроде бы у java машыны наилучшая поддержка железа должна быть.

Вот это дельная мысль, нужно что то приличное поискать.

780Мгц вот он предел для проца.

Я правильно понял шо предел этот заложен намеренно производителем, а не фактический предел кремния?

Это в какой строчке ты такое прочитал? ) нет такого понятия намерено заложено. Тут не биос с кнопкой разогнать, тут ты сам напрямую в регистры проца все пишеш. Намерено он заложил при расчетах 532, а по факту гони как хочешь, тока все нестабильно и ненадежно, а после 780 просто падает производительность, вероятнее всего из-за того что уже сбиваются такты и в итоге пропускаются вычисления.

Там не уточнивается расщот при чтении или при записи (/sys/mpm/op например).
Уточнение №2: 740 МГц по старому методу какой реальной частоте соответствует, раз она щитается, а не отображаєтся?

Чтение запись? Ты про что )) это частота для задания частоты работы проца в целом. Проц ниче непишет, он только считает.
И все показывается, только смотреть нужно в правильном месте, в /proc/cpu/clock . Название файла говорит за себя. А если ты про mom , то это просто режим работы, на действительную частоту оно не влияет, там может быть любая цифра.

Добавлено позже (29.8.2021, 22:31):

А вдруг 781 MHz?

Сразу видно кто следил за темой ))) 781 там фигово считается. Но можно заморочиться проверить.

Добавлено позже (29.8.2021, 22:34):
Есть еще идея замеры с разным размером памяти сделать. Но это походу работает только на ядрах lj6.1, но это покач-то и неточно.
Нужно что бы вин проверил на своем z6, файл я уже кидал ему.

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