[mantech 40]

11 часов назад, aaarrr сказал:

дашь проц с MMU - отключите,

Зачем это? Ну не надо виртуальных адресов - используй физические)))

11 часов назад, aaarrr сказал:

запустишь ОС на проце без MMU

Какой смысл от такой ОС? Кроме консоли?))))))))))

[dxp 53]

20 минут назад, mantech сказал:

Какой смысл от такой ОС? Кроме консоли?))))))))))

Какой-то смысл есть. ADI вложили прилично усилий в uCLinux для своего Blackfin, у которого нет MMU (хотя в остальном проц вполне для своего времени норм -- быстрый, кэши и т.п.). Позиционировали они его в том числе и как мультимедийный процессор для построения на его основе разного рода музыкальных и видео плейеров. Если всё это делать на baremetal, то это путь портирования кучи софта, который уже есть, который отлажен и исправно работает -- это разного рода кодеки, конвертеры форматов.

А имея Linux -- пусть даже в кастрированной версии uCLlinux, весь этот зоопарк софта заезжает туда практически без изменений. Плюс поддержка файловых систем из коробки. Плюс полноценные сетевые возможности. Плюс GUI. И т.д. 

Главная проблема uCLinux как системы без поддержки MMU в том, что она очень уязвима для сценария, когда на ней запускают сторонние приложения, когда любое приложение может в случае ошибки завалить всю систему. Поэтому в пользовательские OC uCLinux не пошла. Но для сценария, когда на ней строят закрытую платформу, не предназначенную для запуска стороннего софта, когда к коду ОС и приложений имеет доступ только ограниченный круг разработчиков дивайса, картина существенно меняется. Да, на этапе разработки ошибки приложений будут по-прежнему заваливать ОС, но это обычное дело -- когда пишут драйвера (модули ядра) полноценного Linux, ситуация точно такая же. А когда разработка закончена, ПО оттестировано, у потребителя уже никаких дополнительных рисков нет -- он использует дивайс в рамках, предоставленных производителем.

Другое дело, что профита от мощных процов без MMU при нынешнем развитии микроэлектроники (чипдизайна и технологий производства) почти нет -- стоимость MMU исчезающе мала на фоне остального, а преимущества, которое оно даёт, очень большое, начиная от поддержки разных моделей памяти (Normal, Device, Strongly-ordered, в терминологии ARM) и заканчивая аппаратной трансляцией адресов (защищённый режим работы памяти). Поэтому по факту uCLinux уже отошёл в историю.

[Arlleex 160]

2 часа назад, dxp сказал:

Разве можно MMU отключать, если он есть?

Можно конечно. Как раз выключив MMU, трансляция и выключается, адресация становится физическая.
 

11 часов назад, aaarrr сказал:

Да уж много лет как поддерживаются конфигурации без MMU.

Озадачили. Нет, ну я помню статью на хабре лет 15 назад, парень на AVR и SD-карте поднимал линукс. Но ему там напихали сразу, что, мол, по факту там не линукс никакой. Плюс индусские лекции по линуксу  сколько раз вразумляли, что базовая аппаратурная потребность Unix-подобных ОС - как раз виртуализация памяти.

[dxp 53]

9 минут назад, Arlleex сказал:

Можно конечно. Как раз выключив MMU, трансляция и выключается, адресация становится физическая.

А кто разруливает корректность обращения к разным типам памяти? Например, блокирует спекулятивное чтение из MMR регистров периферии, где недопустимо читать некоторые регистры (адреса памяти) просто так, т.к. чтение является разрушающим? Или запись в подобные области, где требуется строго соблюдать порядок обращения (чтобы команды включения периферийного устройства и записи в его регистры не поменялись местами -- современные CPU такое запросто делают, когда не обнаруживают связи между обращениями)?

[Arlleex 160]

11 минут назад, dxp сказал:

А кто разруливает корректность обращения к разным типам памяти? Например, блокирует спекулятивное чтение из MMR регистров периферии, где недопустимо читать некоторые регистры (адреса памяти) просто так, т.к. чтение является разрушающим? Или запись в подобные области, где требуется строго соблюдать порядок обращения (чтобы команды включения периферийного устройства и записи в его регистры не поменялись местами -- современные CPU такое запросто делают, когда не обнаруживают связи между обращениями)?

Если Вы имеете в виду то, каким образом CPU понимает, что нельзя осуществлять перетасовку обращений к памяти на уровне шинных транзакций, так это делается исходя из дефолтной карты памяти, как, например, в Cortex-M. CPU "знает", что определенные диапазоны являются памятью типа Device, другие - Normal или Strongly-ordered. Включив MPU/MMU, можно внести определенные изменения в эту "стандартную" схему. Затем, если программисту требуется, чтобы при обращении к обычной Normal ОЗУ у него не мешались volatile-доступы на уровне шины памяти (потому что на уровне инструкций CPU будет все ок - согласно стандарту на язык), то в помощь ему барьеры.

