[mantech 33]

9 часов назад, sonycman сказал:

Ниже не снижает, на 216МГц не хочет работать, видимо что-то не даёт, но не понятно, что.

Скорее всего зависимость от этой частоты, скажем шин или модуля памяти. Не уверен, что в данном камне сделано так же, но в IMX6, частота ЦП вообще отвязана от всего прочего, и настраивается от 1ГГц до 24МГц без проблем. Правда, к слову там это не сильно влияло на потребление, т.к. контроллер ДДР делали бестолковые индусы или кто-то вроде них и его потребление и низкая скорость передачи все сводили на нет...

Изменено 30 декабря, 2021 пользователем mantech

[sonycman 0]

10 hours ago, GenaSPB said:

В RCC MP1 есть специальный делитель в клоковом дереве... который позволяет практически одним битом переключаться между прямым или делённым тактовым сигналом MPU части.
RCC_MPCKDIVR_MPUDIV
RCC_MPCKSELR_MPUSRC

Вы имеете ввиду MPU Clock MUX, наверное?

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

1 hour ago, mantech said:

Скорее всего зависимость от этой частоты, скажем шин или модуля памяти. Не уверен, что в данном камне сделано так же, но в IMX6, частота ЦП вообще отвязана от всего прочего, и настраивается от 1ГГц до 24МГц без проблем. Правда, к слову там это не сильно влияло на потребление, т.к. контроллер ДДР делали бестолковые индусы или кто-то вроде них и его потребление и низкая скорость передачи все сводили на нет...

Тоже думаю, что мешать могут частоты шин, которые на 266 МГц работают.

Хотя видно, что ядро А7 работает от выделенной PLL1.

 

Так на то в линуксе и есть подсистема клоков, которая должна автоматизировать этот процесс.

Надо разбираться глубже, короче.

 

Ещё есть небольшой затык - при выходе из спячки, виснет ethernet - зелёная лампа на сокете моргает как бешеная, проц молотит на полную и сети нет, пока не сбросишь адаптер командами ip link set eth0 down/up.

Это норма или бага какая-то?

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

[mantech 33]

4 часа назад, sonycman сказал:

Это норма или бага какая-то?

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

4 часа назад, sonycman сказал:

Так на то в линуксе и есть подсистема клоков, которая должна автоматизировать этот процесс.

можно предположить, что за это может отвечать DVFS.

[sonycman 0]

С наступившим всех!

 

Копаюсь в CubeIDE с прошивкой ядра CM4, и вот затык получился с тулчейном по умолчанию - GCC for STM32.

Вроде последняя версия (10), обновил, в настройках тулчейна стоит использовать полновесную библиотеку С - упорно втыкает "нано" версию memcpy и memset:

