Jump to content

    

sasamy

Участник
  • Content Count

    849
  • Joined

  • Last visited

Community Reputation

0 Обычный

About sasamy

  • Rank
    Знающий

Recent Profile Visitors

2083 profile views
  1. fastboot это протокол для андроид систем а не мифический промышленный стандарт загрузчиков, поддерживается в u-boot, он же (убут) и является фактически стандартным загрузчиком на arm-процессорах. Для залочивания прошивки одного софта мало - нужна аппаратная поддержка, у i.mx процессоров это HAB https://boundarydevices.com/high-assurance-boot-hab-dummies/ механизм этот документирован и есть поддержка в u-boot. NXP кстати использует своё расширение протокола fastboot в u-boot для кроссплатформенного инструмента работы со своими процессорами https://github.com/NXPmicro/mfgtools Насчет yocto скорей соглашусь что фактический стандарт для компаний-производителей процессоров, но он крайне неэфективен для небольших проектов. Для примера рекмомендуемое аппаратное обеспечение для разработки - кластер от 32 ядер и выше и 64 гига ОЗУ и выше.
  2. https://blog.er0p.win/?p=64 много лет назад пробовал такое, смысла вообще не увидел
  3. mmap память не выделяет, она её отображает в адреснои пространстве CPU. Примерный аналог для mmap в ядре ioremap
  4. примерно это и ожидалось от kmalloc. Если буферы в ядре не нужны а драйвер использует их для DMA устройства то тут и аллокатор в принципе не нужен - надо как-то зарезервировать выровненный кусок памяти, а в юзерспейсе есть флаг у mmap чтобы при отображении физической памяти в адресном пространстве CPU использовались большие страницы. Для конкретного процессора на ARM когда известна карта памяти это без проблем можно сделать через параметр ядра mem = , как на x86 это оформить не знаю
  5. Да вроде есть ответы https://stackoverflow.com/questions/46212872/how-to-allocate-huge-pages-in-linux-kernel насколько это работает неизвестно
  6. Проблема в том что openwrt это какой-то трэш - куча своих патчей и разобраться что в исходниках вашей сборки мне не представляется возможным. До какой-то версии контроллер gpio у них не генерировал прерывания https://patchwork.ozlabs.org/project/openwrt/patch/20180530063639.31017-8-rosenp@gmail.com/ и если смотреть DTS разных роутеров на этом процессоре кнопки на GPIO у них без прерываний на поллинге - програмном периодическом опросе.
  7. не вызываются потому что запрос на прерывание не приходит - cкорей всего прерывание неправильно описано в dts. У этого процессора 3 банка GPIO (gpio0, gpio1, gpio2) https://github.com/openwrt-mirror/openwrt/blob/9b4650b3b92e6246b986ac9e3d7c2a80d66b805b/target/linux/ramips/dts/mt7621.dtsi#L70 я не знаю какой у вас пин и из какого банка, предположим из банка 0 interrupt-parent = <&gpio0>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; pendown-gpio = <&gpio0 18 GPIO_ACTIVE_LOW>;
  8. Странное решение - у этого процессора нет видеоконтроллера для LCD а в логе у вас 4 ядра с драйвером ads7846 имел дело много раз и никаких проблем не возникало
  9. у них используется Synopsys Ethernet IP Core, "клей" тут https://elixir.bootlin.com/linux/v5.7.2/source/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c#L1256 из-за того что драйвер универсальный для всех SoC с такими IP там черт ногу сломит, мне кажется проще китайские исходники смотреть в вендорском ядре или в убуте еще можно посмотреть. Скорей всего у микроконтроллеров stm32xx похожая корка, так что не должно быть проблем с освоением если знакомы с ними - вот "клей" для них https://elixir.bootlin.com/linux/v5.7.2/source/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
  10. Это описание видеоканалов (VI), есть еще каналы интерфейса пользователя (UI) для графики, это они с RGB работают стр. 66 "5.7 DE UIS Specification". Но у v3s этот канал не поддерживает скалинг - у него два видеоканала со скалингом и один графический канал без скалинга https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1548202.html сэкономили
  11. судя по коду надо не за раз записывать значение в регистр а щелкать битами чтение https://elixir.bootlin.com/linux/v5.7.2/source/sound/soc/sunxi/sun8i-adda-pr-regmap.c#L29 запись https://elixir.bootlin.com/linux/v5.7.2/source/sound/soc/sunxi/sun8i-adda-pr-regmap.c#L52 битовые маски https://elixir.bootlin.com/linux/v5.7.2/source/sound/soc/sunxi/sun8i-adda-pr-regmap.c#L17
  12. но ядра два и 64 битные. Потом еще нейронный ускоритель есть - можно жестами управлять вместо кнопок (в том чиле неприличными)
  13. Миконтроллеры на RISC-V не смотрели ? Вот например https://aliexpress.ru/item/33031620950.html https://aliexpress.ru/item/33031221223.html https://aliexpress.ru/item/33031564354.html CPU - зверюга, лишнего MMU нет, встроенная SRAM 8 Мбайт. С дисплеем стоит всего 1500 руб. Паябельный, стоит недорого и натрахаться с запуском можно всласть :)
  14. А зачем если с Linux результат тот же да и написаны все эти емуляторы и клоны линуксоидами под GPL. А если уж писать для баре метал так у i.mx6ull есть SDK с драйверами для всей периферии и примерами с RTOS и с голым железом. Вот и возникло у меня удивление - какой смысл был пару лет дрочить вприсядку ? Причем результат парадоксальный - DSP на обработке изображений и звука внезапно проигрывает RISC CPU с возможностями микроконтроллера.
  15. В чем разбираться ? Вот видео opentyrian на i.mx6ull (cortex a7 800 МГц, он даже слабже a8) - Linux с SDL поверх фреймбуфера, всё полностью софтовое даже звук без DMA - CPU загружает сэмплы в FIFO PWM. Включен софтовый скалер scale2x,а разрешение экрана 800x480 Загрузка ЦПУ 70%. Облака прозрачные, музыка играет. Сделать скалер на PXP (это аналог DE только документирован хорошо и больше форматов RGB поддерживает) и ЦПУ разгрузится и картинка будет нормальной полноэкранной. Сделать это элементарно - доавить в конвеер с LCD контроллером блок PXP, выставить нативное разрешение 320x200 - всё. Сборка этой фигни в buildroot заняла у меня 15 минут. Аудикодек встроенный у imx6ull тоже есть - у меня вариант плаы где он не выведен, включить его и процессор еще разгрузится - у PWM нет DMA и FIFO всего 4 байта - постоянные прерывания контекста от него прилетают.