• Российские и украинские команды взяли верх над европейцами на европейском финале интеловского конкурса InnovateFPGA
    +1
    Открылась регистрация на 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!

  • PROTEQ — протокол обмена по мультигигабитным линиям для ПЛИС Xilinx
    0
    Вот здесь возникает вопрос что значит «взять». Взять и прочитать спецификацию — но её в ПЛИС на засунешь. Нужно 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 что сразу ограничивает пропускную способность.

    Спасибо!

  • PROTEQ — протокол обмена по мультигигабитным линиям для ПЛИС Xilinx
    0
    Однако при ближайшем рассмотрении применять стандартные протоколы в ПЛИС не всегда удобно.

    Протоколы действительно разные, но сравнивать их можно и нужно.

    Вот тут бы подробнее написать, какую именно задачу Вы решаете. Судя по тексту Вам надо организовать соединение точка-точка между двумя ПЛИС Xilinx. Тогда для решения такой задачи, используя наработки RapidIO, из всего стека протоколов RapidIO надо выбрать только подходящий протокол физического уровня (physical layer).


    PROTEQ это не соперник полному стеку RapidIO или PCI Express! Их бесмысленно сравнивать. Но можно сравнить PROTEQ и, скажем, RapidIO LP-Serial Physical Layer v3.1.


    PCI Express и RapidIO работают с кодировкой 8/10 что сразу ограничивает пропускную способность.

    Тут мне знающие люди подсказали, что не одним 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.

  • Запускаем Linux на FPGA: Hello, World
    0

    В публикации указано, что для сборки ядра и bare-metal программ используется один toolchain (arm-non-eabi), а для busybox — другой (arm-buildroot-uclinux-uclibcgnueabi). Криминала большого тут нет, однако, было бы неплохо объяснить, почему сделано именно так.

  • Запускаем Linux на FPGA: Hello, World
    +1
    К сожалению, компилятор Sourcery CodeBench Lite, которым пользовался автор статей о портировании проекта на плату Марсоход, более недоступны для скачивания

    Ещё как доступны! Исчезли легконаходимые ссылки, но сами файлы остались доступны.


    Вот ссылка на использованный авторами 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 — и будет вам кросскомпилятор.

  • Особенности национальных конструкторов (в картинках). Часть 1
    +1

    Был ещё такой советский конструктор "Оптик".



    Из конструктора можно собрать несколько зрительных труб и микроскопов.


    Более подробное описание, чего из этого конструктора можно собрать см. тут.
    На форуме astronomy.ru даже есть отсканированная инструкция к этому конструктору.

  • Omega2: самый маленький в мире микрокомпьютер с Linux и Wi-Fi
    0
    Это всё к тезису о том, что в OpenWRT из коробки тупо не предусмотрена работа SPI с чем-то, кроме флэшки, какое отношение имеет?

    Это всё к тезису <<В AR9331 контроллер SPI точно такой же>>.


    Ваш исходный тезис выглядит так


    На SPI там висит флэшка (как и во всех подобных чипсетах), так что сильно на него не надейтесь.

    В этом тезисе нет упоминания ни OpenWrt в частности, ни какого либо программного обеспечения вообще. Можно подумать, что имеет место чисто аппаратная проблема целой группы чипсетов. Кстати, в исходном комментарии OpenWrt также не помянут.


    Ваше замечание о том, что в OpenWrt


    по SPI очень хочет общаться ядро системы

    также вопросы вызывает:


    • ядро системы, это надо понимать linux; только вот заставить ядро linux по своей инициативе много общаться по SPI это ещё умудриться надо. Как правило общение по SPI — результат запросов к ядро из userspace, а не личная инициатива ядра (напимер, busybox запустил dropbear, и надо этот dropbear загрузить в ОЗУ). Да и старнно было бы, если бы кто-то ещё кроме ядра организовывал обращения по SPI. Источник этих постояных обращений не ясен — кто же именно все эти постоянные обращения организует?
    • то, что OpenWrt очень желает общаться (кстати, не указано с кем он желает общаться, но наверное, с SPI flash) — это факт, только без конкретных цифр, какая пропускная способность SPI потребна для OpenWrt от SPI, принять решение о подключении ещё одного устройства к SPI затруднительно. Так на сколько МБ/с обычно по SPI очень хочет общаться ядро системы?
  • Omega2: самый маленький в мире микрокомпьютер с Linux и Wi-Fi
    +1
    В AR9331 контроллер 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?

  • Omega2: самый маленький в мире микрокомпьютер с Linux и Wi-Fi
    0
    Во-первых, освободить 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" кто-то захватил?

  • Omega2: самый маленький в мире микрокомпьютер с Linux и Wi-Fi
    0
    На SPI там висит флэшка (как и во всех подобных чипсетах), так что сильно на него не надейтесь.

    Флэшка занимает CS0, а CS1 свободен:


  • Российская компания ЭЛВИС выпускает передовой чип для видеоаналитики, «умных камер» с семантическим анализом изображений
    0

    А если пойти по ссылки и посмотреть так называемый datasheet на прошлогодний SoC VIP-1, то c удивлением обнаруживается, что SoC VIP-1 (см. внимательно надписи на корпусе SoC на картинке в данном посте) была построена, страшно сказать, на процессорных ядрах ARM Cortex-A9!


    Отчего это ЭЛВИС-НеоТек внезапно решил пересесть на ядра MIPS?

  • Российский процессор Байкал
    0
    Олег!
    Мне приятно, что вы собаговолили посвятить моей скромной персоне четыре абзаца. Весьма досадно, что только один из них касается обсуждаемого вопроса. Очень вас прошу не отвлекаться!
    Пожалуйста, укажите, где я предлагал планировать крупный и трудоёмкий этап по принципу «когда будет мешать, тогда и сделаем».
    О планировании какого крупного и трудоёмкого этапа идёт речь?
  • Российский процессор Байкал
    0
    Вы ничего не знаете про бизнес Байкала, про его отношения с партнёрами, планируемые сделки и продукты — и это не только не помешало, но даже помогло написать вам кучу совершенно бессмысленного текста.

    Олег! Я уверен, что вы осведомлены о бизнесе Байкала, его отношениях с партнёрами, планируемых сделках и продуктах горазда лучше большинства читателей (нет, правда). Казалось бы это должно дать вам возможность легко и непренуждённо опровергать любые глупости и вымыслы в комментариях к публикации. Вместо этого, не сказав ничего по существу, вы опустились до инсинуации. На всякий случай приведу цитату об инсинуации из Главы 15 (Усложнение и видоизменения палочных доводов) книги С. И. Поварнина Искусство спора:
    Человек стремится подорвать в слушателях или читателях доверие к своему противнику, а, следовательно, и к его доводам, и пользуется для этой цели коварными безответственными намеками. К сожалению, эта уловка очень в ходу, и ею не брезгают даже иные весьма почтенные деятели.
  • Российский процессор Байкал
    0
    Олег!
    Вы написали вопросы к моей реплике, которая относилась к следующему тезису 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 не нашёл, если вам повезёт больше, пожалуйста, сообщите.
  • Опыт запуска AHCI в VxWorks653
    –1
    Это как раз всё понятно. Как ОС-то называется?
    Из публикации я понял, что до использования AHCI использовался медленный программный интерфейс ATA. Драйвер для контроллера диска в ATA-режиме вы тоже сами писали, или он был позаимствован из какого-то BSP (AKA ППМ — пакет поддержки модуля)?
  • Опыт запуска AHCI в VxWorks653
    0
    Откройте секрет, что это за такая ОС РВ для ответственных применений с поддержкой ARINC 653, что в 2016 году она не имеет поддержки SATA контроллера на PCIe?
  • Российский процессор Байкал
    +1
    Скорее всего автор хотел сказать: "В процессор встроены 3 Ethernet PHY". Т.е. подключаешь трансформаторы, розетки и готов Ethernet.

    По части 1GbE. Посмотрите же блок-схему на странице http://www.baikalelectronics.ru/products/35:
    Baikal-T1: rgmii
    Из SoC выходит пара интерфейсов RGMII — надо использовать внешние трансиверы.
    Спасибо, lelik363! Он своим орлиным зрением разглядел пару трансиверов для 1GbE на плате.
    По представленному в публикации фото можно даже определить их тип:
    KSZ9031RNX
    это Micrel KSZ9031RNX.
    По части же 10GbE вновь см. блок-схему на странице http://www.baikalelectronics.ru/products/35:
    из SoC выходит XAUI, то есть и для 10GbE внешний трансивер потребен (см. про XAUI тут https://habrahabr.ru/company/metrotek/blog/234369/).
  • Российский процессор Байкал
    +1
    я каждый раз плачу, читая их документацию на русском.

    От того, что её будут делать не на русском плакать вы меньше не станете. Скорее наоборот.
    не начнут писать качественную документацию на том языке, на котором говорят сейчас все квалифицированные инженеры, мы так и будем вариться в своем соку и бесконечно догонять.

    Ну вот вы всё правильно пишите — надо писать качественную документацию. А вот писать документацию на том языке, на котором говорят сейчас все квалифицированные инженеры, имеет смысл только в том случае, если на этом языке её будет кто-то читать. То есть надо начать делать что-то минимально интересное, и только когда окажется, что продвижению вашего продукта мешает отсутствие документации на на том языке, вот только тогда будет смысл заниматься подготовкой этой самой документации. Давайте решать проблемы по мере их возникновения, а то опять какой-то карго-культ получится.
  • Российский процессор Байкал
    +1
    Девборда на такой процессор стоит, кстати говоря, в несколько раз дороже байкаловской.

    Так и интерфейсов и ядер в несколько десятков (!) раз больше чем в Baikal-T1.
    Этот самый Octeon III — чип немного другого класса, я его привёл в качестве примера специально, чтобы точно обойти Baikal-T1 по номенклатуре интерфейсов в ответ на Такого вроде как ни у кого нет.
    А кроме Octeon III ещё и Octeon II бывает — он скромнее.
  • Являются ли ирландцы потомками кельтов?
    0
    Валлийцы — национальность, уэльсцы — жители Уэльса, вне зависимости от национальности.

    Это несколько поверхностная трактовка; рекомендую ознакомиться с очерком Невтон | Ньюто'н | Нью'тон, или Сколько сторон имеет языковой знак? из книги В.А. Успенского Труды по нематематике.
    Вот только одна цитата:
    Как известно, знаменитый писатель Хаксли (1894—1963) приходится внуком знаменитому биологу Гексли (1825—1895).

    Так вот отношение между валлийцами и уэльсцами приблизительно такое же как между Гексли и Хаксли: валлийцы появились в русском языке в то время когда было принято использовать транслитерацию для заимствования иностранных слов, а уэльсцы — результат использования транскрипции; так что сложно обсуждать, в каком случае какое слово лучше использовать (в этом я абсолютно согласен с Camel).
    Замечу лишь, что в современном русском языке слово валлийцы используется пока ещё чаще, чем уэльсцы (см., к примеру, статистику google).
  • Российский процессор Байкал
    +1
    И что я вижу? "Powered by LOONGSON", "LM228001", "LS3B1500A", "GH22B". Не так я себе представлял иероглифы...

    То есть 龙芯, это не иероглифы?
    Вот если бы вы задали вопрос так: А почему китайцы не маркируют массовые чипы только иероглифами?, тогда да, предъявленные картинки не годились бы в качестве контроаргумента. Так что предъявленне фото свидетельствуют, что китайцы вполне используют иероглифы для маркировки микросхем.
    Более того, обратите внимание, что для указания семейства процессора Loongson использованы арабские цифры 2 и 3, хотя у китайцев есть родные подходящие иероглифы 二 и 三; более того, китайцы очень часто используют арабские цифры, вот пример заметки с сайта агенства Синьхуа http://www.xinhuanet.com/:

    Так, что увидать маркировку только из иероглифов вряд ли получится — цифры скорее всего будут использованы арабские.
  • Российский процессор Байкал
    +2
    apple a9 — 100% разработка архитектуры ядра — кроме графики (графика Imagination Technologies — Великобританя)

    Таки да, Apple сам делает для себя ядра, и, кстати, не только Apple, см. https://en.wikipedia.org/w/index.php?title=List_of_ARM_microarchitectures#Designed_by_third_parties
  • Российский процессор Байкал
    0
    Многие роутеры даже сейчас, имея 1Гбит порты, могут пропустить трафика на 10-20 Гбит. Если взять суммарную скорость всех сетевых интерфейсов то получается 12Гбит, а процессор 1.2ГГЦ, получается за каждый такт процессору нужно обработать 10бит, при теоретическом пределе в 64 бита (2 ядра по 32 бита), т.е. повод сомневаться и провести тесты есть.

    Ваше рассуждение справедливо, если процессор, "просматривает" каждый принятый сетевой пакет. Однако, вы же ведёте речь про роутер, то есть устройство, которое, приняв пакет, смотрит на его заголовок и решает, что с пакетом дальше делать. Но ведь весь пакет просматривать процессору совсем не обязательно! Это в старые времена, когда сетевые контроллеры были туповаты, а производительность сетевых интерфейсов не очень велика, тогда приходилось считать контрольные суммы IP/UDP/TCP на процессоре. Но для гигабитных интерфейсов это может быть слишком накладно. В хороших сетевых контроллерах реализован аппаратный подсчёт контрольных сумм IP/UDP/TCP как на приёме, так и на отправке, так что процессор весь пакет не просматривает (см., например, Intel® Ethernet 10 Gigabit Server Adapters Advanced Driver Settings: Checksum offload.
  • Являются ли ирландцы потомками кельтов?
    +5
    … связал их с современными ирландцами, шотландцами и уэльсцами.

    Принц хотя и Уэльский, но вот жителей Уэльса по-русски обычно зовут валлийцами, а не уэльсцами.
  • Российский процессор Байкал
    +1
    Почему же не маркируют? Очень даже маркируют. Вот Loongson-2 — вполне себе массовый:
    Loongson-2
    А вот Loongson-3 — нельзя сказать, что массовый, плату купить трудно, но всё-таки полюбуйтесь на маркировку:
    Loongson-3B1500
  • Российский процессор Байкал
    –1
    Три эзернета 1+1+10 Гбит уже многого стоит. Такого вроде как ни у кого нет.

    См. http://www.cavium.com/OCTEON-III_CN78XX.html
    • Up to 4x XLAUI
    • Up to 8x XAUI/Dual XAUI
    • Up to 16x KR/XFI
    • Up to 32x SGMII

    Уточню: XLAUI — это для подключения трансивера 40 Гбит/с Ethernet.
    Да и ядер процессорных поболе — от 24 до 48.
    Да и ядра эти — не MIPS32, а MIPS64.
  • Российский процессор Байкал
    0
    См. мой комментарий выше. Подозреваю, что GarryC видел документацию на купленные IP-блоки, которая была написана авторами этих IP-блоков, т.е. не в стенах Байкал электроникс.
  • Российский процессор Байкал
    0
    Я не моуг представить, зачем писать документацию на русском.

    А вы использовали когда-нибудь отечественную СБИС в своих разработках?
    Если да, и на неё была документация на английском языке, то пожалуйста, укажите ссылку (очень интересно посмотреть, возможно там будет что-то вроде ай уил врайт фром май харт).
    В качестве положительного примера см. продукцию Миландр. На миландровском сайте вы легко найдёте тома документации на их продукцию на русском, но не найдёте на английском (хотя часть сайта переведена на английский язык). Аналогично, продукция всяких там МЦСТ, Элвисов да НИИСИ также имеет документацию именно на русском языке. И документация эта есть потому, что заказчик в ТЗ на микросхему указал, что должна быть документация по ЕСКД.
    А так, вы конечно правы: если покупать готовые IP-блоки, которые конечно же сопровождаются документацией на английском, то нет необходимости готовить свою документацию да ещё и на русском — отдать потребителю то, что пришло с IP-блоками, кому надо — разберутся.
    А вот если вы будете делать IP-блок сами — таки да, придётся писать свою документацию (можно даже на английском), хотя бы для того, чтобы на основе этой документации были сделаны тесты для IP-блока.
  • Российский процессор Байкал
    +7
    К сожалению, это держится в секрете.

    Очень жаль!
    Ну могу удержаться от комментирования упомянутого абзаца (пусть и без предложения про некоторые компоненты):
    За основу было взято лицензированное ядро MIPS P5600, кроме того были лицензированы контроллеры Ethernet, SATA и USB. Российским разработчикам предстояло собрать эти компоненты вместе, заставить их корректно работать друг с другом и произвести разводку чипа по современной топологии 28 нм.

    Давайте обратимся к имеющейся на сайте baikalelectronics.ru информации по Baikal-T1. Есть там блок-схема:
    блок-схема
    Какие блоки остались, если вычеркнуть Ethernet, SATA, USB (для последних двух, думаю, можно смело блоки PHY тоже вычёркивать), а также процессорные ядра:
    • DDR3 контроллер (вместе с PHY);
    • PCIe 3.0 контроллер (вместе с PHY);
    • AXI fabric — "быстрая" коммуникационная система на базе ARM AMBA AXI ;
    • мост для подключения контроллеров "медленных" интерфейсов к AXI;
    • ну и эти самые контроллеры "медленных" интерфейсов.

    Отдельно перечислю контроллеры "медленных" интерфейсов (укажу типичные производительности контроллеров, но документации на Baikal-T1 в свободном доступе нет, так что эти данные только для справки):
    • SPI (самые быстрые известные мне SPI Flash устройства работают на 104 МГц, т.е. для одной линии данных SPI выходит около 10 МБ в обе стороны);
    • I2C (типичные частоты на SCK — 100 или 400 КГц, т.е. менее 100/400 Кбит/с в одну сторону);
    • UART (типичные скорости 9600 — 115200 бит/с, хотя, может быть блок в Baikal-T1 умеет и 921 Кбит/с, а может и больше, но всё равно, не десятки Мбит/с);
    • GPIO (тут без конкретики говорить о производительности передачи данных не стоит).

    Усилия на создания хорошего контроллера ОЗУ DDR3 или контроллера PCIe 3.0 сопоставимы или даже больше, чем на создание контроллера Ethernet, PHY для этих интерфейсов — отдельная и непростая работа. Подозреваю, что IP-блоки этих контроллеров покупные. Пожалуйста, учтоните, верны ли мои подозрения.
    Что же касается AXI fabric, то тут обычно покупается не IP-блок, а генератор IP-блока, с помощью которого и создаётся специальный блок с нужным числом портов и требыемыми ограничениями для конкретной SoC.
    Для примера, см. генератор от Xilinx: AXI interconnect IP block.
    Проектирование коммутатора AXI от Xilinx сводится к заполнению нескольких форм и выглядит приблизительно так:

    Далее остаются контроллеры "медленных" интерфейсов, да мост для их подключения к AXI. Тут тем более логично использовать готовые блоки, если только не требуется сделать интерфейсы с нетиповыми дополнительными возможностями (но если так, то почему об этих нетиповых возможностях ничего не рассказывается?).
    Может бытьчто-то действительно сделано с нуля, но этого нет на блок-схеме?
    По поводу того, что российским разработчикам предстояло собрать эти компоненты вместе, заставить их корректно работать друг с другом замечу, что
    • если были закуплены отлаженные и проверенные IP-блоки контроллеров, то их подключение к AXI не должно вызывать проблем другие потребители, которые покупали эти IP-блоки до Байкала уж наверняка пытались их так и эдак подключать, и опыт у поставщика IP-блоков имеется; кроме того, а наверняка с IP-блоком можно купить и поддержку.
    • а если были закуплены непонятные, сырые, кривые и косые IP-блоки, с которых надо заставить корректно работать, то тут можно только развести руками и сказать Бачили очі, що купували, їжте, хоч повилазьте.

    Ну а для того, чтобы произвести разводку чипа по современной топологии 28 нм действительно надо провести большую работу — SoC-то немаленький и если всё работает как надо, то топологов Байкала можно только похвалить.
  • Российский процессор Байкал
    +3
    Если у Вас есть какие-то вопросы по процессору, задавайте их. Я на связи с разработчиками.

    Вот простой вопрос. В публикации есть абзац:
    За основу было взято лицензированное ядро MIPS P5600, кроме того были лицензированы контроллеры Ethernet, SATA и USB. Российским разработчикам предстояло собрать эти компоненты вместе, заставить их корректно работать друг с другом и произвести разводку чипа по современной топологии 28 нм. Некоторые компоненты процессора разрабатывались с нуля.

    Вот скажите, какие именно компоненты разрабатывались с нуля?
  • Маленькая ОС с нуля на C++ и ассемблере
    0
    11 лет? Отличный возраст, чтобы начать участвовать в разработке linux, как ранее рекомендовал rutaka_n!

    Как показала практика, можно открыть счёт своих linux'овых commit'ов и в более юном возрасте.
    Вот, к примеру, в linux взяли commit, автором которого числится девочка четырёх лет:

  • Альтернативы Raspberry Pi
    +1
    То, что стоимость больше и характеристики хуже — то верно подметил hzs.

    Но это было бы не очень страшно, если бы у МВ77.07 была бы ощутимая поддержка (со стороны сообщества пользователей или со стороны производителя) — но её нет.

    В своё время я приобрёл один экземпляр МВ77.07 и вот некоторые подмеченные мной факты:

    • можно пойти в магазин и просто так взять и купить Raspberry PI. С МВ77.07 такой фокус не пройдёт. Надо обращаться непосредственно в НТЦ Модуль;
    • сколько выпущено тех Raspberry PI, а сколько МВ77.07 — мой первый модуль МВ77.07 имел серийный номер между 0050 и 0060 (сходу и не вспомнить). Когда через несколько месяцев я принёс его на гарантийный обмен по причине плохой пайки BGA трансивера Ethernet, то мне выдали модуль с серийным номером между 0060 и 0070. Похоже, что тираж той платы весьма невелик. (Кстати, у выданного на обмен модулю как-то неважно работал наплатный USB-hub);
    • для Raspberry PI есть сайт, и там тебе и HELP и FORUM и DOWNLOAD, новости там, примеры всякие да советы. Для МВ77.07 ничего подобного нет, только страника на официальном сайте НТЦ Модуль, да организация RC-Module на github'е. Поддержкой ПО для К1879ХБ1Я и МВ77.07 занимается единственный человек, сотрудник НТЦ Модуль nekromant (хотя портировать ядро linux, судя по copyright'ам, заказывали в далёком теперь 2011 году конторе Promwad).
    • necromant, надо отдать ему должное, пиарил плату, см., например, http://www.linux.org.ru/news/hardware/10347668 и http://www.linux.org.ru/news/conference/10990627.

    Вижу два возможных объяснения ситуации вокруг МВ77.07:

    • либо это карго-культ — кто-то искренне хотел сделать конкурента RaspberryPI, но хотели как лучше, а получилось как всегда;
    • либо никто и не собирался делать массовую плату, а все видимые потуги вокруг МВ77.07, это больше для отчётности: дескать, мы-то старались, сделали вот плату, но народ у нас какой-то неправильный, не берёт.
  • RISC'овый Debian под QEMU
    0
    Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.

    Внешняя цель подмечена правильно, хотя согласиться с тем, что речь идёт про процы не самой популярной архитектуры не могу; подозреваю, что ARM как раз и является самой популярной архитектурой, см., например, новость, про то, что отметка в 50 млрд поставленных СБИС с ядром ARM преодолена в феврале 2014 года. Сравните оценки IDC по продажам в 2015 году PC (308 млн устройств) и смартфонов (1429 млн устройств); кроме смартфонов есть ещё много всяких интересных устройств, которые трудно заподозрить в использовании процессоров x86...

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

    Дело в том, что публикация получилась на основе моего опыта по работе со студентами и молодыми сотрудниками, которых надо было обучать навыкам разработки ПО для не x86-процессоров: как подготавливать инструментальную ЭВМ, как настраивать инструментальные средства, как собирать и запускать ПО на целевой ЭВМ. Таким образом, публикацию, нужно рассматривать не только как рецепт для решения конкретной практической задачи, но и как учебный материал, дающий читателю некоторые начальные навыки, которые ему пригодятся когда потребуется вносить правки в ядро linux, писать baremetal ПО или даже править QEMU.

    Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage
    насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими
    утилитами.

    В начале публикации было сказано: Debian rootfs отвязана от конкретной платы и SoC, а вот ядро linux может быть привязано к SoC и даже плате. Соответственно компоненты rootfs не грех скачать и готовые; ядро же можно скачать готовое, а можно получить из какого-то другого источника. В дальнейшем изложении эта мысль проиллюстрирована сборкой ядра с нужными опциями, тем более, что выполнить десяток коротких команд в консоли — дело не сложное. А уж с методической точки зрения лишнее упражнение по сборке ядра — только на пользу.

    Я почему и зацепился, потому как усилий на порядок меньше получается.

    Публикация, как говорится в начале, рассказывает о том, как можно при помощи debootstrap установить, а затем как при помощи QEMU запустить ОС Debian для ЭВМ с процессорами MIPS и ARM. Но нигде не обещается выполнить всё перечисленное с минимальными усилиями; изложение построено так, чтобы

    • материал был интересен как можно большему кругу читателей (поэтому рассказано и про MIPS и про ARM; поэтому и используется эмулятор, а не реальная плата);
    • были зацепки для дальнейших модификаций — чтобы можно пройти по рекомендованному в публикации маршруту, убедиться, что всё работает, а затем что-нибудь поменять: toolchain, ядро, rootfs, QEMU, сценарий загрузки; в конце концов, можно и осуществить запуск Debian на реальной плате.
  • RISC'овый Debian под QEMU
    0
    Мда...
  • RISC'овый Debian под QEMU
    0
    Образ делается debootstrap'ом, как и у автора.
    Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage
    насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими
    утилитами.

    Я почему и зацепился, потому как усилий на порядок меньше получается.

    Для достижения какой цели "усилий на порядок меньше получается"?
  • RISC'овый Debian под QEMU
    0
    Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.

    Ну ведь образ, который надо тупо заливать в соответствующие разделы NAND, он ведь как-то делается.

    В публикации как раз описывается, что делать если готовые ФС и/или ядро не подходят или вообще не существуют.
  • Анонсирован моноблочный компьютер “Таволга Терминал TP-T22BT” на базе процессора “Байкал-Т1”
    0
    То, что могут припаять 8 ГБ ОЗУ — это хорошо, но есть одна проблема...

    В Байкал-Т1 использовано ядро MIPS32. Это означает, что пользовательский процесс в Linux сможет адресовать не более 2 ГБ; именно таков размер сегмента kuseg, см. fig 2.1 MIPS memory map: the 32-bit view на странице 48 книжки See MIPS Run (увы, у меня не получается подобрать URL, переход по которому обеспечивает открытие нужной страницы).

    А вот если бы для Байкал-Т1 купили бы ядро MIPS64, этой проблемы бы не было, соответствующий пользовательский сегмент xuseg имеет размер 4294967296 ГБ, см. fig. 2.2 A 64-bit view of the memory map на стр. 51 в той же книжке.
  • RISC'овый Debian под QEMU
    0
    К сожалению, на практике все далеко не так просто.

    Полностью согласен! Я так и написал — на реальной плате запуск будет более хлопотным чем на QEMU.

    Например, в дебиане отсутствуют пакеты для целевой архитектуры.

    Что значит "отсутствуют пакеты для целевой архитектуры"? Если для конкретной архитектуры пакеты совсем отсутствуют — тогда и вовсе не стоит говорить о существовании Debian для этой архитектуры. Вот к примеру, для RISC-V, AFAIK, Debian'а пока и нет.

    А если же имеется в виду, что для MIPS/ARM нет некоторых пакетов, которые доступны для других архитектур, то да,
    такая проблема есть.

    На одной из моих машин с Debian в режиме Multiarch подключены сразу архитектуры i386 и mips, и я решил сравнить количество пакетов из testing main:

        $ cat /var/lib/apt/lists/ftp.ru.debian.org_debian_dists_testing_main_binary-i386_Packages | grep ^Package | sed "s/^Package: //" > /tmp/packages_list_i386
        $ cat /var/lib/apt/lists/ftp.ru.debian.org_debian_dists_testing_main_binary-mips_Packages | grep ^Package | sed "s/^Package: //" > /tmp/packages_list_mips
        $ wc -l /tmp/packages_list_*
        47430 /tmp/packages_list_i386
        45914 /tmp/packages_list_mips
        93344 total

    Получается, что для mips полторы тыщёнки пакетов не доложили! Впрочем, это меньше четырёх процентов числа пакетов для i386.

    С другой стороны часть пакетов для mips отсутствует по объективным причинам — ну не нужны на mips loadlin и lilo.
    Кроме того, я просмотрел список отсутствующих для mips пакетов — из тех которые у всех на слуху я встретил пожалуй что только один — tomboy, остальные — это какие-то узкоспециальные пакеты, которых среднему пользователю особо и не жаль.

    Или в ядре отсутствует поддержка имеющейся платы, а заодно и трех-четырех периферийных устройств.

    Тут бы конкретную ситуацию обсуждать, а не все осуществимые возможности. Что значит "в ядре отсутствует поддержка"? В каком именно ядре? Если нет рабочего ядра linux, или ядро есть, но не поддерживает очень нужную периферию, то тут и говорить не о чем — либо ядро дописывать либо бросить всё как есть.

    Если же речь идёт о ядре с kernel.org, то да, далеко не у всех разработчиков хватает сил/времени/желания на продвижение своих изменений ядра в kernel.org.

    Самый типовой сценарий (то есть без учёта крайностей), запуска Debian на реальной плате по мотивом обсуждаемой публикации представляется мне так:

    • для выбранной платы есть поддержка в ядре linux (неважно с kernel.org или с openwrt.org, или откуда ещё);
    • производятся разборки по поводу того, как ядро будет попадать в плату и запускаться (припомощи штатного загрузчика, через EJTAG-ли или каким ещё чудом);
    • собираем требуемое ядро;
    • собираем образ rootfs Debian, как описано в публикации;
    • обеспечиваем попадание Debian rootfs на плату (записываем на встроенный накопитель, на внешнюю USB-флешку, планируем грузиться в режиме nfsroot или каким ещё волшебным образом);
    • запускам ядро с Debian rootfs;
    • PROFIT!

    Думаю, этот сценарий подходит для большинства плат разработчика (devboard) или поддерживаемых openwrt устройств в широкой продаже.

    А уж нетиповые ситуации потребуют нетиповых же мер.
  • Анонсирован моноблочный компьютер “Таволга Терминал TP-T22BT” на базе процессора “Байкал-Т1”
    +2
    Подскажите, а что имеется ввиду, под понятием "процессорный модуль"?

    Подозреваю, что имеется в виду вот такой SMARC-модуль (см. пост https://geektimes.ru/company/icover/blog/271664/):

  • Анонсирован моноблочный компьютер “Таволга Терминал TP-T22BT” на базе процессора “Байкал-Т1”
    +2
    Вот что Юрий Панчул рассказал про лицензионную политику MIPS на семинаре MIPSfpga:

    • у MIPS (ну теперь Imagination) можно лицензировать готовое процессорное ядро — это стоит одних денег;
    • можно лицензировать архитектуру — это стоит в разы больших денег; лицензируя архитектуру, вы покупаете право разработать процессор, который соответствует архитектуре MIPS и гордо об этом рассказывать. MIPS со своей стороны поможет верификационныи тестами, которые проверят, что вы правильно реализовали архитектуру MIPS (ну чтобы на что попало не ставили гордый значок MIPS32 или даже MIPS64).

    В случае с Байкал-Т1 было куплено готовое процессорное ядро, то есть это "обычный MIPS от Imagination". Сделали бы своё ядро — поводов для гордости было бы значительно больше. Всякие Broadcom'ы, да Cavium'ы свои ядра MIPS запилили...

    Что же касается "просто ARM" от Samsung, Apple и Qualcomm, то они-то (если верить https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures) свои ARMы пилили сами, в итоге получились как раз не "просто ARM'ы",
    я бы даже сказал это "ARMы, но не как у всех".