jcmvbkbc

Как узнать, какой адрес этих регистров уже после инициализации устройств и загрузки ОС?

Физический адрес -- как и написано в dts: 0xfe600000. Виртуальный адрес -- какой-то сравнительно случайный, выделенный вызовом ioremap() или какой-нибудь его обёрткой. Если драйверу нужен доступ к регистрам -- драйвер просто вызывает ioremap() сам и получает адрес. Если доступ нужен в юзерспейсе -- можно (при наличии разрешений) сделать mmap() файлу /dev/mem по смещению равному физическому адресу устройства.

Или обратная задача: есть процесс, который пишет в некоторую область памяти, как узнать, возможно, это какие-то регистры SOM

Сделать cat /proc/<pid>/maps и посмотреть, что отображено в эту область виртуальных адресов.

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

// Получаю ошибку:
7FFF0000: The instruction at 0x7FFF0000 referenced memory at 0x7FFF0000. The memory could not be executed -> 7FFF0000 (exc.code c0000005, tid 6332)

В чем проблема?

По видимому в том, что вызвать функцию получилось, но память по адресу 7FFF0000 -- не исполняемая.

Как починить?

Начать с того, что сделать память по адресу 7FFF0000 исполняемой. После этого вывод в лог должен заработать, но будет падать после него, потому что функция mySuperFunction не возвращается.

Почему ОС не запускается на Virtual box, а на QEMU запускаеться?

Потому что QEMU TCG не очень точно эмулирует x86. Если в командную строку qemu добавить -enable-kvm, то оно тоже не будет работать.

А вот если добавить ret в реализацию GDT::load_gdt() и не вызывать load_tss() то оно начинает в qemu-kvm работать:

diff --git a/src/GDT/GDT_impl.s b/src/GDT/GDT_impl.s
index 4f69835abd9d..5476837f3d0a 100644
--- a/src/GDT/GDT_impl.s
+++ b/src/GDT/GDT_impl.s
@@ -2,6 +2,7 @@
 .extern _ZN8SimpleOS3GDT7gdt_ptrE
 _ZN8SimpleOS3GDT8load_gdtEv:
        lgdt _ZN8SimpleOS3GDT7gdt_ptrE
+       ret
 
 .global _ZN8SimpleOS3GDT8load_tssEv
 _ZN8SimpleOS3GDT8load_tssEv:

Подозреваю, что и в virtual box оно заработает.
Проблема в загрузке TSS, короче. Мне не знакомы дебри TSS, но для поверхностного взгляда кажется странным то, что все сегментные селекторы в твоём TSS имеют RPL=3, а селектор стека -- RPL=0.
Если ты хочешь разбираться с тем, что происходит, то разумно было бы поменять порядок инициализации, сначала загрузить IDT, чтобы иметь возможность обрабатывать исключения, а потом загружать TSS и смотреть, что за исключение эта операция выкидывает.
С другой стороны, непонятно зачем в текущей версии этой ОС нужен TSS. Подозреваю, что никакая функциональность не будет потеряна, если его не загружать.

Без всякого деления можно понять, что 2^32 / (4 * 2^10) = 2^(32 - 12) = 2^20, а если запомнить, что 2^10 -- это "двоичная тысяча" (1024), а 2^20 -- соответственно "двоичный миллион" (1024^2), то жизнь заметно упрощается.

кода я не нашел, или плохо искал

вот код из glibc.

через ряд тейлора не вариант при больших значениях угла ряд медленно сходится

В приведённой реализации сначала аргумент приводится к диапазону ±pi/2, потом берётся фиксированное число слагаемых ряда тейлора.

ругается на g++ -I $(INCL) $(SRCS) -o $(TARGET), как можно исправить?

Заменить пробелы в начале строки одним табом. Команды в makefile начинаются с табов.

В чем может быть проблема?

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

Вот эта структура:

struct IDTPtr {
    uint16_t limit;
    uint32_t base;
};

должна быть определена с атрибутом packed, иначе компилятор вставляет паддинг для выравнивания поля base на границу uint32_t, из-за чего в IDT загружается неверный адрес.

