Сборка ядра для 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]

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, посмотрите что это вообще.

[fill.sa]

Кстати, на тему версии ядра я уже как-то писал, что хоть мы и отталкиваемся от цифры 2.6.10, по факту это не так.
Если в кратце то там изначально montavista взял 2.6.9 или даже 2.6.8 ядро и потом заплатками догнал до 2.6.10, а после пошла отдельная история со своими заплатками в перемешку с еще какими-то. Вообще не зря папка называется 2.6.х , точной версии там не понять ибо есть заплатки от 2.6.18 даже.
Ну так вот, недавно с удивлением для себя обнаружил на линуксовой хранилке официальные заплатки для поднятия версии, правда там только до 2.6.13, но нам все пригодится. И возникла мысль поиграться и поподымать версию ядра.
Сообственно, не глядя на то, что есть смещение по строкам(montavista все таки добавляла свой код) во время применения заплатки можно заметить , что многие вещи уже добавлены, даже есть заметки аля 2006-Mar-01 Motorola Backport of 2.6.14 patch to 2.6.10 kernel.
Так что все как бы очередной раз намекает, что ядро во многих вещах имеет версию выше 2.6.10

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

[EXL]

Как и обещал ранее, скомпилировал это официальное мотороловское приложение для каких-то тестов IPU из дерева исходников ZN5 T-Mobile на 2CR_128, пакет ihal-R6637_G_81.11.2CR_128.tgz, директория "test".

Рецепт сборки примерно такой:

Код

cd ihal && make COMPILERTOOLPATH=/opt/toolchains/motomagx/arm-eabi2/bin PLATFORM_DIR=/home/exl/Downloads/zn5/platform BOOTSTRAP=/home/exl/Downloads/zn5/platform/Makefile.bootstrap COMPTOP=/home/exl/Downloads/zn5/ihal PROPFILES=/home/exl/Downloads/zn5/ihal/properties BUILDTOP=/home/exl/Downloads/zn5/build/ihal test

Похоже библиотека libihal.so взаимодействует с модулем ihal.ko (kernel space) и предоставляет доступ к функциям IPU (user space) прикладным приложениям. Попробуйте запустить эту штуку у себя на мобилках через Telnet, интересно что оно вообще из себя представляет и как тестирует. Там есть следующие пункты (когда приложение запущено, просто нажимайте в Telnet нужные цифры и затем Enter):

Тесты номера которых отмечены как рабочие:
1. Какой-то простой тест IPU и дисплея. Вероятно что-то связанное с отображением цветов, а потом идёт отображения двух изображений которые размещаются в RAM в сыром RAW виде и на битмап просто делается memcpy().
2. Отображение BMP-изображения, файл которого идёт вместе с приложением.
5. Некий CSC-тест, в котором похоже происходит какая-то аппаратная постобработка кадров MPEG4 QCIF (176x144) в которую входит поворот картинки и её ресайз. Вот эта штука интересно что делает, и возможно ли через неё аппаратно ускорить тот же MPlayer.
10. FG/BG-тест. Похоже просто переключение IPU на разные буферы background/foreground.
20. Какой-то BLiT-тест. Похоже какой-то аппаратный блиттинг. Интересно, что именно там происходит, на обычном десктопе подобными фичами могли быть реализованы аппаратные курсоры и т. д., а на игровых консолях всякие операции со спрайтами.

Тесты, номера которых отмечены как нерабочие:
3. Какой-то тест железки подцепленной по протоколу I²C, кажется это что-то с референсных плат тестировалось, оно там закомментировано, но в этом коде есть упоминание некого чипа "Micron MT9M111", при гуглении выяснилось что это какой-то модуль камеры. Там дёргают какие-то регистры и включают подсветку, но похоже ничего в DMA/буферы для IPU не пишут, что странно.
40, 50, 60. Какое-то чтение, запись и просмотр регистров IPU.
70. Какой-то дамп связанный с DMA.
80. Дёргают что-то по GPIO. Похоже на очистку экрана?

Из того что я вижу, можно кормить IPU в неком DMA-режиме, напрямую редактируя его аллоцированные буферы и использовать более-менее удобный API для всяких функций поворота и изменения размера.

Ant-ON, ты не видел эту штуку и вообще не тестил ihal-библиотеку в MotoMAGX? Я посмотрел исходники SDL HW, но похоже там имплементация видеодрайвера вообще это не задействует, а как-то в обход всего этого действует через mmap'ы на DMA. В MPlayer от kuznet похоже было точно так же? Похоже, что с этим прикладным API из библиотеки libihal.so можно было куда быстрее написать драйвер для MPlayer'а и SDL, эх... Посмотри пожалуйста прикреплённый файлик ihapp.c в архиве ihal_test_src.zip, дай свой комментарий насчёт этого API для IPU, почему оно не было заюзано в нативных приложениях для MotoMAGX?

А исходники MPlayer'а у кого-нибудь сохранились? Или их так никто и не выкладывал? Интересно можно ли туда прикрутить аппаратные манипуляции с MPEG4 на этом IPU, или оно только для QCIF (176x144) там сделано. А в хедерах IPU ещё и что-то по H.264 имеется.

Файлы прикрепляю:

[EXL]

VINRARUS,
fill.sa,
Имеется ли на Z6 библиотека libihal.so? Похоже она была добавлена в более поздние MotoMAGX телефоны, вроде ZN5, E8 и VE66. Не вижу её исходников в релизе Motorola для Z6 на SourceForge.

В общем, немного поковырялся, нашёл kuznet'овскую реализацию MPlayer для Z6 с использованием IPU и кодеков специально под проц MotoMAGX-телефонов. Все его наработки до сих пор доступны по адресу: http://www.inr.ac.ru/z6/

В файле z6-mplayer-2008-02-11-v1.tar.bz2 как раз всё необходимое в виде патчей и альтернативного ядерного драйвера для IPU, где kuznet пытался пофиксить какие-то остановки MPlayer'а:

Код

@@ -429,14 +430,30 @@
       printk("mxc_ipu_pp: error setting PP_PP_ROT middle output buffer\n");
       goto err0;
     }
+
+int retry = 0;
+again:
     err = ipu_update_channel_buffer(MEM_ROT_PP_MEM, IPU_INPUT_BUFFER, 0, (void*)mid->addr);
     if(err < 0) {
       printk("mxc_ipu_pp: error setting PP_PP_ROT middle input buffer\n");
+      if (retry == 0) {  
+        retry = 1;
+        __raw_writel(0, IPU_CHA_BUF0_RDY);
+        goto again;
+      }
       goto err0;
     }
+
+    retry = 0;
+again2:
     err = ipu_update_channel_buffer(MEM_ROT_PP_MEM, IPU_OUTPUT_BUFFER, 0, (void*)out->addr);
     if(err < 0) {
       printk("mxc_ipu_pp: error setting PP_PP_ROT output buffer\n");
+      if (retry == 0) {  
+        retry = 1;
+        __raw_writel(0, IPU_CHA_BUF0_RDY);
+        goto again2;
+      }
       goto err0;
     }
     if(pp_data.ic_combine_en != 0) {

Драйвер, который создаёт устройство /dev/alt_mxc_ipu_pp — это модифицированная альтернатива драйвера IPU от kuznet'а, а вот драйвер, создающий устройство /dev/mxc_ipu_pp — оригинальный мотороловский.

Но вот с библиотекой и модулем ihal не всё ясно. Похоже этот дополнительный слой API к IPU был добавлен в более поздних версиях LJ, потому что на Z6 его вообще нет. Видимо поэтому Ant-ON и не заюзал его для SDL и для порта MPlayer для ZN5. А ведь оно бы сильно облегчило жизнь.

Камера как раз через этот libihal.so на ZN5 работает:

Код

$ arm-linux-gnueabi-objdump -x apps_acs | grep NEEDED | grep ihal
  NEEDED      libihal.so

$ arm-linux-gnueabi-objdump -x libomx.so.1.0.23 | grep NEEDED | grep ihal
  NEEDED      libihal.so

А ещё к вопросу о том, почему памяти для IPU у Z6 3.5 МБ, а у ZN5 -- 0.5 МБ:

Код

/* Date         Author      Comment
* ===========  ==========  ==================================================
* 5-Jun-2006  Motorola    Initial revision.
* 3-Jul-2007  Motorola    Compliance issue fix
* 15-Jul-2007 Motorola    Support setting of ADC serial interface bit width
* 24-Jul-2007 Motorola    Compliance issue fix
* 15-Oct-2007 Motorola    Free IPU 3M reserved RAM           !!! <================================================== ВОТ ЗДЕСЬ
* 10-Mar-2008 Motorola    Add three interface functions
* 07-May-2008 Motorola    introduced ipu_disable_channel_no_delay
*/

Это в хедере ih.h ядерной части ihal (в модуле ihal.ko).

[Ant-ON]

EXL,
Да, по сути это это обертка для того, что сейчас используется в SDL и MPlayer. Функционал +- такой же, но в более человеческом виде)

ps А по поводу доступности наработок... Это сайт Институт Ядерных Исследований РАН, там всё до сих пор в стиле 2000х

[VINRARUS]

Имеется ли на Z6 библиотека libihal.so?

Я ненашол.

Попробуйте запустить эту штуку у себя на мобилках через Telnet, интересно что оно вообще из себя представляет и как тестирует.

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

Тесты номера которых отмечены как рабочие:

1.Цветные полосочки заменяются клубничкой с лимоном и кокосиком.
Enter
Пляж.
Жолтый портал вертикальный через пляж.
2. Какой то снегур с долгим клювом под пальмой.
3. Выход.
5. Стадион с мячом который играет людьми.
10. Серый экран. 2й запуск показал Bus error. 3й повесил терминал, хотя подсветка на экране гасла и засвечивалась как обычно. Интересно шо если ещо раз запустить телнет он вроде работает, но вешается во время выполнения ps.
20. То самое шо и 10.
80. Хз.

[EXL]

EXL,
Да, по сути это это обертка для того, что сейчас используется в SDL и MPlayer. Функционал +- такой же, но в более человеческом виде)

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

