Операционная система МЯОС

[БудДен]

Операционная система МЯОС - это будущий перевод подобранной на помойке и восстановленной Minos. Minos/МЯОС вчера (уже сегодня) удалось запустить - в том плане, что печатается трассировка и крутится планировщик задач. Теперь остались следующие действия:

* ✓ сделать две задачи, чтобы посмотреть, что работает не только планировщик, но и механизм задач вообще
* - (оно не работает) не упираясь сильно, попробовать не только получать информацию из системы по UART, но и передавать её в систему. На данный момент эмулятор не реагирует на нажатия клавиш, хотя в нештатном режиме реагировал, понятно, как туда вернуться. Возможно дело в том, что есть два UART, и происходит переключение на второй из них.
* встроить в конфигурацию - сейчас Мяос живёт как бес, вселившийся в тело ZbL и поэтому ЯОС для Zybo в текущем состоянии запустить нельзя. Видимо, это решается добавлением строчки в файл ConfigConsts.Mod, который генерируется в ходе сборки.
* перевести в русскоязычную ветку, чтобы Мяос была частью русскоязычной, а не англоязычной ветки
* записать симпатичное видео

Отдельной задачей является переход на 8-битную кодировку. Есть сведения, что можно настроить и qemu (за счёт настройки терминала), и putty на поддержку 8-битных кодировок. Могут возникнуть проблемы с моими доп.значками, значит, придётся их выкинуть из общей кодовой базы для МЯОС и ЯОС (это модули логирования, потоков, работы со строками), либо их надо представить значками, присутствующими в 8-битной кодировке.

[БудДен]

Вот бумага про Minos, которая описывает, что вообще это такое. Исходные тексты самой МЯОС будут доступны не раньше перевода в русскоязычную ветку.

[БудДен]

https://xilinx-wiki.atlassian.net/wiki/ ... umentation - здесь описана QEMU (пытаюсь понять, в чём дело с отсутствием приёма клавиш).

[БудДен]

По поводу лога и UART - там всё достаточно странно. Похоже, что вовсю используется передача бинарных данных. Байты пишутся и читаются
из потока. Завершающий символ для чтения команды имеет код 0, а признаки начала команды - это коды 16 и 17.

Вероятно, стоит поменять это, чтобы оно было текстовым - мы же тут балуемся просто.

Но потом будет ещё две проблемы:

* лог отстаёт
* фоновые задачи явно перестают выполняться, когда "система окончательно запускается" - а до этого момента работают себе.

[БудДен]

MinOs.HAL.Zynq.Platform.Mos - TimerPeriod
MinOs.HAL.Zynq.Interrupts.Mos - Delay

они явно должны быть как-то взаимосвязаны, не?

[БудДен]

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


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

Т.е. это опять сначала gdb, потом gdb+qemu, чтение документации, адские непонятные понятия и всё вот это, чем я не хочу заниматься. Жаль, конечно, так оставлять, но похоже, что придётся. В этом случае наверное даже прятать англоязычные исходники нет причины, было бы что прятать.

Но понятно, что тут уже заноза засела и так просто не отпустит.

[БудДен]

Ещё возможность - сломан обработчик трапов и поэтому я не вижу проблемы. Попробую отключить. Итак, два пункт:

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

[БудДен]

Фоновые задачи не повреждены и мы не находимся в await.

[БудДен]

Действуем по мотивам https://tvoygit.ru/budden/jaos/src/bran ... erry-pi.md , но у нас ubuntu 18, поэтому:

Код: Выделить всё

sudo apt install gdb-multiarch
gdb-multiarch -tui --command=commands.gdb

Сделал три процедуры Break1, Break2, Break3. Их адреса печатает
сама программа при загрузке, и они одинаковы в разных сессиях.
Далее просто ставим b *0xADRES

Код: Выделить всё

p/x $lr - куда вернёмся
tb *$lr - "беги до возврата" для бедного человека

[БудДен]

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

[БудДен]

