Intel закрывает инициативу x86S

Скорее как с китайскими х86, которые то ли догнали то ли превзошли условный иви бридж. Оригинальное ядро VIA явно не имело ничего необходимого для этого.

Лучше скажите когда у амуде будет 10 серия райзенов. 7 и 9 я решил пропустить. Деньги жгут ляжку, хочу обновить свой 5950X.

Надеюсь, они добавят инструкцию CRN.

Нахрен оно надо? Там давно арм и систем5 развивающийся. не нужна эта устаревшая архитектура никому.

А интел в свое время армы профукала, помню везде фрискейлы были.

Нахрен оно надо?

Да так-то не надо, в общем-то. Я к тому что могли бы хотя бы попытаться.

Угадал что у тебя материнки от известного бракодела (асуса и его аффилированной фирмы асрок).

Они бы лучше fixed size instruction length сделали. Памяти для кода сейчас жопой жуй.

А в чём брак-то? У меня с ними всё работает без проблем.

i8051

Спаси и сохрани

Это типичные клоуны из интернета, которые по единичным случаям какие-то глобальные выводы делают. У меня на msi x570 проблемы с uefi boot и чо!?

На некоторых материнках есть headless режим. Интересно, там такие видеокарты в ОС работать будут?

Лично я об открытии этой инициативы узнал из новости от её закрытии.

Я к тому что могли бы хотя бы попытаться.

А они и попытались: https://www.phoronix.com/news/Intel-RISC-V-International

Но, по-моему, свернули и это.

Они бы лучше fixed size instruction length сделали. Памяти для кода сейчас жопой жуй.

Зато кеша теперь недостаточно.

Я, признаюсь, уже не помню всех подробностей, но ассоциация эта давняя. Помню что я уже в 2015 асус избегал, купил несколько материнок асрок, оказавшихся мусором, а потом только узнал что данная фирма аффилирована с асусом и всё сложилось.

И кстати в них уже тогда был неприкрытый уефи, но mbr-загрузка тоже есть.

И кстати в них уже тогда был неприкрытый уефи, но mbr-загрузка тоже есть.

А проблема-то в чём? Зачем нужна загрузка через MBR, если UEFI работает?

Затем, чтобы запустить ОС, очевидно. Не создавая при этом мусорных разделов.

А, то есть единственная проблема UEFI – это необходимость отдельного раздела? То есть, проблем у UEFI в принципе нет. Понял.

Не прикидывайся шлангом. Вот распишу подробнее:

1) ему нужно чтобы на диске вообще была таблица разделов в понятном ему формате, многие не поддерживают даже традиционную (а поддерживают только gpt), а таблицы других ОС (BSD например) не поддерживаются вообще

2) раздел, который ему нужен, должен быть в нужной ему фс и никак иначе

3) на этом разделе он ищет файлы в виндузятном PE-формате - сразу видно кто стоит за проталкиванием этой пакости

4) выше были практические неудобства, а теперь идеологическое: сам факт того, что прошивка материнки лезет в структуры на диске, чтобы в них активно парсит - никуда не годится

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

Не прикидывайся шлангом. Вот распишу подробнее:

У меня длинный шланг, я не комплексую.

1. ему нужно чтобы на диске вообще была таблица разделов в понятном ему формате

И? Не насрать ли?

а таблицы других ОС (BSD например) не поддерживаются вообще

BSD умеют GPT, вообще проблемы нет.

2. раздел, который ему нужен, должен быть в нужной ему фс и никак иначе

У тебя проблемы с FAT32?

3. на этом разделе он ищет файлы в виндузятном PE-формате - сразу видно кто стоит за проталкиванием этой пакости

Intel стоит. А что? Тебе они не нравятся? Неплохие процессоры вроде как делают, хотя я, как уже писал выше, использую в основном AMD.

И опять же, не вижу тут проблемы. Тулинг для работы с PE под люнексом есть. EFI появился в конце 90х при создании Itanium, когда люнекс был в основном студенческой поделкой и на серверах никто в здравом смысле его не запускал, как и коммерческие юниксы на x86 в принципе (они были на системах соответствующих вендоров). Так что можешь считать это историческим артефактом, как и в принципе всё вокруг x86.

4. выше были практические неудобства, а теперь идеологическое: сам факт того, что прошивка материнки лезет в структуры на диске, чтобы в них активно парсит - никуда не годится

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

