>[оверквотинг удален]
> UEFI также может обновлять сам себя, но опять же работает начиная со
> следующей загрузки..
> Определенный код UEFI работает во время работы ОС - не тот, который
> загружает, а отдельные т.н. runtime-сервисы - например, задумывалось, что UEFI может
> предоставить драйверы устройств, незнакомых операционке, реализованные в виде кода для
> нее. Но практически ОС (как минимум винда и линукс) не обращаются
> к runtime-сервисам, т.к. это сложно организовать безопасно. Поэтому как-то сказать UEFI,
> что нужно выполнять новый залитый код или подобное не выйдет.
> Из http://vzimmer.blogspot.ru/2012/12/accessing-uefi-form-opera...
>> The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid. The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point. The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999. Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks). Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.Это я не к тому, что бы сказать очевидную вещь, а для того что бы сказать еще более очевидную вещь: аппаратный триггер необходимо ставить. Который переключается только в одну сторону и только один раз (до следующего "аппаратного" reset-а). Фирмварь по завершению работы переключит этот триггер, и тем самым (аппаратно) снимет напряжение питания (для записи) с соответствующей ножки микрухи.
|