[dxp 53]

1 минуту назад, Arlleex сказал:

Не совсем понял вопрос - MMU и не разруливал спекулятивные чтения и т.д. Более того, даже без MMU регистры периферии просто так не считываются и порядок чтения не меняется (исходя из потока инструкций). Если Вы имеете в виду то, каким образом CPU понимает, что нельзя осуществлять перетасовку обращений к памяти на уровне шинных транзакций, так это делается исходя из дефолтной карты памяти, как, например, в Cortex-M. CPU "знает", что определенные диапазоны являются памятью типа Device, другие - Normal или Strongly-ordered. Включив MPU/MMU, можно внести определенные изменения в эту "стандартную" схему.

В Cortex-M может и знает, а вот в Cortex-A уже не очень. Потому как там внеочередное выполнение инструкций с переименованием регистров, чтение бёрстом размером в линию кэша и т.п, что запросто приводит к неприятным эффектам при доступе к MMR. И в Cortex-M, насколько мне известно, никакого MMU нет. И для поддержания корректности таких обращений ARM придумал в AXI специальные поля, которые инфраструктуре доступа в память сообщают, как осуществлять физический доступ в память к той или иной области. И управляет этими полями как раз MMU. формируя AXI транзакцию. И, помнится, в Cortex-M AXI не используется, там AHB/APB.

[Arlleex 160]

3 минуты назад, dxp сказал:

И, помнится, в Cortex-M AXI не используется, там AHB/APB.

Еще как используется. Любой STM32F7/H7 посмотрите. И рулит этими битами не MMU а выходной интерфейс памяти CPU.

MMU находится "между" памятью и CPU, поэтому лишь можно переопределить "базовые" настройки доступов, генерируемых CPU.

А если бы реальность действительно была такова

Цитата

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

то отвалилась бы бОльшая часть бареметалистов, однако они до сих пор при деле. Никаких проблем запустить бареметал на любом application CPU без включения MMU и, скорее всего, за первым багом, связанным с внеочередным исполнением, придется километр кода настрочить.

[dxp 53]

2 минуты назад, Arlleex сказал:

Еще как используется. Любой STM32F7/H7 посмотрите. И рулит этими битами не MMU а выходной интерфейс памяти CPU.

В этих МК есть MMU?

[Arlleex 160]

1 минуту назад, dxp сказал:

В этих МК есть MMU?

Нет конечно.

[dxp 53]

Тогда о чём речь? Мы говорим про "выключить MMU", можно ли это безопасно сделать. Выключить можно то, что есть. Оно есть в Application процессорах. Можно ли безопасно выключать MMU в Application процессорах? При чём тут вообще МК? 

[Arlleex 160]

19 минут назад, dxp сказал:

Тогда о чём речь?

Об этом

27 минут назад, dxp сказал:

И в Cortex-M, насколько мне известно, никакого MMU нет. И для поддержания корректности таких обращений ARM придумал в AXI специальные поля, которые инфраструктуре доступа в память сообщают, как осуществлять физический доступ в память к той или иной области. И управляет этими полями как раз MMU. формируя AXI транзакцию.

 

Цитата

Выключить можно то, что есть. Оно есть в Application процессорах. Можно ли безопасно выключать MMU в Application процессорах? При чём тут вообще МК?

MMU изначально выключен, вообще говоря. Его в том же линуксе не сразу включают и настраивают.

Я когда писал бареметалом под Cortex-A9, никаких MMU не включал, разумеется (поначалу так точно).

Немножко текста: https://developer.arm.com/documentation/102376/0200/Describing-memory-in-AArch64/MMU-disabled.

[dxp 53]

1 минуту назад, Arlleex сказал:

Об этом

Ещё раз.

1. Я спросил (не у вас), можно ли выключать MMU безопасно.
2. Вы встряли с ответом, сказав, что можно, что Cortex-M сам знает, где что лежит.
3. У Cortex-M нет никакого MMU, там просто захардкодили свойства регионов адресного пространства.
4. В сложных системах на Cortex-A это делается с помощью MMU, где всё это программируется через регистры.

Т.е. речь изначально шла про системы с MMU. И в них именно MMU рулит свойствами регионов адресного пространства. При чём тут МК вообще?

16 минут назад, Arlleex сказал:

MMU изначально выключен, вообще говоря. Его в том же линуксе не сразу включают и настраивают.

Да, выключен обычно. И его включают. И далеко не только в Linux. Его включают ещё на этапе первичного загрузчика (самый первый код, который запускает BootROM, определив через bootstrap pins источник, откуда грузить код. Чаще всего это, что называют Preloader, у Xilinx оно называется FSBL -- First State Bootloader), на этапе ассемблерного пролога задолго до вызова main этой программы.

