Добрый вечер

Суть вопроса такая. На самодельной плате запускаю uclinux+busybox. Собирал все это в buildroot’e.

Так вот устройство нормально определяется на этапе загрузки системы.

Если его выдернуть - пишет отключено, если после этого вставить обратно, ничего не происходит. Устройство не появляется в выхлопе lsusb.

Пытался отключить и включить usb-hub через /sys/bus/usb/….. пишет что хаб найден, но энумерации usb устроств не происходит..

Тут вопросы такие: Искать проблему в драйвере usb? Нужен ли udev для этого? (он помечен как removed legacy option)

Вообще, это все для подключения usb модема. Оно как бы не очень надо, просто интересно. Когда делаешь usb_modeswitch пишет что все классно, устройство переключено, но по факту существующее отключается, а новое не появляется.

Добрый вечер.

Имеется плата с NAND. Загрузчик u-boot. На флешке есть раздел ubifs, на котором лежит ядро с вкомпиленным rootfs и busybox. Все грузиться и работает.

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

Или нужно минимальный инит в ядре, потом монтирование разделов, а потом переключение корневой фс?

Нужно на случай, если поправить что-то в скриптах загрузки, когда плата уже уехала.

Пытаюсь запустить nano-X GUI на uclinux. Не запускается из за того, что mmap на /dev/fb0 возвращает No such device.

Сам фреймбуфер находится в памяти микроконтроллера и определяется через Device tree. Драйвер используется simplefb.

Если следать cat /dev/urandom > /dev/fb0 экран заполняется шумом, т.е. вроде как драйвер нормально работает.

В самом драйвере, по умолчанию, нет функции fb_mmap, пытался прикрутить свою, в ней просто писал printk(«Hello»), на экране ничего не появилось, такое ощущение что mmap и не пытается вызвать эту функцию из драйвера.

В нете читал что mmap на системах без MMU не работает с блочными устройствами.

Фреймбуффер к блочным относится?

Какие есть варианты получить доступ к фреймбуфферу из приложения?

Притом что адрес известен, но при попытке записи по этому адресу из приложения, ядро падает с исключением Mem manage fault, если же писать туда что-либо из драйвера - все нормально пишется, это я проверял через ioctl, т.е. в драйвере просто делал заливку экрана одним цветом, а из приложения вызывал ioctl и экран заливался нужным цветом.

Вариант через open/lseek/write работает, но ну его нафиг.

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

Система: stm32f429 (ARM v7m) 24мБ ОЗУ ядро 5.6.12 собрано без MMU rootfs - busybox 1.31

Падает стабильно в течении 1-12 часов работы, при этом запущен httpd из busybox. падает с Unhandled exception и соответствующим выводом (приложить пока не могу, вывод на дисплей идет, переключил на вывод в компорт, как свалиться - могу добавить). Сказать что причина падения только в httpd нельзя, пару раз падал без него, но там тайминги памяти чуть другие были.

Поэтому когда часами ждешь результата после изменения чего-либо напрягает сильно.

Кстати, еще одна особенность. rootfs собранная из busybox работает не совсем как надо. Суть в том, что в нете качал rootfs если ее ставлю, при команде reboot проц норм перезагружается, если то что собранное сейчас - падает сразу, с выводом backtrace.

Думал на ошибки памяти,memtester показывает что все норм. Единственное, что без запущенного httpd тестирует 2Мб памяти, при запущенном не более 1Мб. (хотя top показывает в первом случае 15Мб free, во втором 13Мб).

И дальше поехали вопросы:

• Unhandled exception это реально прерывание, на которое нет обработчика?
• Вообще, сколько памяти ядру надо минимум, если free показывает больше половины доступной памяти это норм?
• Больше к железу, например, если FreeRTOS собирать на этот камень, то там обязательно всем аппаратным прерываниям нужно задавать приоритет который ниже чем прерывания самой ОС. Для ядра Linux тоже такое необходимо?
• Каким боком отловить можно причину падения (gdb как то криво работает, через раз останавливается на breakpoint’e)?

Доброго вечера.

В общем суть вопроса такая. Есть своя плата на STM32F429, к ней прикрутил загрузчик U-Boot. В загрузчике есть инициализация RGB дисплея без контроллера, который подключен к LTDC.

Так вот в Device Tree контроллер дисплея не прописывал, а есть только устройство framebuffer. Инициализацию LTDC прописывал ручками.

Так вот пока работает загрузчик - дисплей работает нормально.

Когда грузиться ucLinux, он подхватывает framebuffer и первые несколько секунд дисплей отображает этапы загрузки, а уже перед запуском самого init’a дисплей вырубается.

Пробовал запустить дисплей на стандартных драйверах от ST, ситуация в принципе такая же, т.е. дисплей показывает несколько секунд этапы загрузки (при этом пишет что устройство запущено, консоль переключена на fb0) потом отваливается.

Насколько я понял, сбрасывается периферия самого контроллера LTDC. Причем в ситуации с фреймбуфером, из Device Tree удалял все упоминания о LTDC (ну вроде того, что ядро о нем не знает ничего, и сбрасывать его не должно).

Куда копать?