Embox начинает восхождение на Эльбрус

    Те кто следит за нашим проектом могли заметить, что в каталоге с архитектурами появилась папка e2k, содержащая реализацию поддержки отечественных процессоров с архитектурой Эльбрус. Серия статей о портировании Embox на отечественные платформы была бы неполной без рассказа об этой архитектуре.

    Сделаю пару замечаний по содержимому статьи. Во-первых, процесс освоения нами данной архитектуры находится на начальной стадии, нам удалось запустить Embox на данной платформе, но мы еще не реализовали много необходимых частей, об этом речь пойдет в будущих публикациях. Во вторых, данная архитектура – сложная, и
    для детального описания требуется гораздо больше текста, чем позволяет формат
    одной статьи. Поэтому предлагаем воспринимать данную статью как вводную,
    содержащую минимум технической информации о самой архитектуре.

    Приступим.

    Объект исследований – макет встраиваемой системы на Эльбрус


    Поскольку мы занимаемся Embox (а он, если кто не в курсе, ориентирован на встроенные системы), нас интересовал прежде всего вариант, который самим МЦСТ позиционируется в том числе для встраиваемых систем. Обратившись в МЦСТ мы выяснили, что в компании заинтересованы в применении своих процессоров для встраиваемых систем. Одним из последних решений для данного сегмента является плата E4C-COM . В процессе общения с МЦСТ стало понятно, что для портированая и освоения архитектуры, можно воспользоваться любой из имеющихся машин, и нам во временное пользование дали вычислитель под названием Монокуб. Вообще, монокуб не совсем то, к чему мы привыкли в embedded systems. Обычно во встраиваемых системах используют одноплатные компьютеры, чип — система на кристалле или вовсе микроконтроллер, монокуб же является полноценным компьютером, но поскольку он прошел испытания по “климатике и механике”, то его все-таки можно считать embedded system.

    Компилятор, сборка, заливка образа


    После получения системного блока, естественно, встал вопрос — как заливать образ. В МЦСТ используют свой BIOS (системный загрузчик первого уровня). По умолчанию устанавливается ОС Эльбрус (т.е. Debian с модификациями). Нам же интересно запускать собственный образ. На наше счастье загрузчик МЦСТ умеет запускать образы по сети. Для этого используется протокол ATA over Ethernet.

    После того, как нам помогли настроить стенд и запустить внешний образ по сети, мы приступили к разработке собственного образа. Для этого нам потребовался компилятор. Компилятор в открытом доступе не нашли, но поскольку мы подписали NDA, нам выдали бинарники под Линукс. Компилятор оказался вполне себе gcc-совместимым, и нам ничего не пришлось менять, естественно за исключением флагов компиляции, которые у нас вынесены в отдельный конфигурационный файл. Что очень предсказуемо, ведь линукс, пусть и с модификациями, собирается этим компилятором.

    Пара технических вопросов


    Те, кто занимался такой специфичной деятельностью, как портирование ОС на какую-либо платформу, знают, что первое, что нужно сделать — это правильно разместить программный код в памяти. То есть написать линкер-скрипт (lds) и реализовать стартовый код. С линкер-скриптом довольно быстро разобрались, но вот при реализации стартового кода, мы столкнулись с первой магией, которую так до конца и не поняли. Дело в том, что у Эльбруса есть режим x86-совместимости и по адресу 0x00FF0000 лежит код, на который просто дам ссылку, поскольку мы его позаимствовали из примера МЦСТ. Линкер скрипт содержит

    .bootinfo : {
       	 _bootinfo_start = .;
       	 /* . = 0x1000000 - 0x10000; */
       	 /* 0x00FF0000 */
       	 *(.x86_boot)
       	 . = _bootinfo_start + 0x10000;
       	 _bootinfo_end = .;
        } SECTION_REGION(bootinfo)
    .text : {
       	 _start = .;
       	 /* 0x01000000 */
       	 *(.e2k_entry); 

    Сам же стартовый код написан даже не на ассемблере, а просто на Си. Он положен в секцию, размещенную по адресу 0x01000000, что кстати вполне соответствует стартовому адресу обычных x86-машин — там по этому адресу лежит заголовок multiboot либо другой заголовок.

    Для того, чтобы удостовериться, что стартовый код и адреса верны, нужно добиться какого-нибудь вывода. Если получится вывести какой-нибудь символ, то, скорее всего, не возникнет проблем с выводом строк. Используя этот вывод, уже можно будет использовать привычный printf() для отладки. К тому же, большинство платформ предоставляет возможность выводить символы, делая простую запись в определенный регистр (т.к. загрузчик уже, скорее всего, настроил UART как надо).

    В нашем компьютере используется контроллер последовательного порта am85с30 (он же z85с30 мы достаточно быстро нашли, как вывести один символ, а этого достаточно для работы нашего printf-а. Тут же столкнулись со странной проблемой — часть символов, выводимых printf, будто бы дублировалась, но при этом иногда перемешивалась. Например, при попытке вывести Hello, world! Получалось что-то вроде Hhelellloo,, woworrlldd. Сейчас кажется очевидным, что дело в многоядерности, но сначала мы долго ковырялись в самом драйвере. В нашем монокубе стоит двухъядерный Эльбрус-2С+ (1891ВМ7Я) (четыре DSP ядра не в счет) и загрузчик активизирует все процессорные ядра. В итоге, чтобы не возиться с многоядерностью (SMP), все ядра кроме первого отправляем в бесконечный цикл. Для этого мы ввели переменную для номера процессора и с помощью атомарного сложения инкрементируем ее. Нулевое ядро продолжает работать, а другие ядра зацикливаются.

       cpuid = __e2k_atomic32_add(1, &last_cpuid);
    
        if (cpuid > 1) {
       	 /* XXX currently we support only single core */
       	 while(1);
        }
    
        /* copy of trap table */
        memcpy((void*)0, &_t_entry, 0x1800);
    
        kernel_start();

    Вызов kernel_start() — это уже передача управления нашему коду.
    Атомарное сложение мы тоже позаимствовали, для нас оно смахивает на магию. Но, как известно, работает — не трогай!

    #define WMB_AFTER_ATOMIC    ".word 0x00008001\n" \
       			 ".word 0x30000084\n"
    
    #define __e2k_atomic32_add(__val, __addr) \
    ({ \
        int __rval; \
        asm volatile ("\n1:" \
       		   "\n\tldw,0 %[addr], %[rval], mas=0x7" \
       		   "\n\tadds %[rval], %[val], %[rval]" \
       		   "\n\t{"\
       		   "\n\tstw,2 %[addr], %[rval], mas=0x2" \
       		   "\n\tibranch 1b ? %%MLOCK" \
       		   "\n\t}" \
       		   WMB_AFTER_ATOMIC \
       		   : [rval] "=&r" (__rval), [addr] "+m" (*(__addr)) \
       		   : [val] "ir" (__val) \
       		   : "memory"); \
        __rval; \
    })

    Еще одной магией, которую пришлось позаимствовать, является некий код, который обязателен для всех ядер. А именно

    static inline void e2k_wait_all(void) {
        _Pragma ("no_asm_inline")
        asm volatile ("wait \ttrap = %0, ma_c = %1, fl_c = %2, ld_c = %3, "
       		 "st_c = %4, all_e = %5, all_c = %6"
       		 : : "i" (0), "i" (1), "i" (1), "i" (0), "i" (0), "i" (1), "i" (1) : "memory");
    }

    В итоге, после написания стартового кода у нас не только появились сообщения, выводимые с помощью printk, но и стали загружаться модули, что вообще то не очень тривиально для не совсем стандартных компиляторов. Так что еще раз отмечу, что на этот раз совместимость с gcc очень сильно порадовала.

    Следующим шагом обычно является запуск контроллера прерываний и таймера, но подумав о том, что нам придется реализовать не только поддержку этих устройств, но и архитектурный код обработчиков прерываний, мы решили, что можно начать с периферии. Монокуб имеет шину PCIe, для программистов это выглядит как обычный PCI. Нас интересовали прежде всего два устройства: контроллер дисплея и сетевой контроллер.

    В монокубе используется графический контроллер из серии sm750. Это графический контроллер для встроенных применений, имеет на борту поддержку 2d-графики. Микросхема напаяна прямо на материнскую плату, насколько я понял. Исходники для драйвера под линукса можно найти тут.

    После найденного драйвера казалось, что наши проблемы закончились, оставалось только реализовать контроллер для PCI. точнее операции чтения/записи конфигурационного пространства PCI, чтобы узнать параметры. Реализацию этих функций пришлось опять заимствовать. В итоге, записи чтения сводились к макросам типа

    /*
     * Do load with specified MAS
     */
    #define _E2K_READ_MAS(addr, mas, type, size_letter, chan_letter) \
    ({ \
    	register type res; \
    	asm volatile ("ld" #size_letter "," #chan_letter " \t0x0, [%1] %2, %0" \
                  	: "=r" (res) \
                  	: "r" ((__e2k_ptr_t) (addr)), \
                    	"i" (mas)); \
    	res; \
    })
    
    #define _E2K_WRITE_MAS(addr, val, mas, type, size_letter, chan_letter) \
    ({ \
    	asm volatile ("st" #size_letter "," #chan_letter " \t0x0, [%0] %2, %1" \
                  	: \
                  	: "r" ((__e2k_ptr_t) (addr)), \
                    	"r" ((type) (val)), \
       	 	"i" (mas) \
       	   : "memory"); \
    })
    

    Тут есть некоторое понимание происходящего. У Эльбруса несколько альтернативных адресных пространств, как, например, в SPARC архитектуре. Идентификация идет с помощью идентификатора адресного пространства. То есть одна и та же команда ld попадает по разным внутренним адресам, еще и сгенерит операции чтения разной длины (8, 16, 32, 64 бита). Если в SPARC это отдельная команда lda/sta то в Эльбрусе за счет параметров, это команда ld. Из SPARC архитектуры позаимствовали регистровые окна. Более подробный рассказ я отложу для последующих статей.

    В итоге, у нас все получилось с PCI. Мы смогли получить все необходимые данные, перенесли к себе графический драйвер, но тут столкнулись со следующей проблемой. Для отрисовки картинки в видеопамять нужно было писать два раза. Все указывало на cache. Для того чтобы решить эту проблему, нужно было разобраться с MMU, а это, как говорится, с кондачка не решается, как, в принципе, и многие другие проблемы, с которыми мы столкнулись и еще не раз столкнемся во время освоения данной архитектуры.

    Мы продвинулись и в других направлениях: прерывания и системные вызовы, но об этом мы также расскажем в следующих статьях данной подсерии. В завершение данной статьи я просто приведу вывод в консоль (по последовательному порту).


    Выводы


    Как я говорил в предисловии, я хочу сосредоточиться в первую очередь не на технических деталях, а на общих ощущениях. Так вот, ощущения противоречивые, хотя конечно больше положительные. С одной стороны, процессор существует и является очень интересным с точки зрения архитектурных особенностей. На основе этого процессора выпускаются вычислительные системы, есть ПО, достаточно высокого качества. Как я сказал, к компилятору не было претензий (до определенного момента, который опишу чуть позже), есть полноценный Линукс (ОС “Эльбрус”). Я лично видел, как в самом МЦСТ, разработчик творил прямо на десктопе с архитектурой Эльбрус.

    Но с другой стороны, я не понимаю, почему с таким упорством пытаются сделать из данного процессора банальную замену интеловским x86. Ведь нигде в мире не используют процессоры на основе VLIW архитектуры в качестве универсальных персональных компьютеров. VLIW в силу своих архитектурных особенностей является крутой “числодробилкой”, на ней делают DSP, делали сервера itanium, делали графические карты. Нет экскаватором конечно можно вырыть ямку для посадки деревца, но стоит ли.

    Главной же проблемой препятствующей развитию архитектуры, на мой взгляд является закрытость всей экосистемы. Да, для того чтобы получить описание системы команд, нужно просто подписать NDA, но ведь этого мало. Архитектура незнакомая и очень сложная. Да, я всегда считал, что какое-то базовое ПО должно разрабатываться прямо у производителя процессоров, ну или в тесном сотрудничестве с ним. По этому принципу у ПК на Эльбрусах есть комплект ПО с ОС “Эльбрус”. Но все же слишком наивно считать, что одна компания, пусть даже крупная, может обеспечить качественную поддержку всем составляющим: процессор, компилятор, средства разработки и отладки, системное ПО (ОС различные), прикладное ПО, …. такое не под силу даже Интелу. Мир давно идет в сторону так называемой коллаборации или совместной разработки.

    Приведу пример проблемы с компилятором, на которую мы наткнулись. Драйвер последовательного порта в какой то момент перестал выводить символы, причем, на первый взгляд, ничего не изменилось. Оказалось, что мы убрали неиспользуемую отладочную функцию, которую вставили для того, чтобы через дизассемблер понять, как на ассемблере передать аргументы в функцию. То есть, если функция присутствует, все нормально, если нет, то пропадает вывод. Сначала грешили на выравнивание, но оказалось, что функцию можно перенести и в конец Си-шника, поэтому все символы из драйвера оказывались на тех же местах, что и раньше, но проблема воспроизводилась. Пока данную проблему не решили, продолжаем исследовать, чтобы показать разработчикам компилятора из МЦСТ или понять, где мы ошиблись.

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

    Проблему закрытости осознают и в МЦСТ, поскольку процесс открытия несекретных вещей все-таки пошел. Например, я видел на нескольких конференциях работу Альт-Линукса на ПК серии Эльбрус. Вот фотки дисплея с одной из конференций в этом году (извините что плохо видно, было темно). Мы тоже подключились с освоению. Надеемся, что мы будем полезны МЦСТ, поскольку, как выясняется, некоторые изюминки архитектуры Эльбрус не могут быть поддержаны в Линукс (или затраты очень большие), например, тегированная память.



    Еще один важный момент, когда мы обсуждали проблему закрытости с разработчиками МЦСТ, они возразили, что, например, исходники ядра линукса открыты долгое время, однако только мы и разработчики компании Доломант задавали вопросы и как то их использовали.

    Кроме того, по моей информации, в компании МЦСТ собираются организовать стенд
    доступный удаленно. На котором можно будет собрать и запустить ПО на ПК с архитектурой Эльбрус. Если есть подобный интерес и хочется использовать стенд, то следует обратиться, например, ко мне: описать, как планируется его использовать, сколько времени нужно и так далее, ведь для совместного доступа с изменением ПО, нужно организовать расписание. Данные я передам в МЦСТ или свяжу желающих с организаторами.



    Полезные ссылки:

    Адрес рассылки для пользователей — user[at]mcst.ru
    Краткое описание архитектуры Эльбрус
    Исходники Embox

    P.S. Всем желающим мы покажем, то что у нас получилось, на IT-фестивале TechTrain 1-2 сентября.
    Embox
    56,00
    Открытая и свободная ОС для встроенных систем.
    Поделиться публикацией

    Похожие публикации

    Комментарии 73

      –5
      А сайта на не-русском у МЦСТ совсем нет?
        +3
        хм, похоже нет. Наверное это следстие ориентации только на российский рынок. Что наверное и правильно на сегодняшний день.
          0
          Наверное это следстие ориентации только на российский рынок.

          А он этот рынок есть?

        +2
        Но с другой стороны, я не понимаю, почему с таким упорством пытаются сделать из данного процессора банальную замену интеловским x86

        Весной общался с представителями МЦСТ.
        С технической точки зрения — они действительно молодцы. Команда из 450 человек тащит абсолютно всё — от проектирования кристалла и плат до портирования и оптимизации конкретного ПО заказчика.
        Основная их проблема — отсутствие массовости. Они не могут запустить серию, потому что на неё нет спроса. Отсюда и штучные изделия и их цена.
        И откровенно говоря, я не вижу альтернатив, кроме как активно продвигать двоичный транслятор x86 для запуска огромной кучи ПО, которое используется в гос. структурах. Ибо никто не будет его пересобирать под VLIW.
        В этом случае есть хотя бы гипотетическая вероятность, что они смогут-таки пропихнуть несколько тысяч машин в какую-либо гос. структуру, где их будут использовать как простую замену x86, безо всяких преимуществ VLIW.

        Очень надеюсь, что у ребят это получится.
        А вот тогда уже можно и показать «А вот смотрите-ка, то же самое приложение, скомпиленное под VLIW, работает на 70 % быстрее.»
          0
          Возможно Вы правы и единственный вариант это бинарная трансляция!
          Но если задуматься, несколько тысяч системных блоков (пусть 10 тыс). А для этого нужно выпустить чипы, что ну прямо скажем не дешевое удовольствие, зарплату на 450 человек ну и все остальное. И это получается, что системный блок, как был золотым, так и остался золотым. И главное ничего нового не получим, ведь Вы правильно заметили, что теряются преимущества,
          Другое дело, если для определенного класса задач где требуются эти преимущетсва, выкинуть бинарную трансляцию и оптимизировать ПО. Вот при таком подходе, есть надежда, что и другие сегменты появятся. Пример задачи, реализация того самого закона Яровой, где нужно очень много серверов для хранения данных.
          Но абсолютно согласен на счет того, что разработчики молодцы!
            0
            Мы активно применяем Эльбрусы в гос-структурах. Все ПО пересобирается на Эльбрусья в лёт и нормально работает. Сложнее бывает, когда ПО написано под винду, тогда приходится сначала портировать в линукс, а потом уже просто собирать на Эльбрус.
              0
              Согласен. С ПО для Линукса проблем особых нет, пересобирается и работает нативно
                0
                А с поддержкой свежих плюсов как у тамошнего компилятора?
                  0
                  Компилятор регулярно (пару раз в год) обновляется. В текущем норм C++11, с C++14/17 пока есть сложности, обещают поправить в ближайшее время.
                    0
                    Неожиданно приятно, спасибо!
                0
                Расскажите об этом подробнее, что за софт, как портируется, какой линукс используется, и так далее…
                  0
                  Все ПО пересобирается на Эльбрусья в лёт

                  А какое это или что это за ПО, которое мспользуется в госах на Эльбрусье?

                    0
                    В основном специфическое для конкретного заказчика ПО: субд, развесистый GUI, документооборот, специалилизрованное серверное ПО и т.д. К сожалению, когда речь идет о государственном заказчике, подробности рассказать не получится :(
                      0
                      когда речь идет о государственном заказчике, подробности рассказать не получится

                      Какие-то тайны полишинеля. А может дело не в ПО? Что же может быть специфического в СУБЛ или GUI. Так мы никогда и ничего импорто не заменим.

                        0
                        0_о как «так»? Вы считаете, что если в интернете написать о том, какой софт гос-структуры для самих себя разрабатывают и используют, импортозамещение пойдет бодрее? Довольно странная позиция.
                        Суть же не в том, что там СУБД сильно особенные или GUI какие-то не такие как везде. Особенной является информация, которая в них храниться и обрабатывается. Само существование некоторых систем может являться государственной тайной. И наше государство в этом вопросе никак не отличается от других.
                          0
                          Само существование некоторых систем может являться государственной тайной.

                          Систем — Да! А общесистемного ПО? ОС — не секретна, а какая СУБД от того же Линукс Секретна!


                          Вы считаете, что если в интернете написать о том, какой софт гос-структуры для самих себя разрабатывают и используют, импортозамещение пойдет бодрее?

                          Да, именно бодрее пойдет! Личный пример (в данном случае госструктур) никто не отменял. И принцип "делай как я" тоже жив. Вопрос в том, если что делать?

                            0
                            Так никто свои СУБД и не разрабатывает. Все используют опенсерс. Чаще всего — постгрес. И на его основе строят специализированные системы :)
                            ОС Эльбрус (Линукс на Эльбрус) открыт, ссылку на гитхаб давали. Большая часть «общесистемного» софта опенсерсная: glibc, systemd, Qt5, .NET Core и т.д.
                            Большая часть вносимых в опенсерс продукты изменений коммитится, так как это выгоднее, чем поддерживать самостоятельно.
                            Скрывается только специфика, которая все равно никому кроме конкретной гос структуры не нужна :)
                      0
                      это обычные прикладные программы для Линукса. Очень много использует Qt, ну и конечно весь остальной набор, типа баз данных.
                      У военных если используют Эльбрусы насколько я знаю тоже стоит Линукс (ОС Эльбрус) ну и тоже самое. Тема действительно специфическая, делается под заказчика, ну а у нас принято скрывать все на свете, даже если скрывать там не чего.
                    0
                    Ценник у них сейчас рухнул минимум в два раза, если сравнивать с тем временем, когда монокуб был ещё предсерийной бетой. Да и СБК сейчас живет на достойном уровне.
                      0
                      Ну все равно цены хотелось бы поменьше. Но с другой стороны, процесс движется, что безусловно радует. Ну и Эльбрусы все таки не стоит с малинаками сравнивать. А для спец применений характерен другой порядок цен не только у нас.
                        0
                        А малинка тут причём?
                          0
                          Ни при чем. Я имел в виду, что высокая цена понятие относительное.
                  +3
                  Компилятор в открытом доступе не нашли, но поскольку мы подписали NDA, нам выдали бинарники под Линукс. Компилятор оказался вполне себе gcc-совместимым [...] линукс, пусть и с модификациями, собирается этим компилятором [...] совместимость с gcc очень сильно порадовала

                  Все это наводит на определенные мысли, уж не форк ли это GCC случаем? В этом случае очевидно нарушение GPL.

                    +3
                    Нет, это не форк gcc. это оригинальная разработка основанная на lcc, которая совместима по интерфейсу с gcc. Я не уверен, что там осталось хоть что то от lcc, но совместимость с gcc реально порадовала.
                      +3
                      Немного уточню, эльбрусовский компилятор не основан на lcc, название lcc идет от eLbrus Compiler Collection, у МЦСТ-шного lcc фронтенд EDG , такой же как у интеловского icc, остальное оригинальная разработка.
                        +1
                        Все верно, компилятор у них от EDG. Я его глядел, там от gcc вообще ничего нет.
                        К сожалению Edison имеет достаточно кабальную лицензию, что не позволяет МЦСТ открыть даже исходники их собственного бэкенда :( Хотя сейчас у них есть проект по портированию всего этого чуда на LLVM, но он пока в зачаточном состоянии.
                        Вообще в МЦСТ все чаще ходят мысли о том, что пора опенсерситься, так что весьма возможно, что в ближайшие годы мы увидим на гитхабе их исходники.
                    0
                    исходники ядра линукса открыты долгое время, однако только мы и разработчики компании Доломант задавали вопросы и как то их использовали.


                    Сдается, что вы не владение информацией. Достаточно взглянуть на официальные пресс-релизы МЦСТ:

                    Обеспечена совместимость серверной платформы Эльбрус-4.4 и ЗОСРВ «Нейтрино-Э»:

                    Отвечая современным требованиям, АО «МЦСТ» и ООО «СВД Встраиваемые Системы» обеспечили совместимость отечественной серверной платформы Эльбрус-4.4 и защищенной операционной системы реального времени (ЗОСРВ) «Нейтрино-Э».
                      0

                      Ядро ОС Эльбрус — монолитное, у QNX — микроядерная архитектура. Так что ваша цитата не противоречит тому что линуксовым ядром никто не интересовался.

                        0
                        Это отличие не играет никакой роли. При портировании любой ОС на это железо не подглядывать в Linux разработчики 100% не могут. У коллег из МЦСТ уж больно много своих фишечек, включая разбиение стеков потоков на группы, ассемблерную магию и т.п. По их же словам ряд функций системной библиотеки получен за счет дизассемблированного когда, сгенерированного LCC по Си-шной заготовке просто потому, что он это делает лучше, чем у специалистов получалось вручную.

                        Так что тут без первоисточника, а это в первую очередь Linux, ни шагу.
                          0
                          Ответил ниже, но повторюсь. Речь идет об использовании именно открытой версии ядра линукса. Информацию из цитаты получил от одного из разработчиков в МЦСТ. Могу предположить, что МЦСТ передали исходники в рамках соглашения между компаниями!
                            0
                            Постойте, на гитхабе по ссылке выше исходникам 3 дня. Ваш исходный тезис говорит о том, что они открыты долгое время. Как так?

                            Могу предположить, что МЦСТ передали исходники в рамках соглашения между компаниями!


                            МЦСТ выложили в открытый доступ какой-то другой Linux, а под NDA распространяет некие «настоящие» наработки? Даже если на время забыть о 3х днях.
                              0
                              Да, изначально мы нашли ядро линукса в другом месте. Сейчас та ссылка закрыта. Взамен, нам дали приведенную ссылку на github. Мы обнаружили, что ссылка была закрыта когда готовили статью, возник приведенный Вами разговор, и по нашей просьбе исходники ядра появились на github.

                              МЦСТ выложили в открытый доступ какой-то другой Linux, а под NDA распространяет некие «настоящие» наработки?

                              Наработки настоящие. Но казус который мы так упорно обсуждаем мог возникнуть из за того, что в отличие от нас, когда портировали QNX, сразу передали исходники ядра или еще что то, и не пришлось искать это в открытом доступе! То есть при общении между компаниями, не нужны исходники в открытом доступе!
                        0
                        Спасибо за информацию, теперь буду ей владеть. А кто владеет информацией, владеет миром.:)

                        Собственно, меня немного опередили, но свормулирую иначе.

                        Речь шла конечно, не о том кто запускается на Эльбрусах, а имено об использовании открытого кода. Я знаю еще несколько ОС которые поддерживают данную архитектуру, но речь повторяю не об этом. К тому же, не стоит воспринимать статью на хабр, как официальный пресс-релиз. Ну как минимум, мы еще не реализовали всех функций ядра, поэтому заявить, что Embox полностью поддерживает данную платформу, мы не можем.

                        Вот еще информации о том что еще сделали под Эльбрус на свободном ПО

                        По поводу приведенной Вами информации. Я могу только приветсвовать, то что экосистема развивается и, что ООО «СВД Встраиваемые Системы» вносит свою лепту! :)
                          0
                          Я знаю еще несколько ОС которые поддерживают данную архитектуру, но речь повторяю не об этом.


                          А вот это интересно, просьба пролить свет. Если речь об Астре, то по моим сведения её портировали как раз МЦСТ и рассматривать это как отдельную разработку не стоит.

                          И эти самые люди с неназванными ОС все писали не глядя в Linux?

                          Вот еще информации о том что еще сделали под Эльбрус на свободном ПО


                          По ссылке жалуются на «The page you were looking for doesn't exist.»
                            0
                            извините, вот ссылка https://lvee.org/ru/abstracts/286
                            И эти самые люди с неназванными ОС все писали не глядя в Linux?

                            Где я такое написал?
                            Думаю все ОС были портированны с участием сотрудников МЦСТ или как минимум с их консультациями. Конечно использовались наработки от МЦСТ в том числе и в коде ядра линукса.
                              0
                              Если верить этому:

                              Бывшая команда ALT Linux выпустила ОС для процессоров «Эльбрус», ARM и MIPS,

                              То Альт там запущен лишь в режиме бинарной трансляции, а это уже сильно снижает ценность разработки.

                              Думаю все ОС были портированны с участием сотрудников МЦСТ или как минимум с их консультациями. Конечно использовались наработки от МЦСТ в том числе и в коде ядра линукса.


                              В чем тогда ценность наличия некоего deprecated опенсорса?
                                0
                                А почему Вы решили что это бинарная трансляция у Альт-а. Не понимаю с чего вы это взяли, с фразы
                                ОС АЛЬТ пересобирается из ОС АЛЬТ для x86 версии 9.

                                Ну так тут написано, что пересобирается, а не запускается в бинарном виде.

                                И что Вы подразумеваете под термином «deprecated опенсорс»?
                                  0
                                  Ну так тут написано, что пересобирается, а не запускается в бинарном виде.


                                  Из исходников ОС для x86 нельзя получить полноценную ОС под Эльбрус простой пересборкой другим компилятором. Тут как минимум иная логика обработки аппаратных исключений, другой ABI, много стэков у потоков, 128 битная адресация (если про защищенный режим говорить) и особый набор периферии, включая контроллер прерываний. Так что ничем иным, кроме как бинарной трансляцией (что в некотором смысле тоже пересборка) это быть в такой формулировке не может.

                                  И что Вы подразумеваете под термином «deprecated опенсорс»?


                                  Это вопрос в владельцам репозитория на гитхабе по Вашей ссылке. Коммент к коммиту вполне однозначный: «Add deprecated kernel sources».
                                    0
                                    Насколько я знаю Альты часть софта портировали под платформу, а часть действительно пересобрали в режиме бинарной трансляции. А что-то и вообще не потребовало порта, достаточно было компиляции. Плюс у них там до сих пор лишь половина репозитория портирована. Многие вещи пока даже не собираются.
                                      0
                                      Если Вы в курсе их кухни, интересно все-таки ядро ОС какое: нативное Альт, ядро от ОС Эльбрус (как указали ниже) или бинарно-транслированное Альт. Насколько мне известно, тут не может быть двух вариантов.

                                      А с софтом мне сказать нечего, не совсем понимаю в чем тут изюминка, поскольку есть официальный дистрибутив Линукса — ОС Эльбрус.
                                        0
                                        Не могу сказать что прям сильно в курсе. Просто на ютубе есть относительно свежая двухчасовая лекция Шигорина о состоянии дел с эльбрусами в Альте.И емнип ядро там от МЦСТ, но относительно свежее. Хотя я не знаю как оно им было предоставлено, в виде бинарников или патчей к ванильному ядру.
                                          0
                                          Спасибо. Кроме МЦСТ, похоже, никто разработку ядра Линукс под Эльбрус так и не осилил.
                                            0
                                            Так они же не открывают свою систему команд, даже тем кто подписал NDA. Все из-за заморочек с военными/академией наук. Например товарищам из Унипро, по состоянию на конец 2016 года, ее так и не открыли, хотя те по заказу МЦСТ портировали Java и сейчас портируют js и C# движки. Им пришлось реверсинженирингом ее получать. Так-что ничего удивительного что никто кроме самих МЦСТ не учавствовал в портировании ядра. Да и зачем, если МЦСТ это уже сделали.
                                              0
                                              Систему команд они открывают достаточно спокойно. Если того хотят, естественно. Без ассемблера там очень плохо, если нужно что-то начинать ускорять.

                                              Видимо у обозначенной конторы какие-то свои терки с МЦСТ.
                                                0
                                                Так на нераскрытие системы команд и альтовцы жаловались. Вот тут например. Что-то конечно открыто, но далеко не все. Позиция МЦСТ в том, что компилятор все-равно умнее. Человеку ассемблер не особо нужен. Да и дело тут не в терках. Эта позиция вынужденная. В 90-е военные спасли эту архитектуру, и часть наработок принадлежит минобороны, и еще часть академии наук, в том числе и система команд. МЦСТ хотят открыть ее, но для этого ее нужно рассекретить, и опять-же по словам Шигорина военные довольно активно ведут работы по согласованию рассекречивания, более того тоже заинтересованны в раскрытии, а соответственно привлечении гражданских специалистов к работам. А вот с академией наук ситуация другая. Им пофиг откроют систему команд или нет, и шевелиться по этому вопросу они не хотят.
                                          0
                                          Кстати вот нашел на Ютубе что ядро они таки собирают свое, но с патчами от МЦСТ. youtu.be/Ky_MShm_qVc?t=1499
                                            0
                                            В Базальте сказали, что у них никогда не использовалась бинарная трансляция. Ни для каких частей
                                              0
                                              Лукавят. То что они пересобрали по под целевую архитектуру не значит что ПО не генерирует асемблерный код для х86. Они лишь частично портируют приложения по эльбрус, там где могут. Яркий пример php. Они его собрали, но не адаптировали, поэтому интерпретатор(а с новой версии и jit-компилятор) генерят х86 инструкции. И поэтому все ваши php скрипты будут исполняться в режиме бинарной трансляции.
                                                0
                                                ну, как говориться, мы сами не местные, в смысле не из базальта, за что купил за то продал.
                                                Цитата от Шигорина, которого Вы упоминали:
                                                у нас как раз отродясь e2k-alt-linux
                                          0
                                          Про бинарную трансляцию, тут обсуждать бесполезно.
                                          а также о совместимости с архитектурами ARM и MIPS в их 32- и 64-разрядных вариантах.

                                          Это по вашему тоже в бинарной трансляции сделано, ведь все из x86 собирается.
                                          В общем, Альт Это дистрибутив Линукс, полное название Alt-Linux. Если не догадались, то ядро там от МЦСТ, ну а прикладные пакеты уже собраны нативным компилятором.

                                          «Add deprecated kernel sources»
                                          Теперь понятно, спасибо. Ну я думаю, это не последняя версия ядра которую используют в МЦСТ, для ознакомления с архитектурной частью, вполне достаточно.
                                            0
                                            Это по вашему тоже в бинарной трансляции сделано, ведь все из x86 собирается.


                                            Это у ядра линукса из коробки есть и собирается из отдельных веток дерева ядра — kernel/arch/*. Ни о какой сборке x86 под ARM/MIPS речи тут нет.

                                            Если не догадались, то ядро там от МЦСТ, ну а прикладные пакеты уже собраны нативным компилятором.


                                            В чем отличие от ОС Эльбрус, если так?
                                              0
                                              В чем отличие от ОС Эльбрус, если так?

                                              ну приблизительно как дебиан отличается от альта.
                                              Да, выше правильно подмечено, что некоторые пакеты из репозитория Альта до сих пор не собираются, но насколько я знаю это не основные пакеты.
                                              По поводу текущего состояния и бинарной трансляции, спросил у сотрудника альта, который этим занимается.
                                                0
                                                В чем отличие от ОС Эльбрус, если так?

                                                Ну как минимум libc там точно отличается. Да и пакентый менеджер со всем содержимым репозитория тоже. ОС Эльбрус это дистрибутив который разрабатывался под нужды военных, там очень ограниченный набор ПО. Военным его хватает с головой, а вот для гражданского применения его уже не достаточно. Вот для этих целей и портируется Альт и Астра.
                                                  0
                                                  Не думаю, что без МЦСТшного glibc / libm есть жизнь на марсе. У них и memcpy()/… и вся математика сильно свои и на специфичных стероидах.

                                                  А по репозиторию и направленности вопрос понял. Думается, что у Альта с Астрой проблем по поддержке прибавится много.
                                                    0
                                                    Ну насколько я знаю у альт тоже есть свои наработки в libc, и видимо либо альтовцы вмержили свои изменения в libc от МЦСТ, либо МЦСТ предоставило свои патчи к ванильному libc. Тут я к сожалению не в курсе.
                                          0
                                          Смысл в том что теперь можно нагуглить ассемблерные команды для Эльбруса. И эту статью, где к ним еще есть текст на русском языке. Раньше это нагуглить было нельзя.

                                          Если автор продолжит серию статей, то нагуглить можно будет еще больше. Это и есть развитие отечественной инженерной культуры: а вдруг к имеющимся в России нескольким десяткам разработчиков ядра, которые понимают что в этих текстах написано, удастся вырастить еще одного. Это будет хорошо.

                                          Буду ждать продолжения.
                                  –1
                                  Ну вот не пойму. Два-три года назад у этого набора ещё была куча преимуществ. Сейчас любознательному школьнику проще купить какой-нибудь Orange Pi в N раз дешевле и безо всяких NDA, у которого на сегодняшний день обвязка и получше может быть. Если бы это уже было в каждой школе, была нормальная (да пусть и закрытая, но доступная всем) программная инфраструктура, если бы листинги программ печатались в условно бесплатных школьных и кружковых журналах, то глядишь и раскупали бы их как горячие пирожки. Замкнутый круг какой-то: дорогое, потому что мало продают, а мало продают потому что дорогое.
                                    0
                                    Не уверен, что я Вас правильно понял, но попытаюсь сформулировать.
                                    Да, проблема объема продаж первоочередная, но сравнивать с Распбери некоректно!
                                    Я считаю, что некорректно даже сравнивать с десктопами, ведь как я написал в статье, данная архитектура имеет ряд преимуществ в других сегментах. Если раздать школьникам, то это не решит проблему, а лишь увеличит затраты. На мой взгляд, следует искать рынок, причем в тех сферах где преимущества налицо (высокая производительность, обработка сигналов, обработка мультимедиа). Пока, к сожалению, есть сегмент госсектора, в котором используют как замену доверенному ПК, это важно, но все таки не расскрывает преимуществ.
                                      0
                                      Может тогда и ниши — нет? Вот пользуются же спросом всякие радиоконтроллеры от AD, которые стоят весьма некислых денег.
                                        0
                                        Думаю в нише как раз проблема. Она наверное есть, но в условиях нашей экономики не выгодно ее искать.
                                        Тут ведь, либо кто то вольет очень много частных денег (с соотвествующими рисками), либо государство. А как объяснить чиновнику, что делаем что то нужное. Ну сказать, что вот у него будет компьютер, такой как он привык, только наш отечественный.
                                          0
                                          Ну вот чем не выход — пропихивать через образование? Придётся потратить примерно сопоставимые суммы, примерно в такое же никуда, но в итоге получим массы молодёжи, которые знакомы с этой системой. Конечно, в работу их потом брать будут ничтожные доли процента, но даже этого может быть достаточно, чтобы эта же молодёжь потом нашла применение этим числодробилкам.

                                          Ну сказать, что вот у него будет компьютер, такой как он привык, только наш отечественный.
                                          В этом тоже загвоздка, не тянет оно на «такой же, только отечественный,» послабее в таких приложениях. Как некое embedded-решение, или для обучения сойдёт. А вот танчики на нём плохо запускаются, в госконторы массово не зайдёт.
                                            0
                                            Имхо странное решение. Мое видение что им нужно пробиваться на сервера. Вся их продукция кроме серверов уж очень дорогая, а сервера, с учетом довольно неплохой производительности последнего поколения процессоров(Эльбрус 8СВ), получаются сильно дешевле рынка. Сервера от HP или IBM сильно дороже. Плюс у них дорогая техподдержка. Поэтому на сервера можно пробиться из-за дешевизны. И к счастью в МЦСТ это понимают поэтому и занимаются портипованием языков программирования, субд и прочим.
                                              0
                                              согласен, в серверах данная архитектура вполне себе уместна.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Но оно хотя бы доступно для покупки без этого NDA. Можно под них собирать программы без NDA. И главное — стоит оно копейки.
                                          0
                                          ну тут тоже самое, когда покупаете, то можно собирать программы, просто например драйвера вы не сможете написать, а прикладные программы пожалуйста, есть компилятор входит в состав ПО насколько я знаю. Не уверен на счет внешнего репозитория пакетов, но думаю Альт его сделает, если уже не сделал.
                                            0
                                            Я вот не понимаю. Драйвера чего писать? Те, которые от вендора должны идти — зачем? Под собственную ОС — ну тогда мозгов и на реверс-инжиниринг может хватать. Для своих девайсов — я, конечно, в этом не понимаю ни грамма, но мне кажется, у линукса должен же быть какой-то HAL? И зачем авторы статьи подписывали NDA для получения бинарников компилятора? И если есть выбор покупать одно или другое с одинаковыми костылями по открытости, то не проще ли купить то, что дешевле и доступнее? Вот OrangePi я пошёл и купил на алишке за минуту, через неделю оно у меня в кармане. Где достать этот волшебный набор, когда на него не то чтобы магазинов нет, но и цен нигде не написано? Ну вот сходу совсем не нашёл.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                На OPi/RPi/Arduino я в Doom 3 сыграть не смогу, а на эльбрусе — вполне себе да.
                                                  0

                                                  Малина правда не тянет дум3 ?

                                                    0
                                                    FullHD? С нормальными текстурами? Или у малины вдруг вырос PCIe и дрова для AMDшных карт появились?
                                                    0
                                                    Ну да, Эльбрус как раз для Doom 3 :)
                                                      0
                                                      Ну в ключе вышеупомянутых вопросов дум3 какраз подходит =) А так можно ещё упомянуть СУБД и всякие расчёты белков.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое