Комментарии 25
А почему не взяли tianocore edk2? С его помощью приложения и загрузчики, в том числе многопоточные - пишутся на раз два.
Написание ОС с нуля: ...
Ну а за ссылку спасибо, может из исходников тиана че-нидь таки возьму
Написание ОС с нуля уже не получается - так как UEFI уже сделал первоначальную настройку железа, запустил АР-ядра (все кроме первого) и перевел процессор в защищенный режим, сильно упростив задачу будущему ядру.
как минимум из tiano можно взять API доступа к возможностям самой uefi.
тогда в таком случае написание ОС с нуля не получилось бы и при legacy boot - ведь BIOS уже сделал первоначальную настройку и тестирование железа, настроил прерывания и сегментные регистры. Не спорю, Legacy boot требует больше кода, но по вашей логике это тогда тоже не с нуля.
По моему личному мнению - ОС это в первую очередь скедулер, а не работа с железом. Но да, Uefi сделал сильно больше legacy boot и отнял часть работы программиста, что даже хорошо :)
Впрочем статья не столько про ОС с нуля, а про ОС на ассемблер с нуля, так что снимаю шляпу в любом случае - Мне пришлось однажды написать многопоточное приложение, которое должно захватывать процессор в realmode, подменить таблицы прерываний и нагрузить все ядра синтетикой. Вроде и код получился простым, но проштудировать SDM пришлось знатно
Надо же :) Впрочем, я сейчас работаю над следующей частью - планирую сделать некое подобие DOS Shell, только на свой лад, потом сделать автозагрузку сценария из boot.sh, выйдет, по-моему, неплохо. Однако проблема в том, что UEFI, TianoCore и EDKII рассчитаны на язык С, и мне сложно "добывать" информацию под ассемблер. Что ж, сейчас пытаюсь написать макро, который в цикле сканирует клавишу пока не встретит CRLF. Звучит просто, а с проблемой этой уже весь день сижу, аж стыдно :_)
Сделайте лучше подобие posix shell, не надо dos
UEFI FORTH
есть 2 вот таких проекта:
https://github.com/mak4444/gnu-efi-code-forth
https://github.com/c2d7fa/jonasforth
но мне показалось, что оба сыроваты
Интересно как это будет выглядит для одноплатников типа raspberry pi
Честно, мне тоже, но у меня малинки нету `\_(^-^)_/`
Там ARM, вроде всё проще. При запуске процессор переходит по адресу, лежащему в 0x0 - и поехали, дальше фантазия ограничена только упоротостью SoC и периферии.
C большой степенью вероятности там будет uboot - https://github.com/u-boot/u-boot
Можно посмотреть на примере kolibri os. Тоже написано на ассемблере.
С выходом первого Raspberry Pi появился обучающий туториал про разработку ОС от Кембриджского университета. Если коротко, то чтобы выдать даже банальное "Hello world!", потребуется сначала нарисовать шрифты.
в долгом режиме
В «длинном» тогда уж.
Насколько я понимаю, long mode так назван по аналогии с типом данных long в Cи.
Только не Secure Boot, а просто EFI boot, потому что первое - это про то, что собранный загрузчик подписан, и его подпись EFI-совместимая прошивка проверяет до того, как передаст управление на его точку входа.
Не совсем понятно, зачем тут ассемблер, кроме как "захотелось вот на ассемблере", потому что все, что тут на ассемблере написано - это переопределения типов данных из С, части структур из Extended Firmware Interface тоже из С, и вызов функций с интерфейсом MS x64 ABI.
Выучите лучше С, намного легче станет писать что-то сложнее хелловорлдов, а ассемблер оставьте для задач, которые на С либо решаются плохо (мужики из coreboot'а в свое время ROMCC не от хорошей жизни написали), либо не решаются совсем. Ссылку на EDK2 и TianoCore уже сверху давали.
ищет диски с известными файловыми системами (ntfs, brtfs, extFAT, FAT32, isofs, cdfs, ext2/3/4, есть ещё, но это уже опционально)
ЭТО не точно, по спецификации ищется специальный загрузочный, имеющий специальный идентификатор UEFI раздел FAT32. И уже на этом разделе в каталоге файл. Правда спецификация не запрещает дополнительно исползовать другие фс, что многие производители и делают-включают драйвера ntfs и exfat. (и исключительно редко ext4).
ОС с нуля: Глава 2, Часть 1 — Да зачем нам этот Legacy