1000496c <memcpy>:
1000496c:	440a      	add	r2, r1
1000496e:	4291      	cmp	r1, r2
10004970:	f100 33ff 	add.w	r3, r0, #4294967295	; 0xffffffff
10004974:	d100      	bne.n	10004978 <memcpy+0xc>
10004976:	4770      	bx	lr
10004978:	b510      	push	{r4, lr}
1000497a:	f811 4b01 	ldrb.w	r4, [r1], #1
1000497e:	f803 4f01 	strb.w	r4, [r3, #1]!
10004982:	4291      	cmp	r1, r2
10004984:	d1f9      	bne.n	1000497a <memcpy+0xe>
10004986:	bd10      	pop	{r4, pc}

10004988 <memset>:
10004988:	4402      	add	r2, r0
1000498a:	4603      	mov	r3, r0
1000498c:	4293      	cmp	r3, r2
1000498e:	d100      	bne.n	10004992 <memset+0xa>
10004990:	4770      	bx	lr
10004992:	f803 1b01 	strb.w	r1, [r3], #1
10004996:	e7f9      	b.n	1000498c <memset+0x4>

Получается, настройка версии библиотеки не работает :(

Поставил тулчейн от ARM - та же самая версия - проблемы нет, +20 килобайт кода, зато нормальные быстрые версии этих функций.

Что стм-овцы наворотили со своей версией тулчейна - хз. Может, я просто не умею его готовить?

[sonycman 0]

Можно вопрос по поводу линукса и как правильно под ним организовать обмен между A7 <--> M4?

Я в этом совсем новичок пока что.

 

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

Запустил OpenAMP на CM4, там поднимается виртуальный UART под линуксом, куча кода с обеих сторон, в котором так просто и не разобраться, но работает вроде бы.

Стоит ли интерфейс ввода вешать на такой виртуальный UART? 

Наверное, можно работать по прерыванию от порта, затем считывать данные и обрабатывать.

 

Но, может быть лучше было бы просто через mmap получить прямой доступ к памяти M4, и читать\записывать данные напрямую, безо всяких тяжёлых прокладок?

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

 

Хотел бы услышать совет, в какую сторону двигаться.

Или может лучше спросить в ветке по линуксу?

[aaarrr 63]

29 minutes ago, sonycman said:

Стоит ли интерфейс ввода вешать на такой виртуальный UART? 

Нет. И вообще нет смысла грузить M4 UI - A7 справится гораздо лучше.

[sonycman 0]

26 minutes ago, aaarrr said:

Нет. И вообще нет смысла грузить M4 UI - A7 справится гораздо лучше.

Когда А7 будет спать в стэндбае, он не сможет быстро среагировать на входной сигнал - время пробуждения из стэндбая до 1.5 секунд, то есть сигнал будет пропущен.

А М4 быстро просыпается - он сможет после пробуждения А7 передать ему входной сигнал.

Поэтому ввод на М4.

[aaarrr 63]

А с точки зрения пользователя что хуже - пропуск воздействия, или задержка реакции на 1.5с? Оба хуже.

[sonycman 0]

7 minutes ago, aaarrr said:

А с точки зрения пользователя что хуже - пропуск воздействия, или задержка реакции на 1.5с? Оба хуже.

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

 

Кстати, приятно удивило, что ST добавили онлайн репозиторий, можно пользоваться apt-get для установки доп. софта 

А у NXP есть такая фишка, интересно?

[aaarrr 63]

1 minute ago, sonycman said:

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

Может безумно раздражать. Нормальный подход: устройство спит (экран выключен или притушен) -> первое воздействие пользователя -> пробуждение (включение или вывод на нормальную яркость экрана) -> второе воздействие -> реакция.

 

7 minutes ago, sonycman said:

онлайн репозиторий

А смысл? Только подсадить на свою "экосистему". При разработке весь софт должен собираться локально.

[sonycman 0]

2 minutes ago, aaarrr said:

Может безумно раздражать. Нормальный подход: устройство спит (экран выключен или притушен) -> первое воздействие пользователя -> пробуждение (включение или вывод на нормальную яркость экрана) -> второе воздействие -> реакция.

Можно и так.

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

4 minutes ago, aaarrr said:

А смысл? Только подсадить на свою "экосистему". При разработке весь софт должен собираться локально.

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

А готовому девайсу особо и не надо, согласен.

[mantech 33]

6 часов назад, sonycman сказал:

время пробуждения из стэндбая до 1.5 секунд

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

5 часов назад, sonycman сказал:

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

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

6 часов назад, sonycman сказал:

А М4 быстро просыпается - он сможет после пробуждения А7 передать ему входной сигнал.

Поэтому ввод на М4.

М4 задуман для реалтайм процессов, например измерения частоты, реакции на внешнее событие, т.к. монстроидальный линукс быстро с места не столкнуть, но это про микро и миллисекунды речь, не полторы секунды все равно...

[sonycman 0]

2 hours ago, mantech said:

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

Ну так у меня ведь не вылизанный планшет, или там телефон. Это у ST, наверное, спросить надо, почему так долго просыпается их чип. Или китайцы чего намудрили с линуксом.

Тут было бы интересно сравнить, у кого есть оригинальные платы от ST - какой результат у них? Только они все на 157 чипах, а не на 151, если правильно помню.

 

Насколько знаю, при выходе из standby, когда питание с чипа было снято практически полностью, реинициализируется всё активное железо - контроллеры eth, sd card и остальные, что занимает время.

А из стопа, когда питание не снимается, по идее выходить должен быстрее, но по факту такой-же разбег: от 0.5 до 1.5 секунды.

2 hours ago, mantech said:

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

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

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

Я до этого не дорос пока что :(

2 hours ago, mantech said:

М4 задуман для реалтайм процессов, например измерения частоты, реакции на внешнее событие, т.к. монстроидальный линукс быстро с места не столкнуть, но это про микро и миллисекунды речь, не полторы секунды все равно...

Ну так вот пусть и занимается реакцией на внешние сигналы, пока А7 с линуксом спят, разве не логично?

[aaarrr 63]

35 minutes ago, sonycman said:

разве не логично?

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

[sonycman 0]

1 hour ago, aaarrr said:

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

Спасибо, приму к сведению. 

В одном из примеров от ST для межпроцессорного обмена на стороне линукса загружается маленький модуль ядра, там кода строчек 100, он принимает и отправляет данные для М4 через майлбокс (openamp на стороне М4).

То есть без поднятия всем видимых ttyRPMSG портов виртуального UART.

В принципе, можно доработать этот модуль под свои нужды. Надо только определиться с ними :)

 

Сейчас посмотрел на примере IMX6ULL, она после standby запускается быстрее стмки, всего за 100 мс, если верить репорту линукса. Там, правда, отключение питания не реализовано.

Значит, есть какой-то косяк на стороне стмки.

 

Надо бы сравнить с оригинальной платой, например STM32MP157A-DK1...