Почему статическая оперативная память (SRAM) не требует контроллера памяти?

#embedded #embedded-linux #bootloader #u-boot

#встроенный #встроенный-linux #загрузчик #u-boot

Вопрос:

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

Мой вопрос в том, что для запуска DRAM требуется контроллер, но почему SRAM этого не делает? Кто управляет SRAM? или как это контролируется? Кроме того, что происходит после того, как система выполняется с помощью SRAM, и что происходит с DRAM?

Я пока не знаю, имеет ли это смысл или нет, но было бы лучше, если бы вы могли ответить с точки зрения u-boot и Linux.

Комментарии:

1. Не будет ли этот вопрос лучше подходит для electronics.stackexchange.com ?

2. @Codo Нет, это больше касается программного обеспечения и общей теории, чем аппаратного вопроса.

3. Нет, это действительно не программный вопрос, это полностью о том, как работает аппаратное обеспечение. Это ясно как из формулировки вопроса, так и из текущих ответов. Это явно не по теме — даже если это интересно. SRAM является статическим , поэтому не требует управления обновлением. Он имеет более простой интерфейс и синхронизацию; установите адресную шину, синхронизируйте разрешение вывода, считайте шину данных. Я не понимаю, почему uboot или Linux имеют значение. SRAM, достаточно большой для запуска Linux, был бы непомерно дорогим и довольно медленным. SDRAM отличается высокой плотностью, недорог и быстр.

Ответ №1:

Для обоих нужны контроллеры, однако DRAM необходимо периодически обновлять, чтобы сохранить его состояние (в конденсаторах), в отличие от SRAM, который сохраняет свои состояния через цепи блокировки.
Это означает, что если вы хотите сохранить содержимое памяти после сброса (например, из Linux или U-Boot), вы должны настроить контроллер DRAM на «автоматическое обновление» памяти на этапе сброса. В SRAM такой необходимости нет.

Комментарии:

1. Тогда как она доступна загрузочным ПЗУ в начале, а DRAM — нет?

2. Для DRAM требуется более сложная конфигурация, запускаемая программным обеспечением. Внутренняя SRAM может быть инициализирована прозрачно.

3. Как бы выглядел такой контроллер SRAM, не могли бы вы добавить ссылку? У меня глубокий опыт работы с маленькими микроконтроллерами и старыми процессорами, и их SRAM никогда не нуждались в контроллере.

4. @thebusybee, статический «контроллер» ОЗУ так же прост, как декодер адресов. en.wikipedia.org/wiki/Address_decoder

5. @0andriy Hm, на сайте, где среди прочих новички ищут знания, мы не должны путать их с такими «фактами». Я знаю несколько проектов, которым даже не нужен декодер адресов или, например, драйвер шины данных между процессором и памятью, который можно было бы назвать «контроллером» с аналогичными рассуждениями. — Однако вопрос был задан Эрику, который утверждает, что SRAM нуждается в контроллере, без двойных кавычек. Прежде чем утверждать, что это просто неправильно, я хотел бы заполнить свой потенциальный пробел в знаниях.

Ответ №2:

Обычно, когда вы ссылаетесь на SRAM с точки зрения загрузчика, контроллер имеет доступ к внутренней оперативной памяти. Доступ к этой оперативной памяти осуществляется контроллером с помощью шины AHB / AXI (для устройств на базе ARM). Может существовать мост памяти, который преобразует сигналы из шины AHB / AXI в шину памяти. Таким образом, с точки зрения программного обеспечения, она прозрачна, для доступа к этой оперативной памяти не требуется никакой конкретной конфигурации программного обеспечения.

Ответ №3:

… затем код ПЗУ загружает небольшой фрагмент кода в SRAM.

Это обычная процедура для некоторых SoC, но она не требуется. Существуют альтернативные схемы загрузки.

Для SoC Etrax, в которых использовались процессоры CRIS (которые в настоящее время сняты с производства), параметры DRAM должны храниться в энергонезависимой памяти (NVM). Код загрузки встроенного ПЗУ обратился к этому NVM и инициализировал контроллер DRAM. Таким образом, загрузочный код ROM был способен напрямую загружать ядро Linux.

Некоторые ARM SOC имеют вывод селектора загрузочной памяти (BMS) (например, Atmel AT91SAM9xxx и Microchip SAMA5Dx), который может отключать внутренний код ПЗУ и позволяет процессору выполнять код после сброса с внешнего NVM (например, NOR flash), который имеет возможность выполнения на месте (XIP). Такая схема загрузки может быть настроена для инициализации внешнего DRAM, а затем загрузки U-Boot или даже ядра Linux.


Мой вопрос в том, что для запуска DRAM требуется контроллер, но почему SRAM этого не делает? Кто управляет SRAM? или как это контролируется?

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

Для сравнения, взаимодействие с SRAM намного проще. Обычно нет «контроллера SRAM». Логика управления интерфейсом SRAM обычно достигает уровня сложности, требующего «контроллера». Например, я использовал SBC, микропроцессор Z80 которого был напрямую подключен к микросхемам памяти SRAM (HM6264) и EPROM (MBM2764), а также некоторую логику для декодирования адресов.

«Контроллер SRAM», используемый в современных SoC, в первую очередь представляет собой буферизованный интерфейс для внешней SRAM с внутренней системной шиной. Внутренняя SRAM SoC не требует какой-либо программной инициализации и будет доступна сразу после сброса.

Кроме того, что происходит после того, как система выполняется с помощью SRAM, и что происходит с DRAM?

Обычно внутренняя SRAM остается неиспользованной, если она не включена в состав памяти, которой управляет ядро Linux. Я не знаю, связано ли это с какими-либо техническими причинами, такими как проблемы с виртуальной памятью или кэшированием, или недосмотр, или стремление к простоте однородной памяти.
Для некоторых SoC объем внутренней SRAM настолько мал (например, 8 КБ в Atmel AT91SAM926x), что усилия по его использованию в ядреможет считаться, что это плохой компромисс между затратами и выгодами.
Смотрите Это обсуждение, касающееся исправления ядра для SRAM на Atmel / Microchip SAMA5D3x

Драйвер устройства все еще может использовать внутреннюю SRAM в качестве своей частной области памяти для высокоскоростных буферов. Например, в ядре было исправление для использования SRAM для хранения пакетов передачи Ethernet, чтобы избежать ошибок при передаче.