Отказ от биоса

утилиту для настройки и API ввода-вывода в реальном режиме, всякие int13h, а также всякие там управления перефирией, SMM, и все остальное, кроме загрузчика

Читается даташит на девайс, после чего пишется код управления.

откуда читается, куда пишется?

Порядок загрузки реализован у разных по-разному.

Зоопарк.

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

То есть юзер решать не может?

налейте два чаю этому адеквату

откуда читается, куда пишется?

Из файла с даташитом.

Например: http://www.atmel.com/Images/Atmel_6438_32-bit-ARM926EJ-S-Microcontroller_SAM9...

То есть юзер решать не может?

Почему? Пускай использует подходящий вторичный. U-Boot, например, вполне позволяет выбирать.

ok, убедили

Ну логично.

Скорее, закономерно. И нужна очередная порция ругани от Торвальдса, чтобы это исправить: http://www.zdnet.com/one-linux-for-all-arm-systems-7000005348/

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

Как ты быстро читаешь. Я так быстро, тем более на английском, не умею.

Достаточно прочитать название.

Я смотрел, как выглядит конфигурация линукса для ARM at91, там далеко не ограничивается make menuconfig. Чтобы выбирать режимы работы различной периферии, приходится править исходный код, благо там все довольно удобно расписано.

Я совершенно не представляю, ка кони собрались все это переделывать.

никак не организовано, это не нужно. Как управлять железом - знает само железо. Идентификационные данные (id->устройтсво,флаги) записываются в файл конфигурации (который все равно нельзя редактировать никому, кроме производителя железа). Ни пользователь, ни ОС в это дело не вмешиваются, а когда вмешиваются - им бьют по рукам. (ну, по крайней мере так по-хорошему, есть упоротые случаи - на блобы видеокарт, например, можно накатывать фиксы через kernel extensions).

Как управлять железом - знает само железо.

оно то знает, а вот знает ли ос? А как она иначе будет управлять? Как она скажет железу, что надо поберечь потребление, так как внешний ИБП скоро сядет?

И далеко не всегда железо знает. Это самое железо вполне может быть тупо регистром, подсоединенным к ШИМ или ЦАП.

Я совершенно не представляю, как они собрались все это переделывать.

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

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

Ты же понимаешь, насколько это дико? Представь себе PC, где для каждой новой модели надо править исходники ядра.

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

На Android планшетах нет ни BIOS, ни UEFI. Но подавляющее большинство производителей всё так же зажимает даташиты. Так что это не поможет.

Если я правильно помню историю, именно единое API для загрузки любой ОС и низкоуровневого доступа к оборудованию (с последнего, конечно, мигрировали на драйверы для ОС, но во время загрузки оно ещё работает) и позволило IBM сделать IBM PC единой платформой.

Если похерить BIOS и UEFI, то вместо единого firmware, хоть и с зоопарком «вендорных расширений» появится Microsoft Preboot Firmware, который не будет грузить никаких «альтернативных ОС».

наверное, под BIOS понимается вполне конкретный Award/AMI/etc BIOS, который таки вполне конкретный продукт

наличие биоса - не единственная причина зажимания.

Но на x86 полные даташиты зажимают все, приоткрывая лишь для некоторых устаревших моделей, благодаря чему вообще возможен coreboot. На не-x86 есть множество систем с открытыми даташитами. На то, что в планшеты/телефоны пихают - да, зачастую закрыты. Но есть множество систем и с открытыми спеками.

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

Вот если бы не было BIOS/UEFI, примерно это тебе говорили бы в каждом магазине в ответ на вопрос «А почему на этот комп нельзя поставить Линукс?».

Как управлять железом - знает само железо

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

Вот если бы не было BIOS/UEFI, примерно это тебе говорили бы в каждом магазине в ответ на вопрос «А почему на этот комп нельзя поставить Линукс?».

Линукс много где используется, в частности на серверах его более 90%, так что был бы рынок железок незалоченых и с достаточно открытыми спеками.

Но только вот вопрос: зачем менять BIOS на альтернативную реализацию? Я понимаю зачем менять ОС, но зачем менять BIOS, задача которого пару секунд показать логотип изготовителя и отдать управление ОС?

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