а таблицы других ОС (BSD например) не поддерживаются вообще

*BSD поддерживают таблицу разделов GPT. Haiku тоже поддерживает. Не знаю ни одной актуальной ОС, которая не поддерживает GPT. Вы про DOS что ли? Она мертва давно.

Из 512 байт загрузочного сектора запустить современную ОС нельзя. Надо выдумывать костыли с загрузчиком, загружающим загрузчик, загружающим загрузчик, загружающим загрузчик… И всё это на антикварном 16 битном коде x86 real mode.

Будут если есть куда подключить. Современные ОС умеют инициализировать видеокарту с нуля без участия BIOS. Из неудобств может быть разве что отсутствие картинки на начальных этапах загрузки.

BSD умеют GPT, вообще проблемы нет.

Я не про то, что умеют BSD системы, а про то, чего этот дурацкий уефи не умеет - BSD-разметку. Ну как ты не понимаешь, дело не в этой конкретике, а в том, что прошивка материнки вообще диктует как ОС должна использовать жёсткий диск. Может быть у меня кастомная ОС с вообще другой структурой данных, и эти разделы мне нафиг не сдались, но ради уефи я должен их поддерживать?

То есть, в том, что прошивка материнки лезет в бутсектор

Неужели ты не видишь разницы между «прочитать один единственный, самый первый, сектор и тупо запустить» и лазанье по произвольным местам диска и парсинг из него всяких таблиц?

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

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

Я не про то, что умеют BSD системы, а про то, чего этот дурацкий уефи не умеет - BSD-разметку

А зачем ему её уметь-то?

Может быть у меня кастомная ОС с вообще другой структурой данных, и эти разделы мне нафиг не сдались, но ради уефи я должен их поддерживать?

Так у тебя кастомная ОС с вообще другой структурой данных и диск вообще без разделов? Или ты это выдумал просто чтобы повыдрючиваться?

Неужели ты не видишь разницы между «прочитать один единственный, самый первый, сектор и тупо запустить» и лазанье по произвольным местам диска и парсинг из него всяких таблиц?

Этот один единственный первый сектор должен быть в специальном формате с таблицей разделов (из 4 штук), один из которых обязательно должен быть помечен как загрузочный, плюс 446 байта на код для загрузки. Вообще полностью аналогичная хрень, минус тот факт, что MBR – наследие флоппиков из 80х и там были другие требования по упаковке и размеру.

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

Чем плохо? Тут всё просто: либо ты доверяешь прошивке, и тогда проблемы нет вообще, либо ты не доверяешь прошивке, и тогда тебе стоит сжечь твой компьютер и купить другой.

А вот что в MBR плохо так это то, что эта дрисня не поддерживает диски больше 2 терабайт. Т.е. на трёх из пяти дисков в моей системе MBR просто не может использоваться, они тупо больше.

а таблицы других ОС (BSD например) не поддерживаются вообще

BIOS не поддерживает таблицы разделов, отличные от MBR. Оно как минимум читает первые 512 байт, а зачастую и всю таблицу разделов.

Неужели ты не видишь разницы между «прочитать один единственный, самый первый, сектор и тупо запустить» и лазанье по произвольным местам диска и парсинг из него всяких таблиц?

Нет тут никакой разницы. Требование размещения загрузчика в первых 512 байтах диска ломает совместимость с некоторыми форматами таблицы разделов.

Этот один единственный первый сектор должен быть в специальном формате с таблицей разделов (из 4 штук)

Нет, достаточно магического числа. Разделов вообще может не быть. Если мы рассматриваем загрузку через BIOS.

Проблема чтения через ФС, и PE файлов что оно нормально не работает. Это слишком сложно для реализации, прочесть файл на диске и определить что это загрузчик. Патрику из за этого приходиться разбираться в grub, на многих компьютерах elilo просто не хочет загружаться. А прочесть сектор и прыгнуть на него это уже попроще.

Проблема чтения через ФС, и PE файлов что оно нормально не работает. Это слишком сложно для реализации

што? Драйвер FAT32 – сложно для реализации? Совсем упоролись, что ли?

Патрику из за этого приходиться разбираться в grub, на многих компьютерах elilo просто не хочет загружаться.

