Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1371 сообщений
Cообщения с меткой

bios - Самое интересное в блогах

Следующие 30  »
barbossi

У персонажей Half-Life обнаружили обоняние

Среда, 27 Сентября 2017 г. 15:07 (ссылка)

Спeциальная cистема позвoлялa охpанникам чувствoвать вoнь трупов. А одна из pазновидностей монстpов использовалa обоняние для поиска пищи
Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Пишем для UEFI BIOS в Visual Studio. Часть 3 — русифицируем Front Page

Воскресенье, 25 Сентября 2017 г. 02:00 (ссылка)

https://habrahabr.ru/post/338634/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Пишем для UEFI BIOS в Visual Studio. Часть 2 – создаем свой первый драйвер и ускоряем отладку

Четверг, 21 Сентября 2017 г. 14:15 (ссылка)

Введение



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

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



Те, кто заинтересовался — добро пожаловать под кат.
Читать дальше ->

https://habrahabr.ru/post/338404/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Загрузка с GPT диска из BIOS

Пятница, 01 Сентября 2017 г. 11:59 (ссылка)

В статье описано как заставить загружаться компьютер с BIOS, с жесткого диска размеченного в GPT.

Данная статья является не переводом оригинальной статьи, а скорее вольным пересказом статьи написанной Rod Smith, за которую лично я ему очень благодарен. Ссылка на первоисточник в конце данной статьи.
Читать дальше ->

https://habrahabr.ru/post/336686/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ferderfre

Роскомнадзор потребовал от 123 сайтов удалить «Игру престолов»

Понедельник, 17 Июля 2017 г. 23:15 (ссылка)

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­Роскомнадзор принимает меры по защите фэнтезийного сериалa «Игpа прeстолов» от pаспpостpанeния нeлегальных копий. Об этом в понeдельник, 17 июля, сообщается на cайте ведомства.

Отмечается, что Роскомнадзор потрeбовал у влaдельцев порталов и хостинговых компаний удалить пpотивoпpавный контент. Речь идeт о 123 интернeт-ресурcах, публикующих эпизоды «Игры прeстолов».

«В случае нeудаления нeлегальных копий сериалa эти cайты будут заблокиpованы опеpатоpами связи», — говoрится в объявлении. В ведомстве подчеркнули, что к ним поступили дeсять опрeделений Мосгорсуда об обеспeчении защиты пpав «Игры прeстолов».

Материалы по теме

09:20 — Сегодня

Кто умрeт в новoй «Игрe прeстолов»?

Читатели «Ленты.ру» выбиpают пeрвyю жертвy седьмого сезона сериалa

4 июля в мессенджерe соцсети Facebook заpаботал чат-бот, который pассказывает пользователям о событиях шести сезонов «Игры прeстолов».

В июнe Роскомнадзор потрeбовал от 103 cайтов удалить пиpатские копии документального фильма «Интервью с Путиным» американского рeжиссеpа Оливеpа Стоуна.

«Игpа прeстолов» выходит на канале HBO с 2011 года. Литеpатурной основoй фэнтезийной cаги стал цикл книг «Песнь льда и плaмени» американского пиcателя Джорджа Мартина. Прeмьеpа прeдпоследнeй, седьмой части сериалa состоялaсь 16 июля.

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Немного о багах в BIOS/UEFI ноутбуков Lenovo/Fujitsu/Toshiba/HP/Dell

Среда, 12 Июля 2017 г. 10:53 (ссылка)

В этой статье я приведу описание багов в BIOS/UEFI ноутбуков, с которыми приходилось работать и для которых приходилось адаптировать загрузчики. В первую очередь речь пойдет о багах, которые не видны пользователю, но которые могут помешать работе загрузчика даже при условии, что все было сделано правильно. Баги были выявлены как в интерфейсах соответствующих сред исполнения, так и в коде режима SMM процессоров Intel. Приводимый материал основывается на накопленном опыте, который растянут на достаточно большой период времени. Поэтому к моменту написания список конкретных моделей был утрачен. Тем не менее, сохранился список фирм-производителей, на ноутбуках которых возникали проблемы. Баги будут описаны последовательно, начиная с простых и заканчивая самыми сложными. Также по ходу описания будет приведен способ их обхода.





Прежде, чем мы начнем



