Atmel ATSAMD20-XPRO: собираем компилятор

Поскольку сборка компилятора привела к боли и страданиям, она будет тут сохранена для истории (такими историями гугл полнится).

Возьмем последний binutils-2.24:
./configure  --target=arm-none-eabi -enable-interwork   --enable-multilib --disable-nls  --disable-libssp --prefix=/opt/arm-none-eabi
make
make install-strip
export PATH=$PATH:/opt/arm-none-eabi/bin

Возьмем newlib-2.0.0 и распакуем его, пусть проветривается.

Возьмем gcc-4.8.2 который слышал о cortex-m0plus. Возьмем дебиановские патчи отсюда. Наложим их и скомпилируем:
mkdir build
../configure  --target=arm-none-eabi --prefix=/opt/arm-none-eabi --enable-languages="c,c++" --enable-interwork --enable-multilib  --with-
newlib --with-headers=/path/to/src/newlib-2.0.0/newlib/libc/include/  --disable-nls --disable-libssp  --with-system-zlib --with-multilib-lis
t=armv6-m
# в этом месте ./configure может ругаться, надо проследить чтобы он заголовки смог переписать на место
make
make all-gcc
make install-gcc

newlib собирается со следующими ключами (без --disable-newlib-supplied-syscalls не собираются некоторые куски для armv6-m, и atmel-овский asf ругается на дублирующиеся определения функций из syscalls):
./configure --target=arm-none-eabi -enable-interwork --enable-multilib --disable-libssp --disable-nls --prefix=/opt/arm-none-eabi --disable-newlib-supplied-syscalls  --enable-newlib-register-fini --enable-newlib-io-long-long
make
make install

После доделываем gcc:
cd build
make all
make install

Atmel ATSAMD20-XPRO


ATSAMD20-XPRO оценочный набор для новой серии микроконтроллеров Atmel ATSAMD20 на ядре Cortex-M0+. Выглядит следующим образом:
Купить в России можно например тут: Дельта Электроника.

Этот пост о том как подключать эту плату в GNU/Linux. Плата снабжена интерфейсом micro-USB для отладки, реализуемым через отдельную микросхему. Atmel называет это «Embedded Debugger», анонсируется наличие виртуального последовательного интерфейса (прикрученного к основному чипу) и собственно средств отладки и программирования.

При подключении появляется устройство:
Bus 001 Device 010: ID 03eb:2111 Atmel Corp.

[13761.329235] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=2111
[13761.329240] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13761.329242] usb 1-1.5: Product: EDBG CMSIS-DAP
[13761.329245] usb 1-1.5: Manufacturer: Atmel Corp.
[13761.329247] usb 1-1.5: SerialNumber: ATML1873040200000110
[13761.330868] hid-generic 0003:03EB:2111.000A: hiddev0,hidraw3: USB HID v1.11 Device [Atmel Corp. EDBG CMSIS-DAP] on usb-0000:00:1a.0-1.5/input0
[13761.330964] cdc_acm 1-1.5:1.1: ttyACM0: USB ACM device

Устройство, как видно, отдает нам виртуальный последовательный интерфейс на /dev/ttyACM? и интерфейс CMSIS-DAP на /dev/hid*.

В openocd недавно добавили поддержку этого интерфейса. Пока пакеты openocd с поддержкой CMSIS-DAP доступны здесь:

В пакетах есть небольшой баг, связанный с тем, что udev стремится поставить на /dev/hidraw* группу владельца plugdev, которая по-умолчанию в системе не существует и в пакете не создается. openocd будет искать свой devel-project и потом попадет в Factory.

Запускаем и убеждается, что таки оно работает:
> openocd -f /usr/share/openocd/scripts/board/atmel_samd20_xplained_pro.cfg 
Open On-Chip Debugger 0.8.0-dev-snapshot (2013-12-13-18:45)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: FW Version = 01.0F.00DB
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : IDCODE 0x0bc11477
Info : at91samd20j18.cpu: hardware has 4 breakpoints, 2 watchpoints

Быстродействие UNIX сокетов

