Специально для того, чтобы настройки MPU можно было изменить, для обработчиков прерываний MemManage Fault и HardFault Fault сделано аппаратное исключение - если бит HFNMIENA установлен в 0, то HardFault в MemManage_Handlerне происходит.
Вот цитата из TRM:
HFNMIENA - This bit enables the MPU when in Hard Fault, NMI, and FAULTMASK escalated handlers. If this bit = 1 and the ENABLE bit = 1, the MPU is enabled when in these handlers. If this bit = 0, the MPU is disabled when in these handlers, regardless of the value of ENABLE.
Я немного поисследовал вопрос, происходит ли запись вместе с прерыванием, если она запрещена в MPU, и не нашел никаких подтверждений, что она она всё равно происходит. Вероятно, у вас она выполняется после возвращения из прерывания, в котором отключается MPU - в этом случае она и должна происходить. А так, множество ОС используют этот механизм совместно с разделением процессов на privileged и unprivileged, и успешно защищают память в версиях ядра M3 и M4 безо всякого TrustZone. Например, Zephyr или FreeRTOS-MPU.
Там скорее недовереному коду должно быть запрещёно вообще писать в какие-либо регистры управления ядром и периферией самостоятельно, он должен делать это через ОС. Такому процессу должен быть разрешен доступ только к его собственному коду в ROM и его данным в RAM, и запрещено всё остальное. Возможно, кроме записи в экранный буфер, если он есть. Правила перекрытия регионов в MPU позволяют сделать это достаточно легко.
Невозможен будет возврат к коду, который вызвал срабатывание обработчика, и продолжение его выполнения. Но это и не должно происходить - обработчик должен остановить выполнение процесса, нарушившего права доступа к памяти, инициировать его повторную инициализацию при необходимости, и переключиться на другие процессы. При этом в самом обработчике MemManage Fault переконфигурирование MPU может быть разрешено установкой специального бита HFNMIENA в MPU Control Register в 0.
Я сам не использовал MPU, но, насколько я понимаю, от отключения MPU можно защититься настройкой MPU так, чтобы его регистры, регистры управления прерываниями, и область памяти с векторами прерываний были защищены от записи. Тогда при попытке записи произойдёт прерывание MemManage Fault, которое будет гарантировано обработано кодом ОС. Правда, в этой статье говорится, что запись при этом всё-таки произойдёт, поэтому в этом случае вероятно потребуется перезагрузка, хотя не обязательно. Наверное, это недоработка в железе, запись в этом случае происходить не должна.
Перечисленные применения - это не главное, для чего предназначен MPU. Его главная задача - исключить для недоверенного процесса возможность как-то повлиять на код и данные операционной системы и других процессов. Это позволяет одновременно выполнять на одном ядре сертифицированный по функциональной безопасности код, и кроме того ещё и какой-то некритический код, который в случае проблем может быть отдельно перезапущен, перезагружен, и обновлён без прерывания работы всей системы.
Кроме того, MPU позволяет защитить часть кода в системе от считывания из другой части кода, что может быть важно для обеспечения секретности его алгоритмов работы. Например, так код радиомодуля может быть защищён от считывания из пользовательского кода и дизассемблирования.
В ближней перспективе наиболее массовая задача - кэширование интернета для его раздачи с низкоорбитальных спутниковых созвездий вроде Старлинк. Чтобы популярный в моменте ролик Youtube не передавался на спутник с Земли, а хранился либо на самом спутнике, либо в отдельном специальном спутнике на немного более высокой орбите. Во втором случае преимущество - возможность использования более высокоскоростного лазерного канала связи.
В дальней перспективе наиболее массовая задача - обеспечение серверов ИИ солнечной энергией без использования для этого площадей на Земле, и с большей эффективностью за счёт почти постоянной освещенности панелей на высоких орбитах.
Я имею в виду обновление прошивки не пользователем, а производителем или продавцом. Такая необходимость может появиться после какого-нибудь опасного происшествия, вместо того, чтобы отзывать уже отгруженные устройства, можно обновить им ПО. Другого смысла выводить на USB линии данных в серийном устройстве я не вижу. Если линии данных не выведены, то такая возможность однозначно не предусмотрена, а если выведены - думаю, о ней по крайней мере думали. В некоторых микроконтроллерах есть предпрошитый загрузчик с USB, там для обновления через USB не нужно писать специальный софт - всё уже есть, достаточно вывести линии данных.
Чёрные дыры могут взрываться из-за Хоккинговского испарения. Скорость испарения нарастает с потерей массы, и в какой-то момент становится взрывной. Чёрные дыры звёздных масс не смогут испариться до такой степени ещё очень долго, но тут речь о первичных чёрных дырах, предполагается, что среди них могут быть и совсем маленькие.
Подгорел немного, вот и выглядит не очень. В норме должен быть полностью чёрным после нескольких полётов, вполне в эстетике боевого имперского космического эсминца. Это, конечно, гораздо мрачнее сверкающих космолётов 60х, но тоже по-своему красиво.
Спасибо за подробный ответ. Мне интересно в первую очередь, какой вклад могут попытаться сделать любители в астрономическую науку, участвуя в наблюдениях этого покрытия. Например, при покрытии карликовыми планетами или астероидами звезд данные каждого наблюдавшего это явление любителя могли дополнить полученную информацию о карликовой планете или астероиде. А есть ли подобные общественные проекты для покрытия Плеяд?
Что касается наблюдения красивого, то Плеяды очень красивы сами по себе, и их покрытие Луной вряд ли способно на мой взгляд что-то к этому добавить. Скорее наоборот, серп Луны может дать засветку, которая ухудшит условия наблюдений.
Неясным осталось главное - что может дать наблюдение покрытия Плеяд Луной с точки зрения возможных астрономических открытий? Или это просто редкое событие, которое интересно только своей редкостью?
Маск в интервью говорил, что подбор зазоров - это сложная задача, как раз из-за теплового расширения плиток. Просто температура их наружной поверхности очень высокая, за счёт их хороших теплоизорлирующих свойств. А это даёт заметное расширение даже при относительно малом температурном коэффициенте линейного расширения.
Боковые манёвры возможны уже на высотах 60-80 км. Это всё ещё горячий участок.
Не понял почему нижние края плиток можно сделать немного толще. Насколько я понимаю, плитки расширяются как единое целое не смотря на меньший нагрев их внутренней поверхности - тепловое расширение их наружной поверхности растягивает и внутреннюю поверхность тоже.
Сейчас зазоры между плитками намного больше технологического минимума, который нужен для их замены и учёта погрешностей их изготовления. Потому что плитки нагреваются до высоких температур, и сильно расширяются из-за этого. Я говорю о том, что зазоры в холодном состоянии можно уменьшить до технологического минимума, а в горячем состоянии они закроются совсем за счёт температурного расширения плиток.
Если повернуть плитки на 90 градусов, то боковые края плиток будут иметь только 30-градусное отклонение от оси корабля. При углах атаки порядка 40 градусов и длительном большом крене при боковых маневрах 30-градусное отклонение щелей не спасёт - в некоторых положениях корабля некоторые щели будут при этом открыты для набегающего потока, и молекулы воздуха при полёте в разреженной атмосфере в этих местах будут передавать всю свою энергию абляционному слою. Другое дело, что можно сделать плитки с перекрывающимися выступами по краям, но это может осложнить их быструю замену. Наверное есть какой-то компромиссный вариант между улучшением теплозащиты и лёгкостью замены - например, плитки могут перекрываться только в нагретом и расширенном состоянии, а в холодном точно совпадать друг с другом, не оставляя щели существенной ширины. Мне такой вариант кажется надёжнее, чем хрупкое керамическое волокно.
Выходит, они будут менять всю теплозащиту, чтобы установить эту "хрустящую плёнку". Это может занять много времени. А испытания Starlink v3 снова откладываются, не вполне понятно почему.
Специально для того, чтобы настройки MPU можно было изменить, для обработчиков прерываний MemManage Fault и HardFault Fault сделано аппаратное исключение - если бит HFNMIENA установлен в 0, то HardFault в MemManage_Handler не происходит.
Вот цитата из TRM:
Я немного поисследовал вопрос, происходит ли запись вместе с прерыванием, если она запрещена в MPU, и не нашел никаких подтверждений, что она она всё равно происходит. Вероятно, у вас она выполняется после возвращения из прерывания, в котором отключается MPU - в этом случае она и должна происходить. А так, множество ОС используют этот механизм совместно с разделением процессов на privileged и unprivileged, и успешно защищают память в версиях ядра M3 и M4 безо всякого TrustZone. Например, Zephyr или FreeRTOS-MPU.
Там скорее недовереному коду должно быть запрещёно вообще писать в какие-либо регистры управления ядром и периферией самостоятельно, он должен делать это через ОС. Такому процессу должен быть разрешен доступ только к его собственному коду в ROM и его данным в RAM, и запрещено всё остальное. Возможно, кроме записи в экранный буфер, если он есть. Правила перекрытия регионов в MPU позволяют сделать это достаточно легко.
Невозможен будет возврат к коду, который вызвал срабатывание обработчика, и продолжение его выполнения. Но это и не должно происходить - обработчик должен остановить выполнение процесса, нарушившего права доступа к памяти, инициировать его повторную инициализацию при необходимости, и переключиться на другие процессы. При этом в самом обработчике MemManage Fault переконфигурирование MPU может быть разрешено установкой специального бита HFNMIENA в MPU Control Register в 0.
Я сам не использовал MPU, но, насколько я понимаю, от отключения MPU можно защититься настройкой MPU так, чтобы его регистры, регистры управления прерываниями, и область памяти с векторами прерываний были защищены от записи. Тогда при попытке записи произойдёт прерывание MemManage Fault, которое будет гарантировано обработано кодом ОС. Правда, в этой статье говорится, что запись при этом всё-таки произойдёт, поэтому в этом случае вероятно потребуется перезагрузка, хотя не обязательно. Наверное, это недоработка в железе, запись в этом случае происходить не должна.
Перечисленные применения - это не главное, для чего предназначен MPU. Его главная задача - исключить для недоверенного процесса возможность как-то повлиять на код и данные операционной системы и других процессов. Это позволяет одновременно выполнять на одном ядре сертифицированный по функциональной безопасности код, и кроме того ещё и какой-то некритический код, который в случае проблем может быть отдельно перезапущен, перезагружен, и обновлён без прерывания работы всей системы.
Кроме того, MPU позволяет защитить часть кода в системе от считывания из другой части кода, что может быть важно для обеспечения секретности его алгоритмов работы. Например, так код радиомодуля может быть защищён от считывания из пользовательского кода и дизассемблирования.
В ближней перспективе наиболее массовая задача - кэширование интернета для его раздачи с низкоорбитальных спутниковых созвездий вроде Старлинк. Чтобы популярный в моменте ролик Youtube не передавался на спутник с Земли, а хранился либо на самом спутнике, либо в отдельном специальном спутнике на немного более высокой орбите. Во втором случае преимущество - возможность использования более высокоскоростного лазерного канала связи.
В дальней перспективе наиболее массовая задача - обеспечение серверов ИИ солнечной энергией без использования для этого площадей на Земле, и с большей эффективностью за счёт почти постоянной освещенности панелей на высоких орбитах.
Я имею в виду обновление прошивки не пользователем, а производителем или продавцом. Такая необходимость может появиться после какого-нибудь опасного происшествия, вместо того, чтобы отзывать уже отгруженные устройства, можно обновить им ПО. Другого смысла выводить на USB линии данных в серийном устройстве я не вижу. Если линии данных не выведены, то такая возможность однозначно не предусмотрена, а если выведены - думаю, о ней по крайней мере думали. В некоторых микроконтроллерах есть предпрошитый загрузчик с USB, там для обновления через USB не нужно писать специальный софт - всё уже есть, достаточно вывести линии данных.
Сама необходимость зарядки - это не требование ЕС, требование ЕС - это чтобы разъём зарядки был USB-C.
Для зарядки, это требование ЕС. И заодно, наверное, для обновления прошивки.
Чёрные дыры могут взрываться из-за Хоккинговского испарения. Скорость испарения нарастает с потерей массы, и в какой-то момент становится взрывной. Чёрные дыры звёздных масс не смогут испариться до такой степени ещё очень долго, но тут речь о первичных чёрных дырах, предполагается, что среди них могут быть и совсем маленькие.
Подгорел немного, вот и выглядит не очень. В норме должен быть полностью чёрным после нескольких полётов, вполне в эстетике боевого имперского космического эсминца. Это, конечно, гораздо мрачнее сверкающих космолётов 60х, но тоже по-своему красиво.
Спасибо за подробный ответ. Мне интересно в первую очередь, какой вклад могут попытаться сделать любители в астрономическую науку, участвуя в наблюдениях этого покрытия. Например, при покрытии карликовыми планетами или астероидами звезд данные каждого наблюдавшего это явление любителя могли дополнить полученную информацию о карликовой планете или астероиде. А есть ли подобные общественные проекты для покрытия Плеяд?
Что касается наблюдения красивого, то Плеяды очень красивы сами по себе, и их покрытие Луной вряд ли способно на мой взгляд что-то к этому добавить. Скорее наоборот, серп Луны может дать засветку, которая ухудшит условия наблюдений.
del
Неясным осталось главное - что может дать наблюдение покрытия Плеяд Луной с точки зрения возможных астрономических открытий? Или это просто редкое событие, которое интересно только своей редкостью?
Маск в интервью говорил, что подбор зазоров - это сложная задача, как раз из-за теплового расширения плиток. Просто температура их наружной поверхности очень высокая, за счёт их хороших теплоизорлирующих свойств. А это даёт заметное расширение даже при относительно малом температурном коэффициенте линейного расширения.
Боковые манёвры возможны уже на высотах 60-80 км. Это всё ещё горячий участок.
Не понял почему нижние края плиток можно сделать немного толще. Насколько я понимаю, плитки расширяются как единое целое не смотря на меньший нагрев их внутренней поверхности - тепловое расширение их наружной поверхности растягивает и внутреннюю поверхность тоже.
Сейчас зазоры между плитками намного больше технологического минимума, который нужен для их замены и учёта погрешностей их изготовления. Потому что плитки нагреваются до высоких температур, и сильно расширяются из-за этого. Я говорю о том, что зазоры в холодном состоянии можно уменьшить до технологического минимума, а в горячем состоянии они закроются совсем за счёт температурного расширения плиток.
Если повернуть плитки на 90 градусов, то боковые края плиток будут иметь только 30-градусное отклонение от оси корабля. При углах атаки порядка 40 градусов и длительном большом крене при боковых маневрах 30-градусное отклонение щелей не спасёт - в некоторых положениях корабля некоторые щели будут при этом открыты для набегающего потока, и молекулы воздуха при полёте в разреженной атмосфере в этих местах будут передавать всю свою энергию абляционному слою. Другое дело, что можно сделать плитки с перекрывающимися выступами по краям, но это может осложнить их быструю замену. Наверное есть какой-то компромиссный вариант между улучшением теплозащиты и лёгкостью замены - например, плитки могут перекрываться только в нагретом и расширенном состоянии, а в холодном точно совпадать друг с другом, не оставляя щели существенной ширины. Мне такой вариант кажется надёжнее, чем хрупкое керамическое волокно.
Выходит, они будут менять всю теплозащиту, чтобы установить эту "хрустящую плёнку". Это может занять много времени. А испытания Starlink v3 снова откладываются, не вполне понятно почему.