LINUX.ORG.RU

Релиз встраиваемой системы реального времени Embox v0.4.0

 , , , ,


2

2

8 января 2020 года вышел релиз встраиваемой системы реального времени Embox v0.4.0.

  • Добавлена частичная поддержка архитектуры RISC-V
  • Добавлен ряд поддерживаемых платформ в том числе и Байкал-Т
  • Переработаны несколько подсистем (USB, FS, ..)
  • Добавлена подсистема MMC
  • Добавлен ряд драйверов

>>> Подробности

Ответ на: комментарий от anonymous

Я бы сказал, что это супер-монолит (возможно, ТС оспорит эту формулировку), но с возможностью гибкого конфигурирования исходников, что и составляет одну из главных фич проекта.

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Я бы сказал, что это супер-монолит (возможно, ТС оспорит эту формулировку), но с возможностью гибкого конфигурирования исходников, что и составляет одну из главных фич проекта.

Супер-монолит, прямо в точку не задумывались о подобной формулировке! Поясню, все (почти) задается на этапе сборки, отсюда экономия ресурсов и другие плюшки. В последнее время это прям лейб-мотив использования системы.

abondarev ()
Ответ на: комментарий от hobbit

в википедии пишут экзоядро (врут наверное, в википедии много врут). надо наверное будет поковыряться, это очень круто и очень интересно.

anonymous ()
Ответ на: комментарий от anonymous

надо наверное будет поковыряться

Будем рады помочь и ответить на вопросы. Есть русский телеграм https://t.me/embox_chat.

это очень круто и очень интересно