Для того чтобы было полное понимание, при каких обстоятельствах приходилось сталкиваться с описываемыми проблемами, я кратко расскажу, какого сорта работу приходится выполнять. Существует продукт, шифрующий системный диск. Поэтому на этапе запуска ПК требуется расшифровывать диски, чтобы ОС могла запуститься. Поэтому был разработан загрузчик, который и выполняет эту роль. После установки всех своих перехватчиков этот загрузчик передает управление оригинальному загрузчику ОС. Далее в процессе описания термин “загрузчик” будет использоваться для обозначения нашего загрузчика. А термин “загрузчик ОС” будет использоваться для обозначения загрузчика, который мы подменяем.



Проблемы запуска загрузчика (Lenovo, UEFI)



Известно, что UEFI реализует глобальные переменные. В том числе существуют глобальные переменные, каждая из которых описывает вариант запуска ПК (load option entry). Также существует глобальная переменная BootOrder, которая описывает порядок вызова этих вариантов. Таким образом, загрузчик записывался на системный раздел UEFI, и для него создавалась новая запись, когда в BootOrder этот загрузчик ставился первым в очереди. Однако при запуске ПК вызывался загрузчик Windows. Выяснилось, что UEFI начисто игнорировал значение BootOrder и загружал всегда Windows, если находил его запись.



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



Проблемы при посылке USB-команд (HP, UEFI)



Загрузчик работает с USB-устройствами. А именно с CCID-ридерами. Для работы с USB-устройствами использовался предусмотренный для этих целей протокол — EFI_USB_IO_PROTOCOL. Проблема заключалась в том, что запущенный загрузчик не определял ни одного USB-устройства, когда на других ПК этот же загрузчик определял их. На первый взгляд могло показаться, что это полностью нефункционирующие драйвера USB, но при работе с ноутбуком я не мог обойти стороной тот факт, что ноутбук успешно запускался с флэшки. Далее выяснилось, что проблема возникает при посылке команд через управляющий канал (control transfer pipe) при помощи функции UsbControlTransfer протокола EFI_USB_IO_PROTOCOL. Прототип функции изображен ниже.



typedef EFI_STATUS (EFIAPI *EFI_USB_IO_CONTROL_TRANSFER) (
IN EFI_USB_IO_PROTOCOL* This,
IN EFI_USB_DEVICE_REQUEST* Request,
IN EFI_USB_DATA_DIRECTION Direction,
IN UINT32 Timeout,
IN OUT VOID* Data OPTIONAL,
IN UINTN DataLength OPTIONAL,
OUT UINT32* Status
);


Функция всегда возвращалась с ошибкой EFI_USB_ERR_TIMEOUT. Оказалось, что тип EFI_USB_DATA_DIRECTION был реализован разработчиками не в соответствии с UEFI спецификацией. Определение самого типа из спецификации приведено ниже.



typedef enum {
EfiUsbDataIn,
EfiUsbDataOut,
EfiUsbNoData
} EFI_USB_DATA_DIRECTION;


Ошибка в реализации типа заключалась в том, что на соответствующем ноутбуке EfiUsbDataIn и EfiUsbDataOut были перепутаны местами. Следовательно, когда загрузчик вызывал функцию UsbControlTransfer с третьим параметром равным EfiUsbDataOut, то в действительности происходила не запись в устройство, а чтение с него. И наоборот. Поскольку EfiUsbDataOut в коде приложения встречается первым, то получалось, что драйвер USB пытался прочитать данные с устройства, которых при посылаемых запросах быть не может. Соответственно, функция завершалась по таймауту.



Решение проблемы крайне некрасивое. При запуске загрузчик проверял, содержит ли поле FirmwareRevision структуры EFI_SYSTEM_TABLE строку «HPQ», и если содержит, проверялось, чтобы поле FirmwareRevision содержало значение 0x10000001. Если оба условия соблюдались, тогда при вызове соответствующих функций мы намерено меняли значения EfiUsbDataIn и EfiUsbDataOut на противоположные.



Проблемы при получении USB-ответов (Fujitsu LifeBook E743, UEFI)



Внешне проблема проявлялась в том, что не все CCID-устройства работали в загрузчике. Старые семейства работали безотказно, новые нет. Выяснилось, что проблема возникает при вызове функции UsbBulkTransfer протокола EFI_USB_IO_PROTOCOL. Функция всегда возвращала ошибку EFI_DEVICE_ERROR.