18 минут назад, Arlleex сказал:

Я когда писал бареметалом под Cortex-A9, никаких MMU не включал, разумеется.

Если вы его не включали, это не значит, что оно не было включено. Его для вас заботливо включили ещё на этапе первичного загрузчика, где инициализируется вся эта непростая аппаратура (L1 Cache, L2 Cache, SCU, MMU). После выполнения первичного загрузчика вы имеете готовую к использованию для baremetal аппаратуру. Трансляция адресов в MMU при этом не включена. Это вторая функция MMU. Но MMU при этом включено и обеспечивает корректность работы с регионами памяти на низком уровне, включая методы кэширования.

[Arlleex 160]

22 минуты назад, dxp сказал:

Ещё раз.

И тогда я тоже еще раз.
 

Цитата

1. Я спросил (не у вас), можно ли выключать MMU безопасно.

Я встрял с ответом на первый вопрос

1 час назад, Arlleex сказал:

Можно конечно. Как раз выключив MMU, трансляция и выключается, адресация становится физическая.

 

Цитата

2. Вы встряли с ответом, сказав, что можно, что Cortex-M сам знает, где что лежит.

Нет, по хронологии это Вы вопросили, как тогда CPU будет разруливать всякую всячину

Цитата

А кто разруливает корректность обращения к разным типам памяти? Например, блокирует спекулятивное чтение из MMR регистров периферии, где недопустимо читать некоторые регистры (адреса памяти) просто так, т.к. чтение является разрушающим?

Я на это написал

1 час назад, Arlleex сказал:

Если Вы имеете в виду то, каким образом CPU понимает, что нельзя осуществлять перетасовку обращений к памяти на уровне шинных транзакций, так это делается исходя из дефолтной карты памяти, как, например, в Cortex-M.

Это по-Вашему, я встрял с ответом, что в Cortex-M можно??? Естественно я привел его в качестве аналогии и только лишь.
 

Цитата

4. В сложных системах на Cortex-A это делается с помощью MMU, где всё это программируется через регистры.

Программируется, да. Когда надо изменить дефолтную схему атрибутов доступа к памяти.

Цитата

3. У Cortex-M нет никакого MMU, там просто захардкодили свойства регионов адресного пространства.

И по аналогии с MMU, атрибуты можно переопределить с помощью MPU. Суть вся та же самая.

Дальше Вы заявили

Цитата

И для поддержания корректности таких обращений ARM придумал в AXI специальные поля, которые инфраструктуре доступа в память сообщают, как осуществлять физический доступ в память к той или иной области. И управляет этими полями как раз MMU. формируя AXI транзакцию.

Я читаю это как: если в архитектуре нет MMU, то AXI-шины не могут быть имплементированы. Я привел контраргументом микроконтроллеры с AXI-шинами внутри и без MMU.

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

[mantech 40]

3 часа назад, dxp сказал:

Мы говорим про "выключить MMU", можно ли это безопасно сделать.

Выключив ММУ выключаешь и кэш, а без него 1ГГц проц превращается в "тыкву", раз в 10 понижая быстродействие)))

4 часа назад, dxp сказал:

Какой-то смысл есть. ADI вложили прилично усилий в uCLinux для своего Blackfin,

Так можно обосновать и всякие protothreads в которые  TI тоже вложил немало, а кодеки и пр прекрасно и в бареметал работает, ну или под простейшей РТОС, зачем тут кастрированный линукс - загадка, которая походу только ADI и известна))

[dxp 53]

28 минут назад, mantech сказал:

Выключив ММУ выключаешь и кэш, а без него 1ГГц проц превращается в "тыкву", раз в 10 понижая быстродействие)))

Ну, не сам кэш, а управление свойствами регионов, где и свойства кэширования задаются. Но скорость -- это одно, и сильно падает она преимущественно при доступе во внешнюю память, а baremetal программа вполне может работать во внутренней памяти (которая обычно там есть в количествах 64..256 кбайт). Тем не менее с тормозами оно хотя бы работает. А вот корректная работа с периферийными регионами просто невозможна.

35 минут назад, mantech сказал:

Так можно обосновать и всякие protothreads в которые  TI тоже вложил немало, а кодеки и пр прекрасно и в бареметал работает, ну или под простейшей РТОС, зачем тут кастрированный линукс - загадка, которая походу только ADI и известна))

Однако, ADI это для промышленного применения двигали. Точно не помню, но вроде попадался даже чуть ли не какой-то мелкий осциллограф (лет 10-15 назад, китайский клон какого-то то ли LeCroy (типа WaveAce), то ли ещё кого), где управляющим процессором был Blackfin. Подозреваю, что GUI прибора реализовывался не на baremetal.