Ну и, вдобавок, нельзя делать iret из середины с++-функции, потому что компилятор организовал в ней кадр стека и вместо возврата iret снимает и интерпретирует мусор из этого кадра:

001000e6 <SimpleOS::IDT::dividing_by_zero()>:
  1000e6:       55                      push   %ebp
  1000e7:       89 e5                   mov    %esp,%ebp
  1000e9:       53                      push   %ebx
  1000ea:       83 ec 04                sub    $0x4,%esp
  1000ed:       e8 15 01 00 00          call   100207 <__x86.get_pc_thunk.ax>
  1000f2:       05 06 11 00 00          add    $0x1106,%eax
  1000f7:       83 ec 0c                sub    $0xc,%esp
  1000fa:       8d 90 08 fe ff ff       lea    -0x1f8(%eax),%edx
  100100:       52                      push   %edx
  100101:       89 c3                   mov    %eax,%ebx
  100103:       e8 4c 00 00 00          call   100154 <SimpleOS::Terminal::print(char const*)>
  100108:       83 c4 10                add    $0x10,%esp
  10010b:       fa                      cli
  10010c:       cf                      iret
  10010d:       90                      nop
  10010e:       8b 5d fc                mov    -0x4(%ebp),%ebx
  100111:       c9                      leave
  100112:       c3                      ret

Нужны подробности сборки. Согласно спецификации заголовок multiboot должен быть в пределах 8192 байт от начала, но если в сборку не подсовывать никаких дополнительных ключей и потом пытаться загружать elf-файл, то в нём multiboot header может оказаться дальше 8К от начала:

$ gcc -m32 boot.s -nodefaultlibs -nostartfiles -Wl,-Tlinker.ld -no-pie -o boot.elf
$ readelf -S boot.elf
There are 8 section headers, starting at offset 0x3140:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.gnu.bu[...] NOTE            00100000 001000 000024 00   A  0   0  4
  [ 2] .multiboot        PROGBITS        00101000 003000 00000c 00      0   0 4096
  [ 3] .text             PROGBITS        00102000 002000 000009 00  AX  0   0 4096
  [ 4] .bss              NOBITS          00103000 003000 004000 00  WA  0   0 4096
  [ 5] .symtab           SYMTAB          00000000 00300c 0000a0 10      6   9  4
  [ 6] .strtab           STRTAB          00000000 0030ac 00004d 00      0   0  1
  [ 7] .shstrtab         STRTAB          00000000 0030f9 000044 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

При такой сборке секция .multiboot оказалась по смещению 0x3000.

Сигналы доходят до меги, но она не включает ни один из светиков.

Я бы начал с отладки простым безусловным включением led на старте программы. Потому что 1К резистор последовательно со светодиодом с падением в 2В ограничивает ток 3ма, чего, скорее всего, недостаточно для заметного свечения.

Если записать вывод данных в файл
# /opt/speedtest/speedtest | tee spdt.log
то в файле не видно промежуточных значений значений.

Дело в том, что консольная программа может определить, направлен ли её вывод в терминал или в файл, и вести себя по разному, в зависимости от этого. Понаблюдать, что и как именно программа выводит можно запустив её под strace, например так:

strace -f -e ioctl,write -o log <program command line>

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

Что это значит

подозреваю, что вот эта часть: ���`�B��Χh� �l<*�� !����� -- это вывод скетча на 9600. Откуда LoadProhibited -- непонятно.

можно ли это как-то исправить?

только разобравшись, что происходит. idf.py monitor обычно декодирует стек трейс и выводит соответствующие строчки исходников, можно начать отсюда.

Для выхода из вложенных циклов при try/catch в случае исключения произойдёт свертка стека

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

будет ли тоже самое для goto?

То же самое будет и для goto.

movw $0x4F02, %ax
movb $0x03, %bl
int $0x10

в bh остался мусор, а этот вызов принимает аргумент в bx.

как это сделать вместе?

Повесить второе SPI-устройство на отдельную линию CS. Я вижу, что сигнал U2RXD с разъёма P1 можно для этого использовать, если речь об этом модуле.