![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
In our lab we are using a lot of different DUTs and most of them are connected via PDUs for the remote power cycle. The biggest part of PDUs are APC 7820B or similar (from APC). APC is controllable via SNMP and everything is so far, so good.
Couple of years ago I have got Keil Systems EnviroBot PDU (not produced anymore) from e-waste, which is 12 ports and quite an interesting device in a sense that it's accessible via HTTP only.
After a few hours of experimenting (yeah, I'm not a ninja in HTML/XML + shell) I have nailed it down to make it accessible via our scripts that in their turn are for users logged via SSH.
So, to show the state of the certain port:
Turning OFF...
...and turning ON:
Couple of weeks ago, due to some changes, we have ordered another PDU from IntelliNet, which appears a new device also accessible via HTTP-only.
For it it looks slightly different.
State:
OFF:
ON:
In all cases:
<ADDRESS>: IP or FQDN address of the PDU
<PORT>: power switch port, usually from 0 to 7
<FILE>: temporary file to cache the results, so one can get info for all ports on per port basis
Couple of years ago I have got Keil Systems EnviroBot PDU (not produced anymore) from e-waste, which is 12 ports and quite an interesting device in a sense that it's accessible via HTTP only.
After a few hours of experimenting (yeah, I'm not a ninja in HTML/XML + shell) I have nailed it down to make it accessible via our scripts that in their turn are for users logged via SSH.
So, to show the state of the certain port:
curl -s -L --noproxy '*' -o "<FILE>" "http://<ADDRESS>/power.cgi?mdu=0" xmllint --xpath "//tr[td/input[@name=\"switch<PORT>\"]]/td[3]/text()" --html "<FILE>" 2>/dev/null
Turning OFF...
curl -s -L --noproxy '*' -o /dev/null -d switch<PORT>="1" -d d12="1" -d B1="Submit" http://<ADDRESS>/out_control.cgi
...and turning ON:
curl -s -L --noproxy '*' -o /dev/null -d switch<PORT>="1" -d d12="0" -d B1="Submit" http://<ADDRESS>/out_control.cgi
Couple of weeks ago, due to some changes, we have ordered another PDU from IntelliNet, which appears a new device also accessible via HTTP-only.
For it it looks slightly different.
State:
curl -s -L --noproxy '*' -o "<FILE>" -u "admin:admin" "http://<ADDRESS>/status.xml" xmllint --xpath "//outletStat<PORT>/text()" "<FILE>" 2>/dev/null
OFF:
curl -s -L --noproxy '*' -o /dev/null -u admin:admin -X POST "http://<ADDRESS>/control_outlet.htm?op=1&outlet<PORT>=1&submit=Anwenden"
ON:
curl -s -L --noproxy '*' -o /dev/null -u admin:admin -X POST "http://<ADDRESS>/control_outlet.htm?op=0&outlet<PORT>=1&submit=Anwenden"
In all cases:
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.
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.
It's hard to get an ACPI ID
Apr. 9th, 2021 03:52 pmHistorically and due to lack of knowledge about process the ACPI IDs for some devices are abusing the specification. As of today the v6.4 of it [1] says in the chapter 6.1.5 "_HID (Hardware ID)":
Note that the first part of the ACPI ID is a Vendor ID which has to be in the official registry.
However, we have a lot of IDs, including some of them issued by Intel, that do not follow that.
Recently, while I cleaned up kernel from fake IDs [2] that hardware vendors never ever allocated for their devices (many of them simply don't care), it appears that Siemens on behalf of Seiko Epson was trying to establish yet another fake ID for their RTC discrete component in the Coreboot [3] and Linux kernel [4].
Luckily they have listened to me and actually followed the process, i.e. they have asked Seiko Epson to register themselves in ACPI registry [5], which happens couple of month ago under the 'SECC' vendor (while it’s even better, I dunno why they haven't simply reused their PNP Vendor ID which is in the registry for ages). And they have allocated the proper ID, SECC6110, for their RX6110SA component.
Now the patches for Coreboot (see [6]) and Linux kernel, as commit 8d69f62fddf6 ("rtc: rx6110: add ACPI bindings to I2C"), are accepted.
I really wish that all hardware vendors will follow this, including Intel (for the record, we improved a lot the ACPI ID allocation process and there shouldn’t be new cases).
Funny thing that newly introduced ID for Alibaba abusing the specification due to potential collisions with real PCI IDs ('BABA' can be represented as 0xbaba).
A valid ACPI ID must be of the form “NNNN####” where N is an uppercase letter or a digit (‘0’-‘9’) and # is a hex digit. This specification reserves the string “ACPI” for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.
Note that the first part of the ACPI ID is a Vendor ID which has to be in the official registry.
However, we have a lot of IDs, including some of them issued by Intel, that do not follow that.
Recently, while I cleaned up kernel from fake IDs [2] that hardware vendors never ever allocated for their devices (many of them simply don't care), it appears that Siemens on behalf of Seiko Epson was trying to establish yet another fake ID for their RTC discrete component in the Coreboot [3] and Linux kernel [4].
Luckily they have listened to me and actually followed the process, i.e. they have asked Seiko Epson to register themselves in ACPI registry [5], which happens couple of month ago under the 'SECC' vendor (while it’s even better, I dunno why they haven't simply reused their PNP Vendor ID which is in the registry for ages). And they have allocated the proper ID, SECC6110, for their RX6110SA component.
Now the patches for Coreboot (see [6]) and Linux kernel, as commit 8d69f62fddf6 ("rtc: rx6110: add ACPI bindings to I2C"), are accepted.
I really wish that all hardware vendors will follow this, including Intel (for the record, we improved a lot the ACPI ID allocation process and there shouldn’t be new cases).
Funny thing that newly introduced ID for Alibaba abusing the specification due to potential collisions with real PCI IDs ('BABA' can be represented as 0xbaba).
20-тилетие FreeBSD
Jun. 22nd, 2013 08:00 pmЧто-то много разговоров о FreeBSD на этой неделе. Даже твит был, где явно радостно воспевалось "Happy Birthday [to me, FreeBSD]". Увидев тот твит, подумалось, что Сен-Санс написал музыку "[Умирающего] лебедя" как раз в мажорных тонах, но партия, исполненная Анной Павловой, заканчивалась трагически...
Popularity versus time
Jan. 16th, 2011 06:29 pmК вопросу о быстротечности жизни, я вчера под прямой эфир Радио-Т решил сделать скрипт, который брал бы по имени пользователя Youtube все запощенные им ролики и строил график количества просмотра ролика в зависимости от даты его публикации. Как и показывает практика, у тех, кто постит исключительно свои творения в своём стиле, популярность со временем падает (может даже кто-то увидит экспоненту там или ещё какую функцию, обобщающую стиль падения).
( А теперь графики )
Программерское
Dec. 13th, 2010 04:16 pmЗацените содержимое патча.
http://git.gnome.org/browse/epiphany/commit/?id=5641c511a80969b910ba45897a2be3c411d40618
P.S. Оно совсем короткое, но говорит о многом, да.
http://git.gnome.org/browse/epiphany/commit/?id=5641c511a80969b910ba45897a2be3c411d40618
P.S. Оно совсем короткое, но говорит о многом, да.
Обновление
Oct. 31st, 2010 05:57 pmДобавил фильтрацию в скрипт gopmlgen, которым я синхронизирую подписки в Google Reader'е.
Добавлена опция
Таким образом можно держать человека во френдах в соответствующей соц. сети, но при этом не аггрегировать его поток в Google Reader.
Исходники проекта: http://github.com/andy-shev/gopmlgen
P.S. Предыдущие записи по теме:
http://andy-shev.livejournal.com/113313.html
http://andy-shev.livejournal.com/81393.html
http://andy-shev.livejournal.com/67256.html
Добавлена опция
--exclude <FILE> или --exclude "STRING", которая принимает список URI для исключения из обработки.Таким образом можно держать человека во френдах в соответствующей соц. сети, но при этом не аггрегировать его поток в Google Reader.
Исходники проекта: http://github.com/andy-shev/gopmlgen
P.S. Предыдущие записи по теме:
http://andy-shev.livejournal.com/113313.html
http://andy-shev.livejournal.com/81393.html
http://andy-shev.livejournal.com/67256.html
хозяйке на заметку
Oct. 28th, 2010 04:09 pmЧтобы узнать размер кластера FAT на работающей системе
- можно использовать и hexdump
- можно вырезать и самой dd, но прочитается с диска всё равно не один байт
Есть более лёгкие способы?
dd if=/dev/mmcblk0p1 bs=512 count=1 2>/dev/null | od -j13 -N1 -i- можно использовать и hexdump
- можно вырезать и самой dd, но прочитается с диска всё равно не один байт
Есть более лёгкие способы?
Irish visa
Oct. 19th, 2010 11:17 amNow I'm a happy owner of the Irish visa to participate in the MeeGo Conference.
Fedora vs. Git
Sep. 11th, 2010 02:44 pmFedora переехала на Git где-то с месяца полтора назад. Таким образом дистрибутив F-14 уже собирается из пакетов, хостящихся в Git-репозиториях.
Соответствия старым командам описаны на страничке Using Fedora GIT.
Работать стало приятнее, по сравнению с CVS, да и происходит всё быстрее (так как репозитории маленькие и автономные).
Соответствия старым командам описаны на страничке Using Fedora GIT.
Работать стало приятнее, по сравнению с CVS, да и происходит всё быстрее (так как репозитории маленькие и автономные).
Google - strange corporation
Sep. 11th, 2010 01:57 pmВот как Google поступает с "обработанными" отчётами об ошибках:
gdata-python-client
Google Data APIs Python Client Library
...
Issue Not Found
What happened?
Issue 391 has been deleted.
Такое вот взаимодествие с community. Потом и не поймёшь, откуда ноги растут.
gdata-python-client
Google Data APIs Python Client Library
...
Issue Not Found
What happened?
Issue 391 has been deleted.
Такое вот взаимодествие с community. Потом и не поймёшь, откуда ноги растут.
Хозяйке на заметку
Jul. 18th, 2010 02:15 pmНаконец дошли руки обновить подписки в Google Reader.
В связи с этим допилил частично свой скрипт, о предыдущей версии которого я уже писал ранее.
Теперь скрипт умеет две основные вещи, обновление подписок и сравнение подписок между GR и другим сервисом (таковых сейчас три: YouTube, LiveJournal, PicasaWeb).
Соответственно опция --subfolder носит не только полезную, но и смысловую нагрузку. Иначе в разнице будут присутствовать совсем не те подписки, которые хотелось бы обновить.
Примеры запуска:
Есть однако и ложка дёгтя, заключающаяся в ошибке #391, не позволяющей отправлять запросы со своим Content-Type. Лечится патчем на gdata-python-client.
В связи с этим допилил частично свой скрипт, о предыдущей версии которого я уже писал ранее.
Теперь скрипт умеет две основные вещи, обновление подписок и сравнение подписок между GR и другим сервисом (таковых сейчас три: YouTube, LiveJournal, PicasaWeb).
Соответственно опция --subfolder носит не только полезную, но и смысловую нагрузку. Иначе в разнице будут присутствовать совсем не те подписки, которые хотелось бы обновить.
Примеры запуска:
$ gopmlgen --service youtube --subfolder 'YouTube' --diff
Removed(1):
http://gdata.youtube.com/feeds/base/users/0andriy/subscriptions - Videos published by : 0andriy
$ gopmlgen --service youtube --subfolder 'YouTube' --diff --self --update all
Removed(1):
http://gdata.youtube.com/feeds/base/users/0andriy/subscriptions - Videos published by : 0andriy
Added(1):
http://gdata.youtube.com/feeds/base/users/0andriy/uploads - Videos published by : 0andriy
Есть однако и ложка дёгтя, заключающаяся в ошибке #391, не позволяющей отправлять запросы со своим Content-Type. Лечится патчем на gdata-python-client.
Для тех, кто в теме
Jul. 16th, 2010 11:23 amИнтересный правовой вопрос. Имеем некий консольный инструмент, разрабатывавшийся в рамках GPLv2.
Затем авторы решили сделать следующие вещи:
- перейти на лицензию GPLv3
- перейти от CVS на Git
- наложить все pending патчи и выпустить новый релиз.
Теперь смотрим хронологию.
- была версия n.m
- её залили в Git
- наложили отдельными комитами pending патчи
- удалили лицензию атомарным комитом
- навели какой-то порядок несколькими комитами
- переписали часть инфраструктуры сборки несколькими комитами
- ввели новую лицензию атомарным коммитом
- зарелизили новую версию
Вот, есть два вопроса:
- с какого места считается программа под новой лицензией?
- какая лицензия у программы, когда файлы лицензии были удалены?
Естественно, упирается вопрос также в то, что можно ли срез дерева на определённый момент считать продуктом творчества авторов?
P.S. Понятно, что отчасти все эти вопросы бредовые, но это же мир юриспруденции - им бы повод языками почесать да денег за это побольше срубить.
Затем авторы решили сделать следующие вещи:
- перейти на лицензию GPLv3
- перейти от CVS на Git
- наложить все pending патчи и выпустить новый релиз.
Теперь смотрим хронологию.
- была версия n.m
- её залили в Git
- наложили отдельными комитами pending патчи
- удалили лицензию атомарным комитом
- навели какой-то порядок несколькими комитами
- переписали часть инфраструктуры сборки несколькими комитами
- ввели новую лицензию атомарным коммитом
- зарелизили новую версию
Вот, есть два вопроса:
- с какого места считается программа под новой лицензией?
- какая лицензия у программы, когда файлы лицензии были удалены?
Естественно, упирается вопрос также в то, что можно ли срез дерева на определённый момент считать продуктом творчества авторов?
P.S. Понятно, что отчасти все эти вопросы бредовые, но это же мир юриспруденции - им бы повод языками почесать да денег за это побольше срубить.
DSP Bridge
Jun. 24th, 2010 10:32 amNow officially: TI DSP Bridge driver take a place in the Linux kernel mainstream under staging subtree.
Therefore, all my patches to that driver were not in vain.
Therefore, all my patches to that driver were not in vain.
LinuxTag 2010 (links)
Jun. 14th, 2010 06:07 pmПросто подборка разрозненных постов про LinuxTag 2010 (обратный хронологический порядок):
Доклад
Берлин, день 2
Выставка-конференция
linux tag 2010
Berlin, Berlin...
Next week
LinuxTag2010
Доклад
Берлин, день 2
Выставка-конференция
linux tag 2010
Berlin, Berlin...
Next week
LinuxTag2010
Выставка-конференция
Jun. 9th, 2010 05:40 pmПрилетел вовремя, только до отеля добирался долговато, не торопясь.
А в Берлине классно! Участников конференции поселили в 4-хзвёздочный отель "Сенатор"
Отличная комната, 12й этаж, ресторан на 16ом со смотровой площадкой, там будут завтраки давать.
Осталось только выступить.
P.S. Сейчас сижу на стенде OpenVZ с Кириллом (![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
k001) и Лесей (al_shams)
А ещё обнаружилось место, где участникам раздают бутерброды и пиво.
А в Берлине классно! Участников конференции поселили в 4-хзвёздочный отель "Сенатор"
Отличная комната, 12й этаж, ресторан на 16ом со смотровой площадкой, там будут завтраки давать.
Осталось только выступить.
P.S. Сейчас сижу на стенде OpenVZ с Кириллом (
k001) и Лесей (al_shams)А ещё обнаружилось место, где участникам раздают бутерброды и пиво.
linux tag 2010
Jun. 9th, 2010 04:14 pmHello from linux tag 2010!
Now I'm sitting at the OpenVZ booth withk001. We just had a good lunch in Casino restaurant.
Now I'm sitting at the OpenVZ booth with
k001. We just had a good lunch in Casino restaurant.Dear friends,
on next week I'll travel to Germany. I remind you to book your tickets to Berlin in time.
See you there!
Дорогие друзья,
на следующей неделе я еду в Германию. Позволю напомнить, что пора уже покупать билеты в Берлин.
Встретимся!
on next week I'll travel to Germany. I remind you to book your tickets to Berlin in time.
See you there!
Дорогие друзья,
на следующей неделе я еду в Германию. Позволю напомнить, что пора уже покупать билеты в Берлин.
Встретимся!
