Сборка ядра для 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. Мануал.

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

[VINRARUS]

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

Не.

У тебя dmesg забивается многомегабайтным флудом этих сообщений и его начала тупо нет.

Защита от хакеров.

[fill.sa]

Провел тут температурные тесты

условия теста:
-температура помещения 23
-тел на столе экраном вверх
-меряю прямиком на проце, через окошко в защитном экране подлез
мерял китайский мультиметром

в простое 30-32
133 - 32-34
266 - 32-33 хорошо прогрев 34-35
399 - 33-35 хорошо погрев 36-37
532 - по началу 34-37 через продолжительное время 39-40 хорошенько подождав 41 и даже мелькало 42
636 - по началу 36-39 погрузив некоторое время 39-41 через длительное прогой винраруса получилось прогреть до 41-43 и потом даже помелькало 44
740 - достаточно быстро до 40-41 подождав по дольше 43-45 и помелькало немного 46

[fill.sa]

Где-то разговор про скорость по USB была, чего-то не нашел поста того.
Вообщем проверил у себя в моде, как положено 1500кбс заливает файл.

[Unreal_man]

fill.sa,

Где-то разговор про скорость по USB была, чего-то не нашел поста того.
Вообщем проверил у себя в моде, как положено 1500кбс заливает файл.

Ага, я сам где-то прочёл и задавал вопрос по поводу скорости передачи. Как так? На ZiniMOD у меня 700. В чём разница, если никто насильно это не правил?

Сообщение отредактировал Unreal_man - 24.10.2016, 22:08

[fill.sa]

Unreal_man,
ну почемуже, у меня порядком измененное ядро, я много чего в нем изменял и половину сам непомню что та )))

[Unreal_man]

у меня порядком измененное ядро

А что в ядре даёт такую скорость. Можно в другом моде такое реализовать(в частности ZiniMod)? Твой мод на зину не ставил, но он на V8 у меня стоит. Слишком он простой. Может на зине в SAedition чего поболее реализовано канеш, но я уже вылизал всё так как надо на моде Вина.

[fill.sa]

Unreal_man,
ну нефакт что тут только ядро влияет.

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

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

[Unreal_man]

fill.sa, ну так как сделать так, чтоб и у меня скорость передачи была 1500, кроме как перешиваться твоим модом?

[VINRARUS]

ну так как сделать так, чтоб и у меня скорость передачи была 1500, кроме как перешиваться твоим модом?

Если не в курсе на ZiniMod в режиме "Синхронизация" с Windows 10 скорость записи большого файла 3 Мб/с (при чтении правда 1,3). Винда глюкнула. 1,3 Мб/с потолок у меня в обе стороны в том режиме.
ПС: зачем тебе высокая скорость, все равно ты вебгалереей не пользуешся. А при залитии файлов кардридер в разы быстрее все равно.

Сообщение отредактировал VINRARUS - 27.10.2016, 13:15

[Unreal_man]

А при залитии файлов кардридер в разы быстрее все равно

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

Так что там за режим такой синхронизации? Где он включается?

[VINRARUS]

Так что там за режим такой синхронизации? Где он включается?

Там где и все другие, в настройках ЮСБ.

[fill.sa]

А можно узнать на какой частоте загружается тел? Может там по дефолту на 133 грузится. И в какой момент апмд врубается? Может можно это контролировать? Если будет 740, то и грузиться будет быстрее?

Тел грузится с максимальной частотой пока не подхватится apmd. А он уже в каждом моде по свойму.
И фишка в том что при таком мощном старте в 740 пол батареи уже сядит. Нужно вам такое?

А вот похоже и ответ найден

Код

         * If the bootloader is an older one that uses LFS mode, then
     * we have already set cur_dvfs_op_point_index.  Otherwise, we
     * need to do it here.
     */
if (bootloader_used_lfs == 0) {
        switch (mot_boot_frequency()) {
        case BOOT_FREQUENCY_532:
            cur_dvfs_op_point_index = INDX_532;
            break;
        case BOOT_FREQUENCY_399:
        default:
            cur_dvfs_op_point_index = INDX_399;
            break;
        }
    }

Т.е. указано четко на какой частоте стартовать. Менять еще непробовал но думаю это оно и есть.

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

[Unreal_man]

fill.sa, тогда с тебя результаты замеров секундомера

Сообщение отредактировал Unreal_man - 3.11.2016, 21:59

[fill.sa]

Оставлю ссылочку тут
https://www.kernel.org/pub/linux/kernel/v2.6/

Все исходники ядер 2.6 ,а также список изменений от версии к версии, а также, видимо, патчи для изменения одной версии ядра в другую.

Если кто в ладах с инглишем, можно в истории поискать полезные изменения для нас и попробовать их портироваьт на наше ядро.