А зачем Патрегу GRUB-то? И как это связано с «слишком сложно для реализации», если оно уже реализовано? Плюс, можно просто ядро кинуть в раздел ESP и не париться, если GRUB собрать такая проблема.

https://docs.kernel.org/admin-guide/efi-stub.html

Другой вопрос, что слака просто не нужна.

на многих компьютерах elilo просто не хочет загружаться.

Ну и нахер его?

Не наш.

Ты странный.

А что делать? Вот такое оно, смиряемся и принимаем, «как есть».... И как пить...

Не, я лулзы ловлю. firkax и stanson два моих любимых шизофреника тут. Оба любят сишечку и asm под 8086 какой-то очень странной, затмевающей здравый смысл любовью. Один тут про кастомную ОС со своей таблицей разделов пишет, хотя казалось бы, EFI stub пишется куда проще 16-битного загрузчика и позволяет не париться с инициализацией процессора лишний раз. Второй вообще предлагал выше бинарики из под 8086 запускать в long mode зачем-то. Разве это не офигенно?

што? Драйвер FAT32 – сложно для реализации? Совсем упоролись, что ли?

Ну реальность показывает что для разработчиков UEFI это часто невыполнимая задача.

А зачем Патрегу GRUB-то?

Потому что elilo через раз работает из за кривого UEFI. Хотя как загрузчик он довольно простой и приятный. Вот и приходится впиливать grub как стандартный. Он всегда был в репозитории, но установщик предлагал lilo или elilo.

Плюс, можно просто ядро кинуть в раздел ESP и не париться, если GRUB собрать такая проблема.

Это не подходит, проблем будет еще больше чем у elilo. GRUB был выбран потому что его чаще всего видят. Некоторые UEFI реализации настолько безумные, что имеют whitelist для путей.

А зачем ему её уметь-то?

Конечно незачем, он вообще не должен туда лезть и что-то парсить. Но он лезет и навязывает свой формат.

Этот один единственный первый сектор должен быть в специальном формате с таблицей разделов (из 4 штук), один из которых обязательно должен быть помечен как загрузочный, плюс 446 байта на код для загрузки. Вообще полностью аналогичная хрень, минус тот факт, что MBR – наследие флоппиков из 80х и там были другие требования по упаковке и размеру.

Нет, не должен. Биос предполагает про MBR ровно две вещи: последние два байта 55AA (и то вроде не все это проверяют), и по смещению 0 там точка входа в x86 исполняемый код. Всё.

Чем плохо? Тут всё просто: либо ты доверяешь прошивке,

Прекращай клоунаду, я тебе уже 5 там писал и ты в упор не замечаешь суть. Доверие тут ни при чём. При чём - разделение ответственности. За содержимое диска отвечает ОС, у биоса к нему должны быть самые минимальные требования, насколько это возможно. И с MBR это так и было: загрузчик прочитать откуда-то нужно, тут никуда не деться, так давайте его читать тупо с нулевого байта и размером в 1 блок.

А вот что в MBR плохо так это то, что эта дрисня не поддерживает диски больше 2 терабайт

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

Ещё один. Ну как можно быть таким безграмотным? Иди изучай устройство PC-загрузчика, потом лезь в спор, чтоб не позорится. Никакие таблицы разделов биосу не нужны.

кастомная ОС с вообще другой структурой данных, и эти разделы мне нафиг не сдались, но ради уефи я должен их поддерживать?

Нет. Таблица разделов - штука настолько простая, что тут не требуется городить огород. Даже если ваша ОСь не поддерживает ГПТ нативно, то всё равно можно выделить ей большой ГПТ-раздел, и передать в параметрах ядра смещение и его размер, чтобы она воспринимала это пространство как отдельный диск, и никуда бы больше не лазила. Даже с ДОСом можно такой трюк сотворить, если ваш любимый int13 будет предоставлять определённый ГПТ-раздел как отдельный (и единственный) диск.

То есть, в рамках одной таблицы разделов, можно запросто создать вторую на каком-то из разделов, и совершенно не обязательно, чтобы уефи её пониал, а недо-ось бы понимала ГПТ. Уефи - это простота и минимализм. Туда не пихают поддержку сотни форматов таблиц разделов, если хватает и 1й.

Неужели ты не видишь разницы между «прочитать один единственный, самый первый, сектор и тупо запустить» и лазанье по произвольным местам диска и парсинг из него всяких таблиц?

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

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