из наших достижений: Qt, OpenCV и VoIP phone на stm32f7 (http://embox.github.io)

abondarev ()
Ответ на: комментарий от anonymous

российские мобилки, роутеры или какое-то другое сетевое оборудование на этом может взлететь

Летает потихоньку, в мобилках нет, а сетевом оборудовании встречается, ну и других «специализированных» системах.

abondarev ()
Ответ на: комментарий от abondarev

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

P.S.

root@embox:/#uname -a
Embox localhost 0.3.3 Jan 10 2020 11:19:20 x86 unknown  Embox-OS

версию бампнуть не забыли?

anonymous ()
Ответ на: комментарий от abondarev

Супер-монолит, прямо в точку не задумывались о подобной формулировке!

Дело в том, что я когда-то вынашивал план написания чего-то подобного (как известно, почти каждый программист мечтал написать свою ОС). Тогда и формулировка появилась. Но узнав про Embox, понял, что это, видимо, оно.

Не самый плохой финал мечты, мог бы и в режим метапрога впасть…

hobbit ★★★★★ ()
Ответ на: комментарий от anonymous
Error: modules dependency cycle:
	embox.driver.tty.vterm_video
	embox.driver.tty.vterm
Error: modules dependency cycle:
	embox.driver.tty.vterm_video
	embox.driver.tty.vterm
Error: modules dependency cycle:
	embox.driver.tty.vterm_video
	embox.driver.tty.vterm
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
qconfig.cpp:20:155: error: too many decimal points in number
qconfig.cpp:20:155: error: expected ‘,’ or ‘;’ before numeric constant
qt 4.8.5
MBOX_GCC_LINK=full ./mk/extbld/arch-embox-gcc ./mk/extbld/toolchain_test.c -o ./build/base/obj/toolchain_test
/usr/bin/ld:./build/base/obj/mk/image.lds:5: ignoring invalid character `\033' in expression
/usr/bin/ld:./build/base/obj/mk/image.lds:5: syntax error
collect2: error: ld returned 1 exit status
make[4]: *** [mk/extbld/toolchain.mk:72: build/base/obj/toolchain_test] Error 1
make[3]: *** [mk/build.mk:24: build] Error 2
make[2]: *** [mk/load.mk:41: build] Error 2
make[1]: *** [mk/main.mk:30: build] Error 2
make: *** [Makefile:37: all] Error 2
(Unknown):: error: No abstract realization: embox.arch.vfork_entry.
make[4]: aarch64-elf-gcc: Command not found
...
$ aarch64-linux-gnu-gcc -v
gcc version 9.2.0 (GCC) 
...
make[4]: arm-none-eabi-gcc: Command not found
...
$ arm-none-eabi-gcc -v
gcc version 9.2.0 (Arch Repository) 
(Unknown):: error: No abstract realization: embox.arch.locore.

получилось собрать только x86/minimal версию, запустил, сижу уже 10 минут на строчке «booting from rom..».

SeaBIOS (version ?-20191223_100556-anatol)


iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FF928E0+0FEF28E0 CA00
                                                                               


Booting from ROM..

«загружается очень быстро, сеть работает, очень круто»

хоть бы проверяли перед тем, как людям показывать. а про qt 4.8.5 вообще прикола не понял, 2к2к-тый год на дворе

anonymous ()
Ответ на: комментарий от anonymous

оно уже близко к vxWorks?

Ну смотря по каким параметрам :)

По архитектуре и идеям оно отличается от VxWorks.

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

abondarev ()
Ответ на: комментарий от anonymous

хоть бы проверяли перед тем, как людям показывать.

Мне кажется, что Вы просто не разобрались. Выше кто то очень быстро и легко собрал и запустил. Собственно у нас на travis крутятся тесты в том числе и проверки основных темплейтов <arch>/qemu. Плюс еще на внутренних серверах на билдботе гоняем.

Версия Qt была осознано выбрана, мы делали работы для заказчиков у которых использовалась именно она. Сейчас действительно хотим запустить пятую, но это не принципиальный момент. Помните это не Linux, у проекта есть своя ниша.

Если все же интересно запустить, то выполните:

make confload-x86/qemu
make
./scripts/qemu/auto_qemu

а то на я не очень понял, что у Вас за беда с кросс-компиляторами. Почему на версию они выдают обычный gcc

P.S. На Arch-е проверяли все работает

abondarev ()
Последнее исправление: abondarev (всего исправлений: 5)
Ответ на: комментарий от hobbit

Дело в том, что я когда-то вынашивал план написания чего-то подобного (как известно, почти каждый программист мечтал написать свою ОС).

ну можно же не свою маленькую писать, а одну большую :) Присоединяйтесь, мы всегда рады новым идеям, к тому же идеи похожие, как Вы сами говорите!

abondarev ()
Ответ на: комментарий от Erepb

Корректно ли сравнение Embox vs QNX?

почему нет, но только нужно понять по каким параметрам сравнивать. Скорее всего мы выиграем по таким параметрам как минимально необходимая память, работа без MMU и так далее. Но QNX конечно более стабильный и отлаженный. Все таки коммерческий и популярный проект. Но с технической точки зрения где используется QNX везде можно использовать и Embox, конечно нужно будет доработать драйвера для платформ и так далее.

Мы в последнее время придумали термин Embox - Linux без Linux. То есть на данный момент нам видится ниша в тех местах где использование Linux по каким то причинам затруднено.

abondarev ()
Ответ на: комментарий от AlexVR

А как с потенциальной поддержкой чего-то типа NanoPi NEO2, или как всегда 64 бита не для RTOS?

Ну мы не совсем RTOS. Есть порт на Эльбрус (E2K) и aarch64 imx8 (там как раз упомянутый Вами ARM Cortex-A53), так что не вижу препятсвий уж по крайней мере в потенциальной поддержке. Тут скорее дело в целесообразности, для данной платформы нужна задача которую не может (или не очень хорошо) выполнить Linux.

abondarev ()
Ответ на: комментарий от abondarev

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

Задача уже классическая: скорость реакции на Ethernet пакет.

AlexVR ★★★★★ ()
Ответ на: комментарий от Uncle_Bobby

где используется QNX везде можно использовать и Embox, конечно нужно будет доработать драйвера

Т.е. использовать нельзя?

Странный вывод. Как раз можно! Embox уже имеет довольно большую базу драйверов. Если чего то не хватает, можно (прийдется) доработать. Но тут приимущества открытого проекта, можно и самим доработать или портировать из Linux, мы стараемся использовать близкое api для драйверов. А если нет в qnx, то прийдется ждать когда добавят и платить им за поддержку!

abondarev ()
Ответ на: комментарий от AlexVR

Задача уже классическая: скорость реакции на Ethernet пакет.

Тут как раз один заказчик тоже решает такую задачу, правда на платформе de0-nano-soc. при Linux с RT патчами задержка при передачи UDP пакетов туда обратно порядка 800 мкС при использовании Embox 100 мкС.

abondarev ()
Ответ на: комментарий от abondarev

Супер-монолит … с возможностью гибкого конфигурирования исходников, что и составляет одну из главных фич проекта

Где-то я это уже видел… В AUTOSAR, например.

anonymous ()
Ответ на: комментарий от anonymous

Где-то я это уже видел… В AUTOSAR, например.

Ну идея конфигурироемости конечно не нова, есть eCos (Embedded Configurable Operating System). Конфигурируемость прямо в названии.

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

abondarev ()
Ответ на: комментарий от abondarev

Поэтому есть еще довольно много нелепых багов, детская болезнь.

То есть формальную верификацию кода проводить не планируете? Ну понятно что не всего, но хотя бы ядра и основных библиотек…

anonymous ()
Ответ на: комментарий от anonymous

То есть формальную верификацию кода проводить не планируете?

Пока верификации, сертафикации и так далее, делались конечными заказчиками. У нас были (и есть) исследования по формальной верификации, но они имеют скорее научный интерес.

abondarev ()
Ответ на: комментарий от abondarev

У нас были (и есть) исследования по формальной верификации, но они имеют скорее научный интерес.

То есть может и будет, но потом… Ну чтож - хоть так… Но без этого - не понимаю где ее можно реально использовать кроме «игрушечных» применения, а-ля IoT

anonymous ()
Ответ на: комментарий от anonymous

Но без этого - не понимаю где ее можно реально использовать кроме «игрушечных» применения, а-ля IoT

А мы точно говорим о формальной верификации? Просто о формально верифицированном ядре у seL4 можно долго спорить.

Цитата из википедии

В 2009 году было завершено доказательство корректности кода микроядра seL4. Существование доказательства гарантировало соответствие реализации и спецификации, подтверждало отсутствие в реализации некоторых ошибок (например, отсутствие взаимных блокировок, livelocks, переполнений буферов, арифметических исключений и случаев использования неинициализированных переменных).

То есть доказано соотвествие спецификации, но кто сказал, что спецификация корректна.

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

abondarev ()
Ответ на: комментарий от anonymous

Корректно ли сравнение Embox vs QNX?

Корректно, но нечестно… по отношению к Embox. :)

ну почему же сразу по отношению к Embox :) Все таки зависит от задачи, в некоторых задачах у нас есть преимущества. ;)

abondarev ()
Ответ на: комментарий от anarquista

вот именно это интересно, RTOS или просто маленькая операционка? какие RT-планировщики есть? может быть, какие-то lock-free ipc в самом ядре?

да, в оригинальном вопросе речь шла о маленькой операционке (RTOS) скорее для микроконтроллеров, поскольку говорилось про 64 битные архитектуры.

На Ваш вопрос очень сложно ответить однозначно, по крайней мере коротко. Попробую коротко, но неоднозначно.

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

lock-free ipc в самом ядре

Стараемся добавлять по максимому все возможные варианты, конечно используемые, очереди сообщений и различные средства коммуникации в том числе. Обычно это posix API, но могут быть и варианты. В любом случае, предоставляем разработчику максимальный контроль за системой.

abondarev ()

Круто. Завидую людям, которые в этом секут настолько, что даже пишут такие оси. А работа со звуком там возможна? Вот бы портанули бы faust на embox, или csound какойнить, а сверху навернуть гитароэмуль curufinwe'а на какомнить синглборде... Мммм... Кросотааа...

ChekPuk ()
Ответ на: комментарий от abondarev

Вот о сертификации конечной системы я и говорил. Но это очень дорого, и не понятно кому нужно.

В первую очередь тем, кто захочет прикрыть свой... э... тыл.

Erepb ★★★ ()
Ответ на: комментарий от ChekPuk

Круто. Завидую людям, которые в этом секут настолько, что даже пишут такие оси.

Спасибо!

А работа со звуком там возможна?

Да, VoIP телефон, на базе pjsip работает, то есть ввод и вывод.

Вот бы портанули бы faust на embox, или csound какойнить, а сверху навернуть гитароэмуль curufinwe’а на какомнить синглборде… Мммм… Кросотааа…

Ну это задача не из простых :) В принципе в качестве api звуковой либы используется portaudio, это существенно упрощает затаскивание софта высокого уровня, но пока очень мало звуковух поддержано. К тому же могут быть всякие проблемы с многоканальностью и так далее. Но в принципе задача интересная, сами что нибудь подобное хотели сделать, просто руки пока не доходят :)

abondarev ()
Ответ на: комментарий от Erepb

В первую очередь тем, кто захочет прикрыть свой… э… тыл.

А тогда понятно. :)

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

abondarev ()
Ответ на: комментарий от ChekPuk

Завидую людям, которые в этом секут настолько, что даже пишут такие оси.

кстати, есть такая цитата, в фильме Брилиантовая рука, если не ошибаюсь

Каждый человек способен на многое. Но, к сожалению, не каждый знает, на что он способен

я к тому, что может стоит попробовать, и окажется что не так страшен черт как его малюют :)

У нас студенты разбираются, для начала помогаем конечно.

abondarev ()
Ответ на: комментарий от abondarev

Вот звук… не очень интересен. :)

Гораздо более интересен сетевой стек и внезапно - подсистема хранения. Возможно на нем реализовывать аналоги OpenWRT/pfsense, желательно с интерфейсом на основе CLISH или скажем ESOS…

anonymous ()
Ответ на: комментарий от abondarev

Поэтому мы говорим, что система сертифицируемая, а не сертифицированная

Понимаю, что денег мало... А вы есть, хотя бы, в реестре отечественного ПО (не хочу лезть туда с поисками)?

Erepb ★★★ ()

ребят, подскажите пожалуйста, что это такое? и для чего оно?

почему такое название? разве это не просто очередная ОС?

anonymous ()
Ответ на: комментарий от ChekPuk

Я собираюсь портануть на DSP без ОС, тем более что железо я давно приобрел. Думаю это эффективнее, т. к. эти DSP прямо предназначены для обработки звука и обеспечивают минимально возможные задержки. К тому же очень просто программируются в графической среде соединением блочков.

curufinwe ★★★★★ ()
Ответ на: комментарий от abondarev

Мне кажется, что Вы просто не разобрались.

как ты себе представляешь ситуацию «не разобрался в двух нерабочих командах»? типа ctrl+c ctrl+v не осилил?

Выше кто то очень быстро и легко собрал и запустил

а, ну тогда ладно. тогда у меня всё быстро и легко работает

Версия Qt была осознано выбрана

а я думал, кубики кидали. какие выпадут, такая и версия

для заказчиков у которых использовалась именно она

они не нужны, как и qt 4.8.5

Если все же интересно запустить, то выполните: …

а я вместо этого vim запускал, наверное, или /dev/random grep-ал, да?

а то на я не очень понял, что у Вас за беда с кросс-компиляторами

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

Почему на версию они выдают обычный gcc

они выдают свою версию, а не «обычный gcc»

P.S. На Arch-е проверяли все работает

я проверил - не работает. будем и дальше втупую повторять, что всё работает? ошибки я сам придумал и руками нарисовал? детский сад, ей богу

anonymous ()