RP/M - годится название для операционки?

[vak]

Мысль у меня бродит.

Ко мне периодически обращаются, спрашивают, как бы приспособить RetroBSD для нынешних микроконтроллеров. Я сам давно задался вопросом, только маленько ширшее. Ясно, что идея юникса не годится (потом объясню), но вероятно её можно как-то изменить, приладить к реалиям современных чипов. И натолкнул меня на мысль тот самый компьютер Агонь Лайт, точнее его операционка MOS. Глянул я исходники - фактически народ удачно сваял с нуля подобие CP/M. Нашёл я и клон CP/M, перепёртый кем-то на Си для прикола (x86_cpm_22_0_1.zip). Внезапно осознал, что это оно самое и есть. Ну то есть почти. Реализация бог с ней, а основополагающая идея правильная. Однозадачная операционка по типу CP/M или MS-DOS с поддержкой файловой системы. Но без исторических кривостей и странностей. Ровно то, что по сути хотят сторонники RetroBSD. Пусть всего одна задача, зато с файловой системой, динамическим загрузчиком, загружаемыми драйверами, подключением к сети (отдельный интересный вопрос).

Для конкретики покажу платку, которую я подобрал для такой разработки.



Плата называется Sparkfun Thing Plus RP2040. Тот же процессор, что и Raspberry Pico: два ядра Cortex M0+. Пока задействуем одно ядро, а второе позже пригодится для стека TCP/IP. Имеем 256 килобайт оперативной памяти, 128 мегабайт Flash-памяти и гнездо для внешней SD-карточки.

Представьте, что вы подключаете платку через USB к компьютеру, открываете окошко доступа к консоли (виртуальному или физическому серийному порту) и видите знакомое приглашение:

c:/> _

Диск С: находится в Flash-памяти микроконтроллера. Дальше стандартными командами DIR, CD и прочими бродите по диску и запускаете с него нужные программы. На внешней SD-карточке лежит диск A:. К нему тоже можно обращаться, переписывать файлы туда-сюда, вызывать программы. Активировать и деактивировать загружаемые драйвера. Создавать и запускать BAT-файлы, то есть скрипты. Редактировать и компилировать программы из исходников. Скачивать файлы из интернета, или наоборот, посылать в интернет.

Система должна получиться более-менее переносимой. На этой платке свет клином не сошёлся, да и на микроконтроллере тоже. Два основных требования к процессору: размер RAM хотя бы в несколько десятков килобайт, и Flash-память, прямо отображаемая на адресное пространство процессора.

Как всё это будет фунциклировать - уточню позже, а пока перечислю основные компоненты:

• Командная оболочка, аналог /bin/sh в юниксе или cmd.exe в Windows.
• Файловая система exFAT.
• Набор системных вызовов, видимо подобие Posix.
• Динамический загрузчик, для связывания адресов в момент запуска программ.
• Механизм загружаемых драйверов.

Самый трудный вопрос: название. Пока лучшее, что пришло в голову - RP/M.

Comments

[iyak2]

Интересно, а чем не годится идея Unix для данной платки? Если это Гарвардская архитектура, то вряд ли это будет помехой. Есть идея такая, кратко. Например, с Flash-диска исполняем файл, .text процесса никуда в SRAM не загружается, сейчас .text'у достаточно readonly еще со времен PDP-11, самомодифицируемый нужен был только в PDP-7(9) из-за особенности архитектуры. Косвенную блочность для файлов не используем, используем только монолитные contiguous file. Для секций .data, .bss каждого процесса выделяем необходимую память(фиксированную или динамически изменяемую) - своп область в SRAM. Сколько процессов - столько и своп областей. Как минимум 3,к примеру, в UnixV1 их было 16, только на диске, правда. Создаем там же, в SRAM, еще одну область для .data, .bss, для текущего выполняемого процесса. Ясно, что она должна быть больше или равна любой своп области процессов. По итогу, Unix, мультизадачность,(мир, жевачка))и железное НЕТ деградации Flash-памяти свопингом! Классно, стильно, молодежно! В отличии от многих RTOS, программы можно компилировать отдельно от самой ОС, по идеи, т.к. .data,.bss не привязаны к разным участкам памяти, переключение задач честное.
Да, опционально для экономии памяти, кое-что нужно сделать с .data. При загрузке (exec) исполняемого файла изменяемые данные .data продублировать в своп область. А константными программа будет оперировать с Flash. Для такой особенности нужно немного переписать Си, как кажется. Кому-то далеко до этого. Но если закончить разбираться с ar+ld+as+stip, то может за полгода или год до Си, возможно, сначало изучив Би, вполне добраться. И ничего лучшего, чем понять и простить и портировать, наверное, нет (для усвоения материала).

P.S. Сам такое сделал бы давно, но, увы, с 2018 узнал(диагностировали), что давненько хожу с так называемым орфанным недугом. Вот-то оно и работается мне не очень, не более 1-2 часа в день. Делаю все как получается. А как хотелось рыбки вездесущего Unix для микроконтроллеров!!!

[vak]

Юникс для таких процессоров я уже делал. Для PIC32 с архитектурой MIPS есть RetroBSD: https://github.com/RetroBSD/retrobsd/wiki

Недавно его затащили на ARM Cortex-M4 под названием DiscoBSD: https://github.com/chettrick/discobsd

Но как-то Юникс не приживается. Есть несколько причин.

1. Для Юникса требуется место для swap, а его нету. Без swap не реализуется основополагающий механизм создания процессов fork(). Хотя бы два мегабайта нужно для RetroBSD. Приходится создавать специальный раздел на SD-карточке. В результате без SD-карточки ядро вовсе не может стартовать.

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

3. Доступ к периферии микроконтроллера из юниксного процесса весьма затруднённый. Условно говоря, под каждый чих приходится драйвер писать. Просто так из программы ножками GPIO не подёргаешь.

Многозадачность как раз для народа некритична. Думаю, что подобие CP/M или PC-DOS подошло бы лучше.

[iyak2]

С первым пунктом согласен, с оговоркой, что все-таки с более примитивными Юниксами может что-то получится, и fork, и swap, хотя его возможностей маловато по нынешним меркам. Уже такое делали: https://github.com/MicrochipTech/avrfreaks-projects/tree/main/projects/phoenixu1-porting-unix-v1-atmega-8-bit
Про него в первом посте и писал, в общем-то.

Насчет второго, не знаю, полезная инфа или нет, но было вот такое: https://ru.wikipedia.org/wiki/UMSDOS
Насколько возможно отображать Юникс filesystem на FAT? Это вопрос.

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

Я когда в немного в истории железа копался, часто натыкался, на непростую генеологическую линию аэсок, много слухов ходит, якобы CP/M это есть как бы упрощенная RT-11, созданная Килдалом, а MSDOS это такоЕ некое творение Франкенштейна, все что смогли заимствовать сначала с CP/M, а потом Xenix, по частям.

А назвать аэску можно Microcontroller Control Program(MCP), по приколу, это во-первых напоминает CP/M, буквы переставлены немного, а во-вторых напоминает главпрограмму из фильма TRON. То же есть кому-то чо вспомнить.