Comments 14
Спасибо за статью! Написано толково и интересно. Вспомнил свои мытарства с прошивкой загрузчика и FamiliarLinux на HP iPAQ3900. Тогда еще андроидов не было, да и Linux на носимых устройствах еще был чем-то из ряда вон.
Плату заказал в феврале, руки чешутся завести llst под новой платформой :)
P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.
Плату заказал в феврале, руки чешутся завести llst под новой платформой :)
P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.
P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.
К сожалению детальной информацией о состоянии дел у разработчиков Black Swift я не владею.
Но есть по крайней мере одна хорошая новость: платы Black Swift существуют на самом деле :)
По первому впечатлению мой экземпляр работает вполне стабильно, хотя, конечно, чтобы утверждать это наверняка потребуются сколь-нибудь продолжительные испытания.
Что касается отсутствия открытых исходных текстов, то не вижу тут большой проблемы. Плата Black Swift это только одна из плат размером с почтовую марку на базе AR9331. Сходу вспоминаются Carambola 2 и Onion Omega, возможно есть и другие. Устройство микросхемы AR9331 не оставляет разработчику платы слишком большого простора для манёвра, так что платы получаются с хорошим уровнем совместимости между собой; отличаются лишь типом разъёмов да отчасти номенклатурой выведенных интерфейсов. В качестве ОС используется OpenWrt, это значит, что спроблем с портированием более-менее качественно написанного ПО пользователя быть практически не должно.
А утаивание исходных текстов (хотя на github.com уже завёлся малоактивный пользователь с подходящим именем, адресом и стрижом на юзерпике) и недостаток информации может выйти разработчикам боком, ибо нет ничего тайного, что не сделалось бы явным, ни сокровенного, что не сделалось бы известным и не обнаружилось бы.
Призываю разработчиков Black Swift поскорее обнародовать исходные тексты!
Похоже, что форум black-swift.com почтил своим вниманием pepe2k (автор загрузчика u-boot_mod). pepe2k просит раскрыть исходные тексты u-boot_mod для Black Swift.
Во-первых, спасибо за статью! Крайне полезная информация. Альтернатива для u-boot в виде barebox — это прекрасно! Больше загрузчиков хороших и разных! Пусть расцветают 100 цветов! И т.п. :-)
Во-вторых — да, мы (вернее, конкретно — я) виноваты в плане недостаточной информационной поддержки проекта Black Swift. Но реально зашиваемся, времени на общение не хватает. К тому же и бутлоадер, и прошивка меняются просто постоянно. Финальную версию бутлоадера я добил буквально вчера вечером, в таком виде исходники уже можно выкладывать в общий доступ — все работает наконец-то. Промежуточные версии людям выдавать — это нарываться на дикое количество потенциальных проблем с поддержкой…
В-третьих, исходники как загрузчика, так и прошивки OpenWrt (будут) полностью открыты, мы ничего не скрываем. Тут чисто техническая проблема — у меня вся разработка идет в виртуальной машине, образ которой занимает 20 Гб. Т.е. надо либо весь образ куда-то вываливать (а много ли желающих найдется 20 Гб качать?), либо писать подробнейшую инструкцию, как аналогичную среду получить самостоятельно. Чем, собственно, я сейчас и занимаюсь.
P.S. Антон, нет же никаких проблем получить исходники нашей версии u-boot. Просто спросил бы у меня…
Во-вторых — да, мы (вернее, конкретно — я) виноваты в плане недостаточной информационной поддержки проекта Black Swift. Но реально зашиваемся, времени на общение не хватает. К тому же и бутлоадер, и прошивка меняются просто постоянно. Финальную версию бутлоадера я добил буквально вчера вечером, в таком виде исходники уже можно выкладывать в общий доступ — все работает наконец-то. Промежуточные версии людям выдавать — это нарываться на дикое количество потенциальных проблем с поддержкой…
В-третьих, исходники как загрузчика, так и прошивки OpenWrt (будут) полностью открыты, мы ничего не скрываем. Тут чисто техническая проблема — у меня вся разработка идет в виртуальной машине, образ которой занимает 20 Гб. Т.е. надо либо весь образ куда-то вываливать (а много ли желающих найдется 20 Гб качать?), либо писать подробнейшую инструкцию, как аналогичную среду получить самостоятельно. Чем, собственно, я сейчас и занимаюсь.
P.S. Антон, нет же никаких проблем получить исходники нашей версии 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 можно было использовать штатно ;).
Объем виртуальной машины — реально 20Гб, потому как только билдрут OpenWrt занимает больше 8Гб после билда. А на этой же виртуалке еще и Eclipse развернут, и Java для него…
Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)
Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)
Объем виртуальной машины — реально 20Гб, потому как только билдрут OpenWrt занимает больше 8Гб после билда. А на этой же виртуалке еще и Eclipse развернут, и Java для него…
Вы меня заинтриговали. Скорее публикуйте описание вашей технологии!
Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)
Нет только. Надо ещё проверить, что после этого изменения всё работает как надо ;)
P.S. Прежде чем править один битик. Прошу не обойти вниманием issue #1.
Мы довольно далеко от pepe2K u-boot_mod ушли, к сожалению… Он апгрейд с USB носителей не поддерживает, и не только. Не факт, что получится как-то с ним синхронизироваться.
Как раз наоборот. Ваши изменения как раз будут явны — будет понятно далеко ли вы ушли. В любом случае, был же когда-то момент (ну хотя бы несколько минут ;), когда исходные тексты выглядели одинаково. Эта точка и будет базой для rebase.
Кроме того, если ваши изменения структурно реализованы удачно, то они в большинстве своём будут 1) «отключаемы» и 2) «где-то сбоку»; в этом случае обмениваться изменениями в обе стороны легко.
У pepe2k всего 120 коммитов в репозитории, так что найти ту версию, которую вы заимствовали для внесения изменений даже перебором не слишком сложно; но будет лучше если вы сами скажите версию в репозитории pepe2k, которую вы форкнули.
Кроме того, если ваши изменения структурно реализованы удачно, то они в большинстве своём будут 1) «отключаемы» и 2) «где-то сбоку»; в этом случае обмениваться изменениями в обе стороны легко.
У pepe2k всего 120 коммитов в репозитории, так что найти ту версию, которую вы заимствовали для внесения изменений даже перебором не слишком сложно; но будет лучше если вы сами скажите версию в репозитории pepe2k, которую вы форкнули.
35a5cbe, судя по всему
github.com/pepe2k/u-boot_mod/commit/35a5cbe18f8182b5b0ec166e5a06382f6d05143a
github.com/pepe2k/u-boot_mod/commit/35a5cbe18f8182b5b0ec166e5a06382f6d05143a
Вот искомая ветка github.com/frantony/u-boot_mod/tree/bsb-over-35a5cbe.
Найти 35a5cbe18f оказывается довольно просто:
В этой выдаче во второй колонке — SHA1 коммита из ветки master pepe2k, с которым сравниваем 'Initial upload', а в первой колонке будет количесво строк в соответствующем патче.
Таки да, первый локальный минимум соответствует как раз 35a5cbe:
Вот некоторые проблемы вашего commit'а 'Initial upload', решив которые вы значительно уменьшите его размер:
Найти 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/.
Да понятно, что можно получить снапшот из u-boot_mod (последней версии) и сделать к нему патч, который превратит его в исходники для нас. Только там несколько десятков файлов добавляются/меняются…
Т.е. по-хорошему надо тогда уж делать наш бутлоадер не из u-boot_mod, а из основной ветки u-boot. Заодно и версию с 1.1.4 проапгрейдить… Только это задача, мягко говоря, нетривиальная.
Т.е. по-хорошему надо тогда уж делать наш бутлоадер не из u-boot_mod, а из основной ветки u-boot. Заодно и версию с 1.1.4 проапгрейдить… Только это задача, мягко говоря, нетривиальная.
Да понятно, что можно получить снапшот из 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: для нетривиального адаптера желательно использовать буферизацию, см., например, 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 .
- зачем 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 .
Sign up to leave a comment.
Black Swift: использование EJTAG