Комментарии 73
"Каждый такой регистр имеет 16 бит в ширину и 2 байта в длину."
Это как?
Про линковщик в примере на C:
слова «входной» и «выходной» надо бы поменять местами.
• test.elf: имя входного файла (соответствующий платформе формат хранения исполняемых файлов. Windows: PE, Linux: ELF)
• -o: генерация объектного кода.
• test.o: имя выходного файла объектного кода.
слова «входной» и «выходной» надо бы поменять местами.
НЛО прилетело и опубликовало эту надпись здесь
Это помешает восприятию статьи, так как это совершенно о другом.
НЛО прилетело и опубликовало эту надпись здесь
поправка:
классическая таблица разделов содержит в себе величины DWORD для описания смещений и длин разделов в секторах. 32 бита без знака позволяют описать от 0 до 4 294 967 295 секторов
При размере сектора 512 байт — это будет ровненько 2ТБ
беря в расчет менее привычные случаи, например сектор 4096 байт, получим поддерживаемую емкость в 16ТБ.
А MBR не покрывает более 1Tb диска.
классическая таблица разделов содержит в себе величины DWORD для описания смещений и длин разделов в секторах. 32 бита без знака позволяют описать от 0 до 4 294 967 295 секторов
При размере сектора 512 байт — это будет ровненько 2ТБ
беря в расчет менее привычные случаи, например сектор 4096 байт, получим поддерживаемую емкость в 16ТБ.
И кстати, на для рисования на x86 намаплен фреймбуфер начиная с адреса 0xA0000.
Крайне любопытно, не покидаете ссылочек что почитать?
НЛО прилетело и опубликовало эту надпись здесь
О нет, очередная, стопицотая (даже на хабре) статья о том, как написать загрузчик для legacy-режима. Да его поддержку уже выпилить собираются из новых материнских плат.
TL;NR
- Берете EDK2
- Следуете гайду и делаете HelloWorld
- Полученный efi переименовываете как bootx64.efi и кладете в /EFI/BOOT на любом fat32 носителе.
???грузитесь с него- Profit!
Распространенные ответы:
Q: Я просто хотел понять, как это все работает "ближе к железу", без этих ваших выскоуровневых EFI
A: legacy-режим — это не ближе к железу, а слой совместимости
А черт его знает. С одной стороны даже не смешно. В 2021 году не все даже знают о дискетах. И Legacy слой действительно своего рода HAL. С другой стороны браться за x64 не представляя себе работу x86 так себе идея.
В целом согласен — лучше силы на какой-нить микроконтроллер потратить. С другой стороны современная архитектура x64 это такой монстр, что даже слой UEFI не сильно спасает.
А вот что статей про "Hello, World" на UEFI, да с графикой действительно не хватает. Больше того — я таких вообще не припомню. А вот про Legacy было очень много. Хотя, мое мнение, по этой части руководства для вирусописателей времён MSDOS и Window 3.11 много полезнее и информативные. Впрочем, они подразумевают знание ассемблера и базовой x86 обвязки, что сегодня уже редкость. Потому какую-то ценность эти статьи имеют. Не стоит, наверное, гнать их в шею. Пусть пока остаются. Мало ли кого реально заинтересует.
А интересны ли статьи про потроха относительно современных x86? Многоядерность, старт/стоп процессоров, LAPIC/X2APIC и другие «встроенные» устройства, особенности 64-битного режима и т.д.? С одной стороны, я таких почти не встречал, но может это почти никому и не надо?
Очень интересно, если есть возможность, пишите!
Весьма и весьма интересны!
Тут еще вопрос в том, что эти знания сейчас не особо востребованы, насколько я вижу. Много ли на рынке вакансий, где нужно знание архитектуры x86/arm на низком (и при этом хорошем) уровне? Вот и статьи поэтому пишут редко на эти темы, получается это удел очень узкой группы людей.
p.s. про статью подумаю, все никак не выберу тему, мне все знакомые темы кажутся избитыми и неинтересными, но может это потому что я в них и варюсь? :)
p.s. про статью подумаю, все никак не выберу тему, мне все знакомые темы кажутся избитыми и неинтересными, но может это потому что я в них и варюсь? :)
Очень много задач бринг-апа х86 вообще не освещено на русском нигде, совсем. Да тот же, прости рандом, IRQ routing, про который как раз и можно рассказать, заодно рассказав про PIC/APIC/X2APIC, или про MSI (и их связь с SIPI). Про PCIe можно вообще книгу писать, и не одну, то же самое про CPU power management, то же самое про ACPI, и т.п. Вот это все — оно интересное очень, но действительно удел узкой группы людей, и продолжит таковым быть, если не писать про это.
Согласен, много из того, что вы перечислили это достаточно узкая специфика. Поэтому и возникает вопрос — а нужна ли она такая? Все-таки книги писать на эти темы — это требует приличного времени (да даже статью на хабр). Вот вы, наверное, профильный специалист, но много ли вы знаете еще людей разбирающихся на низком уровне хоть как-то в современных x86? Тема совершенно не популярна, про какой-нибудь веб-фреймворк сейчас больше пишут, чем про MSIX или ACPI… А еще при написании надо не задеть ни чьего NDA, что сложно, когда они есть от всех ведущих производителей :)
JerleShannara CodeRush
Давно мечтаю прочитать такую статью, где вся информация была бы не разбросана по OsDev комьюнити а собрана в одному туториале, чтобы можно было за пару дней завести собственную флешку с MyOS
Так что пишите!
Давно мечтаю прочитать такую статью, где вся информация была бы не разбросана по OsDev комьюнити а собрана в одному туториале, чтобы можно было за пару дней завести собственную флешку с MyOS
Так что пишите!
Вот если наберётся народа, которому это интересно, то можно написать статью про PIC/PIR, APIC, MSI и компанию, правда там гарантировано вылезут vendor specific части, коие я в основном по AMD только подробно знаю.
Правда практической ценности от неё будет мало, т.к. PIC уже можно похоронить, да и MSI уже начнает сдавать позиции на фоне PME, хотя девайсы на нулевой виртуально шине ещё живут в APIC спокойно.
Хотя когда я ставил эксперименты с различными укуренным вариантами загрузки (типа «мне надо SMP, но чтобы только PIC» или «APIC но без ACPI»), то современные платы весьма часто не могли загрузиться, т.к. такие комбинации уже мертвы. По большому счёту сейчас живы только три варианта: адов легаси одноядерный PIC, многоядерный APIC+ACPI ну и полный фарш.
Правда практической ценности от неё будет мало, т.к. PIC уже можно похоронить, да и MSI уже начнает сдавать позиции на фоне PME, хотя девайсы на нулевой виртуально шине ещё живут в APIC спокойно.
Хотя когда я ставил эксперименты с различными укуренным вариантами загрузки (типа «мне надо SMP, но чтобы только PIC» или «APIC но без ACPI»), то современные платы весьма часто не могли загрузиться, т.к. такие комбинации уже мертвы. По большому счёту сейчас живы только три варианта: адов легаси одноядерный PIC, многоядерный APIC+ACPI ну и полный фарш.
Да пишите уже, пофиг, достаточно там народа или нет, народ сам понемногу подтянется из поисковых систем, если ему интересно будет. Понятно, что создание контента — это тяжелый труд, но тут получается известная уловка 22, и разорвать цикл «нет контента» -> «нет читателей» -> «нет смысла писать» -> «нет контента» можно только на этапе «нет смысла писать», выдумав себе этот смысл. Я в свое время три десятка статей так написал (и посмотрите до чего они меня довели!), и очень постараюсь продолжить писать, когда снова время найду и НДА спадут.
titbit, JerleShannara — я не могу говорить за весь хабр, но за себя скажу.
Мое понимание внутреннего устройство ПК закончилось где-то на 386-ом/486-ом. Тогда мне это было нтересно, а начиная с «пентиумов» у меня началось исключительно прикладное использование компьютера. В том смысле, что драйвера для шинных устройств под разные оси — да, а внутреннее устройство BIOS исключительно по необходимости. Не, я в курсе про ACPI (как минимум частично), но объективно мои познания здесь весьма обрывочны и целостной картины (даже в первом приближении) не содержат. Потому я бы с удовольствием почитал. Маловероятно, что мне это понадобится в работе, но… пожалуй именно формат статей на хабре и был бы идеальным форматом для восполнения пробелов. Если вдруг заинтересует всегда можно копнуть глубже. Да и часть важных и интересных моментов из x86/x64 порастеклась. Даже в тот же ARM/aARM64. В первую очередь, конечно, PCI с обвязкой. Потому однозначно интересно.
Мое понимание внутреннего устройство ПК закончилось где-то на 386-ом/486-ом. Тогда мне это было нтересно, а начиная с «пентиумов» у меня началось исключительно прикладное использование компьютера. В том смысле, что драйвера для шинных устройств под разные оси — да, а внутреннее устройство BIOS исключительно по необходимости. Не, я в курсе про ACPI (как минимум частично), но объективно мои познания здесь весьма обрывочны и целостной картины (даже в первом приближении) не содержат. Потому я бы с удовольствием почитал. Маловероятно, что мне это понадобится в работе, но… пожалуй именно формат статей на хабре и был бы идеальным форматом для восполнения пробелов. Если вдруг заинтересует всегда можно копнуть глубже. Да и часть важных и интересных моментов из x86/x64 порастеклась. Даже в тот же ARM/aARM64. В первую очередь, конечно, PCI с обвязкой. Потому однозначно интересно.
Само собой! Я сюда зашёл вспомнить детство и первый резидент на асме, который очень помогал играть в леммингов на Искре. (для создателей раскладки JCUKEN приготовлен отдельный котёл в аду, я уверен! ;-)
Если вы думаете, что это никому не надо, то где-то грустит один джун)
У меня вопрос, если статья не нравится, вы знаете что не хватает такой статьи, как вы описали, то почему же вы сами её не напишите? Либо не найдёте того, кто может написать?
Я не просто так спрашиваю, обычно когда такое вижу, я не бегу писать возмущённый комментарий, а просто пишу недостающую статью. Так как от комментария пользы не много (статья не появится), а вот от статьи польза есть.
Я не просто так спрашиваю, обычно когда такое вижу, я не бегу писать возмущённый комментарий, а просто пишу недостающую статью. Так как от комментария пользы не много (статья не появится), а вот от статьи польза есть.
Есть статьи там https://habr.com/ru/post/338264/, есть сям https://habr.com/ru/users/coderush/posts/…
У меня с EDK2 совсем не сложилось, даже по гайдам не получилось скомпилить приложение, не то, что по официальной документации. Поэтому я начал разбираться, как это делается без сторонних монструозных библиотек, и написал пример, который должен быть понятен новичкам. Графика там тоже есть, кстати: github.com/VioletGiraffe/UEFI-Bootloader
Точнее, сам код примера я тоже не писал, где-то подсмотрел, я только слепил его с заголовочными файлами UEFI и заставил компилироваться (и работать на голом железе), что оказалось на удивление легко.
Точнее, сам код примера я тоже не писал, где-то подсмотрел, я только слепил его с заголовочными файлами UEFI и заставил компилироваться (и работать на голом железе), что оказалось на удивление легко.
Дествительно, статья запоздала лет на… цать. И странно, ничего не сказано, что у ассемблера х86 есть два варианта написания, от Intel и от AT&T.
У ассемблера именно x86 есть только один правильный вариант написания и это от Intel. Наличие же вырвиглазного синтаксиса AT&T это прихоть GNU'шно-DEC'овского мира, которые почему-то считают (тут перехожу на high level language) что «int 5 = i;» это более естественно чем «int i = 5;»
int i = 5 появилось позже чем mov 5, r0 (move 5 to r0)
Я же говорил:
И речь тут не идёт про процессоры с r0...r15. Вернее про DEC'овские процессоры. Потому как на ARM тоже r0...r15, но там направление приёмник-источник тоже привычное большинству народа, как на x86, i.e. сначала приёмник, а после источник. Привычное именно большинству народа сейчас, а не малой кучке динозавров (правда я и сам не молод), которые начинали с DECALGOL, COBOL, PL/I и им привычнее сначала источник, а после приёмник.
У ассемблера именно x86...
И речь тут не идёт про процессоры с r0...r15. Вернее про DEC'овские процессоры. Потому как на ARM тоже r0...r15, но там направление приёмник-источник тоже привычное большинству народа, как на x86, i.e. сначала приёмник, а после источник. Привычное именно большинству народа сейчас, а не малой кучке динозавров (правда я и сам не молод), которые начинали с DEC
В конце концов, мнемоника ассемблера должна облегчать написание и понимание написанного на интуитивном уровне, и если оно MOV EAX, EBX, то неподготовленному читателю можно же ждать именно «Move EAX to EBX», а не наоборот :)
Сравним тот же Mикрочиповский MOVLW = «Move Literal to W» и MOVWF x = «Move W to Fx», и тут же рвущие шаблон интуитивно понятные SUBLW = «Subtract W from Literal» (или наоборот?) и SUBWF x = «Subtract W from Fx» (или наоборот?), которые, низачто не догадаетесь, делают абсолютно противоположные вещи: «L-W» (нелогично) и «Fx-W» (логично).
Или 8051ый: MOV R0, #0, тут уже спокойно заменяем запятую знаком "=", и SUBB A, #01h, заменяем запятую минусом.
Или z80: LD A,n это именно A=n, а SUB A это именно А-А.
Или вообще древний IBM704-ый: LDQ A будет «Load MQ from A», а STQ A «Store MQ to A»
Сравним тот же Mикрочиповский MOVLW = «Move Literal to W» и MOVWF x = «Move W to Fx», и тут же рвущие шаблон интуитивно понятные SUBLW = «Subtract W from Literal» (или наоборот?) и SUBWF x = «Subtract W from Fx» (или наоборот?), которые, низачто не догадаетесь, делают абсолютно противоположные вещи: «L-W» (нелогично) и «Fx-W» (логично).
Или 8051ый: MOV R0, #0, тут уже спокойно заменяем запятую знаком "=", и SUBB A, #01h, заменяем запятую минусом.
Или z80: LD A,n это именно A=n, а SUB A это именно А-А.
Или вообще древний IBM704-ый: LDQ A будет «Load MQ from A», а STQ A «Store MQ to A»
Вот именно, на интуитивном уровне. Интуитивно как раз и ожидается что «i = 5», а не «5 = i».
Нет, про соответствие "," = "=«я не знаю, когда читаю текст. Я читаю „переместить что куда“, а не „переместить куда что“, „сложить а и б“, „вычесть б из а (или наоборот? все время путаю!)“, „прыгнуть на строку, если не ноль“, „сдвинуть влево“ (и опять х86 с арифметическими и логическими сдвигами, поясните непонятливому читателю — в чем разница, двигаем же бит в байте!).
Также, для верхнего уровня текстов программ, „если а равно б то с“, „для каждого И от 1 до 10 с шагом 2“, „делать, пока не ноль“.
А про то, что запятую надо знаком равенства заменять — это меня заранее авторы должны предупредить, тогда это уже и нельзя прочитать „переместить а в б“, а „переместить в а из б“, а это уже сложнее языковая конструкция :)
Также, для верхнего уровня текстов программ, „если а равно б то с“, „для каждого И от 1 до 10 с шагом 2“, „делать, пока не ноль“.
А про то, что запятую надо знаком равенства заменять — это меня заранее авторы должны предупредить, тогда это уже и нельзя прочитать „переместить а в б“, а „переместить в а из б“, а это уже сложнее языковая конструкция :)
интуитивно? Это дело привычки, но в массовость вошло, что i = 5, а не 5 = i И идти по другому пути лишь бы отличаться чем-то — это фиаско для AT&T
Да, привычки, согласен. Но раз в массовость вошло, раз с младых ногтей учат что приёмник слева, а источник справа, то это значит что это уже лет с пяти как минимум именно интуитивно. Не знаю как там у тех кто пишет справа налево (арабы, евреи и т.д.), но у всех остальных интуитивно «i = 5», а не «5 = i».
А зачем неподготовленному читателю, а не программисту, вообще читать ассемблер? Вроде уже не 60-е годы прошлого века, когда всё только зарождалось. Сейчас во всех языках программирования (кроме редкой экзотики) присваиваемое значение является левым операндом. Вот ассемблер не должен выпендриваться.
Там ещё более необычные конструкции возможны:
addl %edx, 8(%esi,%edi,4)И как человек интуитивно догадается, что это значит:
add [esi + edi * 4 + 8], edxНеподготовленный чиататель, это человек, знакомый, допустим, с одним ассемблеромязыком программирования и читающий программу на другом.
Обычно, в рамках одной идеологии, проблем возникнуть не должно (кроме разве что функций в Си после комментариев Паскаля). Тонкости про [esi + edi * 4 + 8] уже смотрим в документации.
Не возникнет же проблем понять назначение, например, таких инструкций:
разве что сдвиг надо сделать в первую очередь, а запятую на, соответственно, равно и минус поменять во вторую.
Обычно, в рамках одной идеологии, проблем возникнуть не должно (кроме разве что функций в Си после комментариев Паскаля). Тонкости про [esi + edi * 4 + 8] уже смотрим в документации.
Не возникнет же проблем понять назначение, например, таких инструкций:
MOV ACC,@VarA << #10
SUB ACC,@VarB << #6
разве что сдвиг надо сделать в первую очередь, а запятую на, соответственно, равно и минус поменять во вторую.
Нет никаких вариантов. Синтаксис команд ассемблера определяется исключительно разработчиком микропроцессора! Не нравится — выберите другого разработчика.
НЛО прилетело и опубликовало эту надпись здесь
Некая часть информации доступна здесь: https://habr.com/ru/company/selectel/blog/516810/
На ранних стадиях загрузки, в качестве ОЗУ используется процессорный кэш. Вот еще нашел: https://www.researchgate.net/publication/295010710_Booting_an_Intel_System_Architecture
Думая в будущее — лучше учите UDK/EFI, т.к. на свежих жЫрных ARMах и компании uboot уже уходит в прошлое. Про классический BIOS — только ради истории.
Вчера ремонтировал Gigabyte на H110, а это мать 2015 года!!! И там просто отсутствует legacy загрузка как класс, нет IDE эмуляции… кроме спортивного интереса разве есть смысл СЕГОДНЯ во всём этом?
Только исторический. Более того, судя по тому, что творится сейчас со свежими AMD, скоро real mode останется в прошлом — новая рязань, если я правильно понял всю котовасию, стартует уже в защищенном режиме и с настроенной памятью.
Хитрый план, т.е. раньше мы кормили PSP настройками из PEI, а теперь будем их класть прямо на его ФС, чтобы он память до отпускания ресета тренировал? Забористое курят, не отнять…
Ага, я сам прифигел с того, что для втуливания рязани в coreboot народу пришлось вытащить куски поддержкий Intel FSP. И да, теперь PSP настраивает память, снимает сброс и родные х86 ядра стартуют с уже настроенной памятью (и наверняка почти всем PCI пространством) как во времена 8086/80286. Телефончиком диллера правда почему-то нее делятся, а жаль, я тоже хочу такое творить.
НЛО прилетело и опубликовало эту надпись здесь
я понимаю, что это перевод, но что все таки означает: «написание кода на компиляторе»?
void initGraphics() {
...
for(;;) { ... }
этот цикл разве не бесконечный? Где там условие выхода?
Выхода куда?
выхода из цикла
Не откуда, а куда.
Это я к тому, что из загрузчика некуда выходить — он либо грузит ОС, либо зависает.
Либо грузит OS, либо пишет «Press any key to reboot...», ждёт любую клавишу и делает jmp 0xf000:0xfff0. Просто зависать ему негоже.
Сектор – это особый раздел загрузочного диска
На этом чтение данной статьи можно закончить )))
Подскажите, пожалуйста, почему у меня не компилируются test4.c и test5.c ?
Я запускаю:
gcc -c -g -Os -march=i686 -m32 -ffreestanding -Wall -Werror test4.c -o test4.oВывод:
/tmp/cc3WIudi.s: Assembler messages:
/tmp/cc3WIudi.s:41: Error: 4-byte relocation cannot be applied to 2-byte fieldМетодом исключений я выяснил, что ошибка появляется, когда используется процедура типо getch()
Почему так получается?
Потому, что автор немножечко мухлюет при использовании инструментов. gcc думает, что он генерирует код для 32-битного режима работы cpu (-march=i686 -m32), а ассемблер интерпретирует мнемоники инструкций в предположении 16-тибитного режима (.code16 в начале файла). Иногда gcc генерирует мнемоники, для которых не существует машинного кода в 16-тибитном режиме, с такой диагностикой, как у вас, тут уж как повезёт.
Возможно, ваш gcc по-умолчанию генерирует pie-код (а у автора — не-pie), и проблема уйдёт, если вы скажете своему gcc: -fno-pie
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем загрузчик на Ассемблере и C. Часть 1