Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
neemestniii
Я вам как электронщик скажу - процедуры Remap, Low Level Format (LLF) запускает плата электроники диска под управлением его микропрограммы, но специальное ПО может выдать запрос на осуществление процедуры Remap, а окончательное решение о её осуществлении принимает алгоритм прошивки.
Что касается ОС, тут свои сложности - чтобы передать в контроллер привилегированную команду "проверить возможность и при необходимости запустить процедуру Remap / LLF " нужно записать её код в командные регистры платы в технологическом режиме работы диска, что осуществимо только с помощью специальной схемы его включения и зачастую требует ручной установки в определённые положения не документированных переключателей или перемычек на плате контроллера. Так что в обычном режиме вы не сможете управлять системой самодиагностики и исправления ошибок диска, а потому максимум что доступно пользователю это считывание журналов системы самодиагностики S.M.A.R.T. и расшифровка значений атрибутов 0x00 - 0x0F назначение которых фиксировано в спецификациях S.M.A.R.T., а интерпретация атрибутов с большими номерами зависит от производителя, хотя и тут есть некоторые общие договорённости "по умолчанию", но они не закреплены спецификацией и могут быть изменены производителем в любой момент и для любой модели, а потому однозначно полагаться на них нельзя.
И конкретно относительно ОС семейства Windows NT - более ранние по времени разработки 32-х битные ОС семейства, начиная с Windows NT 3.1 и до Windows XP допускали возможность прямого обращения к портам дискового контроллера сторонних драйверов что сделало возможным работу программы Victoria в режиме PIO, в 64-х битных ОС, в том числе в изданиях Windows NT 3.1 AXP (для процессоров DEC Alpha AXP 21x64/24x66/21x68) и Windows NT 3.1 Power (для ЦП IBM Power) такой возможности нет на уровне HAL (Hardware Abstraction Layer) поскольку в этом режиме контроллер памяти ЦП аппаратно изолирует адресные пространства 32-х и 64-х битных запущенных процессов что делает не возможным прямой доступ ПО к портам аппаратуры.
В 64-х битных ОС семейства UNIX пользовательские процессы вообще не имеют доступа к аппаратуре в обход ОС что в 93-м вызывало вопросы у многих программистов:
"Вы говорите что процессор Alpha AXP совместим по архитектуре и набору инструкций с ЦП nVAX, и отличается только тем, что у него больше регистров, и добавлены новые инструкции для работы с фиксированной и плавающей точкой, а так же что он может исполнять двоичные программы для других процессоров без потери производительности и их переделки, и что любым программам доступно 264 байт памяти. Но его поведение говорит что это совсем иной ЦП который ни программы, ни я не знаем, а значит для него нужно писать программы заново!
На PDP 11 (там стоял 32-х битный процессор nVAX) любая программа работает, а на DEC Server 4000 AXP (там стояли 4 ЦП Alpha AXP 21064A на 190 MHz) падает! Объясните мне чем новый 64-х битный ЦП принципиально отличается от 32-х битных и что надо исправить в программах чтобы они не падали? По моему их отличия только в том, что на 64-х битном процессоре можно сложные вещи считать!".
А вы говорите купаться.
Добавлено:
Ну а причина почему в 64-х битной ОС не возможно прямо обратится к железу достаточно проста - в архитектуре IBM PC управление устройствами осуществляется через код BIOS, а он 16-х битный поскольку в начальный момент запуска любого IA32/IA64-совместимого (IA - Intel Architecture) ЦП он работает в режиме Real Mode и для программ BIOS выглядит как i8086, и только зашитые в BIOS тесты после обработки возвращённой командой CPUID строки распознают конкретный тип ЦП, после чего BIOS находит в своих таблицах подходящую именно для него строку начальных настроек и перезапускает ЦП в Protected Mode с применением указанных в ней параметров, а после этого запускает следующие процедуры нужные для запуска машины. А сами режимы Real Mode и Protected Mode имеют разные аппаратно-изолированные адресные пространства, так что работающая в Protected Mode программа должна сама выполнять все аппаратно-зависимые протоколы I/O, а разработчики устройств далеко не всегда, а главное очень не охотно делятся информацией о том, как их устройство управляется. Я сам такой, и причина проста - мне некогда возится с ответами на сложные вопросы не участвовавших в разработке людей. Потому наши программисты подключаются к проекту в тот момент времени когда у меня на столе уже лежит готовый макет будущего изделия и основные электронные проблемы и ошибки я уже устранил, а его реализация соответствует требованиям ТЗ. А вот дальше они вместе со мной работают над ним вплоть до момента когда изделие пройдёт приёмо-сдаточные испытания после чего я занимаюсь новым проектом с нуля, а они под этот математику пишут, хотя с момента как мне на стол ляжет новое ТЗ они в схемные дела не лезут, но ТЗ изучают и периодически спрашивают у меня что я им предоставлю. И понятно думают как с эти работать, но на этой стадии мы работаем в большой степени независимо друг от друга...
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Всего записей: 34481 | Зарегистр. 31-07-2002 | Отправлено: 08:15 04-01-2020 | Исправлено: Victor_VG, 08:25 04-01-2020 |
|
