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

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

[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

[VINRARUS]

Нужно что бы вин проверил на своем z6, файл я уже кидал ему.

Нету там заметной разницы.

[fill.sa]

Цитата(fill.sa @ Сегодня, 0:23)
Нужно что бы вин проверил на своем z6, файл я уже кидал ему.

Нету там заметной разницы.

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

Добавлено позже (30.8.2021, 9:33):
Кстати, разные програмульки от imx
http://repository.timesys.com/buildsources/i/
Нужно будет пособирать, там есть какие-то test программы.

[EXL]

Нету там заметной разницы.

Речь про память IPU? А чем ты тестировал?

Ну все imx по 8 версию с ipu идут.

IPU или уже VPU? По твоей ссылке в посту выше как раз есть некие VPU-утилиты и похоже прошивки.

[VINRARUS]

Это плохо, должно же как-то реагировать.

Токо шо пробовал повторно шыть — ошыбка.
Наверно и тогда не пришылось.

[fill.sa]

Речь про память IPU?

Да, вренее память та общая из опартивы, но она выдляется под использование отдельно. Вот и появилась мысль поиграться со значениями и проверить на что повлияет.

Цитата(fill.sa @ Сегодня, 4:23)
Ну все imx по 8 версию с ipu идут.

IPU или уже VPU? По твоей ссылке в посту выше как раз есть некие VPU-утилиты и похоже прошивки.

Хороший вопрос, на форумах обычно используется формулировка ipu, хотя возможно по старой памяти пишут. Ибо я тоже заметил vpu и еще есть dpu. vpu - это видео процессор юнит.
Полез смотреть литературу, нашел на imx7 imaging processor, тока не понятно это ipu или не ipu, ибо нехватает слова unit
https://www.nxp.com/products/processors-and...m4-cores:i.MX7S

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

Токо шо пробовал повторно шыть — ошыбка.
Наверно и тогда не пришылось.

Ошибка где? и какая.
По идее там ничего такого не поменялось чтобы ошибку бить.

[EXL]

Вот и появилась мысль поиграться со значениями и проверить на что повлияет.

Повлиять количество памяти IPU может лишь в тех приложениях, где IPU используется, вроде Галереи и Камеры. Ну и во всех приложениях, которые используют SDL HW, тот же GPMark.

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

Помнится, Ant-ON приводил объёмы памяти IPU, которые по-умолчанию используются в различных телефонах. Вроде как у Z6/V8 её там больше всего, а у ZN5/U9 -- меньше всего.

Насколько я помню, объём памяти IPU задаётся в comandline ядра? На MotoMAGX есть выхлоп по cat /proc/cmdline? Где вообще эта штука задаётся? В hardhat, platform или lbl?

[VINRARUS]

Ошибка где? и какая.

При прошывке, чексума по моему.

[fill.sa]

Ну и во всех приложениях, которые используют SDL HW, тот же GPMark.

Именно на этом и планировали проверять.

Вроде как у Z6/V8 её там больше всего, а у ZN5/U9 -- меньше всего.
Насколько я помню, объём памяти IPU задаётся в comandline ядра? На MotoMAGX есть выхлоп по cat /proc/cmdline? Где вообще эта штука задаётся? В hardhat, platform или lbl?

По всей видимости именно так. Тут много путей, в ядре есть явные константы, и они между ядрами lj61 и lj63 разные. Также есть возможность передать параметры ядро через comandline и вроди как это работает только на lj61, но до конца пока не разобрался. Уже когда ядра обьеденю будет понятно.

[VINRARUS]

а RAM в MotoMAGX всегда не хватает толком.

Не в 128 Мб ZN5.

[EXL]

Именно на этом и планировали проверять.

Я бы его ещё модернизировал для IPU с большим куском памяти. Например, сделал в нём разрешение 800x600, в теории это должно потребовать больше памяти и сделать разницу в результатах более явной.

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

А где этот comandline задаётся? Киньте выхлоп cat /proc/cmdline, есть ли там что-то про IPU? Разобраться в том, как его менять в оригинальных прошивках было бы полезно.

[VINRARUS]

EXL,

Код

#ZN5
noinitrd console=/dev/null rw mem=122M@0x90000000 init=/linuxrc root=/dev/mtdblock/root brdrev=P0A
motobldlabel=R6637_G_81.11.2CR_128
mtdparts=nand0:1152k@896k(pds),128k@2176k(logo_cli),128k(panel_script)ro,128k(device_tree)ro,
128k(setup),256k(logo),128k(secure),1664k(kern)ro,3968k(bpsw),256k(ho_data),256k(fota_ua)ro,384k(ua_temp),
256k(ua_backup),42m@9984k(root)ro,9m(user),9m(lang),24m(resrc),6m(fota_up),154112k(mass_storage),128k(kpanic),5760k(rsv)

#Z6
ipu_mem=1000K@0x93700000
brdrev=P3A noinitrd console=/dev/console rw mem=60M@0x90000000
init=/linuxrc ip=off root=/dev/mtdblock/root mtdparts=nand0:192k@256k(pds),128k(setup),256k(logo),128k(secure),
1536k@1088k(kern)ro,3968k(bpsw),29680k(root)ro,7680k(lang),7m(user),10752k(resrc),66512k(mass_storage),16k(kpanic),2672k(rsv)

[fill.sa]

А где этот comandline задаётся? Киньте выхлоп cat /proc/cmdline, есть ли там что-то про IPU?

Через кодовые группы, но на lj61 и lj63 это разные группы.
Про ипу там будет, на lj61 там и задается размер памяти, но у меня нет z6 посмотреть. На lj63 соответственно ничего небудет.


Добавлено позже (31.8.2021, 23:25):
VINRARUS,
А говорил не прошилось, по факту вижу , что изменения прошиты. Так что можно проверять через сдл и попробовать ява бэнчмарк что выкладывали.

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

[EXL]

fill.sa,
SDL HW при запуске любого приложения кстати в логах пишет сколько памяти удалось задействовать для IPU.

[fill.sa]

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

Не смотря на то что я уже это прделывал тут

И так,коли я уже добрался до телефона, нужно было проверить видяху уже на норм частотах.
Поднял до 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 показатели, видимо они прям за графику отвечают.

Попробовал еще раз видео на 266 для режимов проца 266 и 532
И в итоге ловил прикольные артефакты. Они не сразу появляются, примерно в момент повышения нагрузки на проц.

Хз как в прошлый раз оно так удачно сработало.
Однако ранее я проверял 195 и 221 частоты для видяхи и вроди как они стабильно работали.

[EXL]

VINRARUS, спасибо. А можешь ещё посмотреть сколько памяти IPU выделяется на SDL HW у Z6 и ZN5?

И в итоге ловил прикольные артефакты. Они не сразу появляются, примерно в момент повышения нагрузки на проц.

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

[VINRARUS]

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

Ой.

ipu_mem=1000K@0x93700000 brdrev=P3A noinitrd console=/dev/console rw mem=60M@0x90000000 init=/linuxrc ip=off root=/dev/mtdblock/root mtdparts=nand0:192k@256k(pds),128k(setup),256k(logo),128k(secure),1536k@1088k(kern)ro,3968k(bpsw),29680k(root)ro,7680k(lang),7m(user),10752k(resrc),66512k(mass_storage),16k(kpanic),2672k(rsv)

1.bmp   ( 225.05 килобайт ) Кол-во скачиваний: 18

ПС: 532 МГц.

ipu_mem=4444K@0x93700000 brdrev=P3A noinitrd console=/dev/null rw mem=60M@0x90000000 init=/linuxrc ip=off root=/dev/mtdblock/root mtdparts=nand0:192k@256k(pds),128k(setup),256k(logo),128k(secure),1536k@1088k(kern)ro,3968k(bpsw),29680k(root)ro,7680k(lang),7m(user),10752k(resrc),66512k(mass_storage),16k(kpanic),2672k(rsv)

2.bmp   ( 225.05 килобайт ) Кол-во скачиваний: 22

сколько памяти IPU выделяется на SDL HW у Z6

Вот стоко:

Z6, fill.sa мод
MAGX_VO: FB 262144@0x78000000
MAGX_VO: Try open /dev/mxc_ipu_pp...
MAGX_VO: IPU memory: 0.5 M
MAGX_VO: set new bpp 16 (24) on FB
MAGX_VO: switching to bpp: 16
MAGX_VO: seted bpp on FB
MAGX_VO: SetVideoMode width=320 height=240 bpp=16
MAGX_VO: set new bpp 16 (16) on FB
MAGX_VO: seted bpp on FB
MAGX_VO: vwidth=320 vheight=240 hw_pixel_size=2
MAGX_VO: screen rotated
MAGX_VO: PP mode: 1, PP buf count: 1
ipu_malloc alloacte page 38 gTotalPages 128
ipu_malloc: 1st current->start 0 current->end 38
MAGX: SDL request:
MAGX_VO: focus in
Screening...
MAGX: MAGX_VideoQuit
ipu_free alloacte page 0
ipu_free next->start 0 next->end 38
ipu_free prev->start 0 prev->end 0
MAGX_VO: All uninit

Z6, стандарт
MAGX_VO: FB 262144@0x78000000
MAGX_VO: Try open /dev/mxc_ipu_pp...
MAGX_VO: IPU memory: 3.8 M
MAGX_VO: set new bpp 16 (24) on FB
MAGX_VO: switching to bpp: 16
MAGX_VO: seted bpp on FB
MAGX_VO: SetVideoMode width=320 height=240 bpp=16
MAGX_VO: set new bpp 16 (16) on FB
MAGX_VO: seted bpp on FB
MAGX_VO: vwidth=320 vheight=240 hw_pixel_size=2
MAGX_VO: screen rotated
MAGX_VO: PP mode: 1, PP buf count: 1
ipu_malloc alloacte page 38 gTotalPages 960
ipu_malloc: 1st current->start 0 current->end 38
MAGX: SDL request:
MAGX_VO: focus in
Screening...
MAGX: MAGX_VideoQuit
ipu_free alloacte page 0
ipu_free next->start 0 next->end 38
ipu_free prev->start 0 prev->end 0
MAGX_VO: All uninit

ZN5
MAGX_VO: FB 262144@0x78000000
MAGX_VO: open(/dev/alt_mxc_ipu_pp): No such file or directory
MAGX_VO: Try open /dev/mxc_ipu_pp...
MAGX_VO: IPU memory: 1.5 M
MAGX_VO: set new bpp 16 (24) on FB
MAGX_VO: switching to bpp: 16
MAGX_VO: seted bpp on FB
MAGX_VO: SetVideoMode width=320 height=240 bpp=16
MAGX_VO: set new bpp 16 (16) on FB
MAGX_VO: seted bpp on FB
MAGX_VO: vwidth=320 vheight=240 hw_pixel_size=2
MAGX_VO: screen rotated
MAGX_VO: PP mode: 1, PP buf count: 1
ipu_malloc alloacte page 38 gTotalPages 384
ipu_malloc: 1st current->start 0 current->end 38
MAGX: SDL request:
MAGX_VO: focus in
MAGX: MAGX_VideoQuit
ipu_free alloacte page 0
ipu_free next->start 0 next->end 38
ipu_free prev->start 0 prev->end 0
MAGX_VO: All uninit

[fill.sa]

Ой.
Цитата
ipu_mem=1000K@0x93700000 brdrev=P3A noinitrd console=/dev/console rw mem=60M@0x90000000 init=/linuxrc ip=off root=/dev/mtdblock/root mtdparts=nand0:192k@256k(pds),128k(setup),256k(logo),128k(secure),1536k@1088k(ke
rn)ro,3968k(bpsw),29680k(root)ro,7680k(lang),7m(user),10752k(resrc),66512k(mass_
storage),16k(kpanic),2672k(rsv)
1.bmp   ( 225.05 килобайт ) Кол-во скачиваний: 3

ПС: 532 МГц.
Цитата
ipu_mem=4444K@0x93700000 brdrev=P3A noinitrd console=/dev/null rw mem=60M@0x90000000 init=/linuxrc ip=off root=/dev/mtdblock/root mtdparts=nand0:192k@256k(pds),128k(setup),256k(logo),128k(secure),1536k@1088k(ke
rn)ro,3968k(bpsw),29680k(root)ro,7680k(lang),7m(user),10752k(resrc),66512k(mass_
storage),16k(kpanic),2672k(rsv)
2.bmp   ( 225.05 килобайт ) Кол-во скачиваний: 3

Ничего не изменилось.

MAGX_VO: IPU memory: 0.5 M

MAGX_VO: IPU memory: 3.8 M

Хотя по выводу sdl видно что значения меняются. Правда значения очень странные, то ли глюк то ли куда-то еще часть от выделенной памяти отрезается.

MAGX_VO: IPU memory: 1.5 M

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


Добавлено позже (3.9.2021, 23:12):
Кстати, вин, сделай свои замеры на зине 399 532 636 проца.
Сравним, на сколько плавают значения между мной, тобой и exl

[EXL]

VINRARUS,
Похоже что изменения в бенчмарке на уровне погрешности. Видимо количество памяти в IPU сильно не на что не влияет. У нас же нет там текстур и всего такого. Только пиксельные буферы, которых по идее должно быть два, а они влазят даже в 0.5 МБ. Интересно, если 0.1 МБ сделать, изменится ли что-либо.

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

Да, у Z6 главное меню быстрое на нативном Qt, а у ZN5 тормозной и прожорливый flowplayer на SVG-плюшках. Пусть оно и поддаётся намного большей кастомизации, но слишком расточительно. Вообще на 64 MB острая нехватка в RAM была.

Кстати, вин, сделай свои замеры на зине 399 532 636 проца.

И ещё на Z6 (со стандартными 3.5 МБ в IPU) можно. Относительную производительность оно должно показать.

Всё же действительно, похоже что память отделяемая для IPU мало на что влияет. Даже если ZN5, в которой этот IPU заюзан в камере и в галерее, где он ворочает 5 МП фотографиями, хватает всего 1.5 МБ, то зачем Z6 понадобилось целых 3.5 МБ?

[fill.sa]

Даже если ZN5, в которой этот IPU заюзан в камере и в галерее, где он ворочает 5 МП фотографиями,

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

. Интересно, если 0.1 МБ сделать, изменится ли что-либо.

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

[EXL]

По сути телефон только получает готовую картинку

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

Код

$ grep -ri ipu_
Binary file usr/bin/medld matches
Binary file usr/lib/libihal.so.1.1.6 matches
Binary file usr/lib/libomx.so.1.0.23 matches
Binary file usr/lib/libmedl.so.1.5.3 matches
etc/initservices/services/startdsp.sh:if [ -f /mnt/msc_int0/nexus_on_ipu_ap_bp.sh ]; then
etc/initservices/services/startdsp.sh:/mnt/msc_int0/nexus_on_ipu_ap_bp.sh
Binary file lib/modules/ihal.ko matches
Binary file lib/modules/dmcam.ko matches

$ strings usr/lib/libihal.so.1.1.6 | grep ipu_cam
ipu_cam_wait_for_int_event
ipu_cam_cancel_wait_for_int_event
ipu_cam_request_irq
ipu_cam_free_irq

Даже какие-то специальные функции вида ipu_cam_* имеются.

Кстати, сейчас проверил файлик ihal-R6637_G_81.11.2CR_128.tgz, который как я думал отвечал за HAL, то есть абстракцию через которую можно получить доступ к различному железу телефона через userspace, но оказалось что это лишь абстракция доступа для IPU, видимо буковка
"i" в названии отвечает за imaging. Получается, что все приложения которые каким-либо образом (напрямую или через другие библиотеки) зависят от библиотеки ihal работают с IPU.

Так вот, в этом архиве в директории тестов есть какой-то интересный проект с исходниками приложения прямо для MotoMAGX, который позволяет тестировать работу IPU. Дома буду, если кому интересно, попробую скомпилировать его для ZN5 или Z6, посмотрите что это вообще.