Есть замечательная книжка про базовые китайские иероглифы: Fun with chinese characters. Одна страница --- один иероглиф. Для каждого иероглифа толкование и забавная картинка, например:
Ну можно подумать, что с приходом Device Tree ядро перестало инициализировать устройства...
Тема Device Tree не настолько тривиальна, чтобы можно было вот так, в коротком абзаце, рассказать разработчику необходимый минимум.
Тут на помощь могут придти замечательные материалы от Bootlin (бывшие Free Electrons).
Начать можно с доклада Device Tree for Dummies, который Thomas Petazzoni сделал на ELC 2013. Слайды и само видео доклада легко гуглятся. Есть и обновлённый вариант этого доклада, который называется Device Tree: hardware description for everybody! (2020).
А Дмитрий, кстати, не почил на лаврах, а разработал печатную плату-визитку с микроконтроллером помощнее и USB-разъёмом, которая эмулирует MIPS R3000. Теперь насладиться загрузкой linux на 32-выводном микроконтроллере можно за считанные минуты, см. https://dmitry.gr/?r=05.Projects&proj=33. LinuxCard
По заголовку думал вы даёте удаленный доступ к железке, а тут веселей.
А вот удалённый доступ к железкам возможно как раз и был бы веселее.
pro:
для того, чтобы работать с платой очно, необходимо обеспечить некоторые рабочие условия (минимально, запитать плату, подключить средства программирования и отладки, и т.д.), нет платы на рабочем месте, нет и соответствующей возни на рабочем месте; (точнее, эта возня переваливается на плечи того, кто предоставляет плату в доступ);
плата никуда не ездит, меньше возможностей, что с платой что-нибудь случится (как тут сказали, "Кривая ручка, случайно упавший проводок на плату, пролитое в запаре Жигулевское");
плата не уходит из доступа на 6 недель, плата легко переходит от одного пользователя к другому в течение дня;
contra:
пользователь загружает свою интеллектуальную собственность в какую-то удалённую плату; не все готовы с этим смириться;
кому-то психологически тяжело работать с платой, если она не находится на собственном столе;
номенклатура внешней периферии, которую можно подключить к удалённой плате по разным причинам ограничена;
если возникают аппаратные проблемы (неисправность платы или подключенной внешней периферии), то издалека не всегда легко понять, в чём дело.
По крайней мере, удалённое использование годится для ряда сценариев:
учебные ситуации; собственно, @KeisN13 и говорит, "что целевая аудитория это студенты в основном, или начинающие". Для этой аудитории было бы актуально начать с повторения готовых проектов (например, "выполнить лабы MIPSfpga"). Соответственно можно подключить к плате всё необходимое для выполнения лаб, проверить, что лабы можно выполнить, после чего отдать плату в общий доступ;
если номенклатура отладочных плат и аппаратных конфигураций фиксирована; если разработаны толковые тесты, то запускать их на удалённо доступных платах автоматически очень удобно; вот примеры проектов, для которых наличие удалённо доступных плат может быть великим благом:
LiteX framework (см. https://github.com/enjoy-digital/litex#welcome-to-litex), список поддерживаемых FPGA-плат см. тут: https://github.com/litex-hub/litex-boards#-boards-list При таком обширном списке плат, сделанных на ПЛИС разных семейств, легко может оказаться, что очередные прогрессивные нововведения, которые автор проверил на имеющейся у него плате, ломают поддержку каких-то других семейств ПЛИС. В этой ситуации, возможность быстро проверить новый прогрессивный commit на удалённо доступной плате позволит выявить проблему;
zephyr-rtos (см. https://github.com/zephyrproject-rtos/zephyr): в репозитории проекта сотни тестов, которые можно запускать автоматически, собственно каждый новый pull request подвергается базовому тестированию, включая запуск тестов на эмуляторе qemu; среди поддерживаемого zephyr оборудования есть SoC litex_vexriscv, которая отлично зашивается в плату Arty; к Arty можно подключать шилды Arduino и проверять, к примеру, что очередной commit в репозиторий zephyr не нарушил работу драйвера контроллера I2C для litex_vexriscv (AFAIR, воспользоваться qemu для такой проверки litex_vexriscv, увы, не получится).
Примеры того, как можно организовать удалённую работу с отладочными платами:
чтобы изделие считалось отечественным, оно должно содержать не менее 90 процентов от общего количества указанных электронных компонентов. Учитывая проблемы, описанные выше, я просто не представляю как это вообще будет выглядеть
Открылась регистрация на 2019 год!
www.innovatefpga.com/as/rule.html
Регистрация-то открылась, только работает сайт как-то странно.
Вот на странице http://www.innovatefpga.com/as/ говорится про Projects & Teams 5,
а в разделе Projects только три демонстрационных проекта с одинаковым названием Example: AlphaBot:
Весьма примечателен объёмный и очень-очень критический комментарий Jorge Saltore, в котором рабираются судейские комментарии к некоторым проектам, прошедшие в финал американской зоны в 2018 году. Как кое-кто заметил, отсутствие адекватного ответа на комментарий Jorge Saltore тоже о многом говорит.
Жаль, что Jorge Saltore прокомментировал только проекты из американской зоны. Вот, например, в зоне EMEA в финал (!) вышел проект EM102 Get Ready with Johnny, ролик которого совсем не демонстрирует использования платы DE10-Nano c ПЛИС Altera, как требовали правила соревнований, зато демонстрирует использование платы Nexys 3 Spartan-6 FPGA Trainer Board с ПЛИС Xilinx!
Вот здесь возникает вопрос что значит «взять». Взять и прочитать спецификацию — но её в ПЛИС на засунешь. Нужно IP ядро. Для Rapid IO есть OpenSource ядро которое сделали в Индии, но они сами пишут что в железе не проверяли. У них это академическая разработка. Xilinx имеет IP Core для спецификации 2.0 — это кодировка 8/10. Стоит он дорого, ~2M рублей. Есть американская фирма, которая предлагает IP Core спецификации 3.0, так они мне даже цену не сообщили.
Если сравнить PROTEQ и RapidIO LP-Serial Physical Layer v3.1, то скорее всего PROTEQ будет гораздо компактнее и обеспечит более быстрое восстановление при сбое. Что мне и нужно.
Вот такое объяснение звучит гораздо убедительнее, чем
PCI Express и RapidIO работают с кодировкой 8/10 что сразу ограничивает пропускную способность.
Однако при ближайшем рассмотрении применять стандартные протоколы в ПЛИС не всегда удобно.
…
Протоколы действительно разные, но сравнивать их можно и нужно.
Вот тут бы подробнее написать, какую именно задачу Вы решаете. Судя по тексту Вам надо организовать соединение точка-точка между двумя ПЛИС Xilinx. Тогда для решения такой задачи, используя наработки RapidIO, из всего стека протоколов RapidIO надо выбрать только подходящий протокол физического уровня (physical layer).
PROTEQ это не соперник полному стеку RapidIO или PCI Express! Их бесмысленно сравнивать. Но можно сравнить PROTEQ и, скажем, RapidIO LP-Serial Physical Layer v3.1.
PCI Express и RapidIO работают с кодировкой 8/10 что сразу ограничивает пропускную способность.
В публикации указано, что для сборки ядра и bare-metal программ используется один toolchain (arm-non-eabi), а для busybox — другой (arm-buildroot-uclinux-uclibcgnueabi). Криминала большого тут нет, однако, было бы неплохо объяснить, почему сделано именно так.
К сожалению, компилятор Sourcery CodeBench Lite, которым пользовался автор статей о портировании проекта на плату Марсоход, более недоступны для скачивания
Ещё как доступны! Исчезли легконаходимые ссылки, но сами файлы остались доступны.
На SPI там висит флэшка (как и во всех подобных чипсетах), так что сильно на него не надейтесь.
В этом тезисе нет упоминания ни OpenWrt в частности, ни какого либо программного обеспечения вообще. Можно подумать, что имеет место чисто аппаратная проблема целой группы чипсетов. Кстати, в исходном комментарии OpenWrt также не помянут.
Ваше замечание о том, что в OpenWrt
по SPI очень хочет общаться ядро системы
также вопросы вызывает:
ядро системы, это надо понимать linux; только вот заставить ядро linux по своей инициативе много общаться по SPI это ещё умудриться надо. Как правило общение по SPI — результат запросов к ядро из userspace, а не личная инициатива ядра (напимер, busybox запустил dropbear, и надо этот dropbear загрузить в ОЗУ). Да и старнно было бы, если бы кто-то ещё кроме ядра организовывал обращения по SPI. Источник этих постояных обращений не ясен — кто же именно все эти постоянные обращения организует?
то, что OpenWrt очень желает общаться (кстати, не указано с кем он желает общаться, но наверное, с SPI flash) — это факт, только без конкретных цифр, какая пропускная способность SPI потребна для OpenWrt от SPI, принять решение о подключении ещё одного устройства к SPI затруднительно. Так на сколько МБ/с обычно по SPI очень хочет общаться ядро системы?
Только производительность при работе с не-SPI-flash-с-3-байтовой-адресацией будет отличаться.
AFAIR, приблизительно на порядок.
Вот в mt7621_spi_transfer_full_duplex, чтобы отправить 32 бита на SPI надо сделать одну запись в регистр, а затем запустить передачу, дёрнув бит SPI_CTL_START:
static int mt7621_spi_transfer_full_duplex(struct spi_master *master,
struct spi_message *m)
{
...
for (i = 0; i < len; i += 4)
mt7621_spi_write(rs, MT7621_SPI_DATA0 + i, data[i / 4]);
...
val = mt7621_spi_read(rs, MT7621_SPI_TRANS);
val |= SPI_CTL_START;
mt7621_spi_write(rs, MT7621_SPI_TRANS, val);
...
А в ath79_spi_txrx_mode0 придётся для отправки 32 битов каждый битик вручную выставить, да ещё вручную-же на SCLK фронт организовать:
static u32 ath79_spi_txrx_mode0(struct spi_device *spi, unsigned nsecs,
u32 word, u8 bits)
{
...
/* clock starts at inactive polarity */
for (word <<= (32 - bits); likely(bits); bits--) {
u32 out;
if (word & (1 << 31))
out = ioc | AR71XX_SPI_IOC_DO;
else
out = ioc & ~AR71XX_SPI_IOC_DO;
/* setup MSB (to slave) on trailing edge */
ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, out);
ath79_spi_delay(sp, nsecs);
ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, out | AR71XX_SPI_IOC_CLK);
ath79_spi_delay(sp, nsecs);
if (bits == 1)
ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, out);
word <<= 1;
}
...
А вот по SPI очень хочет общаться ядро системы.
И на сколько МБ/с обычно ядро системы хочет общаться по SPI?
Во-первых, освободить SPI с CS1 в OpenWRT для какого-то стороннего устройства — задача сама по себе нетривиальная,
во-вторых, нормальная скорость у вас будет только в специфических условиях, а в общем случае будет либо ОС стоять и ждать, когда её к флэшке пустят, либо внешнее устройство — когда ОС SPI отпустит.
Говорите: <<ОС стоять и ждать, когда её к флэшке пустят>>?
Давайте посчитаем, имеет ли это смысл.
К примеру, в старом Onion Omega использовалась загрузочная флешка MX25L1605D, наверняка в Omega2 используется либо такая-же флешка, либо флешка со схожими характеристиками.
MX25L1605D была подключена через единственную линию MISO (см. https://github.com/OnionIoT/Onion-Hardware/raw/master/Schematics/Omega.pdf), по даташиту максимальная частота SCLK в таком режиме — 86 МГц.
То есть чтение можно осуществлять с производительностью не более ~ 8 МБ/с. В реальной жизни, 86 МГц выставлять наверняка никто не будет и это цифру придётся разделить на 2, а то и на 4.
А вот я взял плату WRTnode2R-Mini (SoC MT7688AN, ближайшая родственница SoC MT7688K, что применяется в Omega2),
и прямо под родным OpenWRT
root@OpenWrt:~# uname -a
Linux OpenWrt 3.18.23 #35 Wed Nov 18 17:57:57 CST 2015 mips GNU/Linux
root@OpenWrt:~# dmesg | grep "SoC Type:\|CPU Clock"
[ 0.000000] SoC Type: MediaTek MT7688 ver:1 eco:2
[ 0.000000] CPU Clock: 575MHz
запустил тест производительности чтения из ОЗУ из пакета lmbench:
root@OpenWrt:~# bw_mem 16M rd
16.00 236.84
Тест чтения ОЗУ из блока 16 МБ выдаёт 236 МБ/с.
Имея на борту 64 МБ быстрого ОЗУ, едва не имеет смысла часто читать из медленного SPI flash 16 МБ.
А теперь, что касается записи.
В даташите на MX25L1605D говорится о Typical 100,000 erase/program cycles.
Если в MX25L1605D непрерывно писать хотя бы 100 КБ/с, сколько она продержится?
(впрочем, даже 100 КБ/с — это совсем немного при частоте SCLK в десятки МГц).
Так что, в грамотно построенной системе на MT76x8 загрузочная SPI flash устройству на CS1
особых хлопот не доставит.
Что же касается того, что "нормальная скорость у вас будет только в специфических условиях",
то понятие нормальная скорость полностью определяется решаемой задачей.
Кому-то и 1 Мбит/с может хватить.
Кроме того, надо обратить внимание на используемый контроллер SPI.
Вот, к примеру, в AR9331 контроллер таков, что работа с SPI, в общем случае, реализуется при помощи bit-bang — там никакой производительности не светит.
А в MT76x8 контроллер чуть получше, но тоже слабенький — при передаче/приёме байтики/слова надо
копировать процессором, DMA нет, см. функцию mt7621_spi_transfer_full_duplex() в linux'ом драйвере.
P.S. Я не понял, что имеется в виду под "освободить SPI с CS1 в OpenWRT для какого-то стороннего устройства — задача сама по себе нетривиальная".
Зачем нужно это самое освобождение, разве "SPI с CS1 в OpenWRT" кто-то захватил?
А если пойти по ссылки и посмотреть так называемый datasheet на прошлогодний SoC VIP-1, то c удивлением обнаруживается, что SoC VIP-1 (см. внимательно надписи на корпусе SoC на картинке в данном посте) была построена, страшно сказать, на процессорных ядрах ARM Cortex-A9!
Отчего это ЭЛВИС-НеоТек внезапно решил пересесть на ядра MIPS?
Олег!
Мне приятно, что вы собаговолили посвятить моей скромной персоне четыре абзаца. Весьма досадно, что только один из них касается обсуждаемого вопроса. Очень вас прошу не отвлекаться!
Пожалуйста, укажите, где я предлагал планировать крупный и трудоёмкий этап по принципу «когда будет мешать, тогда и сделаем».
О планировании какого крупного и трудоёмкого этапа идёт речь?
Вы ничего не знаете про бизнес Байкала, про его отношения с партнёрами, планируемые сделки и продукты — и это не только не помешало, но даже помогло написать вам кучу совершенно бессмысленного текста.
Олег! Я уверен, что вы осведомлены о бизнесе Байкала, его отношениях с партнёрами, планируемых сделках и продуктах горазда лучше большинства читателей (нет, правда). Казалось бы это должно дать вам возможность легко и непренуждённо опровергать любые глупости и вымыслы в комментариях к публикации. Вместо этого, не сказав ничего по существу, вы опустились до инсинуации. На всякий случай приведу цитату об инсинуации из Главы 15 (Усложнение и видоизменения палочных доводов) книги С. И. Поварнина Искусство спора:
Человек стремится подорвать в слушателях или читателях доверие к своему противнику, а, следовательно, и к его доводам, и пользуется для этой цели коварными безответственными намеками. К сожалению, эта уловка очень в ходу, и ею не брезгают даже иные весьма почтенные деятели.
Олег!
Вы написали вопросы к моей реплике, которая относилась к следующему тезису LampTester'а:
не начнут писать качественную документацию на том языке, на котором говорят сейчас все квалифицированные инженеры, мы так и будем вариться в своем соку и бесконечно догонять.
Мою реплику следует рассматривать именно как замечание к этому тезису и не стоит пытаться приписывать мне обобщения, которых я не делал. Ключевые слова в исходном тезисе — на том языке, а совсем не документация.
А уж ваш вопрос
Я правильно понимаю, что на текущем этапе к Т1 документацию никакую вообще писать не надо, потому что пока продукт не продаётся, то её отсутствие ничему не мешает?
и вовсе провокационен.
Для того, чтобы на него ответить надо знать ответы на вопросы:
какой там сейчас у Байкал в части T1 этап и сколько он продлится?
существует ли вообще документация на T1 на любом языке? может она уже написана (на нескольких языках), но её никому не показывают?
продаётся ли сейчас продукт?
А для розничного товара, например, надо сначала его выпустить, заполнить им склад, а потом уже начинать думать о какой-то дистрибьюции, убедившись, что сам товар со склада себя не продаст?
Давайте конкретнее. Вот скажите, а Baikal T1 (ну или платы с ним) — это розничный продукт? Как у него с дистрибуцией?
П — планирование.
Ц — цель.
Если была цель сделать продающейся в рознице продукт, будет одно планирование. А если цели были совсем другие — другое планирование.
А уж какие там у руководства Байкал Электроникс цели… Открываем устав ОАО «Байкал Электроникс» (см. http://e-disclosure.ru/portal/files.aspx?id=30795&type=1), смотрим пункт 4:
4.1. Основной целью деятельности Общества является извлечение прибыли.
Каких либо более конкретных целей по части Baikal-T1 я на сайте http://www.baikalelectronics.ru не нашёл, если вам повезёт больше, пожалуйста, сообщите.
Есть замечательная книжка про базовые китайские иероглифы: Fun with chinese characters. Одна страница --- один иероглиф. Для каждого иероглифа толкование и забавная картинка, например:
Ну можно подумать, что с приходом Device Tree ядро перестало инициализировать устройства...
Тема Device Tree не настолько тривиальна, чтобы можно было вот так, в коротком абзаце, рассказать разработчику необходимый минимум.
Тут на помощь могут придти замечательные материалы от Bootlin (бывшие Free Electrons).
Начать можно с доклада Device Tree for Dummies, который Thomas Petazzoni сделал на ELC 2013. Слайды и само видео доклада легко гуглятся. Есть и обновлённый вариант этого доклада, который называется Device Tree: hardware description for everybody! (2020).
А Дмитрий, кстати, не почил на лаврах, а разработал печатную плату-визитку с микроконтроллером помощнее и USB-разъёмом, которая эмулирует MIPS R3000.
Теперь насладиться загрузкой linux на 32-выводном микроконтроллере можно за считанные минуты, см. https://dmitry.gr/?r=05.Projects&proj=33. LinuxCard
А вот удалённый доступ к железкам возможно как раз и был бы веселее.
pro:
для того, чтобы работать с платой очно, необходимо обеспечить некоторые рабочие условия (минимально, запитать плату, подключить средства программирования и отладки, и т.д.), нет платы на рабочем месте, нет и соответствующей возни на рабочем месте; (точнее, эта возня переваливается на плечи того, кто предоставляет плату в доступ);
плата никуда не ездит, меньше возможностей, что с платой что-нибудь случится (как тут сказали, "Кривая ручка, случайно упавший проводок на плату, пролитое в запаре Жигулевское");
плата не уходит из доступа на 6 недель, плата легко переходит от одного пользователя к другому в течение дня;
contra:
пользователь загружает свою интеллектуальную собственность в какую-то удалённую плату; не все готовы с этим смириться;
кому-то психологически тяжело работать с платой, если она не находится на собственном столе;
номенклатура внешней периферии, которую можно подключить к удалённой плате по разным причинам ограничена;
если возникают аппаратные проблемы (неисправность платы или подключенной внешней периферии), то издалека не всегда легко понять, в чём дело.
По крайней мере, удалённое использование годится для ряда сценариев:
учебные ситуации; собственно, @KeisN13 и говорит, "что целевая аудитория это студенты в основном, или начинающие". Для этой аудитории было бы актуально начать с повторения готовых проектов (например, "выполнить лабы MIPSfpga"). Соответственно можно подключить к плате всё необходимое для выполнения лаб, проверить, что лабы можно выполнить, после чего отдать плату в общий доступ;
если номенклатура отладочных плат и аппаратных конфигураций фиксирована; если разработаны толковые тесты, то запускать их на удалённо доступных платах автоматически очень удобно; вот примеры проектов, для которых наличие удалённо доступных плат может быть великим благом:
LiteX framework (см. https://github.com/enjoy-digital/litex#welcome-to-litex), список поддерживаемых FPGA-плат см. тут: https://github.com/litex-hub/litex-boards#-boards-list При таком обширном списке плат, сделанных на ПЛИС разных семейств, легко может оказаться, что очередные прогрессивные нововведения, которые автор проверил на имеющейся у него плате, ломают поддержку каких-то других семейств ПЛИС. В этой ситуации, возможность быстро проверить новый прогрессивный commit на удалённо доступной плате позволит выявить проблему;
zephyr-rtos (см. https://github.com/zephyrproject-rtos/zephyr): в репозитории проекта сотни тестов, которые можно запускать автоматически, собственно каждый новый pull request подвергается базовому тестированию, включая запуск тестов на эмуляторе qemu; среди поддерживаемого zephyr оборудования есть SoC litex_vexriscv, которая отлично зашивается в плату Arty; к Arty можно подключать шилды Arduino и проверять, к примеру, что очередной commit в репозиторий zephyr не нарушил работу драйвера контроллера I2C для litex_vexriscv (AFAIR, воспользоваться qemu для такой проверки litex_vexriscv, увы, не получится).
Примеры того, как можно организовать удалённую работу с отладочными платами:
Удалённая работа с оборудованием в pengutronix при помощи Labgrid
https://www.pengutronix.de/en/blog/2021-02-21-showcase-remote-working.html
Удалённая работа с оборудованием в bootlin при помощи lavabo
https://bootlin.com/blog/tag/lab/
Ну и на закуску, лаборатория электроники "Байкал"
https://baikal.cs.msu.ru/
Вот картинка, взятая из https://zx.clan.su/forum/18-67-652-16-1439061611:
Регистрация-то открылась, только работает сайт как-то странно.
Вот на странице http://www.innovatefpga.com/as/ говорится про Projects & Teams 5,
а в разделе Projects только три демонстрационных проекта с одинаковым названием Example: AlphaBot:
Весьма примечателен объёмный и очень-очень критический комментарий Jorge Saltore, в котором рабираются судейские комментарии к некоторым проектам, прошедшие в финал американской зоны в 2018 году. Как кое-кто заметил, отсутствие адекватного ответа на комментарий Jorge Saltore тоже о многом говорит.
Жаль, что Jorge Saltore прокомментировал только проекты из американской зоны. Вот, например, в зоне EMEA в финал (!) вышел проект EM102 Get Ready with Johnny, ролик которого совсем не демонстрирует использования платы DE10-Nano c ПЛИС Altera, как требовали правила соревнований, зато демонстрирует использование платы Nexys 3 Spartan-6 FPGA Trainer Board с ПЛИС Xilinx!
Вот такое объяснение звучит гораздо убедительнее, чем
Спасибо!
Вот тут бы подробнее написать, какую именно задачу Вы решаете. Судя по тексту Вам надо организовать соединение точка-точка между двумя ПЛИС Xilinx. Тогда для решения такой задачи, используя наработки RapidIO, из всего стека протоколов RapidIO надо выбрать только подходящий протокол физического уровня (physical layer).
PROTEQ это не соперник полному стеку RapidIO или PCI Express! Их бесмысленно сравнивать. Но можно сравнить PROTEQ и, скажем, RapidIO LP-Serial Physical Layer v3.1.
Тут мне знающие люди подсказали, что не одним 8/10 жив RapidIO LP-Serial. В версии 3 спецификации RapidIO LP-Serial для baud rates более 3.125 Гбод используется кодирование 64b/67b (см. http://www.rapidio.org/wp-content/uploads/2014/10/RapidIO-3.1-Specification.pdf, стр. 479 и далее). А есть и совсем новая спецификация RapidIO версии 4 (см. http://www.rapidio.org/rapidio-specifications/).
Никак не критикую проделанную автором работу, просто прошу быть более последовательным в изложении и точным в деталях.
P.S. Не в коей мере не пытаюсь восхвалить RapidIO, просто знаком с RapidIO чуть лучше, чем с PCI Express или Aurora.
В публикации указано, что для сборки ядра и bare-metal программ используется один toolchain (arm-non-eabi), а для busybox — другой (arm-buildroot-uclinux-uclibcgnueabi). Криминала большого тут нет, однако, было бы неплохо объяснить, почему сделано именно так.
Ещё как доступны! Исчезли легконаходимые ссылки, но сами файлы остались доступны.
Вот ссылка на использованный авторами marsohod.org toolchain arm-2012.03-57-arm-none-linux-gnueabi.
Ссылку я подсмотрел в исходниках buildroot: см. файл toolchain/toolchain-external/toolchain-external.mk.
Самый последний Sourcery CodeBench toolchain для ARM — arm-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2.
P.S. Кстати, в Debian Linux (testing) можно поставить пакет
gcc-arm-linux-gnueabi— и будет вам кросскомпилятор.Был ещё такой советский конструктор "Оптик".
Из конструктора можно собрать несколько зрительных труб и микроскопов.
Более подробное описание, чего из этого конструктора можно собрать см. тут.
На форуме astronomy.ru даже есть отсканированная инструкция к этому конструктору.
Это всё к тезису <<В AR9331 контроллер SPI точно такой же>>.
Ваш исходный тезис выглядит так
В этом тезисе нет упоминания ни OpenWrt в частности, ни какого либо программного обеспечения вообще. Можно подумать, что имеет место чисто аппаратная проблема целой группы чипсетов. Кстати, в исходном комментарии OpenWrt также не помянут.
Ваше замечание о том, что в OpenWrt
также вопросы вызывает:
Только производительность при работе с не-SPI-flash-с-3-байтовой-адресацией будет отличаться.
AFAIR, приблизительно на порядок.
Вот в mt7621_spi_transfer_full_duplex, чтобы отправить 32 бита на SPI надо сделать одну запись в регистр, а затем запустить передачу, дёрнув бит
SPI_CTL_START:А в ath79_spi_txrx_mode0 придётся для отправки 32 битов каждый битик вручную выставить, да ещё вручную-же на SCLK фронт организовать:
И на сколько МБ/с обычно ядро системы хочет общаться по SPI?
Говорите: <<ОС стоять и ждать, когда её к флэшке пустят>>?
Давайте посчитаем, имеет ли это смысл.
К примеру, в старом Onion Omega использовалась загрузочная флешка MX25L1605D, наверняка в Omega2 используется либо такая-же флешка, либо флешка со схожими характеристиками.
MX25L1605D была подключена через единственную линию MISO (см. https://github.com/OnionIoT/Onion-Hardware/raw/master/Schematics/Omega.pdf), по даташиту максимальная частота SCLK в таком режиме — 86 МГц.
То есть чтение можно осуществлять с производительностью не более ~ 8 МБ/с.
В реальной жизни, 86 МГц выставлять наверняка никто не будет и это цифру придётся разделить на 2, а то и на 4.
А вот я взял плату WRTnode2R-Mini (SoC MT7688AN, ближайшая родственница SoC MT7688K, что применяется в Omega2),
и прямо под родным OpenWRT
запустил тест производительности чтения из ОЗУ из пакета lmbench:
Тест чтения ОЗУ из блока 16 МБ выдаёт 236 МБ/с.
Имея на борту 64 МБ быстрого ОЗУ, едва не имеет смысла часто читать из медленного SPI flash 16 МБ.
А теперь, что касается записи.
В даташите на MX25L1605D говорится о Typical 100,000 erase/program cycles.
Если в MX25L1605D непрерывно писать хотя бы 100 КБ/с, сколько она продержится?
(впрочем, даже 100 КБ/с — это совсем немного при частоте SCLK в десятки МГц).
Так что, в грамотно построенной системе на MT76x8 загрузочная SPI flash устройству на CS1
особых хлопот не доставит.
Что же касается того, что "нормальная скорость у вас будет только в специфических условиях",
то понятие нормальная скорость полностью определяется решаемой задачей.
Кому-то и 1 Мбит/с может хватить.
Кроме того, надо обратить внимание на используемый контроллер SPI.
Вот, к примеру, в AR9331 контроллер таков, что работа с SPI, в общем случае, реализуется при помощи bit-bang — там никакой производительности не светит.
А в MT76x8 контроллер чуть получше, но тоже слабенький — при передаче/приёме байтики/слова надо
копировать процессором, DMA нет, см. функцию
mt7621_spi_transfer_full_duplex()в linux'ом драйвере.P.S. Я не понял, что имеется в виду под "освободить SPI с CS1 в OpenWRT для какого-то стороннего устройства — задача сама по себе нетривиальная".
Зачем нужно это самое освобождение, разве "SPI с CS1 в OpenWRT" кто-то захватил?
Флэшка занимает CS0, а CS1 свободен:
А если пойти по ссылки и посмотреть так называемый datasheet на прошлогодний SoC VIP-1, то c удивлением обнаруживается, что SoC VIP-1 (см. внимательно надписи на корпусе SoC на картинке в данном посте) была построена, страшно сказать, на процессорных ядрах ARM Cortex-A9!
Отчего это ЭЛВИС-НеоТек внезапно решил пересесть на ядра MIPS?
Мне приятно, что вы собаговолили посвятить моей скромной персоне четыре абзаца. Весьма досадно, что только один из них касается обсуждаемого вопроса. Очень вас прошу не отвлекаться!
Пожалуйста, укажите, где я предлагал планировать крупный и трудоёмкий этап по принципу «когда будет мешать, тогда и сделаем».
О планировании какого крупного и трудоёмкого этапа идёт речь?
Олег! Я уверен, что вы осведомлены о бизнесе Байкала, его отношениях с партнёрами, планируемых сделках и продуктах горазда лучше большинства читателей (нет, правда). Казалось бы это должно дать вам возможность легко и непренуждённо опровергать любые глупости и вымыслы в комментариях к публикации. Вместо этого, не сказав ничего по существу, вы опустились до инсинуации. На всякий случай приведу цитату об инсинуации из Главы 15 (Усложнение и видоизменения палочных доводов) книги С. И. Поварнина Искусство спора:
Вы написали вопросы к моей реплике, которая относилась к следующему тезису LampTester'а:
Мою реплику следует рассматривать именно как замечание к этому тезису и не стоит пытаться приписывать мне обобщения, которых я не делал. Ключевые слова в исходном тезисе — на том языке, а совсем не документация.
А уж ваш вопрос
и вовсе провокационен.
Для того, чтобы на него ответить надо знать ответы на вопросы:
Давайте конкретнее. Вот скажите, а Baikal T1 (ну или платы с ним) — это розничный продукт? Как у него с дистрибуцией?
Ц — цель.
Если была цель сделать продающейся в рознице продукт, будет одно планирование. А если цели были совсем другие — другое планирование.
А уж какие там у руководства Байкал Электроникс цели… Открываем устав ОАО «Байкал Электроникс» (см. http://e-disclosure.ru/portal/files.aspx?id=30795&type=1), смотрим пункт 4:
Каких либо более конкретных целей по части Baikal-T1 я на сайте http://www.baikalelectronics.ru не нашёл, если вам повезёт больше, пожалуйста, сообщите.