Чипы делают совместимыми со старыми для упрощения создания изделий на базе этих самых чипов.
Гораздо проще и быстрее (да, и в конечном итоге, дешевле) использовать уже готовое программное обеспечение и наработки в области аппаратуры, чем заниматься освоением новой неведомой фигни, которая, возможно толком и не работает.
Ну с точки зрения совместимости у Baikal-T1 полный порядок — не хуже чем у аналогов. Достаточно посмотреть, сколько ребят с почтой в imgtec.com участвуют в разработке ядра linux. К примеру поддержку процессорного ядра Warrior AKA P5600 в ядре linux ведут сотрудники Imagination (см. например, Add basic MIPS P5600 core support). Аналогичная ситуация и для прочих нужных opensource компонентов (GCC, U-Boot, qemu). Так, что Baikal в этом смысле делает изделие для которого имеется и поддерживается всё нужное для разработки ПО.
Кроме процессорного ядра в Baikal T1 есть и всякие там контроллеры (DDR3, PCIe, Ethernet 10G и Ethernet 1G, USB и SATA, и, по мелочи, всякие UART'ы и SPI). AFAIK эти контроллеры тоже покупные.
Возникает вопрос: а на сколько процентов этот самый T1 «российский»?
Думаю, что козырять словом «российский» применительно к изделию отвёрточной сборки не слишком хорошо, даже скажу больше, плохо.
IMHO, заголовок «Массовое производство SoC Baikal-T1 запустят в начале 2016 года» для данного поста был бы более уместен.
По поводу количества логических ячеек, которое требуется для mips32r1, надо внести поправку.
На самом деле из более чем 9000 LE надо вычесть те LE, которые пошли на реализацию bootrom (подозреваю, что bootrom можно было сделать на memory и cъэкономить LE). Так что за вычитом bootrom mips32r1_soc_nano занимает чуть меньше 6000 LE.
Для лаб ядро MIPSfpga конфигурируется в little-endian режиме, но легко может быть переключено в big-endian.
А вот mips32r1, как я понял, предназначено для работы в big-endian, а работоспособность little-endian режима ещё надо проверять.
На фоне MIPSfpga ядро mips32r1 смотрится довольно блекло:
* версия r1 архитектуры против r3 в MIPSfpga;
* нет кэшей и TLB.
Раз нет кэшей и TLB, значит никто не пускал на этом ядре Linux, то есть ядро можно сразу считать малотестированным.
Опять же переходники на Wishbone отъедают такты, их надо убирать.
С другой стороны это ядро может привлечь энтузиастов, которым интересно самим сделать собственное ядро. Хотя ядро не очень новое, а желающих его развивать не видно.
А у меня таких сомнений нет — такие люди существуют!
Я включил этот параграф именно потому, что один из моих студентов пару раз перепутал, какой вариант Debian ему надо установить — для i386 или для amd64. Так что лишним этот параграф не будет.
Вот комментарии от Павла Ферцера, которые он лбезно разрешил опубликовать:
зачем 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
Да понятно, что можно получить снапшот из u-boot_mod (последней версии) и сделать к нему патч, который превратит его в исходники для нас. Только там несколько десятков файлов добавляются/меняются…
Т.е. по-хорошему надо тогда уж делать наш бутлоадер не из u-boot_mod, а из основной ветки u-boot. Заодно и версию с 1.1.4 проапгрейдить… Только это задача, мягко говоря, нетривиальная.
Если прямо сейчас ваша версия u-boot_mod решает все возлагаемые на загрузчик задачи и вы не планируете добавлять загрузчику новые задачи в ближайшем будущем, то смысла переходить на mainline u-boot нет.
$ 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:
Вот некоторые проблемы вашего commit'а 'Initial upload', решив которые вы значительно уменьшите его размер:
в commit'е добавляется несколько *orig* файлов и каталогов;
в commit'е меняются атрибуты многих файлов (считаю, что pepe2k зря сделал их executable, но такое изменение лучше делать отдельным commit'ом);
некоторые файлы конвертируются из DOS line endings в unix line endings (к примеру, u-boot/include/pci_ids.h); этого лучше делать отдельным commit'ом или не делать вовсе;
Как раз наоборот. Ваши изменения как раз будут явны — будет понятно далеко ли вы ушли. В любом случае, был же когда-то момент (ну хотя бы несколько минут ;), когда исходные тексты выглядели одинаково. Эта точка и будет базой для rebase.
Кроме того, если ваши изменения структурно реализованы удачно, то они в большинстве своём будут 1) «отключаемы» и 2) «где-то сбоку»; в этом случае обмениваться изменениями в обе стороны легко.
У pepe2k всего 120 коммитов в репозитории, так что найти ту версию, которую вы заимствовали для внесения изменений даже перебором не слишком сложно; но будет лучше если вы сами скажите версию в репозитории pepe2k, которую вы форкнули.
Объем виртуальной машины — реально 20Гб, потому как только билдрут OpenWrt занимает больше 8Гб после билда. А на этой же виртуалке еще и Eclipse развернут, и Java для него…
Вы меня заинтриговали. Скорее публикуйте описание вашей технологии!
Я так понял, что включить EJTAG из исходников u-boot — это ровно один бит поправить в одной строчке. :-)
Нет только. Надо ещё проверить, что после этого изменения всё работает как надо ;)
P.S. Прежде чем править один битик. Прошу не обойти вниманием issue #1.
Тут чисто техническая проблема — у меня вся разработка идет в виртуальной машине, образ которой занимает 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. Просто спросил бы у меня…
Похоже, что форум black-swift.com почтил своим вниманием pepe2k (автор загрузчика u-boot_mod). pepe2k просит раскрыть исходные тексты u-boot_mod для Black Swift.
P.S.: Вы не подскажете, как идут дела у разработчиков BlackSwift? Информации на форуме крайне мало, в основном кормят завтраками. А хотелось бы услышать реальные новости пусть и с проблемами. Долетают только самые крохи информации не говоря уже о том, что исходники до сих пор не открыты. Очень странно все это смотрится на фоне статей самих разработчиков, которые всячески подчеркивали важность информационной поддержки.
К сожалению детальной информацией о состоянии дел у разработчиков Black Swift я не владею.
Но есть по крайней мере одна хорошая новость: платы Black Swift существуют на самом деле :)
По первому впечатлению мой экземпляр работает вполне стабильно, хотя, конечно, чтобы утверждать это наверняка потребуются сколь-нибудь продолжительные испытания.
Что касается отсутствия открытых исходных текстов, то не вижу тут большой проблемы. Плата Black Swift это только одна из плат размером с почтовую марку на базе AR9331. Сходу вспоминаются Carambola 2 и Onion Omega, возможно есть и другие. Устройство микросхемы AR9331 не оставляет разработчику платы слишком большого простора для манёвра, так что платы получаются с хорошим уровнем совместимости между собой; отличаются лишь типом разъёмов да отчасти номенклатурой выведенных интерфейсов. В качестве ОС используется OpenWrt, это значит, что спроблем с портированием более-менее качественно написанного ПО пользователя быть практически не должно.
Мне хотелось бы поспособствовать улучшению качества этого (и надеюсь будущих) видеоуроков.
Вот мои замечания:
термин порт в видеоуроке используется в двух смыслах: в одних случаях под портом понимается одна линия GPIO микроконтроллера; в другом случае употребляется порт B (см. урок после момента 3:18) в смысле блок управления восемью линиями GPIO. Это усложняет восприятие видеоурока;
было бы здорово, если бы исходные тексты находились не в zip-архиве (причём, для доступа к исходным текстам надо спуститься аж на 3 уровня вниз по иерархии каталогов: PDF/PDF/???/Indikator.h), а в каком-нибудь публичном репозитории; да хотя бы на github.com;
Отдельно отмечу оформление исходных текстов. Надо бы их как-то аккуратнее оформить.
Вот как выглядит ваш Indikator.h моём редакторе vim (символы табуляции показаны стрелкой, trailing whitespaces подсвечены красным):
Также замечу, что если сразу обозначить (1 << E) и аналогичные битовые маски макросами, то читать код станет легче (см., например, как задаётся PCIE_PL_PFLR_FORCE_LINK в pci-imx6.c). См., также макрос BIT.
В посте как-то странно использованы термины Multi-Drop и Point-to-Point.
Вот пара цитат:
Новая шина с оригинальным название Point-to-Point
Раньше шина Multi-Drop имела всего два канала
Можно подумать, что это имеются в виду названия конкретных шин (сравните шина PCI). На самом деле речь идёт о способе, которым конкретный компьютерный интерфейс (шина) обеспечивает соединения нескольких устройств.
Термин Multi-Drop переводится как общая шина и означает, что несколько устройств, подключённых в шине, используют общие линии для передачи данных; организацию общая шина используют I2C, PCI, VME и коаксиальный Ethernet 10Base-2.
Термин Point-to-Point обозначает, что для передачи данных между двумя устройствами выделены отдельные линии, которые никакое третье устройство задействовать не будет. Если надо соединить вместе более двух устройств, то как правило используются промежуточные устройства с несколькими интерфейсами (обычно зовутся коммутаторами). Организация точка-точка используется в RS232, PCI Express, Infiniband и USB.
Ограничение на передачу данных только между двумя устройствами имеет очевидные преимущества:
надо меньше париться по поводу того, как осуществлять арбитрацию (решать, кто в данный момент будет использовать общую среду передачи); более эффективно используется пропускная способность среды передачи;
разводку линий по печатной плате сделать проще, если знаешь, что эти линии соединяют только два устройства; проще обеспечить работу на высоких частотах, а значит и получить высокую пропускную сособность.
Гораздо проще и быстрее (да, и в конечном итоге, дешевле) использовать уже готовое программное обеспечение и наработки в области аппаратуры, чем заниматься освоением новой неведомой фигни, которая, возможно толком и не работает.
Ну с точки зрения совместимости у Baikal-T1 полный порядок — не хуже чем у аналогов. Достаточно посмотреть, сколько ребят с почтой в imgtec.com участвуют в разработке ядра linux. К примеру поддержку процессорного ядра Warrior AKA P5600 в ядре linux ведут сотрудники Imagination (см. например, Add basic MIPS P5600 core support). Аналогичная ситуация и для прочих нужных opensource компонентов (GCC, U-Boot, qemu). Так, что Baikal в этом смысле делает изделие для которого имеется и поддерживается всё нужное для разработки ПО.
Возникает вопрос: а на сколько процентов этот самый T1 «российский»?
Думаю, что козырять словом «российский» применительно к изделию отвёрточной сборки не слишком хорошо, даже скажу больше, плохо.
IMHO, заголовок «Массовое производство SoC Baikal-T1 запустят в начале 2016 года» для данного поста был бы более уместен.
Уточните, пожалуйста, о какой именно версии ядра идёт речь.
Из текста неочевидно, какая версия ядра подвержена описанной проблеме, а в какой всё починили.
На самом деле из более чем 9000 LE надо вычесть те LE, которые пошли на реализацию bootrom (подозреваю, что bootrom можно было сделать на memory и cъэкономить LE). Так что за вычитом bootrom mips32r1_soc_nano занимает чуть меньше 6000 LE.
См. github.com/open-design/mips32r1_soc_nano/tree/mips32r1_wb
За основу взято ядро mips32r1 c opencores (https://github.com/grantae/mips32r1_soc_nano).
И добавлены компоненты с opencores.
Ядро mips32r1 также как MIPSfpga не подключается к Wishbone напрямую,
использует свою собственную доморощенную шину.
Я сделал переходник с этой шины на Wishbone, так что получилась вот такая конструкция (в bootrom также прошит nmon):
Вот данные по потребляемым ресурсам для ПЛИС плат DE0-Nano, DE1-SoC и Марсоход3:
; Family; Cyclone IV E;
; Device; EP4CE22F17C6;
; Timing Models; Final;
; Total logic elements; 9,236 / 22,320 ( 41 % );
; Total combinational functions; 8,769 / 22,320 ( 39 % );
; Dedicated logic registers; 2,465 / 22,320 ( 11 % );
; Total registers; 2465;
; Total memory bits; 256 / 608,256 ( < 1 % );
; Device; 5CSEMA5F31C6;
; Timing Models; Final;
; Logic utilization (in ALMs); 3,642 / 32,070 ( 11 % );
; Total registers; 2669;
; Total block memory bits; 0 / 4,065,280 ( 0 % );
; Total DSP Blocks; 6 / 87 ( 7 % );
; Device; 10M50SAE144C8GES;
; Timing Models; Preliminary;
; Total logic elements; 9,117 / 49,760 ( 18 % );
; Total combinational functions; 8,754 / 49,760 ( 18 % );
; Dedicated logic registers; 2,465 / 49,760 ( 5 % );
; Total registers; 2465;
; Total memory bits; 256 / 1,677,312 ( < 1 % );
; Embedded Multiplier 9-bit elements; 16 / 288 ( 6 % );
Для лаб ядро MIPSfpga конфигурируется в little-endian режиме, но легко может быть переключено в big-endian.
А вот mips32r1, как я понял, предназначено для работы в big-endian, а работоспособность little-endian режима ещё надо проверять.
На фоне MIPSfpga ядро mips32r1 смотрится довольно блекло:
* версия r1 архитектуры против r3 в MIPSfpga;
* нет кэшей и TLB.
Раз нет кэшей и TLB, значит никто не пускал на этом ядре Linux, то есть ядро можно сразу считать малотестированным.
Опять же переходники на Wishbone отъедают такты, их надо убирать.
С другой стороны это ядро может привлечь энтузиастов, которым интересно самим сделать собственное ядро. Хотя ядро не очень новое, а желающих его развивать не видно.
Я включил этот параграф именно потому, что один из моих студентов пару раз перепутал, какой вариант Debian ему надо установить — для i386 или для amd64. Так что лишним этот параграф не будет.
Примечание 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 .
Повторюсь, см. github.com/frantony/u-boot_mod/tree/bsb-over-35a5cbe
Если прямо сейчас ваша версия u-boot_mod решает все возлагаемые на загрузчик задачи и вы не планируете добавлять загрузчику новые задачи в ближайшем будущем, то смысла переходить на mainline u-boot нет.
Найти 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:
Вот некоторые проблемы вашего commit'а 'Initial upload', решив которые вы значительно уменьшите его размер:
Кроме того, если ваши изменения структурно реализованы удачно, то они в большинстве своём будут 1) «отключаемы» и 2) «где-то сбоку»; в этом случае обмениваться изменениями в обе стороны легко.
У pepe2k всего 120 коммитов в репозитории, так что найти ту версию, которую вы заимствовали для внесения изменений даже перебором не слишком сложно; но будет лучше если вы сами скажите версию в репозитории pepe2k, которую вы форкнули.
Вы меня заинтриговали. Скорее публикуйте описание вашей технологии!
Нет только. Надо ещё проверить, что после этого изменения всё работает как надо ;)
P.S. Прежде чем править один битик. Прошу не обойти вниманием issue #1.
Прошу на github!Пока писал, появился github.com/blackswift/u-boot.20 ГБ ?! Инсталляционный LiveCD какой-нибудь Fedor'ы 16 AFAIR занимал 4 ГБ, там было более чем достаточное количество ПО
(например, для скачки torrent'ов предлагалось 3 или 4 клиента).
Специально, чтобы делать LiveCD с инструментальными средствами для MIPS я сделал скрипты finnix-tuner, которые добавляют средства разработки к Finnix LiveCD. В этом случае размер образа LiveCD получается менее 500 МБ.
Сейчас, правда, я перешёл на использование custom LiveCD сразу на базе Debian, без вмешательства Finnix; размер образа LiveCD от этого не увеличился.
Дмитрий! Напомню, что EJTAG это всё-так атракцион для хакеров.
Кроме того, отсутствие исходников позволяет мне отмазаться от исправления u-boot_mod так, чтобы EJTAG можно было использовать штатно ;).
К сожалению детальной информацией о состоянии дел у разработчиков Black Swift я не владею.
Но есть по крайней мере одна хорошая новость: платы Black Swift существуют на самом деле :)
По первому впечатлению мой экземпляр работает вполне стабильно, хотя, конечно, чтобы утверждать это наверняка потребуются сколь-нибудь продолжительные испытания.
Что касается отсутствия открытых исходных текстов, то не вижу тут большой проблемы. Плата Black Swift это только одна из плат размером с почтовую марку на базе AR9331. Сходу вспоминаются Carambola 2 и Onion Omega, возможно есть и другие. Устройство микросхемы AR9331 не оставляет разработчику платы слишком большого простора для манёвра, так что платы получаются с хорошим уровнем совместимости между собой; отличаются лишь типом разъёмов да отчасти номенклатурой выведенных интерфейсов. В качестве ОС используется OpenWrt, это значит, что спроблем с портированием более-менее качественно написанного ПО пользователя быть практически не должно.
А утаивание исходных текстов (хотя на github.com уже завёлся малоактивный пользователь с подходящим именем, адресом и стрижом на юзерпике) и недостаток информации может выйти разработчикам боком, ибо нет ничего тайного, что не сделалось бы явным, ни сокровенного, что не сделалось бы известным и не обнаружилось бы.
Призываю разработчиков Black Swift поскорее обнародовать исходные тексты!
Интересно, cколько времени ушло на его создание?
Мне хотелось бы поспособствовать улучшению качества этого (и надеюсь будущих) видеоуроков.
Вот мои замечания:
PDF/PDF/???/Indikator.h), а в каком-нибудь публичном репозитории; да хотя бы на github.com;Вот как выглядит ваш
Indikator.hмоём редакторе vim (символы табуляции показаны стрелкой, trailing whitespaces подсвечены красным):(1 << E)и аналогичные битовые маски макросами, то читать код станет легче (см., например, как задаётся PCIE_PL_PFLR_FORCE_LINK в pci-imx6.c). См., также макрос BIT.Вот пара цитат:
Можно подумать, что это имеются в виду названия конкретных шин (сравните шина PCI). На самом деле речь идёт о способе, которым конкретный компьютерный интерфейс (шина) обеспечивает соединения нескольких устройств.
Термин Multi-Drop переводится как общая шина и означает, что несколько устройств, подключённых в шине, используют общие линии для передачи данных; организацию общая шина используют I2C, PCI, VME и коаксиальный Ethernet 10Base-2.
Термин Point-to-Point обозначает, что для передачи данных между двумя устройствами выделены отдельные линии, которые никакое третье устройство задействовать не будет. Если надо соединить вместе более двух устройств, то как правило используются промежуточные устройства с несколькими интерфейсами (обычно зовутся коммутаторами). Организация точка-точка используется в RS232, PCI Express, Infiniband и USB.
Ограничение на передачу данных только между двумя устройствами имеет очевидные преимущества:
Попробуйте получить ответы на свои вопросы на форуме black swift.