Практика Работы С Нестандартными Шинами Комплекса Редд.

В последняя статья Мы рассмотрели теорию управления тысячей мелочей в комплексе Редда, но чтобы не раздувать объём, отложили практику на следующий раз.

Пришло время провести практические эксперименты.

Те, кто не пользуется комплексом Redd, также смогут найти в этой статье полезные знания, а именно способ отправки команд Vendor на USB-накопители из ОС Linux, ведь, как уже говорилось, контроллер STM32 в комплексе выполняет функция SD-ридера, то есть - накопителя.



Практика работы с нестандартными шинами комплекса Редд.

Предыдущие статьи серии

  1. Разработка простейшей «прошивки» для ПЛИС, установленной в Redd, и отладка на примере теста памяти.

  2. Разработка простейшей «прошивки» для ПЛИС, установленной в Redd. Часть 2. Программный код.
  3. Разработка собственного ядра для интеграции в процессорную систему на базе FPGA.
  4. Разработка программ для центрального процессора Redd на примере доступа FPGA.
  5. Первые эксперименты по использованию потокового протокола на примере связи ЦП и процессора в ПЛИС комплекса Redd.
  6. Весёлый Квартусель, или как процессор дошёл до такой жизни.

  7. Методы оптимизации кода для Redd. Часть 1. Влияние на кэш.

  8. Методы оптимизации кода для Redd. Часть 2: некэшируемая память и параллелизм шин.

  9. Обширная оптимизация кода: замена тактового генератора для улучшения производительности системы.

  10. Доступ к сложным шинам Redd, реализованным на контроллерах FTDI
  11. Работа с нестандартными шинами комплекса Редд


Классификация приводов по системам команд

При работе с накопителями следует различать физический интерфейс и систему команд. В частности, CD/DVD/BD приводы и другая оптика.

Традиционно они подключаются к кабелю SATA (ранее IDE).

Но конкретно по этому проводу во время работы выполняются только ПАКЕТНЫЕ команды, блок данных которых содержит команды, закодированные совсем по другому принципу (скоро узнаем, по какому).

Поэтому сейчас мы поговорим не столько о проводах, сколько о командах, которые в них проходят. Мне известны три распространенные системы команд для работы с накопителями.

  • ММЦ.

    SD-карты это понимают. Честно говоря, для меня это самая загадочная система команд. Как их подать вроде понятно, но как управлять приводом, не читая внимательно документ, в котором много граф переходов, меня всегда сбивает с толку.

    К счастью, сегодня нас это не беспокоит, поскольку хотя мы и работаем с SD-картой, контроллер STM32 работает с ней в режиме «черного ящика».

  • АТА.

    Первоначально эти команды выполнялись по шине IDE, затем по SATA. Замечательная система команд, но сегодня мы также лишь упомянем, что она существует.

  • SCSI. Эта система команд используется в широком спектре устройств.

    Давайте рассмотрим его использование в устройствах хранения данных.

    Там сегодня команды SCSI выполняются преимущественно по проводам шины SAS (кстати, сейчас в моду входят даже SSD с интерфейсом SAS).

    Как ни странно, оптические приводы, физически подключенные к шине SATA, также работают через команды SCSI. По шине USB при работе по стандарту Mass Storage Device команды передаются также в формате SCSI. Микроконтроллер STM32 подключается к комплексу Redd через шину USB, то есть в нашем случае команды проходят по следующему пути:

    Практика работы с нестандартными шинами комплекса Редд.

С ПК на контроллер по шине USB передаются команды в формате SCSI. Контроллер перекодирует команды по правилу MMC и отправляет их по шине SDIO. Но нам предстоит написать программу для ПК, поэтому команды оставляют нас в формате SCSI. Их подготавливает драйвер Mass Storage Device, с которым мы общаемся через драйвер файловой системы.

Можно ли смешивать эти запросы с запросами на другие устройства? Давайте разберемся.



Подробности системы команд SCSI

Если подходить к делу формально, то описание стандарта SCSI доступно на сайте t10.org, но давайте будем реалистами.

Никто добровольно это читать не будет. Точнее, не он, а они: целая куча открытых документов и гора закрытых.

Только крайняя необходимость заставит вас погрузиться в сложный язык, на котором написан стандарт (это, кстати, касается и стандарта ATA на t13.org).

Гораздо проще читать документацию к реальным приводам.

Она написана более живым языком, из нее вырезаны гипотетические, но реально не используемые части.

Готовя эту статью, я наткнулся на достаточно новый (2016 г.

) документ. Справочное руководство по командам SCSI от Seagate (прямая ссылка www.seagate.com/files/staticfiles/support/docs/manual/Interface%20manuals/100293068j.pdf но, как всегда, не знаю, сколько она проживет).

