Покидайтесь в меня пожалуйста ссылками на статьи по построению на базе L midi-станции, и по использованию годного для этого софта

Нужно ли что-то кроме комплекта из Piano Booster (для обучения), и RoseGarden (подготовка midi для бустера, микшер и простейшая пост-обработка) ?

В идеале: набор скриптов и/или мануалы по кросс-компиляции custom сборки midiLinux для Raspberry, в плане слепить из дешевой midi-клавы, малины, автомобильного мониторчика, и внешней USB-звуковухи колхозный аналог Yamaha Motif

PS: midi-клава cme u-key (синтом это не назвать)

Нарисовал набор скриптов кросс-сборки emLinux.

По какой-то неясной причине обычная тестовая программа https://github.com/ponyatov/azlin/raw/math/user/cpptest.cpp

при запуске выводит на stdout строку «ILL»

Никаких ошибок в скриптах сборки кросс-компилера и uclibc на нашел, обычный Си-компилятор работает без вопросов, отключение ключей оптимизации дает тот же результат.

Может кто сталкивался с такой проблемой ?

ветка https://github.com/ponyatov/azlin/tree/math

Подскажите google-заклинание для поиска описания, как настроить в локалке сетевую загрузку для пачки аппаратно-разных (x86, и отладочные платы на arm и mips) клиентов ?

Нужно отдавать для каждого клиента отдельное имя образа ядра и корневой файловой системы (nfs) основываясь на клиентском mac-адресе: т.е. запустив x86, получить по tftp kernel.x86, запустив малину — kernel.rpi, и т.д.

Выводится странный объем DRAM на кубике с 2x GT8UB256W DDR.

Пересобрал generic u-boot-2014.10 с Cubieboard_config и a10/cubieboard_512.fex из пакета sunxi-boards - результат такой-же.

Как прописать в cd src/uboot && make $(CFG_UBOOT) дефайны, прописанные в .h-файлах исходников, типа дефайна PHYS_SDRAM_0_SIZE ? Или есть более правильный способ ?

Подскажите, возможна ли сборка микросистемы, бинарно совместимой (способной работать без перекомпиляции) на перечисленных железках ?

С ARMовским железом практически не сталкивался, сейчас стоит задача раскурить, и собрать софт-часть платформы для создания управляющих систем (пока без жестких ограничений по РВ, интерфейсные панели и верхний уровень, увязывающий микроконтроллерные блоки обеспечивающие критический по времени и синхронизации функционал).

ЗЫ: еще еще ТионПро на PXA270, но я его уже не рассматриваю, заведется хорошо, нет — пусть дальше валяется...

Подскажите какие под Linux существуют подсистемы очереди обмена сообщениями между процессами ? Желательно с (включаемыми по необходимости) режимами планировки жесткого РВ, совместимыми с RT-патчами.

В рамках одного узла, в идеале — с возможностью роутинга между несколькими сетевыми узлами.

Что хочется — некая библиотека, можно и наверно даже желательно С++, позволяющая регистрировать обработчики, и посылать пакеты. Желательна возможность специфицировать интерфейсы, и выполнять _быструю_ проверку соответствия пакетов спецификации. Существуют ли реализации чего-нибудь типа CorbaRT и насколько они слонотронны ?

ЗЫ: возможно буду портировать/делать какую-нибудь простейшую GUI-систему, и эвенты будут ходить тоже в этих очередях на низком приоритете.

Нарисовал makefile для кросс-сборки мелкого встраиваемого Linuxа: https://github.com/ponyatov/cross

Обнаружился затык с кросс-сборкой Python 2.7.x: пользуясь мануалом http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html удается статически собрать ядро (python и libpython.a), но со сборкой модулей затык, множественные ошибки

Есть подозрение что для работы Python необходима поддержка динамических библиотек ? Или все же есть способ выбрать десяток модулей, и встроить их статически в интерпретатор, не таская мешок /usr/lib/python ?

PS: сначала попробовал пользоваться buildroot, но не нашел в документации как прописывать свои модули-расширения, сейчас возможно есть какие-то статьи как это сделать, собственный микровариант сборки меня уже устраивает, разве что хочется дополнительных плюшек типа питона