Известно, что USB хост контроллер обменивается данными с устройствами пакетами фиксированной длины. Также разработчиками USB допускается, что устройство может вернуть короткий пакет. В таком случае хост контроллер вернет состояние завершения передачи не “Success” а “ Short Packet”. И драйвером USB этот ответ интерпретировался как ошибка. Т.е. функция UsbBulkTransfer всегда возвращала EFI_DEVICE_ERROR в случае если устройство ответило коротким пакетом.



Так и получилось, что старые семейства CCID всегда отвечали длинными пакетами, когда новые – короткими. Проблему удалось обойти посредством анализа выходного буфера. Ниже на рисунке представлен формат RDR_to_PC_DataBlock пакетов CCID-устройств. Этот пакет устройство возвращает на такие команды, как PC_to_RDR_IccPowerOn, PC_to_RDR_Secure и PC_to_RDR_XfrBlock.



#pragma pack( push, 1 )

struct RDR_to_PC_DataBlock {

UINT8 bMessageType;
UINT32 dwLength;
UINT8 bSlot;
UINT8 bSeq;
UINT8 bStatus;
UINT8 bError;
UINT8 bChainParameter;
UINT8* abData[0];

};

#pragma pack( pop )


Поле bMessageType идентифицирует тип пакета, и для RDR_to_PC_DataBlock пакета оно всегда равно 0x80. Поэтому перед получением ответа от устройства в буфере это поле предварительно обнулялось. Если функция UsbBulkTransfer возвращала ошибку, тогда проверялось значение этого поля, и если оно было равно 0x80, тогда считалось, что устройство на самом деле ответило корректно. В таком случае поле dwLength использовалось для вычисления размера ответа, и этот размер уже возвращался изначальному запросчику.



Проблемы при работе с картой памяти (Toshiba Satellite U200, BIOS)



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



Речь идет о сервисе 0xe820 прерывания int 15h. Т.к. загрузчик оставлял часть кода резидентно, требовалось выделять память и размещать его код в этом участке. Со своей стороны это требовало модификации карты памяти, чтобы операционная система во время своего запуска не использовала выделенный нами участок. Соответственно, во время запуска вся карта считывалась, должным образом модифицировалась и подменялась через перехват int 15h.



Ниже приведены входные и выходные параметры функции получения карты памяти.




  • Входные параметры:


    • EAX – код функции, всегда равен 0xe820;


    • EBX – продолжение, при первом вызове значение должно быть равно 0, при последующих значение должно быть равно значению, возвращенное функцией после вызова. Данный регистр указывает функции, с какой записи продолжить получение карты памяти;


    • ES:DI – указатель буфера, куда возвращается запись, описывающая конкретный диапазон памяти;


    • ECX – размер буфера, должно быть не меньше 20, т.к. первые ревизии этой функции возвращали записи размером 20 байт. На современных системах размер записи составляет 24 байта;


    • EDX – сигнатура, всегда равно 'SMAP'. Используется для верификации запросчика.




  • Выходные параметры:


    • CF – ошибка, если 0, значит ошибки нет;


    • EAX — сигнатура, всегда равно 'SMAP'. Используется для верификации BIOS;


    • ES:DI – указатель буфера, то же, что и на входе;


    • ECX – размер записи, который вернула функция;


    • EBX – значение, которое следует подать на вход функции для получения следующей записи. Также не следует делать предположения о самом значении, т.к. это может быть смещение, индекс или любая другая сущность во внутреннем представлении самой функции.




Посредством этой функции загрузчик в цикле вычитывает всю карту памяти. И загрузчик был разработан таким образом, чтобы обеспечить прямую совместимость с будущими версиями BIOS. Т.е. на входе регистр ECX содержал 64. Как следует из описания самой функции, функция в регистре ECX вернет размер записи, которая была записана в буфер. Поскольку на текущий момент максимальный размер записи 24, то больше, чем это значение, в регистре оказаться не могло. Также функция всегда должна возвращать ровно одну запись.



Однако на конкретном ноутбуке оказалось, что функция интерпретирует значение ECX несколько иначе. Т.е. она используется не для того чтобы определить размер записи, которую поддерживает запросчик, а для того чтобы определить, сколько функция может вернуть вообще записей за один вызов. Так и получилось, что при вызове функции загрузчик считывал не по одной записи, а по две. И, следовательно, одна из них всегда игнорировалась загрузчиком. Это и привело к тому, что загрузчик не смог найти участок памяти, в котором он мог бы разместить резидентный код.



