Из за чего ломается биос

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

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

Что может повредить BIOS

Биос (Основная система ввода/вывода) — это программа, которая обеспечивает коммуникацию между операционной системой и аппаратным обеспечением компьютера. Он является важной частью любого ПК или ноутбука и отвечает за его запуск, а также за конфигурацию и управление аппаратными устройствами.

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

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

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

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

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

Основные причины поломки биоса

Основные причины поломки биоса включают:

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

2. Электрические проблемы: Колебания напряжения или статические разряды способны повредить чипы и другие элементы BIOS, что может привести к его поломке.

3. Вредоносные программы: Вирусы и трояны могут заразить BIOS, нанося ущерб его работоспособности.

4. Неверные настройки: Неправильные параметры в BIOS, такие как неверно выбранные настройки или чрезмерный разгон, могут привести к сбоям в его работе и неработоспособности компьютера.

5. Повреждение или неисправность аппаратных компонентов: Дефектные или поврежденные компоненты, например, материнская плата или процессор, могут привести к неработоспособности биоса и поломке компьютера.

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

Перегрев процессора

При чрезмерном нагреве процессора существует риск его повреждения, что в итоге может привести к выходу из строя биоса.

Причины перегрева процессора могут быть различными:

1.	Неэффективное охлаждение ЦП. Когда система охлаждения не работает должным образом, центральный процессор не способен должным образом рассеивать тепло, что ведет к его перегреву.
2.	Неправильные настройки работы процессора. Ошибочные параметры, такие как завышенные значения частоты или напряжения, могут привести к нагреванию ЦП.
3.	Засорение системы охлаждения. Пыль, грязь и другие мусорные частицы могут забивать вентиляторы и радиаторы, что уменьшает их эффективность и увеличивает риск перегрева процессора.

Для предотвращения перегрева процессора и возможных проблем с BIOS необходимо предпринимать следующие действия:

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

Если процессор всё-таки перегрелся и была обнаружена поломка биоса, возможны следующие способы ремонта:

Попытка перепрошивки BIOS. Для этого может понадобиться специализированный программатор для записи нового образа в чип материнской платы.
Замена чипа BIOS. Если перезапись прошла неудачно или осуществить ее невозможно, может потребоваться замена чипа.
Консультация с профессионалами. Если вам нужна квалифицированная помощь, разумнее обратиться к специалистам, имеющим опыт в восстановлении BIOS и ремонте системы.

Предотвращение перегрева процессора является самым эффективным способом избежать повреждений BIOS и общих проблем с компьютером.

Неисправность оперативной памяти

Одной из частых причин выхода из строя оперативной памяти является её перегрев. Система охлаждения компьютера может оказаться неэффективной или повреждённой, что вызывает перегрев модулей памяти. Это, в свою очередь, может привести к повреждению чипов ОЗУ и их неправильному функционированию.

Возможно неисправность оперативной памяти из-за неправильного подключения модулей ОЗУ или несовместимости модулей с материнской платой. В этом случае компьютер может не загружаться или работать нестабильно.

Проблемы с оперативной памятью могут привести к сбоям при чтении и записи данных, возникновению "синего экрана смерти" (BSOD), зависаниям системы и многим другим затруднениям. Если вы наблюдаете такие признаки, то вероятно, что дело в неисправной оперативной памяти.

В случае неисправности оперативной памяти могут потребоваться следующие действия:

Убедитесь в корректном физическом подключении планок оперативной памяти к материнской плате. Проверьте, что они правильно размещены в слотах и надежно зафиксированы.
Проверьте, совместимы ли планки ОЗУ с материнской платой и соответствуют ли их максимальные частоты поддерживаемым значениям. Убедитесь, что они отвечают требованиям вашей системы.
Проведите диагностику оперативной памяти с помощью специальных утилит, например, Memtest86+. Это поможет выявить возможные ошибки и проблемы с модулями ОЗУ.
В случае, если оперативная память оказалась неисправной, замените ее на новую. При выборе модулей ОЗУ обратите внимание на их совместимость и параметры.
Если причиной проблем с ОЗУ является перегрев, установите дополнительные системы охлаждения или отремонтируйте неисправную систему охлаждения вашего компьютера.

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

Вирусные атаки на ПК

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

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

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

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

Неправильное обновление BIOS

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

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

Дефекты BIOS и проблемы совместимости

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

Не секрет, что ни одна BIOS не может обслуживать все разнообразие существующей компьютерной аппаратуры и успевать за развитием устройств, которые должны поддерживаться со стороны BIOS. Разработчики компьютерных технологий решили эту проблему в использовании драйверов устройств. Первые модели дисководов CD-ROM являются прекрасной иллюстрацией сказанному.

Каждая модель CD-ROM-дисковода имела свои уникальные схемы управления накопителем и взаимодействия с компьютером. Ни одна прикладная программа, а также DOS и BIOS не могли идентифицировать произвольный накопитель или интерфейс. Чтобы решить эту проблему, при загрузке компьютера с диска в оперативную память загружается драйвер устройства низкого уровня.

Драйвер преобразует стандартные вызовы операционной системы в команды, необходимые для работы адаптера и накопителя. После загрузки драйвера в DOS также загружается программа MSCDEX. Она совместно с MSDOS.SYS обеспечивает прикладным программам доступ к дисководу CD-ROM, аналогичный доступу к жестким и гибким дискам.

