Перейти к содержанию
    

sonycman

Свой
  • Постов

    1 951
  • Зарегистрирован

  • Посещение

Весь контент sonycman


  1. У них несколько обучающих курсов по всем аспектам, все что надо есть - от простых примеров с простой логикой, до камер с дисплеями, линуксом и аи. Кинули - это как, плату не прислали?
  2. Спасибо, разбираюсь! Кстати, у этих китайцев с ихнего байду фиг ничего скачаешь через браузер, надо ставить экзешник с качалкой, а там всё с кривыми иероглифами... это вообще реально это приложение поставить с скачать папки через него?
  3. И сюда писал, только вчера отправил. Не ответили пока. Попробую потом ещё, ну и спор открою на али, если продаван так и будет молчать.
  4. Приветствую! Заказал на али платку на базе MPSoC Ultrascale+ XCZU2CG-1SFVC784E, пока ещё не пришла, но никак не могу найти на неё схематик/примеры и прочее. Есть только куцый мануал с сайта alinx.com. На страничке магазина на али и на сайте alinx для получения полной доки приведён имэйл [email protected], кучу писем уже отправил - ни ответа, ни привета :( И другие имэйлы алинкса молчат, как и продаван на али вообще не читает сообщения... Ведут себя эти китайцы как полные сволочи. Может, кто имеет полную доку на эту плату, был бы очень признателен за помощь
  5. Опция активна, но нет не то что фреймбуффера, но и drm (/dev/dri/card0). Наверное, это потому, что не подключены дисплеи?
  6. Ну почему нет - китайцы предоставили всё, что нужно. Наверное, может всплыть какая-то несовместимость по части поддержки стандарта DSI между контроллерами дисплея и процессора? И плохо, что не просто посмотреть, что творится на линиях трансиверов...
  7. STM для своих mp1 камешков не поддерживают FB, только DRM. Это, как я понимаю, из-за наличия GPU, который мне в общем-то и не нужен. В ядре поддержка FB везде включена, но, чтобы он появился в /dev/fb надо, как я понимаю, рабочий драйвер под него? Может быть, подсмотреть у IMX6ULL, но тут пока что сложно для меня будет, наверное. Попробую сначала с drm, а там видно будет...
  8. Да вроде всё есть - и тайминги в даташите панели, и инициализация, и распиновка. Только в линуксе теперь надо разбираться. DRM - это сильно сложнее фреймбуффера?
  9. Ну велосипед тут изобретать не придётся, под линуксом куча готовых драйверов, просто заменю панель, подставлю нужные команды, подредактирую готовое и делов то
  10. Так причем тут DSI, вы что, думаете по тому же SPI или MCU какие-то другие команды будут? Даташит на контроллер просто куцый вот и все.
  11. Похоже, что да: 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]); ...
  12. Код инициализации его видели? Так почти все команды используются такие, которых в доке нет. Так что толку от неё... разве что сам протокол DSI неплохо описан
  13. Даже не ожидал, что продавец ответит. Но предоставили даташит на панель. Распиновку узнал Правда, теперь не хватает примера кода инициализации дисплея. Там контроллер JD9852, на него нет полной доки. В принципе в сети нашёл примеры, может и подойдут, хз. Продавец пообещал найти родной код инициализации, буду ждать...
  14. Да нет, тип контроллера приведен, даже модель панели есть, да только толку, когда распиновки нет? Вот она: https://m.aliexpress.ru/item/1005001296440255.html
  15. А кто-нибудь видел дисплей с MIPI интерфейсом на 2.4 или 2.8 дюйма? Такой, чтобы хотя бы распиновка шлейфа была, а то на али они все без распиновки...
  16. STM32MP151

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

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

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

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

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

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

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

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

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

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