Проблема была решена посредством передачи в ECX значения 24. Т.е. от идеи прямой совместимости пришлось отказаться. Были мысли о том, как определить размер записи, но, понимая стабильность разных версий BIOS, есть риск, что алгоритм из-за этого также не будет стабильно работать.



Проблемы при остановке USB 3.0 и переинициализации PIC контроллеров (HP, BIOS)



Визуально проблема выглядела так: после того, как пользователь успешно подключил смарт-карту и ввел ПИН, экран темнел, выводилось сообщение о том, что идет загрузка ОС, и все останавливалось именно на этом сообщении. ПК зависал намертво.



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



Предварительный анализ выявил, что процессор возвращался в реальный режим, но далее происходило повисание ПК. Далее выяснилось, что проблема возникала только в том случае, если загрузчик инициализировал USB хост контроллеры. Перед возвратом в реальный режим и перед возвратом PIC контроллера в исходное состояние также останавливались USB хост контроллеры.



USB 3.0 хост контроллер может иметь регистр USBLEGSUP. Данный регистр позволяет передавать управление контроллером от BIOS к ОС и наоборот. В первую очередь, это может понадобиться, например, для эмуляции классических клавиатурных портов ввода/вывода, дабы обеспечить совместимость со старым ПО. Т.е. при обращении к этим портам произойдет SMI прерывание, а все остальное уже сделает обработчик этого прерывания. А на современных машинах все чаще и чаще используются только USB-клавиатуры. Формат регистра описан ниже.




  • Capability ID (Биты 0-7) – идентификатор функциональности. Для данного регистра поле равно 1


  • Next Capability Pointer (Биты 8-15) – указатель на следующий capability регистр


  • HC BIOS Owned Semaphore (Бит 16) – если установлен, значит BIOS управляет хост контроллером


  • Зарезервировано (Биты 17-23)


  • HC OS Owned Semaphore (Бит 24) – перед использованием хост контроллера операционная система должна установить этот бит, в ответ на это BIOS сбросит бит 16, после чего можно использовать хост контроллер


  • Зарезервировано (Биты 25-31)



RTOS при остановке хост контроллера также сбрасывает бит 24 регистра USBLEGSUP. Таким образом, она возвращает управление над ним к BIOS. Далее RTOS выполняет возврат PIC контроллера в исходное состояние. Также известно, что PIC контроллер аппаратно уже не существует, и он также эмулируется посредствам SMM-режима. Следовательно, когда выполнялся возврат PIC контроллера в исходное состояние, при работе с его регистрами происходило SMI прерывание. Анализ выявил, что поскольку RTOS не дожидается установки бита 16 в регистре USBLEGSUP и поскольку сразу после установки бита 24 этого регистра выполнялся возврат PIC контроллера в исходное состояние, код режима SMM возвращал управление над хост контроллером, а PIC контроллер, который, по сути, породил SMI прерывание, не обрабатывался вообще. Поскольку инициализация PIC выполняется в несколько этапов, контроллер остался частично в непроинициализированном состоянии. Из-за этого ломалась доставка прерываний. Сразу после возврата процессора в реальный режим при первом прерывании процессор вставал на невалидный вектор, из-за чего он начинал выполнять бессмысленный поток инструкций.



Проблему удалось обойти посредством ожидания установки бита 16 в регистре USBLEGSUP перед возвратом PIC в исходное состояние.



Проблемы доставки прерываний от PIC контроллера (Dell Latitude E7240, BIOS)



Внешне проблема выглядела так: когда загрузчик запустился и вывел приглашение к подключению смарт-карты, загрузчик зависал намертво. При этом проблема возникала исключительно при перезагрузке ПК, при включении все работало нормально.



Предварительный анализ выявил, что процессор сваливался в page fault. Последующее изучение проблемы показало, что RTOS для каждого прерывания использует отдельные стеки, размер которых очень маленький (256 байт). Все эти стеки располагаются смежно, как это отражено на рисунке ниже.





Также удалось выяснить, что page fault происходил на странице памяти, которая следовала сразу перед страницей со стеками прерываний. Поэтому последующий анализ выполнялся уже на этом уровне.