То что на x86 есть BIOS наоборот хорошо. Даже если убить ОС всегда останется некоторая базовая система, которая позволит загрузиться с флешки. А на планшетах и телефонах есть большой шанс убить ОС так, что потом только с JTAG внутрь лезть (а это требует совершенно другого уровня квалификации, чем просто скачать образ и записать на CD/флешку на другом компьютере, да и 100% лишит гарантии). Говоришь можно поставить альтернативный загрузчик непривязанный к ОС? Его установка тоже риск получить кирпич, а на x86 поскольку такая вещь из коробки получить кирпич очень трудно.

Но есть множество систем и с открытыми спеками.

Подход логичный, да. Примерно как у Столлмана: «Нужно отказываться от проприетарных программ и закрытых форматов, если все откажутся, то все программы станут открытыми». И так же, как и в случае Столлмана, у этого подхода на практике проявляется критический недостаток: большинство готово жрать, что дают, и никто ничего не открывает.

А что, тебе уже объяснили, зачем нужен systemd, когда есть autoexec.bat^W bb init?

но зачем менять BIOS, задача которого пару секунд показать логотип изготовителя и отдать управление ОС?

Загрузчик пускай остается. Но он не единственная часть БИОС. Есть еще SMM, всякие там управления питанием/кулерами, итд.

Линукс много где используется, в частности на серверах его более 90%, так что был бы рынок железок незалоченых и с достаточно открытыми спеками.

Это сейчас он много где используется, а что бы было с этим поделием финского студента, пародией на настоящий сертифицированный UNIX™, если бы оно даже на x86 грузилось только на полутора машинах?

и никто ничего не открывает.

4.2

Например, http://www.atmel.com/Images/Atmel_6438_32-bit-ARM926EJ-S-Microcontroller_SAM9... - очень неплохая девайсина.

Речь про сегодняшний день

говорю же - никак. потому что ненужно.

ну то есть, если уж очень нужно, то в руки паяльник и вот так: http://www.lbodnar.dsl.pipex.com/macmini/

но та картинка для старых маков на powerpc, сейчас-то это заблокировано в efi, так что ждет тебя долгая дорога в реверс-инжиниринг чипа на материнке, отвечающего за efi =)

говорю же - никак. потому что ненужно.

А откуда железке знать, срочно мне надо провести расчет, или дело не горит?

это тебе знать, а не железу. Не хватает мощности mac mini - покупаешь mac pro. Не хватает mac pro - покупаешь два mac pro и думаешь как вручную распараллелить задачу.

оверклокинг возможен только на определенных процессорах штеуда, где разблокирован множитель, если мы сейчас говорим об этом. Для этого нужны специальные чипы. Apple специально НЕ использует эти чипы, так что оверклокинг невозможен не только политически, а технически, вообще. Да, даже на самых топовых тачках.

не оверклокинг, а тюнинг - тоже не очень возможен, т.к. все разумные вещи заблокированы в efi (а даже если и не заблокированы, ты должен уметь хачить efi под мак, и если бы ты это умел, ты бы этих вопросов не задавал :)

видюшку разве что можно попробовать разогнать, перезагрузившись в дуалбутную винду и выкрутив в текстолите буст на максимум =)

говорю же - никак. потому что ненужно.

Нужно, просто потому, что без оверклокинга даже чисто в теории нельзя получить максимальную производительность

в руки паяльник

нет, спасибо

так что ждет тебя долгая дорога в реверс-инжиниринг чипа на

материнке, отвечающего за efi =)

ох, ёлки... поэтому нельзя делать так как это сделано на маках.

оверклокинг возможен только на определенных процессорах штеуда, где разблокирован множитель,

Зачем оверклокинг? Пусть будет обычное переключение «жрем много, работаем быстро» и «тормозим, но работаем долго»

Не хватает mac pro - покупаешь два mac pro и думаешь как вручную распараллелить задачу.

не выйдет каменный цветок, увы

оверклокинг возможен только на определенных процессорах штеуда, где разблокирован множитель