Это как раз хорошо, учитывая то, как раньше загрузчики были вынуждены «скрывать» свой пэйлоад от ОСи в резервных секторах, и как это всё накернивалось после различных процедур переразбиения.

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

Это - прямая деза. Всё читалось из резервных зон. В 1 сектор загрузчик не влезает. А теперь это устаканили и стандартизовали. Вам что, небольшой ФАТ-раздел в начале диска спать мешает? Так он там и так был! Только назывался резервной зоной, а теперь получил официальный статус раздела.

Нет. Таблица разделов - штука настолько простая, что тут не требуется городить огород. Даже если ваша ОСь не поддерживает ГПТ нативно, то всё равно можно выделить ей большой ГПТ-раздел,

Я без тебя знаю что гпт поддерживать легко. Вопрос в другом: зачем мне навязывают эту лишнюю сущность?

Даже с ДОСом можно такой трюк сотворить, если ваш любимый int13 будет предоставлять определённый ГПТ-раздел как отдельный (и единственный) диск.

Я такое делал, правда не с гпт а с своим форматом диска, чтобы спрятать свой загрузчик и его данные от доса.

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

Что значит вынуждены? Ничего плохого в этом нет. Интерфейс сохранён максимально простым: в нулевом секторе диска в нулевом его байте находится точка входа на код ОС, каким бы он ни был, а дальше ОС сама разбирается что ей нужно. В случае с grub там идёт чтение ещё секторов с остальным кодом, да. Досовский загрузчик читал бутсектор активного раздела и переходил на него (а тот, в свою очередь, читал первые 3 сектора ibmbio.com и запускал его). Фрибсдшный mbr (если делать mbr-схему) кстати тоже просто читает бутсектор активного раздела.

Это как раз хорошо, учитывая то, как раньше загрузчики были вынуждены «скрывать» свой пэйлоад от ОСи в резервных секторах, и как это всё накернивалось после различных процедур переразбиения.

Скрывать тут надо было разве что от тупых юзеров. А так загрузчик это часть ОС по-нормальному.

Деза это то что ты пишешь. Загрузчик читается с 0 сектора и управление передаётся его нулевому байту. Что делать дальше - на усмотрение загрузчика.

Я без тебя знаю что гпт поддерживать легко.

Нет, я про другое: его можно вообще не поддерживать. Я ж написал: передавай своему кастомному ядру смещение и размер руками, и пускай он создаст таблицу разделов сам, любую, какую угодно. Тот факт, что она окажется внутри раздела ГПТ - можно игнорировать.

Что значит вынуждены? Ничего плохого в этом нет.

Круть! А сделать то же самое, только создав нормальный ФАТ-раздел - это уже сразу плохо, так что ли?

В случае с grub там идёт чтение ещё секторов с остальным кодом, да.

А в случае лило - из них же читалось ядро ОС.

А так загрузчик это часть ОС по-нормальному.

Какой из? Если у вас мульти-бут с кучей осей.

Деза это то что ты пишешь. Загрузчик читается с 0 сектора и управление передаётся его нулевому байту. Что делать дальше

• на усмотрение загрузчика.

Так я и описываю то, что загрузчики реально делали. При чём тут деза. Я вам объясняю, что ФАТ-раздел появился не от хорошей жизни, а как замена резервной области. К этому вопросы есть?

што? Драйвер FAT32 – сложно для реализации? Совсем упоролись, что ли?

Ну реальность показывает что для разработчиков UEFI это часто невыполнимая задача.

В смысле? Все системы с UEFI имеют раздел в FAT32 в начале диска. Иначе они грузиться не умеют.

Потому что elilo через раз работает из за кривого UEFI. Хотя как загрузчик он довольно простой и приятный. Вот и приходится впиливать grub как стандартный. Он всегда был в репозитории, но установщик предлагал lilo или elilo.

Повторюсь: выкинь нахрен этот elilo. «Приходится впиливать GRUB» – это какая-то особая шлакварская мантра, которая не придёт в голову ни одному нормальному пользователю других дистров, в которых GRUB без проблем ставится из коробки.

Это не подходит, проблем будет еще больше чем у elilo.

Каких? У меня пока ни одной проблемы ни с GRUB, ни с EFI stub не было.