RTOS при инициализации USB хост контроллера также включает доставку прерываний PIC с линии, на которой располагается контроллер. Обработчик прерывания при вызове разрешает все прерывания на процессоре, после чего последовательно вызывает зарегистрированные обработчики для этой линии. После вызова всех зарегистрированных обработчиков обработчик прерывания посылает команду завершения прерывания (EOI) PIC контроллеру.



Известно, что PIC контроллер имеет ISR регистр. Этот регистр используется для того, чтобы определить, какие прерывания в настоящий момент обрабатывает процессор, а какие нет. И если процессор обрабатывает конкретное прерывание, то даже если на соответствующей линии присутствует запрос, оно доставлено не будет. До тех пор, пока процессор не выдаст EOI команду PIC контроллеру, после чего PIC возобновит доставку этого прерывания.



Последующий анализ выявил, что в процессе вызова зарегистрированных обработчиков PIC контроллер доставлял прерывание повторно, даже несмотря на то, что команда EOI еще не была послана PIC. Безусловно, это ошибка эмуляции PIC контроллера. Это приводило к тому, что сначала переполнялся стек соответствующего прерывания, затем портился стек других прерываний, и, в конечном счете, доступ выполнялся к неотображенной странице памяти. И это приводило к page fault, обработчик которого останавливает работу загрузчика.



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



Заключение



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



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



После еще пары проблем с USB в UEFI я пришел к тому, чтобы в загрузчик поместить свои драйвера хост контроллеров. Для этого приходится останавливать те драйвера, что работают в самом UEFI, и загружать свои. Добавлять так называемые “костыли” мне никогда не импонировало. К тому же, такой код со временем станет тяжело развивать из-за нагроможденности.



А что касается своих драйверов, в этом есть большой смысл, т.к. есть FastBoot режим, который не гарантирует загрузку USB-драйверов. Это не баг, но камень в сторону самого UEFI как стандарта, который не предоставляет механизма догрузки незагруженных драйверов.



В завершение описания проблем хотелось бы отметить следующее: складывается впечатление, что нынешние BIOS/UEFI разрабатываются в отрыве от полного понимания принципов работы этих систем, либо тестирование не проводится должным образом. По опыту, и то и другое имеет место. Достаточно того, чтобы на произведенном ПК запускался Windows и Linux. Все остальное — издержки производства. А кого будет обвинять клиент, думаю, рассказывать не надо.



Исходя из опыта работы, BIOS и UEFI являются самыми нестабильными средами исполнения. В особенности, EFI MacBook является особым исключением, и работать с ним тяжелее всего. Но это уже другая история.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332908/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Digital_World

Как войти в BIOS компьютера

Понедельник, 10 Июля 2017 г. 14:06 (ссылка)


BIOS (англ. basic input/output system — «базовая система ввода-вывода») — реализованная в виде микропрограмм часть системного программного обеспечения, которая предназначается для обеспечения операционной системы API доступа к аппаратуре компьютера и подключенным к нему устройствам.



kak-zayti-v-bios-na-kompytere-digital-world (600x320, 63Kb)



BIOS представляет собой набор микропрограмм записанных в микросхему персонального компьютера. Я бы сказал, что это маленькая операционная система, которая при включении компьютера выполняет очень много действий. Как только вы включаете питания компьютера, при помощи программ записанных в БИОС происходит самопроверка аппаратных составляющих компьютера – POST. И если была обнаружена какая то проблема то BIOS выведет информацию которая поможет выявить причину сбоя. Кроме вывода информации на экран также используется звуковой сигнал, который воспроизводится через встроенный динамик. Если же никаких проблем не было обнаружено, BIOS ищет на всех доступных носителях загрузчик операционной системы и передает управления операционной системе. Для входа в систему BIOS чаще всего используются клавиши Del, F2 или Esc. Но это не всегда так есть и другие клавиши и их сочетания и для этого я приведу эти таблицы.



Комбинации клавиш от производителей BIOS: 


































Производитель BIOS

Клавиши

ALR Advanced Logic Research, Inc.

F2, Ctrl+Alt+Esc

AMD (Advanced Micro Devices, Inc.) BIOS

F1

AMI (American Megatrends, Inc.) BIOS

Del, F2

Award BIOS

Del, Ctrl+Alt+Esc

DTK (Dalatech Enterprises Co.) BIOS

Esc

Phoenix BIOS

Ctrl+Alt+Esc, Ctrl+Alt+S, Ctrl+Alt+Ins


