sonycman

С наступившим всех! Копаюсь в 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 килобайт кода, зато нормальные быстрые версии этих функций. Что стм-овцы наворотили со своей версией тулчейна - хз. Может, я просто не умею его готовить?

Вы имеете ввиду MPU Clock MUX, наверное? Голое железо понятно, как работает, но вот под линуксом я пока что новичок, сложно разобраться, какой драйвер не даёт добро и что нужно, чтобы заставить его работать, как хочется... Тоже думаю, что мешать могут частоты шин, которые на 266 МГц работают. Хотя видно, что ядро А7 работает от выделенной PLL1. Так на то в линуксе и есть подсистема клоков, которая должна автоматизировать этот процесс. Надо разбираться глубже, короче. Ещё есть небольшой затык - при выходе из спячки, виснет ethernet - зелёная лампа на сокете моргает как бешеная, проц молотит на полную и сети нет, пока не сбросишь адаптер командами ip link set eth0 down/up. Это норма или бага какая-то? В принципе, нетрудно отключать адаптер ручками перед засыпанием/включать снова после пробуждения, или как-то добавить эти команды в скрипты systemd...

Попробовал режимы энергосбережения STOP вместе со вторым ядром (СМ4). Получилось около 55 ма, когда А7 спит, а М4 работает на 64МГц. Если М4 тоже усыпить в стоп - кушают 35 ма. При этом пробуждение у М4 весьма быстрое, что радует. В общем-то получилось, как и говорил mantech, а я не верил тогда... Странно, что в стандартном линуксе от ST никто даже не заморачивается снижением частоты А7, тот всегда молотит на максимуме. Добавил в дерево опцию для снижения частоты до 325МГц (с 650), вроде стал снижать. Хотя толку мало, конечно. Ниже не снижает, на 216МГц не хочет работать, видимо что-то не даёт, но не понятно, что. В дебри лезть не стоит, думаю.

В сети так и не нашёл замеров потребления когда A7->CStop, M4->Run. Но в AN5284 ST приводят сравнительные замеры подобной ситуации, получается экономия около 70ма. То есть, если в моём случае 170ма - линукс в idle, то один М4 (А7 в стопе) будет жрать около 100ма... Надо пробовать на практике.

По умолчанию пробуждение настроено на кнопку ON/OFF. Можно выбирать другие источники - тот же UART или RTC и т.п. Сам пока не успел поиграться. Так в 151 только одно ядро А7. По даташиту по линии Vbat заявлено от пары мка при отключенных backup sram/retention sram, только rtc. А на IMX6 говорят, что да, батарейку выносит быстро, лучше ставить внешний чип.

Не знал, что добились настолько эпичного снижения потребления. Впечатлило В идеале так и хотелось бы, но, думаю, так круто не получится. В standby отключается питание ядер, поэтому такой шикарный эффект. Но если М4 будет работать, то это будет другой режим низкого потребления, что-то типа Stop для A7... Ну 180ма это не мало, сон такой себе получается. К примеру, IMX6ULL в такой ситуации потребляет 120ма всего (но там частота до 200МГц снижена). Вот и думаю, что будет эффективнее по потреблению - IMX6ULL плюс дополнительный мелкий контроллер для реал тайм + стандбай, или STM32MP151, где уже есть М4... Хотя плата с 6ULL не даёт такого эффективного standby - там не реализовано отключение питания, и после mem > /sys/power/state оно кушает 50ма.

Приветствую! Изучаю платку MYD-YA15XC-T на базе STM32MP151, 256MB DDR3, 256MB NAND. Я с такими большими процессорами дел не имел раньше, поэтому хочется задать интересующие вопросы более опытным коллегам. Под линуксом в покое плата потребляет около 180ма, при этом процессор молотит постоянно на 650мгц. Не знаю, почему он в покое не сбрасывает частоту, надо бы попробовать сменить говернор на более экономичный. Работает режим standby, в который плата входит командой: echo mem > /sys/power/state Потребления в нем практически нет - всего 3-4 ма, при этом выход в линукс из него быстрый - меньше секунды. Как достигается столь низкое потребление? Разве 256MB DDR3 в режиме self refresh достаточно всего пары ма? Но больше всего интересует, сколько кушать будет камень, когда ядро А7 спит, а ядро М4 работает на низкой частоте - кто нибудь может подсказать?

Спасибо большое!

Прикрепил архив. У них какой-то баг с инициализацией TCM памяти, readmemh попросту не вызывается из кода вообще, так как вивадо сообщил бы обязательно в логах. AT426-BU-98000-r0p1-00rel0.7z

Попробовал заменить один из шифрованных исходников кортекса на дешифрованный - вылазит ошибка. Оказывается, у меня уже обновлённая версия корки М3 - r0p1, а в закромах расшифрованная r0p0. Нет ли, чисто случайно, возможности обновить версию?

Интересно, надо посмотреть в закромах. А то у меня что-то инициализация памяти ITCM (файлом .hex или .mem) при синтезе в 2019 виваде не работает, и так и сяк пробовал - одни нули в итоге. То ли вивада глючная, то ли корка такой опции не имеет, хотя в настройках ядра опция есть и в доках описана...

Может быть я просто не умею готовить микроблейз, но после вот такого кода, где при вызове мелкой функции запросто сохраняется два десятка регистров, у меня пропало всякое желание использовать его (просто взял корку Cortex-M3 из армового DesignStart, и дело в шляпе): 00000f64 <xil_printf>: f64: f8a10004 swi r5, r1, 4 f68: f8c10008 swi r6, r1, 8 f6c: f8e1000c swi r7, r1, 12 f70: f9010010 swi r8, r1, 16 f74: f9210014 swi r9, r1, 20 f78: f9410018 swi r10, r1, 24 f7c: 3021ff90 addik r1, r1, -112 f80: fa610044 swi r19, r1, 68 f84: f9e10000 swi r15, r1, 0 f88: fac10048 swi r22, r1, 72 f8c: fae1004c swi r23, r1, 76 f90: fb010050 swi r24, r1, 80 f94: fb210054 swi r25, r1, 84 f98: fb410058 swi r26, r1, 88 f9c: fb61005c swi r27, r1, 92 fa0: fb810060 swi r28, r1, 96 fa4: fba10064 swi r29, r1, 100 fa8: fbc10068 swi r30, r1, 104 fac: fbe1006c swi r31, r1, 108 fb0: f8a10038 swi r5, r1, 56 fb4: 32610078 addik r19, r1, 120 fb8: e8610038 lwi r3, r1, 56 fbc: be03001c beqid r3, 28 // fd8 fc0: e9e10000 lwi r15, r1, 0 fc4: e0a30000 lbui r5, r3, 0 fc8: 90a50060 sext8 r5, r5 fcc: be250040 bneid r5, 64 // 100c fd0: aac50025 xori r22, r5, 37 fd4: e9e10000 lwi r15, r1, 0 fd8: ea610044 lwi r19, r1, 68 fdc: eac10048 lwi r22, r1, 72 fe0: eae1004c lwi r23, r1, 76 fe4: eb010050 lwi r24, r1, 80 fe8: eb210054 lwi r25, r1, 84 fec: eb410058 lwi r26, r1, 88 ff0: eb61005c lwi r27, r1, 92 ff4: eb810060 lwi r28, r1, 96 ff8: eba10064 lwi r29, r1, 100 ffc: ebc10068 lwi r30, r1, 104 1000: ebe1006c lwi r31, r1, 108 1004: b60f0008 rtsd r15, 8 Оптимизация тоже Os. Странно, что размер кода не меняется при изменении опции оптимизации O1, O2, O3 или Os. Может, какой-то баг компилятора? Xilinx SDK 2019.1

А еще у микроблейза отвратительный компилятор. Единственный вызов printf обрамляется такой кучей сохранения/восстановления регистров, что это занимает сотню байт памяти программ. И это под максимальной оптимизацией! Жуть какая-то. Я знаю, конечно, что гнутый компилятор это поделка та еще, по сравнению с армовским, но что с микроблейзом все так запущено - никак не ожидал... :(

А тогда при входном 0 результат будет 1 :)

Так этот код: outdata_reg <= ((indata + (32'd1<<31)) >> 16) - (16'd1<<15); для входного значения - 1 даст на выходе ту же - 1, а не 0. Это будет не indata/65536.

По поводу set_load и Vivado:

Благодарю, мир не без добрых людей!

Прошу, если у кого есть доступ к сайту хилых или к приложению сканеру - определите, пожалуйста, какой speed grade у этого цинка. Вероятнее всего будет -1, но может быть и -2. Фото прилагаю.

Так после этого все равно же заново прогонять P&R надо?

Так baremetal только для девайса есть, вроде бы, для хоста нету.

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

У спекки пиксельная экранная область "весила" 6 килобайт, и очистить и заполнить ее всю новыми данными 50 раз в секунду было не просто, но и не так уж сложно. А область цветовых атрибутов вообще - 768 байт всего, и сменить цвет всего экрана можно очень много раз за секунду :)

Простой видеобуфер - это есть самая обычная память, типа DDR SDRAM, как правило. Чем она быстрее - тем быстрее будет копирование. Процессором это делать не самое эффективное решение, а вот с помощью ДМА - уже лучше.

Благодарю!

А можно как-то удобным образом перезадать номера десигнаторов падов на футпринте? Вот поставил я 60 штук падов, теперь нужно их номера упорядочить. Помнится, где-то была фича, можно было мышкой указывать последовательно пады, и перенумеровывать их таким образом. В альтиуме не нашёл. Или это в пикаде было?