Сравнение скорости работы unix-сокетов. Выполнялась передача большого объема данных от одного процесса другому через unix-сокет. Изменялся размер данных, передаваемых за один вызов write/read (chunk). С каждым размером производилось пять измерений, результат усреднялся.


На графике черная кривая — производительность unix-сокетов, красная и зеленая — для сравнения копирование памяти memcpy в рамках одного процесса и, соответственно, копирование из разделяемой (shared) памяти. Если рост производительности при увеличении "размера пакета" для сокетов не является чем-то не очевидным, то падение производительности операции memcpy при росте значения третьего аргумента функции не тривиально.

Характеристики тестового стенда. Процессор: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, память: DDR3 Kingston HyperX KHX1600C9D3P1K2/8G. Ядро: 3.7.10.

Xen: проброс USB устройств

Xen умеет пробрасывать USB-устройства (по отдельности) в гостевые непривилегированные домены. Для этого используется механизм, называемый PVUSB (подозреваю, что сокращение от Para-Virtualized USB), концептуально состояний из модулей usbbk (Xen USB backend driver) и xen_hcd (Xen USB Virtual Host Controller driver). Соответственно, первый модуль съедает устройство в dom0, делая его недоступным для других драйверов, а все URB отправляет через гипервизор в нужный выбранный домен, где их получает перавиртуальный контроллер. Утверждается, что потеря производительности минимальна.

Вся конструкция управляется несколькими командами. Посмотреть, какие устройства доступны:
# xm usb-list-assignable-devices
4-2          : ID 067b:2303 Prolific Technology Inc. USB-Serial Controller
Создать в домене паравиртуальный USB хост контроллер: xm usb-hc-create Domain UsbVer PortNum, где параметры — название домена, версия USB (поддерживаются 1 и 2) и количество USB-портов. После этого, в гостевом домене с помощью lsusb видно появившийся контроллер. Для удаления есть обратная команда xm usb-hc-destroy

Для присваивания устройства есть команда xm usb-attach Domain HostNum PortNum Device, где параметры — название домена, номер хост контроллера (их можно хоть пачку создать), номер порта на виртуальном контроллере, первая колонка выдачи usb-list-assignable-devices. Обратная команда — xm usb-destroy. При этом, в dom0 устройство пропадет на глазах у изумленного драйвера:
[12129.803899] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[12129.803938] pl2303 4-2:1.0: device disconnected
но появится в гостевом домене:
# lsusb
Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Важное замечание. Если в гостевом домене ничего не появилось, кроме записей в dmesg:
[12332.892117] usb 1-1: new full-speed USB device number 70 using vusb
[12332.892126] usb 1-1: parent hub has no TT
то скорее всего, устройство не поддерживает USB 2.0, к которому его прицепили, нужно сделать другой контроллер с правильным параметром UsbVer.

Кроме того, устройство можно прибить гвоздями в конфигурационном файле домена:
vusb=['usbver=1, numports=4, port_1=4-2']
Список литературы:

gen_bunny для RabbitMQ 3.0


Немного подправил gen_bunny для новых версий клиентской библиотеки amqp_client. Поменялся только вызов amqp_connection:start/1 и связанные с ним записи. Брать здесь: https://github.com/matwey/gen_bunny/tree/amqp_client-3.0.4, пока больше ничего не отваливается, если отвалится — поправлю еще.

Настройка сети в Xen

Сеть в Xen работает по принципу виртуального моста, как рассказывается здесь: http://wiki.xen.org/wiki/Xen_Networking.

Сначала, надо сделать этот самый мост. В /etc/sysconfig/network/ifcfg-br0 надо написать буквально следующее:
BOOTPROTO='dhcp4'
# как для простого интерфейса, можно и статический адрес задать 
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0 eth1'
BRIDGE_STP='on'
# если два активных физических интерфейса в мост собраны,
# то пакеты могут и по кругу пойти без Spanning Tree Protocol.
STARTMODE='auto'
ifcfg-eth0 и ifcfg-eth1 лучше просто удалить, чтобы не мешались.

Теперь у нас есть самый настоящий мост, который можно вписывать в параметры конфигураций доменов: http://xenbits.xen.org/docs/4.2-testing/misc/xl-network-configuration.html.

Дальше запускаем домены, и проверяем, что появились их бэкендные интерфейсы:
# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.52540035c714       yes             eth0
                                                        eth1
                                                        vif1.0

Дальше настраиваем внутренний интерфейс домена, как это происходит обычно.

Диагностика ядра Linux

Сбои в ядре Linux приводят к возникновению чрезвычайно разнообразных симптомов. Некоторые авторы дают следующую неполную классификацию проблем, с которыми может столкнуться пользователь:
  • kernel oops — проблема при выполнении кода в ядре, например кто-нибудь попытался разыменовать нулевой указатель. С кем из программистов на C такого не случалось?
  • kernel panic — кто-то попытался разыменовать нулевой указатель в обработчике прерываний. После чего ядро уходит в полную несознанку и начинает мигать caps-lock-ом.
  • soft lockup ­— что-то заблокировалось (вероятно наткнувшись на не освобожденную блокировку), несмотря на это прерывания продолжают обрабатываться. Хорошее упражнение — попинговать машину или попытаться зажечь numlock.
  • hard lockup — компьютер жужжит вентиляторами и ни на что не реагирует. Провести какую-то диагностику в этом случае особенно сложно. Проблема может быть вызвана как вышедшим из строя железом, так и неаккуратной обработкой прерываний.
кроме того, можно добавить:
  • hung — индуцированное неправильной блокировкой последовательное попадание всех или большинства процессов системы в состояние TASK_UNINTERRUPTIBLE (известного так-же как D-состояние, по обозначению в top или ps). Согласно книге Р.Лава такой «наводящий ужас» процесс нельзя убить, завершить, и вообще что-то с ним сделать. При этом с точки зрения пространства пользователя программа просто заблокирована на каком-то системном вызове (например ввода-вывода). При попадании в подобное состояние всех критических процессов системы можно получить симптом похожий на soft lockup.
Получить как можно более подробную информацию о сути возникающей проблемы важно как для правильного написания сообщения об ошибке, так и для временного переконфигурирования системы с целью избегания выполнения проблемного кода и повышения её живучести.

К счастью, ядро обладает неким набором средств первичной самодиагностики, пригодным для постановки примерного диагноза. Согласно, видимо всеобщей, философской парадигме, наиболее устойчивыми и надежными являются наиболее простые подсистемы, поэтому сообщения ядра имеет смысл искать в текстовой и последовательной консолях. Конечно, при достаточном уровне везения нужное сообщение будет сброшено syslog-демону, записано на диск, отправлено по сети на удаленный syslog-демон и прочее, но при недостаточном везении монитор (и фотоаппарат на телефоне), клавиатура и COM-порт являются последней надеждой.

printk


Одним из механизмов общения ядра с внешним миром является printk. При неправильной настройке сообщение скорее всего будет просто потеряно как не обладающее значимостью. Для настройки используется /proc/sys/kernel/printk, соответствующий ему параметр sysctl, утилита klogconsole, SysRq-клавиша и т.п. Ядро обладает восемью уровнями важности сообщений, поэтому установка уровня в 8 заведомо напечатает все на консоль.

sysrq


Магическая кнопка включается в /proc/sys/kernel/sysrq или соответствующим ему параметром sysctl. Предлагается просто записать туда 1, несмотря на то, что новые ядра позволяют изысканный контроль над функционалом. В данной ситуации незачем себя ограничивать, хотя для нормальной работы разумно ограничить функционал на случай случайных нажатий. Если осталась рабочая терминальная сессия (например удаленная сессия по ssh), можно использовать как альтернативу, например, echo b > /proc/sysrq-trigger; с последовательной консоли поведение активируется кнопкой 'break'.

Важно помнить, что SysRq-w, например, выдает сообщение с уровнем KERN_INFO, то есть выдача printk должна быть настроена правильно, чтобы можно было что-то увидеть. Полный список команд SysRq.

softlockup_panic


Параметр ядра softlockup_panic или параметр kernel.softlockup_panic для sysctl включают панику ядра при обнаружении soft lockup. Описание внутреннего устройства. Включение паники позволит остановить выполнение системы и проанализировать выдачу, снабженную трассировкой, хотя контроль блокировки исполняется постоянно. Существует аналогичный механизм отслеживания hard lockup для многопроцессорных систем (если остались живые процессоры — есть шанс что сработает), с соответствующим параметром hardlockup_panic. Время срабатывания обычно в пределах одной минуты.