Я думаю, если кто-то хочет освоить эту систему команд, ему лучше начать с этого документа.

Мы лишь помним, что SD-ридеры реализуют еще меньшее подмножество команд из этого описания.

Если очень кратко, то в накопитель попадает командный блок длиной от 6 до 16 байт. К командному блоку можно присоединить блок данных либо с ПК на накопитель, либо с накопителя на ПК (стандарт SCSI допускает двунаправленный обмен, но для Mass Storage Device через USB разрешен только один блок, то есть только Одно направление).

В командном блоке первый байт всегда является кодом команды.

Остальные байты являются его аргументами.

Правила заполнения аргументов описываются исключительно деталями реализации команды.



Практика работы с нестандартными шинами комплекса Редд.

Сначала я включил в статью много примеров, но потом понял, что они затрудняют чтение.

Поэтому предлагаю всем сравнить поля команды READ CAPACITY(10) из таблицы 119 документа Seagate и поля команды READ(10) из таблицы 97 того же документа (см.

ссылку выше).

Если вы не обнаружили никакой связи, не пугайтесь.

Это именно то, что я хотел показать.

За исключением поля «команда» в нулевом байте, назначение всех полей зависит исключительно от специфики конкретной команды.

Всегда следует открывать документ и изучать назначение остальных полей в нем.

Так:

  • Для связи с накопителем необходимо сформировать командный блок длиной от 6 до 16 байт (в зависимости от формата команды точное количество указано в документации к нему).

  • Самым важным является нулевой байт блока: он определяет код команды.

  • Остальные байты блока не имеют четкого назначения.

    Чтобы понять, как их заполнять, следует открыть документацию конкретной команды.

  • К команде может быть прикреплен блок данных, который передается на привод или с него.

Собственно, это все.

Мы изучили правила выдачи SCSI-команд. Теперь мы можем их подать, лишь бы на них была документация.

Но как это сделать на уровне операционной системы?

Отправка команд SCSI в ОС Linux



Поиск целевого устройства

Для подачи команд необходимо открыть дисковое устройство.

Давайте найдём его имя.

Для этого мы пойдем абсолютно тем же путем, что и в статья о последовательных портах .

Посмотрим на список «файлов» в каталоге /устройство (помните, что в Linux устройства также отображаются в виде файлов и их список выводится той же командой лс ).

Сегодня мы уделим внимание виртуальному каталогу диск :

Практика работы с нестандартными шинами комплекса Редд.

Давайте посмотрим на его содержимое:

Практика работы с нестандартными шинами комплекса Редд.

Знакомый набор вложенных каталогов! Попробуем посмотреть каталог.

по идентификатору , воспользовавшись уже знакомым нам ключом из статьи про последовательные порты –л команды лс :

Практика работы с нестандартными шинами комплекса Редд.

Выделенные слова говорят сами за себя.

Это накопитель, содержащий внутреннюю SD-карту комплекса Redd. Большой! Теперь мы знаем, что устройство MIR_Redd_Internal_SD соответствует устройству /dev/sdb и /dev/sdb1 .

Тот, что без номера, — это сам диск, с ним мы и будем работать, а тот, что с номером, — это файловая система, расположенная на вставленном в него носителе.

Что касается работы с SD-картой, /dev/СДБ является читателем и /dev/sdb1 — файловая система на вставленной в нее карте.



Функция операционной системы для выдачи команд

Обычно в любой ОС все нестандартные вещи с устройствами делаются через прямые запросы к драйверу.

В Linux есть функция отправки таких запросов ioctl() .

Наш случай не является исключением.

Передаем запрос в качестве аргумента SG_IO , описанный в заголовочном файле сг.

х .

Там же описана структура sg_io_hdr_t , содержащий параметры запроса.

Я не буду приводить всю структуру, так как не все ее поля нужно заполнять.

Я приведу лишь самые важные из них:

   

typedef struct sg_io_hdr { int interface_id; /* [i] 'S' for SCSI generic (required) */ int dxfer_direction; /* [i] data transfer direction */ unsigned char cmd_len; /* [i] SCSI command length ( <= 16 bytes) */ unsigned char mx_sb_len; /* [i] max length to write to sbp */ unsigned short int iovec_count; /* [i] 0 implies no scatter gather */ unsigned int dxfer_len; /* [i] byte count of data transfer */ void * dxferp; /* [i], [*io] points to data transfer memory

Теги: #Программирование микроконтроллеров #Компьютерное оборудование #Системное программирование #SD-карта #SD-карты #Redd
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.