VINRARUS, Ясно, я вот тоже не нашёл упоминания libihal.so и ihal.ko в опубликованных исходниках Motorola Z6 на SourceForge.

Отлично, что это приложение работает, значит эти API не висят мёртвым грузом, а реально используются в той же камере. То что оно примитивное, это понятно, это не бенчмарк а проверка того, что IPU корректно работает. Похоже оно рисует в какой-то специальный буфер, который не зависит от буфера WindowServer в Qt или даже /dev/fb/0, видимо как раз размер этого буфера и откусывается от RAM и разработчики Motorola позже посчитали, что в Z6 они откусили от RAM много. Наверное, если никаких багов не будет, можно смело ставить там то же значение, что и у ZN5 -- 0.5 MB. Дополнительные З MB для 64 MB RAM в Z6 далеко не лишние. Ты, кстати, проверял меняется ли выхлоп команды free на ядре где fill.sa уменьшил память у IPU?

По поводу тестов, из написанного тобой не совсем понял, есть ли там какие-то анимации или эффекты накладывания/перемещения изображений? Или лишь статичные картинки?

Эх, раскопать бы этот API не сейчас, а 12 лет назад! Там всё по сути с открытыми исходниками: либа, модуль, тестовый пример с использованием API...

[fill.sa]

Имеется ли на Z6 библиотека libihal.so? Похоже она была добавлена в более поздние MotoMAGX телефоны, вроде ZN5, E8 и VE66. Не вижу её исходников в релизе Motorola для Z6 на SourceForge.

Все верно, появилось оно уже на lj6.3 и на z6 соответственно нету.
На з6 вообще много чего нету, вернее оно есть но как правило все жестко прибито в коде, а уже начиная с lj6.3 более гибки инструменты появились, функции разные которые можно подергать что-то и тд.
Как для телефона, то это пофигу, а вот для смартак это хорошо, можно что-то уже выполнять свое на основе этих функций.

. Какой-то тест железки подцепленной по протоколу IІC, кажется это что-то с референсных плат тестировалось, оно там закомментировано, но в этом коде есть упоминание некого чипа "Micron MT9M111",

да, i2c шина как раз в камере задействована, вроде еше пару каких-то элементов связывает типо тв выхода на зине.

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

[VINRARUS]

По поводу тестов, из написанного тобой не совсем понял, есть ли там какие-то анимации или эффекты накладывания/перемещения изображений? Или лишь статичные картинки?

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

Сообщение отредактировал VINRARUS - 13.9.2021, 4:16

[fill.sa]

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

-Если включен параметр CONFIG_MOT_FEAT_IPU_MEM_ADDR, то последовательность следующая.
Первоначально в файле https://github.com/fillsa/motomagx-kernel_l...h/arm/mm/init.c задается переменная ipu_mem_size и размер для нее в 2Мб, причем изначально на lj6.1 там было 5Мб , а также для ауры свой размер равный 9М.

Далее по коду функция static int __init ipu_mem_setup(char *str) может читать параметры ядра, куда можно передавать свои значения "ipu_mem=" размера и адреса памяти для IPU.
Что собственно успешно и делается на lj6.1, а вот на lj6.3 уже не передаются в параметрах ядру такие значения, т.е. берутся изначальные заданные 2Мб в переменной ipu_mem_size и адрес высчитывается так ipu_mem_addr = PHYS_OFFSET + SDRAM_MEM_SIZE - DSP_MEM_SIZE - ipu_mem_size;

Далее уже в драйвере IPU https://github.com/fillsa/motomagx-kernel_l...s/mxc/ipu/ipu.h появляется новая переменная которая присваивается нашему размеру
#define MXCIPU_MEM_ADDRESS ipu_mem_addr
#define MXCIPU_MEM_SIZE ipu_mem_size

-Если наоборот параметр CONFIG_MOT_FEAT_IPU_MEM_ADDR не включен, то
сразу из файла соответствующего нужной машине, например для scma11 https://github.com/fillsa/motomagx-kernel_l...d-scma11phone.h задаются переменные
#define MXCIPU_MEM_SIZE (SZ_4M + SZ_1M)
#define MXCIPU_MEM_ADDRESS (PHYS_OFFSET + MEM_SIZE)
Кстати тут же стоит заметить интересную помету в этом файле
/*!
* Size and physical start address of IPU buffer memory
* 5MB is a safe value for 2 MP camera support.
* The exact size depends on the hardware configuration.
*/

И дальше по коду все действия идут уже с MXCIPU_MEM_SIZE и MXCIPU_MEM_ADDRESS . Т.е. если что-то и искать то уже грепать эти значения в /linux-2.6.x/drivers

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

[EXL]

fill.sa, Интересно нафига AURA столько памяти для IPU... Понимаю, там по идее у дисплея разрешение больше чем у всех остальных MotoMAGX-телефонов, т. е. адресуется 480x480 вместо 320x240. Да и камеры там нет крутой.

Unreal_man, ты не помнишь fill.sa собирал тебе SDL HW под AURA?