Некоторые UEFI реализации настолько безумные, что имеют whitelist для путей.

Назови свой файлик bootx64.efi и перестань страдать уже.

Никакие таблицы разделов биосу не нужны.

В теории может быть и не нужны, но на практике существуют вендоры, у которых BIOS не загружает ОС, если нет соответствующей таблицы разделов и active флага. Таблица разделов читается и проверяется ещё до исполнения кода в MBR.

Конечно незачем, он вообще не должен туда лезть и что-то парсить. Но он лезет и навязывает свой формат.

Да нет, не навязывает. Раздел FAT32 в начале диска – это мелочи.

Нет, не должен. Биос предполагает про MBR ровно две вещи: последние два байта 55AA (и то вроде не все это проверяют), и по смещению 0 там точка входа в x86 исполняемый код. Всё.

А вот я прозреваю, что ты неправ, и это вполне может зависеть от биоса. Мне в треде куча народа про кривые UEFI прошивки пишет – и я им даже верю! – но почему-то никто не вспоминает про кривые биосы.

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

Раздел FAT32 – достаточно минимально, ящитаю.

Так было пока не сделали дурацкий уефи, который начал принуждать ОС хранить эту самую таблицу в нужном формате.

Опять же, а в чём проблема кроме твоей религиозной шизы? Тебе надо обязательно использовать какую-то другую таблицу разделов?

Круть! А сделать то же самое, только создав нормальный ФАТ-раздел - это уже сразу плохо, так что ли?

Да что ж такое? Плохо не то, что там фат, плохо то что его навязали извне. Я совершенно не против того, что кто-то захочет создать у себя фат и класть в него загрузчик. Но пусть это будет их собственным выбором, а не принуждением. А если не хотят фат - из-за этого не должно возникать никаких проблем.

Какой из? Если у вас мульти-бут с кучей осей.

Вот те, у кого мультибут, разберутся как делать мультибут. Суть традиционной загрузки как раз в том, что у ОС/юзера полная свобода того, что и как располагать на диске, кроме нескольких байт в начале нулевого сектора. Хочет делать фат - делает фат, хочет традиционную mbr-разметку разделов - делает её, хочет gpt - делает её, хочет какую-нить minixfs с первого сектора диска без разделов - делает её (там в 1 секторе найдётся место под буткод).

Я вам объясняю, что ФАТ-раздел появился не от хорошей жизни, а как замена резервной области.

А я в который раз объясняю, что проблема не в том что там конкретно фат, а в том что это навязывается и тебя лишают выбора.

но на практике существуют вендоры, у которых BIOS не загружает ОС, если нет соответствующей таблицы разделов и active флага

Это тоже бракованные материнки. Они были и до UEFI.

Да что ж такое? Плохо не то, что там фат, плохо то что его навязали извне.

Тебе ещё и ACPI извне навязали. Алсо по сравнению со всем остальным кодом UEFI, размер реализации FAT – капля в море.

Тебе ещё и ACPI извне навязали.

Реальные пацаны запускают ядро с acpi=off и никак иначе, сучечка!

Понимаю. Разделяю. ;) :))))

Суть традиционной загрузки как раз в том, что у ОС/юзера полная свобода того, что и как располагать на диске, кроме нескольких байт в начале нулевого сектора.

Какой толк от этой свободы? Из-за неё возникает бардак при использовании multi-boot. А в UEFI несколько загрузчиков могут быть установлены одновременно и выбираться из стандартного загрузочного меню UEFI.

Таблица разделов читается и проверяется ещё до исполнения кода в MBR.

Нет, это совершенно исключено. Таблица разделов МБР оопределяется исключительно загрузочным кодом самого МБР, иначе бы никакие альтернативные таблицы разделов не были бы возможны. Пруф: https://wiki.osdev.org/MBR_(x86)#MBR_Bootstrap

- relocate itself away from the 0x7c00 physical address (using
a memory copy, and usually a far jump)

- determine which partition (or hard disk) to boot from (either
 by looking for the active partition, or by presenting the user
 with a selection of installed operating systems to choose from) 

Пруф: https://wiki.osdev.org/MBR_(x86)#MBR_Bootstrap

Это одна бабка сказала, а не пруф. Ссылка должна быть на спецификацию. К тому же далеко не все вендоры ей следуют.