разве AMD это дело не поддерживает?

«Работает жы!»

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

это там есть. а вот оверклокинг и прочее «странное» - увы

А еще плагины в виде PE-приложений, размещенных на файловой системе FAT32.

P.S. А SecureBoot может быть не зондом, а очень даже нужной фичей, если дать пользователю управление ключами.

Я этого нигде не отрицал. Так обычно и выходит. ОБЫЧНО. Во всяком embedded. Первичный инициализирует железо и грузит вторичный, вторичный — грузит ОС.

Но в нашем случае всё не так просто, т.к. ОС лежит не на каком-то наперед известном устройстве, а может лежать на флоппи-диске, на ATA или SATA (для этого уже нужно инициализировать PCI, ибо мы можем иметь контроллер, подключенный посредством PCI), SAS, на флешке (USB), или вообще грузиться по сети (тогда нам нужно инициализировать сетевую карту, которая может быть подключена посредством PCI, PCI-X, PCI-Express или USB). Короче, для самой только загрузки ОС уже нужна поддержка огромной кучи устройств.

Можно, конечно, эти штуки разделить. И? Все равно они должны быть загружены перед загрузкой ОС, и загружены из ПЗУ. Т.е., получаем эдакую большущую прошивку, которая делает то же, что и используемые сейчас прошивки, с тем лишь отличием, что, в отличии от BIOS или UEFI, она не предоставляет никакого API.

А еще у x86 есть такая штука, как SMM. Всё то, что в нем делается, перевесить на ОС? А если ОС зависла, а действие важное? (как, например, вырубить процессор, когда его температура достигла критического значения)

я бы сказал с градиентами и курсором

Как как - как и должно быть по идее целиком напирает на ACPI стандарты, какие к черту даташиты кого писать?

На FS надо тоже драйверы, а еще круто нативное разрешение, а еще круче HDA звук сразу по включению - как на маках, а не пикающие говнобиперы.

UEFI - это хорошо и правильно, только вот он внедрятся должен был 10 лет назад как минимум.

есть такая штука, как SMM. Всё то, что в нем делается, перевесить на ОС? А если ОС зависла, а действие важное? (как, например, вырубить процессор, когда его температура достигла критического значения)

Если температура достигла критического значения, то куда надежнее вырубать процессор не из SMM, а аппаратно, благо критическая температура известна наперед.

А вот всякие там имитации ps/2 клавы только прививают программистам привычку прибивать гвоздями к конкретной конфигурации, без учета того, что она может смениться.

чёт я не понял, как вы предлагаете на маке разогнать процессор без перепаек

В BIOS не только начальный загрузчик, а железозависимая часть MS-DOS.

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

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

UEFI - это нехорошо и неправильно, поскольку делался с целью блобоводства. Есть OpenFirmware, есть Coreboot. Но нет! Хотим жрать UEFI!

Каких еще паек? как ты на пеке разгоняешь?

man ACPI man P-States

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

Есть OpenFirmware

Именно - он точно такой же и он работает как UNIX, только в мире фирмварей.

Но нет! Хотим жрать UEFI!

У интела нету в штате Forth кодеров для портирования и поддержки OpenFirmware - запилили похожее на Cи с учетом недостатков и желаемых фич, и правильно.

А вот эти вот Coreboot (минимальное ведро) - на десктопах не нужны, его вот лучше закопайте.

На остальную часть поста отвечать будешь?

А отсутствие всяких там имитаций ломает обратную совместимость, которая на x86 необходима больше, чем на любом другом типе железа. Хотя это далеко не так важно, как остальная часть поста, которую ты проигнорировал.

uin> У интела нету в штате Forth кодеров для портирования и поддержки OpenFirmware

А при чём тут штеуд, когда прошивка - дело разработчиков материнских плат?

uin> запилили похожее на Cи с учетом недостатков и желаемых фич, и правильно.

Нет - в штеуде запилили спецификацию.

uin> А вот эти вот Coreboot (минимальное ведро) - на десктопах не нужны, его вот лучше закопайте.

С чего вдруг UEFI нужен, а CoreBoot не нужен?