Пытался разобраться, где есть адреса процедур. В линкере их нет, в компиляторе не разобрался. Остаётся лишь печатать их из самой программы, как мы сделали с Break1, ... BreakN. А касаемо того, куда девается управление, разобраться сначала на уровне модулей.

Итак, сейчас у нас такой эксперимент:

1) печатаем адрес ExecuteBgTask и того, что перед ним.
2) Будем дважды запускать, чтобы можно было поставить брекпойнт, если надо
3) Ставим break2 внутри прерывания UART и смотрим, куда управление в итоге передаётся. Ы?

[БудДен]

Код: Выделить всё

Device.Break1 = *0x1EA1C320 
Device.Break2 = *0x1EA1C348 
Device.Break3 = *0x1EA1C370

Код: Выделить всё

Uart.PSUartIrqHandler = *0x1EA1F9E4 
Uart.SetBaudrate = *0x1EA1FB20
Minos.Scheduler = *0x1EA27D00 
Minos.NullScheduler = *0x1EA28134 
Minos.StartSync = *0x1EA28B08 
Minos.StopSync = *0x1EA28B48 
Minos.ExecuteBGTasks = *0x1EA28B88 
Minos.GetParam = *0x1EA28CF0 

[БудДен]

Похоже, что после нажатия Ctrl-C в gdb разум временно возвращается к Мяосу и он возвращается в цикл выполнения ExecuteBGTasks, но потом, с какого-то момента, он опять проваливается в прерывание и больше уже не возвращается в ExecuteBGTasks. Если нажать опять на Ctrl-C, то опять вернётся в ExecuteBGTasks. Чудной он.

[БудДен]

Код: Выделить всё

target remote localhost:1234
layout asm
set $ab1 = 0x1EA1C320 
set $ab2 = 0x1EA1C348 
set $ab3 = 0x1EA1C370
b *$ab1
commands 1
printf "b1:"
p/x $lr
printf " "
c
end
b *$ab2
commands 2
printf "b2:"
p/x $lr
printf " "
c
end
b *$ab3
commands 3
printf "b3:"
p/x $lr
printf " "
c
end

Делаем, чтобы при каждой из нашех точек останова выполнение продолжалось. Правда, gdb не даёт простыне литься, а заставляет листать, но это переживаемо.

Здесь три переменных в начале - это то, что наша программа печатает в качестве адресов процедур Break1, Break2, Break3 - а дальше нужно их вставить в интересные места.

[БудДен]

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

https://support.xilinx.com/s/question/0 ... uage=en_US

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

Далее, вот тут пишут:

https://support.xilinx.com/s/article/54 ... uage=en_US

Nested Interrupts is currently supported in the GIC Interrupt Controller on the Zynq SoC in version 2013.4/14.7. If you are using this version, then proceed to step 3.

If you are using an older version and would like to add nested interrupt capability, then unzip the ZIP file that is attached at the end of this answer record) into your local EDK install directory:

А вот что говорит ChatGPT:

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

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

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

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

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

Осталось ещё посмотреть на ZbL.

[БудДен]

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

[БудДен]

Что можно было бы сделать? Например, написать планировщик, описанный в бумаге. Хотя не совсем ясно, как могут прерываться задачи на одном и том же стеке иным способом, как через прерывание таймера. Значит, получается, нужно по стеку на каждый приоритет.

Нужно ещё учесть, что Minos не запускается на обычном процессоре. Там специализированный процессор, загружаемый в FPGA:

The FPGA implementation [6] features a CPU,
synthesised from a standard (non fault tolerant) ARM7TDMI
IP core by Actel, a fault tolerant main memory (RAM) and a
fault tolerant ROM.

Поэтому в общем-то никто (наверное) и не обещал, что он будет так же работать на обычном ARM-процессоре в SoC цинка.

[БудДен]

Вот ещё один подобный страдалец:

https://stackoverflow.com/questions/233 ... ing-in-arm

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

И кстати я вчера похоже перепутал - в вопросах по Xilinx речь может идти не про армовскую
часть процессора, а про армовские процессоры, запихиваемые в ПЛИС, аналогично тому, как сделана сама Minos.