Jump to content

    

sonycman

Свой
  • Content Count

    1918
  • Joined

  • Last visited

Everything posted by sonycman


  1. Опция активна, но нет не то что фреймбуффера, но и drm (/dev/dri/card0). Наверное, это потому, что не подключены дисплеи?
  2. Ну почему нет - китайцы предоставили всё, что нужно. Наверное, может всплыть какая-то несовместимость по части поддержки стандарта DSI между контроллерами дисплея и процессора? И плохо, что не просто посмотреть, что творится на линиях трансиверов...
  3. STM для своих mp1 камешков не поддерживают FB, только DRM. Это, как я понимаю, из-за наличия GPU, который мне в общем-то и не нужен. В ядре поддержка FB везде включена, но, чтобы он появился в /dev/fb надо, как я понимаю, рабочий драйвер под него? Может быть, подсмотреть у IMX6ULL, но тут пока что сложно для меня будет, наверное. Попробую сначала с drm, а там видно будет...
  4. Да вроде всё есть - и тайминги в даташите панели, и инициализация, и распиновка. Только в линуксе теперь надо разбираться. DRM - это сильно сложнее фреймбуффера?
  5. Ну велосипед тут изобретать не придётся, под линуксом куча готовых драйверов, просто заменю панель, подставлю нужные команды, подредактирую готовое и делов то
  6. Так причем тут DSI, вы что, думаете по тому же SPI или MCU какие-то другие команды будут? Даташит на контроллер просто куцый вот и все.
  7. Похоже, что да: static int jd9852_readid(void) { struct sprd_dsi *dsi = &dsi_device; uint8_t read_buf[4] = {0}; mipi_dsi_lp_cmd_enable(dsi, true); mipi_dsi_set_max_return_size(dsi, 1); mipi_dsi_dcs_read(dsi, 0x04, &read_buf[0], 1);//0x98 mipi_dsi_dcs_read(dsi, 0x04, &read_buf[1], 1);//0x51 mipi_dsi_dcs_read(dsi, 0x04, &read_buf[2], 1);//0x00 pr_info("fae---read id id0=%x,id1=%x,id2=%x\n",read_buf[0],read_buf[1],read_buf[2]); ...
  8. Код инициализации его видели? Так почти все команды используются такие, которых в доке нет. Так что толку от неё... разве что сам протокол DSI неплохо описан
  9. Даже не ожидал, что продавец ответит. Но предоставили даташит на панель. Распиновку узнал Правда, теперь не хватает примера кода инициализации дисплея. Там контроллер JD9852, на него нет полной доки. В принципе в сети нашёл примеры, может и подойдут, хз. Продавец пообещал найти родной код инициализации, буду ждать...
  10. Да нет, тип контроллера приведен, даже модель панели есть, да только толку, когда распиновки нет? Вот она: https://m.aliexpress.ru/item/1005001296440255.html
  11. А кто-нибудь видел дисплей с MIPI интерфейсом на 2.4 или 2.8 дюйма? Такой, чтобы хотя бы распиновка шлейфа была, а то на али они все без распиновки...
  12. STM32MP151

    Думаете, слишком много? Миллисекунд, конечно. Кстати, функция msleep (и ей подобные) работают очень весело в линуксе. В драйвере мак таймаут сброса работает как периодический опрос регистра dma с паузой 10мс (msleep(10)) в цикле 100 раз. При пробуждении ото сна этот таймаут срабатывает идеально за 1 секунду. А вот при загрузке системы, когда много параллельных задач, этот же таймаут растягивается почти на 3 (!) секунды! Заменил msleep на readl_poll_timeout, которая обеспечивает точное время не зависимо от загрузки. Да, не говорите, у них куча различных плат на сайте, по несколько версий уже, а софт сбит из костылей. Железячники, видимо, хорошие, а программисты студенты одни...
  13. STM32MP151

    Был ещё нюанс с этой весёлой связкой - стшный GMAC и атеросовское PHY. Для сброса при инициализации DMA, gmac требует наличия всех клоков, в том числе клока RX от phy. Которого нет, если не вставлен кабель или просто прошло какое-то время. Экономия энергии, мать её за ногу. Тут то ли не подумали ST, то ли Atheros, но фишка не отключаемая с обеих сторон, похоже. Сетевой драйвер устанавливает бит сброса и ждёт, пока он сбросится - а клока RX нет, и через секунду срабатывает таймаут и привет отвал ethernet. Китайцы просто выкинули проверку на таймаут из драйвера - он, как ни странно, работает дальше и так, но иногда плохо и автоматически ресетится через несколько секунд. После того, как я "починил" сброс phy, эта проблема вроде ушла. После сброса он, видимо, подаёт какое-то время клок и мак успевает прогнать инициализацию. Теперь после сна плата просыпается за 150мс, а после глубокого сна (с отключением питания) - за 500 с копейками (долго поднимается USB, возможно, опять китайцы виноваты). Но в USB пока не полезу, ну его нафиг :)
  14. STM32MP151

    Разобрался вроде с тормозами при пробуждении ото сна и заодно решилась проблема отвала сети. Виноват был "прикрученный" через заднее место ethernet phy AR8035. Китайцы почему то вместо допиливания существующего драйвера phy для него, который сразу не заводится, его совсем выкинули, и прикрутили свой патч-код через вызов phy_register_fixup() (аж два микро модуля ядра регистрируют абсолютно одинаковый код!). Но этот фиксап не вызывается после пробуждения ото сна, что приводит к неработоспособности phy и отвалу сети. Выкинул этот китайский код нафиг, подправил драйвер phy и DT (дерево устройств), изменив опцию rgmii на rgmii-id, чтобы активировались задержки клоков, и всё заработало как положено. А ещё китайцы не смогли (или не захотели разобраться, как правильно) добавить пин сброса для этого-же многострадального ethernet phy, из-за чего сброс тоже не работал после пробуждения. Блин - там же в драйвере stmmac есть опция в DT специально для этого! Правда, немного кривая - работала тоже только один раз, но это быстро исправляется.
  15. STM32MP151

    Эта плата (MYD-YA15XC-T) с завода была прошита старой прошивкой (апрельской вроде), которая в стэндбай вообще не могла войти, зависала после команды echo mem > /sys/power/state (или systemctl standby), после чего ресетилась ватчдогом через 30 секунд. Прошил на их последний образ - заработало, значит, исправили какие-то косяки. Но, видимо, не до конца. Хотя уже собрал и прошил последнюю версию загрузчиков и ядра с гитхаба...
  16. STM32MP151

    Спасибо, приму к сведению. В одном из примеров от ST для межпроцессорного обмена на стороне линукса загружается маленький модуль ядра, там кода строчек 100, он принимает и отправляет данные для М4 через майлбокс (openamp на стороне М4). То есть без поднятия всем видимых ttyRPMSG портов виртуального UART. В принципе, можно доработать этот модуль под свои нужды. Надо только определиться с ними :) Сейчас посмотрел на примере IMX6ULL, она после standby запускается быстрее стмки, всего за 100 мс, если верить репорту линукса. Там, правда, отключение питания не реализовано. Значит, есть какой-то косяк на стороне стмки. Надо бы сравнить с оригинальной платой, например STM32MP157A-DK1...
  17. STM32MP151

    Ну так у меня ведь не вылизанный планшет, или там телефон. Это у ST, наверное, спросить надо, почему так долго просыпается их чип. Или китайцы чего намудрили с линуксом. Тут было бы интересно сравнить, у кого есть оригинальные платы от ST - какой результат у них? Только они все на 157 чипах, а не на 151, если правильно помню. Насколько знаю, при выходе из standby, когда питание с чипа было снято практически полностью, реинициализируется всё активное железо - контроллеры eth, sd card и остальные, что занимает время. А из стопа, когда питание не снимается, по идее выходить должен быстрее, но по факту такой-же разбег: от 0.5 до 1.5 секунды. Возможно и так, но в андроидах и железо с кучей ядер, гигабайтами памяти и гигагерцовыми процами, а не лоу-енд низкопотребляющее ядрышко А7 с минимумом памяти. Соптимизировать, думаю, можно, надо в дебри линукса залезть и посмотреть, на что тратится время конкретно. Я до этого не дорос пока что :( Ну так вот пусть и занимается реакцией на внешние сигналы, пока А7 с линуксом спят, разве не логично?
  18. STM32MP151

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

    Задержка не критична. Может быть, потом как-то удастся добиться более быстрой реакции, повыкидывать всякие левые службы, питоны и т.п. Кстати, приятно удивило, что ST добавили онлайн репозиторий, можно пользоваться apt-get для установки доп. софта А у NXP есть такая фишка, интересно?
  20. STM32MP151

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

    Можно вопрос по поводу линукса и как правильно под ним организовать обмен между A7 <--> M4? Я в этом совсем новичок пока что. На M4 будет обработка клавиатуры, энкодер, и тому подобный ввод от пользователя. Данных не много и скорость большая не требуется, но и сильный инпут лаг не желателен. Запустил OpenAMP на CM4, там поднимается виртуальный UART под линуксом, куча кода с обеих сторон, в котором так просто и не разобраться, но работает вроде бы. Стоит ли интерфейс ввода вешать на такой виртуальный UART? Наверное, можно работать по прерыванию от порта, затем считывать данные и обрабатывать. Но, может быть лучше было бы просто через mmap получить прямой доступ к памяти M4, и читать\записывать данные напрямую, безо всяких тяжёлых прокладок? Но тогда придётся заниматься поллингом, так как прерывания тут уже не будет. Хотел бы услышать совет, в какую сторону двигаться. Или может лучше спросить в ветке по линуксу?
  22. STM32MP151

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

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

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

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