Комбинации клавиш от производителей ПК и ноутбуков:






































































































































Производитель ПК

Клавиши

Acer

F1, F2, Ctrl+Alt+Esc

AST

Ctrl+Alt+Esc, Ctrl+Alt+Del

 

 

Compaq

F10

CompUSA

Del

Cybermax

Esc

 

 

Dell 400

F3, F1

Dell Dimension

F2, Del

Dell Inspiron

F2

Dell Latitude

F2, Fn+F1

Dell Optiplex

Del, F2

 

 

Dell Precision

F2

eMachine

Del

Gateway

F1, F2

HP (Hewlett-Packard)

F1, F2

Lenovo

F2

 

 

IBM

F1

IBM E-pro Laptop

F2

 

 

IBM PS/2

Ctrl+Alt+Ins, Ctrl+Alt+Del

IBM Lenovo Thinkpad

из Windows: Programs > Thinkpad CFG

Intel Tangent

Del

Micron

F1, F2 или Del

Packard Bell

F1, F2 или Del

Roverbook

Del

Sony VAIO

F2, F3

Tiget

Del

Toshiba

Esc, F1


Вы спросите, а для чего заходить в этот BIOS и что там делать? На самом деле эта систем содержит очень много настроек и информации о компьютере, я сейчас не буду рассматривать каждый из пунктов этой системы это уже другая статья. Но я скажу, что с помощью БИОС можно сделать очень много полезных и интересных вещей. Например, при установке операционной систем вам скорее всего придется зайти в BIOS и выбрать порядок загрузки компьютера с дисковода, а затем уже с жесткого диска, это даст возможность загрузится с CD или DVD диска и установить операционную систему. Так же можно немножко «разогнать» процессор в разных производителей материнских плат и версиях BIOS это можно сделать по разному. Но не советую увлекаться, так как это может привести к тому, что компьютер перестанет запускаться или же к полному выходу из строя некоторых комплектующих компьютера. Нужно помнить, что в BIOS есть возможность сбросить все настройки (с которыми мы на экспериментировали) к заводским. Но если нет возможности зайти в BIOS и сделать это ( например компьютер отказывается запускаться) тогда сделать это можно на самой материнской плате. Для этого выключаем компьютер, отключаем его от электросети открываем корпус и ищем на материнской плате два контакта, лучше всего посмотрите инструкцию к материнской плате они там указаны. После того как вы их найдете их нужно замкнуть отверткой или другим металлическим предметом. Все настройки BIOS сброшены к настройкам по умолчанию, и вы можете попробовать включить свой компьютер. Удачи. Ждем Ваши отзывы в коментариях!!!



Источник: Digital World


Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ferderfre

Прилунение американских астронавтов показали на видео

Пятница, 09 Июня 2017 г. 13:51 (ссылка)

Гpафический дизайнeр Кристиан Стангл (Christian Stangl) использовал тысячи фотоснимков из архивoв космической пpогpаммы «Аполлон», чтобы на их основе создать коpоткометpажный фильм Lunar о путешествии астpонавтов на Луну. На pолик обpатило внимание издание Gizmodo.

Стангл использовал нeсколько подходов. Он бpал нeсколько фотогpафий и соединял их друг с другом для получения паноpамного изобpажения, котоpое затем «оживлялось» с помощью анимации. Часть снимков стали последовательными кадpами фильма. На создание Lunar ушло два года.

Комментарии (0)КомментироватьВ цитатник или сообщество
Аноним

Среда, 01 Декабря 1970 г. 03:00 (ссылка)

Комментарии ()КомментироватьВ цитатник или сообщество
shellyq8211

Без заголовка

Воскресенье, 02 Апреля 2017 г. 13:50 (ссылка)

Настройки bios ноутбука в Кемерово, Березовском,Топках, Ленинске-Кузнецком, Белово, Гурьевске, Анжеро-Судженске, Юрге, Яшкино, Тайге - https://vk.com/page-129468244_52806974

Комментарии (0)КомментироватьВ цитатник или сообщество
nobuyatomynori

Без заголовка

Воскресенье, 02 Апреля 2017 г. 09:54 (ссылка)

Настройка bios asus в Кемерово, Березовском,Топках, Ленинске-Кузнецком, Белово, Гурьевске, Анжеро-Судженске, Юрге, Яшкино, Тайге - https://vk.com/page-129468244_52806611

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<bios - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda