Intel Minnowboard (v1) was one of the first Intel's attempts to create an open hardware (okay, to some extent, if we take all possible blobs into consideration) platform based on Intel CPU or SoC (in this case it's an Intel Atom E600 series with EG20T PCH).



Linus Walleij, who was actively maintaining the GPIO subsystem, once sent a patch to convert PCH UDC (USB Device Controller) driver to use GPIO descriptor interface. However, the original code looks strange and seems never worked. It means that VBUS detection mechanism wasn't supported by the kernel. His patch didn't change that, only improved to use modern data structures and APIs. That time I have promised him that I will check the schematics and test it at some point.

First part of the journey appears to be enabling IRQ on GPIO SCH controller, which is not quite usual in a sense of delivery to the OS. The (semi-)wrong assumption that the IRQ is shared with SCI, which is IRQ #9 for x86 case, brought up the wrong change ec689a8a8155 ("mfd: lpc_sch: Add support for Intel Quark X1000") in the kernel (yeah, sometimes product organizations focused on easier way to get job done, without deeper investigation involved). That change has been partially reverted in 922e8ce883e5 ("mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000""). Thanks to Jan Kiszka from Siemens for pointing out to the issue and developing initial fix that landed in the kernel with 7a81638485c1 ("gpio: sch: Add edge event support").

So, are we done? Nope! The second part is to fix GPIO in the UDC driver to be in align with the schematics, according to which (see page 4 D5 and page 8 B1-C2) it uses pin 12 (starting from 0, a.k.a. GPIO_SUS7) on that GPIO controller to detect VBUS. Hence the promised change to the driver 049d3db625a6 ("usb: gadget: pch_udc: Provide a GPIO line used on Intel Minnowboard (v1)") and its updated version dfc03e0bae86 ("usb: gadget: pch_udc: Use PCI sub IDs instead of DMI").

Now we done, right? Not really. What about to test? Yes, the third part is to be sure that it indeed works. The astute reader already asks the question: Why do we need this at all? The board has separate connection for USB host and UDC, it should simply work!. Unfortunately no.

There are possibilities regarding to how UDC should behave when the host is connected. One is to power the device (in our case the board itself) by VBUS, in other words to be USB self-powered device. This is not implemented in case of Minnowboard (v1). So another possibility is to detect VBUS to see when we actually got the host connection. But this is broken on... PCB level and hence doesn't work.

Let's look again at the schematics. First of all on the page 8 B2-B3 the ~4:7 resistor divider (39 kOhm : 68 kOhm) is depicted. It's needed for the high voltage, which is +5v, to be converted to the chip level, which is +3.3v.



So far so good. However, if we go to the page 19 C4 we will see... bootstrap pull-up 10 kOhm to +3.3v (with above 68 kOhm it gives us ~1:7 divider).



Okay, let's assume we connected USB device to it which may consume up to 100 mA on the +5v line. By Ohm's law its resistance could be equal to 50 Ohm. In such case we will have 10 kOhm to +3.3v on one leg and 39 kOhm + 68 kOhm (like in parallel due to above "short circuit") on the other. It still gives us ~1:2.5 divider against +3.3v power rail. That's still well higher than the logical "1" threshold.

Which means that VBUS detection is always high! The bootstrap is dedicated to detect the B1 stepping of the Intel Atom E600 SoC (see page 19 D2-D3). What to do in such case? I don't know the good answer because electrically it's not gonna work. Yes, we may use some timer logic or so to let the BIOS detect that, but I decided just to ignore the bootstrap, so I simply unsoldered R229 from the board. I hope somebody may fix the BIOS to just always assume the B1 stepping if it's not done yet.

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

Вечер первый, или ничто не предвещало беды

Традиционно я обновляю систему через yum. Так же начал и в этот раз, загрузил и установил пакеты fedora-release и fedora-release-notes руками, потом сказал yum update. Yum радостно зашуршал и через какое-то время выдал список ломающих систему зависимостей (самосборные пакеты), после их удаления все зависимости просчитались, и манящий своей перспективой вопрос "Продолжить [д/Н]:" появился на экране. Я, наивный, ответил: "Конечно, да!"

Полчаса на загрузку (да, я отсталый, у меня 10Мбит канал), и приключения начинаются...

Рекурсия - см. Рекурсия. Попытка просчитать транзакцию завершилась печально: rpm не смог найти свою внутреннюю зависимость rpmlib(X-CheckUnifiedSystemdir), и мне предложено было обновить RPM. "Ладно", - думаю я, - "обновлю руками", что сразу и сделал. Перезапускаю yum update, и снова здравствуйте. Картина никак не изменилась, хотя rpm уже 4.10.

Чем дальше в лес... Исходная зависимость требовалась для пакета filesystem - один из базовых пакетов системы. Попробовал установить пакет руками. Ага, идеи чучхэ не дали совершить действие. Я ж совсем забыл, что тут systemd головного мозга во весь рост! /lib, /bin и /sbin - символические ссылки на /usr/lib, /usr/bin и /usr/sbin соответственно. Я прилежно скопировал каталоги и поставил симлинки на их копии, но не подумал, что содержимое каталогов неплохо бы скопировать в соответствующие каталоги в /usr. Тут-то и поджидало меня веселье. Я говорю, хочу filesystem, glibc и ещё каких-то пару пакетов за раз поставить, игнорируя эту внутреннюю зависимость. Установка радостно обламывается, я остаюсь в системе, где у меня в /lib, /bin и /sbin нет никаких базовых утилит (они же в соседние каталоги забэкаплены)! Пришлось вспоминать LD_LIBRARY_PATH, LD_PRELOAD.

Может ли быть хуже? А вот может, после того, что команда ls и подобные заработали снова, я попытался обновить glibc. Я уж не припомню, что там обломалось, но каждый последующий запуск чего угодно заканчивался Segmentation fault. Вот тут пришлось ещё вспомнить и запуск бинарников через ld-linux.so... В процессе борьбы я склонялся к варианту "А ну его к чёрту, может с usb-брелока и по-новому раскатать систему?", но не наш же путь! Кое-как, привёл в чувства, догадался наконец скопировать содержимое /lib и Ко в соответствующие каталоги в /usr и перезапустили yum update, правда уже по частям (пара небольших обновления и пара довольно больших), после чего ушёл спать.

Забыл совсем упомянуть крах базы rpm во время песен и плясок вокруг разломанной системы. rpm --rebuilddb справился вроде бы неплохо, хотя появились дубликаты записей некоторых пакетов. Часть из них я удалил руками, часть (старые пакеты) удалились при обновлении yum'ом.

День следующий
Утром перед работой я перезагрузил систему, чтобы под новое ядро всё запустилось, да и посмотреть на этот самый systemd.

Ага, отвалилась сеть. Ну, ладно, до вечера уж подождёт. Вечером продолжил исследования. Не помню каким бубном и шаманскими танцами, но сеть поднялась (перезагружался для проверки, что автоматом всё тоже сработает). Открыл для себя nm-tool, nmcli и nm-online. Ах, помню, что пришлось сказать systemctl disable network.service - LSB сервис, который по сути кроме красных надписей при загрузке ничего не добавлял (может в этом была причина?).

Следующая проблема - X не стартуют. Долгое копание в заменителях runlevel'ов и файлах настройки systemd выяснил, автор сего чуда - большой любитель символических ссылок. Первое, надо проставить символическую ссылку на необходимую цель (у нас же systemd, помните?), чтобы она была целью по умолчанию. Попытка запуска init 5 ничего не давала. Посмотрел новомодный файл graphics.target, там упоминался display-manager.service. Догадаетесь, что мне было сказано на попытку systemctl start display-manager.service? Правильно "No such file or directory"! Символические ссылки... Эту мантру должен повторять каждый пользователь systemd. systemctl enable gdm.service автоматически (хоть где-то автоматика сработала!) проставил ссылку gdm.service <- default.service.

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

Проблемы с Xfce и их решения.

• systray стал бегать по панели, а не придерживаться её края. Оказывается, раньше tasklist автоматически занимал всю ширину панели. Коммит 080db558 всё испортил. Лечить установкой разделителя перед systray plugin со свойством expandable.


• magnet-link не открывается. Не знаю, что там произошло, исправление здесь.


• и самое нетривиальное, часы на боковой панели стали повёрнутыми вертикально. Вначале потратил время, чтобы найти параметр rotate-vertically, который установили в TRUE по умолчанию (что курили?). Затем выяснил, смена параметров вручную в файле настроек панели ни к чему не приводит, они перезаписываются (может я что-то неправильно там форматировал?), зато православный путь - использование xfconf-query, а именно
  xfconf-query -c xfce4-panel -p /plugins/plugin-18/rotate-vertically -n -t bool -s false, предварительно определив, как называется модуль часов.

Ну, ещё по мелочи, mc перестал нормально отображать цвета в панелях, когда запущен под screen, а терминал 256-цветный. На этот счёт есть запись #902911 в RH Bugzilla.

В остальном пока что полёт нормальный.

We are about to begin to listen to Linus' talk.

А вот как вы думаете, сколько собственных реализаций (не уникальных, а в абсолютной величине) в linux следующих методов?
- atoi() - перевод текстового представления числа в его значение
- hex_to_bin() - перевод шестнадцатиричной цифры из текста в значение
- isxdigit() - проверка символа, является ли он 16ричной цифрой
- hex_asc_hi(), hex_asc_lo() - обратная к hex_to_bin()

Кир как-то писал про возможности поучаствовать в opensource, так вот в ядре этих возможностей просто пруд пруди, ассенизатор - тоже нужная профессия :)

P.S. Кстати, вылавливание подобных копий не ограничивается git grep <...>.

heviosso suggested me to clean up a mess with hex2bin, bin2hex converters in the Linux kernel. In the result I've submitted two series of patches with 11 and 10 items (and two of them were submitted and ACKed before). Let's see a progress...

Обновил я себе на x60s Fedora 10 до Fedora 12 (правда на сайте написано, что так не бывает, возможно они имели в виду с чистой 10-ки до 12-ки никак, но у меня были все обновления наложены, да и обновлял я не сразу, а в несколько приёмов: glibc + зависимости первыми, дальше не помню уже).

Какие баги замечены и способы лечения, если есть:
а) практически всегда при долгом стоянии с закрытой крышкой "отъезжает" ядро, думал, что это bug #489907, так вчера зависло во время активного использования компьютера - симптомы отличаются от приведенных тем, что мигает CapsLock (bug #556156 was submitted);
б) udev не может разрулить ситуацию с интерфейсами, подробности и обход проблемы в bug #531074;
в) deluge не запускается -> лечим;
г) logjam перестал определять музыку (да, что-то в DBus наворотили снова, надо улучшить свой патч :), патч обновлён, redhat осведомлён;
д) во время загрузки udev вначале в консоли нормальный украинский, а потом белые буквы резко становятся жёлтыми, кириллица летит к чёрту, в консоли только можно английский углядеть, как лечить, ума не приложу (не копал ещё) похоже последним обновлением с ядром 2.6.31.12-174.2.3.fc12.i686 всё полечилось;
е) gnome-mount радостно выкинули (теперь каждый диалог открытия файлов содержит подключенные, но не обязательно примонтированные, тома, как в Mac OS X :-) ), так что пока не знаю, как в консоли сие сделать... Уже знаю )

Вот такой первый взгляд :)

Если не хочется ставить файлы документации (/usr/share/doc/<package>-<ver>, /usr/share/info/*, /usr/share/man/*) [1], но сохранить целостность базы RPM, то файл /etc/rpm/maros.custom со следующим содержанием должен помочь:
%_excludedocs 1
%_install_langs C:en:uk
Соответственно вторая строчка отключает установку файлов для непопавших в список локалей [2], то есть в моём случае остаются только /usr/share/locale/uk/* и английские сообщения.

P.S. Все "сопли" что остались после установки или обновления пакета - весьма вероятно ошибки упаковки пакета.

[1] Речь о файлах, описанных с помощью %doc в спеке.
[2] На самом деле отключаются файлы, прописанные в спеке как %lang(<locale>) <file>.

Помогите, кто чем может, сами мы не местные... что сейчас считается самым правильным в области каталогизирования дисков? Есть куча дисков, условно разделённых на категории - музыка, фильмы, программы, фото, документация, мусор. Хочется иметь некую БД, которая бы в обе стороны рассказывала о дисках, файлах, программах, их описаниях и пр. (какие-то custom ключевые слова).
Т.е., запросы вида "хочу знать, что на диске Х" или "музыка (жанр) (исполнитель)" выдал бы диски и файлы. Многого хочу? (В идеале хочется автоматизма добавления и расширения по данным, которые сами файлы хранят, то бишь EXIF для медиа, библиография для текстов, какие-то ключевые слова для документации и т.д.)

Пару недель назад обновил себе машину до Fedora-9.

То, что сделали из KDE, ни словами сказать, ни в посте описать. А была же нормальная структура программ, полезных и хороших.
После терзаний и мучений с глюкавейшим новым Konqueror и Firefox-3.0, в котором просто себя чувствуешь неуютно, да ещё эта зараза норовит всю память скушать как обычно, было принято решение идти обратно на Opera (хотя и здесь всё не так гладко).

Новый flash-plugin от Adobe - это какое-то тормозилово. Надо будет найти 9-ю версию и поставить. Да, после открытия спецификаций что-то совсем не видно подвижки в проектах swfdec и gnash. Или я давно не смотрел туда?

vlc плейер после mplayer'а не смотрится, хорошо, что оба доступны.
Но что сделали с mplayer'ом по части работы с avi - непонятно. Один из свежескаченных фильмов просто втупую стоит после 3-й секунды запуска, а vlc показывает.

Одна радость в жизни - hibernate стал работать стабильнее.

P.S. Меня терзают смутные сомнения, что доведение всего описанного до ума уже где-то описано...
Или есть большие подзрения...
Что-то явно есть!