Black Swift: использование EJTAG

[@Halt]

Спасибо за статью! Написано толково и интересно. Вспомнил свои мытарства с прошивкой загрузчика и FamiliarLinux на HP iPAQ3900. Тогда еще андроидов не было, да и Linux на носимых устройствах еще был чем-то из ряда вон.

Плату заказал в феврале, руки чешутся завести llst под новой платформой :)

P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.

[@Frantony]

P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.

К сожалению детальной информацией о состоянии дел у разработчиков Black Swift я не владею.

Но есть по крайней мере одна хорошая новость: платы Black Swift существуют на самом деле :)

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

Что касается отсутствия открытых исходных текстов, то не вижу тут большой проблемы. Плата Black Swift это только одна из плат размером с почтовую марку на базе AR9331. Сходу вспоминаются Carambola 2 и Onion Omega, возможно есть и другие. Устройство микросхемы AR9331 не оставляет разработчику платы слишком большого простора для манёвра, так что платы получаются с хорошим уровнем совместимости между собой; отличаются лишь типом разъёмов да отчасти номенклатурой выведенных интерфейсов. В качестве ОС используется OpenWrt, это значит, что спроблем с портированием более-менее качественно написанного ПО пользователя быть практически не должно.

А утаивание исходных текстов (хотя на github.com уже завёлся малоактивный пользователь с подходящим именем, адресом и стрижом на юзерпике) и недостаток информации может выйти разработчикам боком, ибо нет ничего тайного, что не сделалось бы явным, ни сокровенного, что не сделалось бы известным и не обнаружилось бы.

Призываю разработчиков Black Swift поскорее обнародовать исходные тексты!

[@Frantony]

Похоже, что форум black-swift.com почтил своим вниманием pepe2k (автор загрузчика u-boot_mod). pepe2k просит раскрыть исходные тексты u-boot_mod для Black Swift.

[@dzhe]

Во-первых, спасибо за статью! Крайне полезная информация. Альтернатива для u-boot в виде barebox — это прекрасно! Больше загрузчиков хороших и разных! Пусть расцветают 100 цветов! И т.п. :-)
Во-вторых — да, мы (вернее, конкретно — я) виноваты в плане недостаточной информационной поддержки проекта Black Swift. Но реально зашиваемся, времени на общение не хватает. К тому же и бутлоадер, и прошивка меняются просто постоянно. Финальную версию бутлоадера я добил буквально вчера вечером, в таком виде исходники уже можно выкладывать в общий доступ — все работает наконец-то. Промежуточные версии людям выдавать — это нарываться на дикое количество потенциальных проблем с поддержкой…
В-третьих, исходники как загрузчика, так и прошивки OpenWrt (будут) полностью открыты, мы ничего не скрываем. Тут чисто техническая проблема — у меня вся разработка идет в виртуальной машине, образ которой занимает 20 Гб. Т.е. надо либо весь образ куда-то вываливать (а много ли желающих найдется 20 Гб качать?), либо писать подробнейшую инструкцию, как аналогичную среду получить самостоятельно. Чем, собственно, я сейчас и занимаюсь.

P.S. Антон, нет же никаких проблем получить исходники нашей версии u-boot. Просто спросил бы у меня…

[@Frantony]

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

Прошу на github! Пока писал, появился github.com/blackswift/u-boot.

Тут чисто техническая проблема — у меня вся разработка идет в виртуальной машине, образ которой занимает 20 Гб. Т.е. надо либо весь образ куда-то вываливать (а много ли желающих найдется 20 Гб качать?), либо писать подробнейшую инструкцию, как аналогичную среду получить самостоятельно. Чем, собственно, я сейчас и занимаюсь.

20 ГБ ?! Инсталляционный LiveCD какой-нибудь Fedor'ы 16 AFAIR занимал 4 ГБ, там было более чем достаточное количество ПО
(например, для скачки torrent'ов предлагалось 3 или 4 клиента).

Специально, чтобы делать LiveCD с инструментальными средствами для MIPS я сделал скрипты finnix-tuner, которые добавляют средства разработки к Finnix LiveCD. В этом случае размер образа LiveCD получается менее 500 МБ.
Сейчас, правда, я перешёл на использование custom LiveCD сразу на базе Debian, без вмешательства Finnix; размер образа LiveCD от этого не увеличился.

P.S. Антон, нет же никаких проблем получить исходники нашей версии u-boot. Просто спросил бы у меня…

Дмитрий! Напомню, что EJTAG это всё-так атракцион для хакеров.

Кроме того, отсутствие исходников позволяет мне отмазаться от исправления u-boot_mod так, чтобы EJTAG можно было использовать штатно ;).

[@dzhe]

Объем виртуальной машины — реально 20Гб, потому как только билдрут OpenWrt занимает больше 8Гб после билда. А на этой же виртуалке еще и Eclipse развернут, и Java для него…

Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)

[@Frantony]

Объем виртуальной машины — реально 20Гб, потому как только билдрут OpenWrt занимает больше 8Гб после билда. А на этой же виртуалке еще и Eclipse развернут, и Java для него…

Вы меня заинтриговали. Скорее публикуйте описание вашей технологии!

Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)

Нет только. Надо ещё проверить, что после этого изменения всё работает как надо ;)

P.S. Прежде чем править один битик. Прошу не обойти вниманием issue #1.

[@dzhe]

Мы довольно далеко от pepe2K u-boot_mod ушли, к сожалению… Он апгрейд с USB носителей не поддерживает, и не только. Не факт, что получится как-то с ним синхронизироваться.

[@Frantony]

Как раз наоборот. Ваши изменения как раз будут явны — будет понятно далеко ли вы ушли. В любом случае, был же когда-то момент (ну хотя бы несколько минут ;), когда исходные тексты выглядели одинаково. Эта точка и будет базой для rebase.

