Нет, раз статический бинарь запускается, значит и в потрохах Qt все нормально, там же все вкомпилено вплоть до кода взаимодействия с фрейм-буфером.
Я еще попробовал старый испытанный билдрут с qt 4.6 скомпилять и там тоже програмы с ГУИ не запускаются.
Причем, вид ошибки - вообще нетипичен для userspace.
Похоже, проблема в ядре 3.16, которое я использую и которое доводил с помощью device tree скрипта описания платы.
Получается, что фрейм-буфер как таковой работает (утилитами проверено) - может быть, проблема во взаимодействии Qt и framebuffer, либо в каком-нибудь другом драйвере устройств, например, /dev/input?
а вы каким кросскомпилятором собираете ? у меня была когда-то похожая проблема на ядре 3.9 с i.mx53 - не работал mplayer на фреймбуфере, я тогда не стал разбираться - не до него было, подумал драйвер "сырой", а сейчас не могу вспомнить - каким компилятором собирал. В общем если компилятор старый - попробуйте собрать прямо в буидруте его с заголовками ядра той же версии что и рабочее ваше - 3.16, там это можно указать явно
на это тоже подумал - попросил inittab, думал конфликт с getty, но у вас нет getty на tty1.
предыдущий раз запускал на платформе am3359 (ti sitara) fb 320x240-16bpp. сейчас попробовал на atmel 9g45 fb 800x600-16bpp - все запускается и показывает..
все, что могу посоветовать еще попробовать поиграть числом цветов при запуске приложения или поискать, как включить вывод отладки - может предсмертный дебаг принесет ответ о незапуске..
ключей, увы, не помню - находил гуглем..
Я собираю предустановленым тулчейном от code sourcery arm-2013.11 А вот на какую версию заголовков ядра он рассчитан - не знаю. Но если не совпадают - это реальная причина таких проблем? Ядро-то я собираю им же.
просто я болььше не представляю на что еще думать :) работает консольный вариант и графический на других процессорах - мысли три:
1 баг в атмеловском драйвере фреймбуфера
2 нехватка RAM (легко проверить включив в ядре поддержку swap и подключив его)
3 проблемы с компилятором. Юзерспейс в общем случае должен быть собран компилятором с заголовками ядра на котором будет работать - так делают все дистрибутивы, но в ядре очень редко меняется базовый API поэтому часто используют одну сборку с разными ядрами. Единственный раз я напоролся на несовместимость где-то в районе версии ядра 2.6.38 - не работала tslib если собрать старым компилятором, так что исключить такой вариант в вашем случае нельзя.
Попробую пересобрать с билдрутовским тулчейном, может, получится
Вообще у меня по симптомам складывается впечатление, что это повреждение памяти. Например, первый запуск программы завершается с сообщением segmentation fault, второй раз не запускается вообще, выводя сообщение об ошибке загрузки libgcc.so (формат файла не elf). Типа повреждения кэша корневой фс в памяти. Правда, против переполнения говорит то, что cat /proc/meminfo показывает 55+ мег свободной памяти, этого должно хватать для запуска программы с qt без отладки.
Кроме 3.16 перепробовал ту же rootfs с ядром 3.14 - результат аналогичный. Похоже, от версии ядра зависит не явно. И потом все-таки фрейм-буфер успешно тестируется другими программами, так что все-таки qt.
Это вот упустил из вида - у вас же своя плата, в первую очередь тогда проверьте тестом memtester (есть в буилдруте) - хотя бы на несколько часов запустите, если есть ошибки памяти - странные баги будут преследовать на каждом шагу :)
Сейчас я на sk-at91sam9g45-xc6slx макетирую, все стандартно. А повреждение памяти - я имел в виду нарушение целостности данных в блоках памяти, выделенной ядром или юзерспейсом. Но за подсказку спасибо, надо будет попробовать.
27.10.2014 21:28 
27.10.2014 21:50