Проще говоря, все драйверы устройств представляют собой дополнения к BIOS и служат для обеспечения взаимодействия операционной системы с определённым оборудованием. Драйверы также необходимы для работы видеокарт, SCSI и сетевых адаптеров. Современные BIOS обладают функцией определения и поддержки работы загрузочных дисководов CD-ROM, соответствующих стандарту EI Torito. 6.4.1.

Использование теневого ОЗУ BIOS Другой проблемой использования микросхем BIOS является традиционно невысокая скорость их функционирования. Современные версии BIOS записываются в перепрограммируемые микросхемы ПЗУ, для обновления которых не требуется специальное оборудование. В отличие от них, старые версии BIOS записывались в стандартные микросхемы ПЗУ, для записи которых использовалось отдельное программаторное устройство.

Использование для хранения BIOS постоянного запоминающего устройства (ПЗУ) обуславливалась необходимостью сохранения данных BIOS даже во время выключения питания компьютера. К сожалению, устройства постоянной памяти (ПЗУ) имеют очень большое время доступа (от 150 до 200 не) по сравнению с обычной памятью, используемой в компьютерах (время доступа к которой не превышает 70 не, а у современных видов гораздо меньше).

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

Поэтому разработчики ПК нашли альтернативное решение — использование теневого ОЗУ (ROM shadowing). Идея состоит в копировании содержимого микросхемы ПЗУ BIOS в верхнюю область памяти ОЗУ (upper memory area, UMA). После копирования система может работать с копией BIOS, а не с оригиналом. В результате время доступа к служебным программам BIOS становится равным времени доступа к быстрому ОЗУ.

Теневое ОЗУ можно применять как для системной BIOS, так и для других BIOS компьютера, при этом чаще всего оно используется для видео BIOS. Включение или отключение теневого ОЗУ возможно через программу CMOS Setup. Однако не все BIOS поддерживают использование теневого ОЗУ, что может вызвать проблемы вплоть до нестабильной работы и зависаний системы.

Если возникают трудности с настройкой системы, целесообразно рассмотреть возможность деактивации всех теневых ОЗУ. В дальнейшем можно повторно активировать теневое ОЗУ, если причина неполадок окажется иной. Также доступна бесплатная лекция: "Обязанности ответственного за газовое хозяйство". 6.4.2.

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

Концепция прямого контроля над аппаратурой не является новшеством — в персональных компьютерах, которые предшествовали IBM-совместимым моделям, прикладные программы осуществляли управление аппаратурой напрямую. Компания IBM представила использование BIOS с целью гарантировать совместимость аппаратных изменений с операционной системой и прикладным программным обеспечением.

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

К примеру, мощный ускоритель трехмерной графики 3Dfx Voodoo 3 функционирует через драйверы, не прибегая к использованию системных утилит BIOS. Этот метод имеет заметный недостаток: прямое управление аппаратным обеспечением может не поддерживаться на всех конфигурациях систем, и любые изменения в оборудовании компьютера (как, например, апгрейд или замена отдельных компонентов) могут привести к некорректной работе системы при запуске определенных приложений или драйверов.

6.4.3. Ошибки программного обеспечения BIOS Как и любой другой программный продукт, BIOS способен содержать разные ошибки или недочеты. После его разработки BIOS дублируется в большом количестве и передается производителям материнских плат, которые устанавливают их на свои устройства. При наличии ошибки в BIOS система может зависать, неожиданно сбойнуть или некорректно работать при выполнении определенных функций.

Поскольку одна и та же версия BIOS используется на разных системных платах, то ошибка может и не проявиться в каждом случае. Например, некоторые пользователи AMI BIOS (датированной 04/09/90 и позднее) сообщают о проблемах с контроллером клавиатуры при работе операционных систем Windows или OS/2. Ошибки BIOS наихудшим образом сказываются на работе компьютера.

Если в прикладном ПО возникает ошибка, то его использование может быть приостановлено. BIOS не подлежит отключению, поэтому в случае выявления ошибки существует несколько вариантов решения: замена микросхемы BIOS, обновление прошивки или замена всей системной платы. При возникновении проблем с работой ПК пользователю следует сначала обратиться к производителю BIOS через службу технической поддержки или официальный сайт, чтобы узнать о возможных известных ошибках в данной версии BIOS для конкретных моделей материнских плат. К примеру, определённая версия Phoenix BIOS может демонстрировать сбои при использовании с некоторыми материнскими платами от Intel. Если ваши симптомы совпадают с ранее отмеченными, замена BIOS может значительно сократить время простоя неисправного компьютера.

Поделитесь ссылкой:

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

В этой статье я приведу описание багов в 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 – параметр, который нужно передать функции для запроса следующей записи. Также нельзя делать предположения о значении, так как это может быть смещение, индекс или какая-либо иная сущность в внутреннем представлении функции.

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

Решение проблемы заключалось в передаче значения 24 в ECX. Таким образом, от идеи полной совместимости было решено отказаться. Появлялись идеи о том, как определить размер записи, но учитывая разнообразие версий 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) – указатель на следующий регистр функциональности
HC BIOS Owned Semaphore (Бит 16) – если этот бит активирован, значит, BIOS контролирует хост-контроллер
Зарезервировано (Биты 17-23)
HC OS Владение Семафором (Бит 24) – перед тем как начать работу с хост-контроллером, операционная система обязана установить этот бит. В ответ BIOS сбросит бит 16, что позволит использовать хост-контроллер
Зарезервировано (Биты 25-31)

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

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

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

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

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

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

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

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

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

Почему ломается BIOS: основные причины и советы по устранению проблем