Кроме того, если ваши изменения структурно реализованы удачно, то они в большинстве своём будут 1) «отключаемы» и 2) «где-то сбоку»; в этом случае обмениваться изменениями в обе стороны легко.

У pepe2k всего 120 коммитов в репозитории, так что найти ту версию, которую вы заимствовали для внесения изменений даже перебором не слишком сложно; но будет лучше если вы сами скажите версию в репозитории pepe2k, которую вы форкнули.

[@olartamonov]

35a5cbe, судя по всему
github.com/pepe2k/u-boot_mod/commit/35a5cbe18f8182b5b0ec166e5a06382f6d05143a

[@Frantony]

Вот искомая ветка github.com/frantony/u-boot_mod/tree/bsb-over-35a5cbe.

Найти 35a5cbe18f оказывается довольно просто:

$ git clone https://github.com/pepe2k/u-boot_mod
$ cd u-boot_mod
$ git fetch https://github.com/blackswift/u-boot master:bsb
# b11b96faffa Initial upload
$ for i in $(git log --pretty=oneline | awk '{print $1; }'); do \
      echo $(git diff $i b11b96faffa | wc -l) $i; done | tac | less

В этой выдаче во второй колонке — SHA1 коммита из ветки master pepe2k, с которым сравниваем 'Initial upload', а в первой колонке будет количесво строк в соответствующем патче.

Таки да, первый локальный минимум соответствует как раз 35a5cbe:

70460 c150c0f936d68a67f5d8d9b0552d4f256a55c428
70229 86c17004f3255f6a7aa8bed7de3a3398d7becfd6
70227 38842e60e2135107b737cba9000a46c53c61f212
70196 75c1b124d016521d880f9049007bcf8b6f04fa59
70178 1ef156c6720aff7597a6ddce9731b8683c94aea2
70061 35a5cbe18f8182b5b0ec166e5a06382f6d05143a <<<<<<<
70076 37a8902138c1fc1e1c70b099caf0a7a0b5cbc574
70077 14f938eff37b2fc5537b02a40807c3f24fdbbbf7
70163 2a60916d779bc480c08605c3b4322f4aa7645ffb
70163 26be42bc8575ac9e3ce3410b14fe89bfa94fdfb2
70175 dd4922832a89a8303a7b76189b852827dc2f2ffc
70338 1fc25e0e9d8404dd5b0cebedec66a58fa2114573

Вот некоторые проблемы вашего commit'а 'Initial upload', решив которые вы значительно уменьшите его размер:

• в commit'е добавляется несколько *orig* файлов и каталогов;
• в commit'е меняются атрибуты многих файлов (считаю, что pepe2k зря сделал их executable, но такое изменение лучше делать отдельным commit'ом);
• некоторые файлы конвертируются из DOS line endings в unix line endings (к примеру, u-boot/include/pci_ids.h); этого лучше делать отдельным commit'ом или не делать вовсе;
• убраны READMEPL.md и original_u-boot_images/.

[@dzhe]

Да понятно, что можно получить снапшот из u-boot_mod (последней версии) и сделать к нему патч, который превратит его в исходники для нас. Только там несколько десятков файлов добавляются/меняются…
Т.е. по-хорошему надо тогда уж делать наш бутлоадер не из u-boot_mod, а из основной ветки u-boot. Заодно и версию с 1.1.4 проапгрейдить… Только это задача, мягко говоря, нетривиальная.

[@Frantony]

Да понятно, что можно получить снапшот из u-boot_mod (последней версии) и сделать к нему патч, который превратит его в исходники для нас. Только там несколько десятков файлов добавляются/меняются…

Повторюсь, см. github.com/frantony/u-boot_mod/tree/bsb-over-35a5cbe

Т.е. по-хорошему надо тогда уж делать наш бутлоадер не из u-boot_mod, а из основной ветки u-boot. Заодно и версию с 1.1.4 проапгрейдить… Только это задача, мягко говоря, нетривиальная.

Если прямо сейчас ваша версия u-boot_mod решает все возлагаемые на загрузчик задачи и вы не планируете добавлять загрузчику новые задачи в ближайшем будущем, то смысла переходить на mainline u-boot нет.

[@Frantony]

Вот комментарии от Павла Ферцера, которые он лбезно разрешил опубликовать:

• зачем openocd запускать с sudo? В Debian по умолчанию должен копироваться список udev правил, чтобы у любого обычного пользователя в группе plugdev была возможность использоваться адаптер. Там не хватает какого-то id или в чём проблема? По идее всё должно работать из коробки, сразу после apt-get install. (Примечание frantony: sudo в этой ситуации — указание на то, что доступ к FT2232 требует определённых полномочий и перестраховка от возможных ошибок на тот случай, если у пользователь Debian настроен не слишком удачно, или пользователь использует вообще не Debian);
• если использовать самодельные JTAG-адаптеры, то рекомендуется последовательно по всем сигнальным линиям прямо у адаптера подключать резисторы 47-100 Ohm для исключения «звона», от которого никакое снижение частоты не поможет. Вот ещё информация по самодельным адаптерам: article.gmane.org/gmane.comp.debugging.openocd.devel/23792

Примечание frantony: для нетривиального адаптера желательно использовать буферизацию, см., например, dangerousprototypes.com/docs/Bus_Blaster_buffer_logic; продвинутый Amontec JTAG Key вообще подстраивается под плату, с которой работает, получая от неё референсное рабочее напряжение: elk.informatik.fh-augsburg.de/hhweb/doc/openocd/usbjtag/usbjtag.html#_amontec_jtagkey_and_jtagkey_tiny .