hung_task_timeout_sec


Механизм отслеживания процессов, надолго застрявших в состоянии TASK_UNINTERRUPTIBLE, параметры настраиваются через sysctl и /proc:
  • kernel.hung_task_panic — включает/отключает панику при обнаружении не прерываемого процесса;
  • kernel.hung_task_warnings — счетчик сообщений. Иными словами, если паника отключена, будет сообщено о таком количестве зависших процессов;
  • kernel.hung_task_timeout_secs — сколько секунд процесс должен непрерывно пробыть в TASK_UNINTERRUPTIBLE, чтобы вызвать сообщение. По умолчанию бывает либо выключено (0), либо очень большое число порядка 10 минут.
Сообщения снабжаются трассировкой, которая подсказывает в какой подсистеме происходит сбой.

FastCGI в Lighttpd и Nginx

Сравнение настроек, приводящих к одинаковому результату в Lighttpd и Nginx.

Настройки Lighttpd:
url.rewrite-once += ( "^/testfc$" => "/testfc/", )

fastcgi.server += ( 
        "/testfc" => ((
                        "bin-path" => "/path/to/fcgi/server.py",
                        "socket" => socket_dir + "/viewvc.sock",
                        "max-procs" => 1,
                        "check-local" => "disable",
                        "fix-root-scriptname" => "enable",
        ))
)

Настройки Nginx:
location /testfc/ {
                fastcgi_pass unix:/path/to/fcgi/sock;
                fastcgi_split_path_info ^(/testfc)(.*)$;
                fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param  PATH_INFO $fastcgi_path_info;
                fastcgi_param  PATH_TRANSLATED $document_root$fastcgi_path_info;
                include        fastcgi_params;
        }

Nginx сам запускать приложения не умеет, поэтому об этом нужно заботиться заранее. Например можно использовать изысканное решение с помощью systemd.

svn+ssh: коллективные соединения

При командах выполняемых на удаленном URL, типа copy или merge, subversion иногда требует несколько соединений. Для облегчения работы, можно применить стандартную возможность ssh — использовать одно TCP/IP соединение для нескольких сессий.

Чтобы не испортить настройки клиентского ssh, в секции [tunnels] файла конфигурации ~/.subversion/config зададим нужные настройки как параметры командной строки:
ssh = $SVN_SSH ssh -o "ControlMaster=auto" -o "ControlPath=/home/user/.ssh/svn_ssh-%r@%h:%p" -o "ControlPersist=60"

При этом соединение будет создаваться каждый раз при необходимости, и закрываться через 60 секунд после того, как оно становится невостребованным. ControlPersist=yes оставит соединение навсегда, что, вероятно, не очень безопасно, но зато позволяет комфортно исполнять разные команды, типа commit или update в течении работы, если расходы на создание соединения велики.

quilt и rpm

quilt — это система контроля патчей, в каком-то смысле предыдущая ступень эволюции систем контроля версий.

Пусть есть rpm-пакет и нужно обновить его версию, используя новый архив исходных кодов. При этом патчи останутся старыми, и не гарантируется, что они наложатся на новую версию, или не потребуется вмешательство человека, из-за того, что какой-то патч устарел. После того, как новый архив получен и Version: исправлен, можно прибегнуть к помощи quilt:
quilt setup libdc1394.spec

Эта команда создаст новую директорию в которой будут лежать распакованные исходные коды, символическая ссылка на директорию patches (хранит сами файлы патчей) и файл series (хранит порядок в котором патчи нужно применять). quilt не всегда успешно справляется с патчами, которые завернуты в %if.