[Unreal_man]

Изменения в
сорцах ядра
Файл 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.

EXL, ты писал что:
выше 0x000000E0
у меня начиналось нечто вроде
дросселирования тактов CPU:
производительность резко
снижалась, да и вообще
появлялось огромное
количество глюков, появлялись
зелёные артефакты на экране
и т. д.

Ты все возможные значения выше 0х000000Е0 пробовал? А если вставить 0х00000100?

Добавлено позже (8.7.2017, 21:58):
Как я могу потестить дыс шит? Или тут спецзнания нужны?

Добавлено позже (8.7.2017, 22:37):
Заставил себя перечитать тему. Ты ставил 931мгц. Как я понял, это и есть 0x00000100.

Сообщение отредактировал Unreal_man - 8.7.2017, 19:01

[VINRARUS]

Как я могу потестить дыс шит? Или тут спецзнания нужны?

Дуже просто.
Но сначала на ПК поставь Linux.
Или в virtual box, если без винды жыть не можеш, но это не так удобно будет.

Сообщение отредактировал VINRARUS - 9.7.2017, 9:04

[EXL]

Ты все возможные значения выше 0х000000Е0 пробовал? А если вставить 0х00000100?

Я уже не помню что там вписывал, это 7 лет назад было. Но по-любому это значение проверял. Вообще спроси fill.sa он недавно копал ядро в сторону разгона и менял эти значения тоже.

Если я правильно помню, были артефакты на экране и нестабильная работа, общее замедление скорости и пр.

[fill.sa]

0x000000E0 , предел. Чему это значение точно равно никто не знает, EXL предположил что это 798.
Выше 0x000000E0 все как и exl писал в самом начале.

[VINRARUS]

были артефакты на экране и нестабильная работа, общее замедление скорости и пр.

Шобы гнать дальше нужно поднимать напряжение - это любой оверклокер вам скажет.
Просто нам повезло шо 399-532 ступень напряжение подымала, и этого хватило для 740 (798?) МГц.

[fill.sa]

были артефакты на экране и нестабильная работа, общее замедление скорости и пр.

Шобы гнать дальше нужно поднимать напряжение - это любой оверклокер вам скажет.
Просто нам повезло шо 399-532 ступень напряжение подымала, и этого хватило для 740 (798?) МГц.

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

[VINRARUS]

нормальный оверклокер сперва спросит какую из частот мы подымали.

Тактовую частоту ядра.

[fill.sa]

нормальный оверклокер сперва спросит какую из частот мы подымали.

Тактовую частоту ядра.

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

Сообщение отредактировал fill.sa - 11.7.2017, 5:47

[fill.sa]

Разбираю свои архивы.
Вот как-то пробовал добавить в ядро поддержку squashfs 3.0 Может кто сможет докопаться до истины, я так до конца и не смог.
На сколько помню тел всегда успешно стартовал до GUI, но дальше отказывался, хотя тел не зависл, все процессы запущеные до гуи успешно работают. Если убать из запуска все сервисы для gui, запуститься и потом удаленно запускать гуишку, то гуишка вела себя странно, как-будто тел сваливалась в какой-то сервисный режим, пологаю на подобие режима tcmd.

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

Сообщение отредактировал fill.sa - 18.7.2017, 9:01

[Unreal_man]

fill.sa, поддержку sdxc не пробовал?

[fill.sa]

fill.sa, поддержку sdxc не пробовал?

Нет у меня таких карт для теста.

[Unreal_man]

fill.sa, поддержку sdxc не пробовал?

Нет у меня таких карт для теста.

Отписался вк. Давайте скинемся филу на карту. Кому интересно - пишите.

[fill.sa]

fill.sa, поддержку sdxc не пробовал?

Нет у меня таких карт для теста.

Отписался вк. Давайте скинемся филу на карту. Кому интересно - пишите.

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

[Unreal_man]

а кто из тех у кого сейчас зина есть понимает7

[fill.sa]

Может кто еще решит заморочиться с разгонами, эта схема поможет.
Схема частот для разных элементов, правда это для argonLV, но у SCMA11 я уверен все эдентично. В этом плане они несильно отличаются.

[EXL]

Репозиторий с исходниками ядра Motorola ZN5 есть на GitHub'е, если кто не в курсе.

https://github.com/GodFox/magx_kernel_xpixl

В них уже исправлена ошибка сборки, которая возникла из-за простейшей опечатки, которую допустили инженеры Motorola.



Примечательно, что эта опечатка не проявлялась на старых версиях утилиты make, а вот с обновлением этой утилиты в современных дистрибутивах GNU/Linux, язык файлов Makefile стал более строгим и ядро перестало собираться.

[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 задействован.