Tue, Aug 19, 2014

OBS: локальная сборка под ARM

Когда требуется локально пересобрать пакет под одну из архитектур ARM, например для тестирования сборки, можно воспользоваться следующим медленным подходом.

osc build --clean --alternative-project openSUSE:Factory:ARM qemu armv7l name.spec

Здесь указывается, что используется альтернативный проект для сборки — openSUSE:Factory:ARM (версию подставить по желанию), используется репозиторий qemu, который есть в этом проекте. Поэтому и указывается этот альтернативный проект.

Несмотря на то, что в данном примере указана архитектура armv7l, технически, это x86_64. В среду сборки будет установлен бинарный транслятор qemu, работающий через подсистему ядра binfmt. При инициализации ядро настраивается таким образом, что при виде сигнатуры ELF для архитектуры ARM вызывает бинарик как qemu-arm /usr/bin/..., подобно тому, как при виде символов "#!" в начале исполняемого файла вызывается указанный интерпретатор. Работает поэтому достаточно медленно.

К сожалению, с пакетами kiwi такое не проходит.

Mon, Apr 28, 2014

Ограничение времени работы — timekpr

Как-то так получилось, что в последнее время часто переустанавливаю систему — то обновляю, то сбои непонятные, то эксперименты разные. И часто забываю название программы, которую использую для ограничения времени игр моего старшего сына.
Это программа timekpr, которая уже вроде давно перестала обновляться, но лучшего варианта для моих целей пока я не нашел.
Главная задача — ограничить время работы моего сына. Сейчас это 1 час в день. Возможностей программы достаточно, чтобы он не смог играть больше часа, в его возрасте и часа многовато.
Раньше и сейчас эту программу легко найти по поиску на сайте opensuse.org, легкая установка в один клик, несложные настройки. Если у кого-нибудь возникнут вопросы — пишите, помогу с настройкой

Thu, Jan 02, 2014

openSUSE 13.1 на BeagleBone Black

BeagleBone Black — одноплатный компьютер на основе процессора TI AM3358 (Cortex-A8), выпущенный весной прошлого года:

На нем вполне успешно может загрузиться и даже работать openSUSE 13.1. Готовые образы для нанесения на microSD карточку находятся здесь. Эти же самые образы должны в теории работать и на BeagleBone. Конечно, пока все на этапе интеграции и поиска ошибок, поэтому имеется подробная инструкция по запуску:
  1. Скачать, распаковать и сделать dd на карточку образ системы *.raw.xz
  2. Подключить отладочный TTL-RS232 порт (можно использовать, например, такой, но важно помнить, что разработчики BeagleBone Black не поставили на свою плату преобразователь уровней и сигнал с отладочного RS232 идет в виде 3.3V. Подключение через обычный COM-порт на большом компьютере обречено на провал.), руководствуясь распиновкой. Используя screen /dev/ttyUSB0 115200, во-первых, можно будет легко видеть все этапы начиная от работы u-boot. Во-вторых, запустится Yast2 firstboot и попросит вас задать root пароль, завести пользователя, установить временную зону и системное время (аналогично тому, как это происходит на соответствующем этапе установки с DVD), а для этого потребуется интерактивное взаимодействие.
  3. Помните, что для загрузки с внешней карты памяти при подаче питания на устройство нужно удерживать кнопку S2 (она же boot select switch). Подсказка — загрузившись с SD карты можно подмонтировать раздел встроенной MMC памяти и переименовать или удалить файл загрузчика MLO, после этого загрузка будет всегда начинаться с SD, но загрузиться с MMC больше не получится.

Технические подробности (тем, кто хочет продолжить ковыряния) изложены в списке рассылки: http://lists.opensuse.org/opensuse-arm/2014-01/msg00001.html.

Sat, Dec 14, 2013

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

Mon, Jul 08, 2013

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']
Список литературы:

Fri, Jul 05, 2013

Elixir

Больше маргинальных языков в openSUSE. Elixir — основываясь на Erlang, является еще более маргинальным языком.

Брать здесь — http://software.opensuse.org/package/elixir.

Mon, Jun 17, 2013

Настройка сети в 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

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

Sat, Apr 13, 2013

Диагностика ядра 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 минут.
Сообщения снабжаются трассировкой, которая подсказывает в какой подсистеме происходит сбой.

Sun, Feb 24, 2013

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 в течении работы, если расходы на создание соединения велики.

Sun, Feb 17, 2013

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 обновлён