Идеологически происходит следующее, у нас есть команда quilt, что-то вроде аналога git или hg, дерево исходников и стек патчей. Стек патчей в чем-то аналогичен ревизиям в системах контроля версий. Используя стек можно переходить от текущего состояния к следующему (применяя патч, quilt push) или к предыдущему (откатывая, quilt pop). Первоначально, мы находимся в самом нижнем состоянии (не модифицированные исходные коды):
>quilt top
Нет применённых патчей
>quilt applied 
Нет применённых патчей
>quilt unapplied 
patches/libdc1394.no-x11.patch
patches/libdc1394.ac.patch
patches/libdc1394-swab_fix.patch
patches/libdc1394.raw1394_set_iso_handler.patch
patches/libdc1394-v4l-2.6.38.patch
patches/libdc1394-visibility.patch

Дальше попробуем наложить первый патч (здесь потребовалась предварительная обработка из-за хитрой структуры директорий в конкретном случае),
>quilt push
Наложение патча patches/libdc1394.no-x11.patch
patching file libdc1394-1.2.2/examples/Makefile.am
patching file libdc1394-2.2.1/configure.in

Текущий патч: patches/libdc1394.no-x11.patch
>quilt top
patches/libdc1394.no-x11.patch
>quilt applied
patches/libdc1394.no-x11.patch

И так далее, пока не закончится весь стек патчей, но скорее всего так просто он не закончится. Задача — обновляя патчи, устранить конфликты. После принудительного применения (quilt push -f) следует вручную просмотреть все конфликтные места и исправить их нужным образом. Каждый патч отслеживает только некоторое число файлов (quilt files), но если отредактирован файл не из списка, то его нужно добавить (quilt add). После того как все исправлено, нужно обновить текущий патч: quilt refresh (это такой аналог commit, который исправляет текущий наложенный патч, основываясь на рабочей директории и предыдущей спрятанной копии)
>quilt refresh
Патч patches/libdc1394-v4l-2.6.38.patch обновлён



udev и camsource

(Пере)запускалка camsource (программы для показывания картинок с веб-камер) с помощью udev:

SUBSYSTEM=="video4linux", ACTION=="add", RUN+="/usr/bin/camsource -r /etc/camsource.conf"

Запускается на старте (когда udev обнаруживается usb-устройства), и перезапускается при их перетыкании (или перетыкивании).

Можно было бы сделать более красиво, т.е. использовать события "add" и "remove" и переменную DEVICE. Однако этому мешает, во-первых, использование нескольких источников в моей конфигурации (и camsource -k выключил бы сразу все), во-вторых какой-то встроенный глюк в самой программе. Дело в том, что запускаясь, процесс почему-то уходит в состояние зомби, и в /proc/NNNNN/fd оказывается пустота. А при использовании параметра [device] код ищет процесс именно по файловым дескрипторам. Иначе говоря, этот параметр вообще не работает.

Применив фантазию к udev, можно например включать трансляцию видео-потока. Что даже удобнее, чем вписывание не комплектуемых init.d-скриптам запуска camsource, ffserver и т.п. во всякие странные места типа /etc/init.d/boot.local.

OBS tar_scm: versionformat

Сервис для OBS под названием tar_scm позволяет автоматически создавать архивы из указанных репозиториев систем контроля версий исходных кодов. Естественно, имеет много параметров, описание которых не так просто найти. На головном web-интерфейсе взаимодействие с сервисами куда-то с недавних пор вообще пропало, там хоть какие-то подсказки содержались.

versionformat — один из самых любопытных параметров, позволяющих хоть как-то оформить название архива, для последующего действия сервиса set_version.

  • Для git в это поле можно указать:
    • @PARENT_TAG@ — bash любезно заменит на ближайший тег
    • поля из --pretty=format для последнего по времени коммита — полный список внизу, какой-то смысл в данной ситуации имеют %ct %cd %h (UNIX таймштамп, дата YYYYMMDD, короткий хэш коммита), причем дефисы будут любезно удалены по дороге sed'ом (даты будут получается в духе 20121221).
  • Для mercurial (hg):
    • поля из --template для последнего по времени коммита — полный список внизу. Огромное богатство для фантазии, есть встроенная опция для latesttag. Во время написания этого текста, не было способа выдать дату в виде YYYYMMDD, без дефисов. Сейчас все дефисы удаляются sed'ом, однако последняя версия tar_scm может быть еще не загружена на головной сервис.
  • svn понимает только %r — номер ревизии

  1. github: obs-service-tar_scm
  2. git show(1)
  3. hg templates