1

Тема: Мост # 3

Привет!

Решил ещё один роман написать. Или прозу. Или новеллу. Блог, в общем.


Abstract

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


Formulation of the problem

Были всякие идеи про расширение моста путём конверторов LPT<->USB,
я даже заказал такой на пробу, но чья-то почта его пролюбила и мы не встретились.
Может как раз вирус сожрал - я заказ делал в начале 2020.

Но это всё полумеры и многих нынешних проблем USB-мост бы не решил.
Когда мосты проектировались и вода была мокрее и здоровье наше тоже позволяло
путешествовать за дисками и девушки тоже ... чем-то отличались,
но я уже забыл - чем.

Сейчас мир изменился, компьютеры с LPT-портом есть не у всех,
BIOS-поддержка, необходимая для работы *dos ушла, пришла EFI, мы рады движняку, но мосты так не работают.
Да и сами компьютеры тоже есть не у всех. Практика показала также,
что у владельцев дисков не всегда есть даже дисководы.
А ещё у них не всегда есть желание отправить диски нам. У них не всегда
есть даже память о том, как вообще выглядят агатовкие файлы и
что иногда диски нужно было переворачивать.
Они не помнят и формат записи, могут путать спектрум, агат, ДВК и далее по списку.

Новые устройства типа флюксы и SCP спасают мало, потому что:

1) Про агат они мало знают. Катастрофически мало. А знать нужно хотя бы для того, чтобы отличить две версии
агатовских форматов (хотя можно ещё помянуть редкий, но всё же изредка встречающийся формат dos32
и это будет уже три версии формата) от других систем. И ещё чтобы хотя бы понять, сколько ещё ретрейсов
понадобиться, чтобы нормально прочитать дорогу. А желательно и сразу подсказать, на каком дисководе нужно читать
этот диск (PC-совместимом или ес5088).

2) Они требуют хотя бы подключиться к компу по USB и всё таки поставить драйвера. И потом запустить прогу.
Иногда даже с комстроки. Это уже плохо ложиться на современный user experience.
А если владелец дисков уже покинул нас, то наследники, скорее всего, знают только что через дискету
удобно на солнечное затмение смотреть.

3) Они не поддерживают ес5088. Или что-то совместимое от шугарта, тика, альпинса и т.д.
Чем ес5088 лучше 80-дорожечного тика для чтения 140кб дисков ?
a) ес5088 имеет широкий магнитопровод головы. Такой, как те дисководы, которые 25 лет назад записывали этот диск.
b) Они не гордые и могут читать перевёрнутый диск (не получая сигнал индекса).
    Тик может читать вторую сторону диска верхней головой, но только от трека 4 и выше. Более ранние
    не может захватить из-за сдвига в положении верхней головки
    (её магнитопровод сдвинут ближе к центру диска, относительно нижней).
c) Они умеют ставить голову с некоторым смещением от дорожки. Мелочь, но иногда тоже полезная.
d) Они гарантированно имеют нужную частотную полосу усилителя чтения.
Т.е. нередко прочитать сторону A у 140кб дискет можно и на PC-совместимом флопе.
Но мы уже наблюдали исключения, когда этого сделать нельзя.
При попытке чтения B стороны у 140кб сложностей ещё добавляется.

To be continue...

2

Re: Мост # 3

Жизнь то у меня похоже налаживается.

3 Отредактировано Voldemar0 (11-07-2021 19:36)

Re: Мост # 3

Proposal

С другой стороны, мир всегда меняется. Причем не так, как принято говорить в журналистике:
"если так продолжиться ещё 10 лет, то все умрут" (а некоторые, к тому же, ещё и сдохнут),
а одновременно, по многим параметрам и не взирая ни на чьи пожелания.
Так что потеряв многое, мы многое и обрели. Включая знания о контроллерах агата, снижение цен на мощные процы,
опыт разработки ПО и РЭА, а также интересные решения и предложения в области встраиваемых систем.
Да и матрицы, конечно!

Таким образом мы хотим (и это возможно реализовать) мост # 3.
Эскиз его особенностей и возможностей:

1) Проц imx6 от FreeScale / NPX. Скорее всего imx6ul или imx6ull. Его производительности
с крышечкой хватит для обработки трека и для других плюшек.

2) Объём набортного ОЗУ >= 256 Мб.

3) Плата будет работать автономно, без участия какого либо компьютера.
Данные будут сохраняться во встроенную flash, возможно формата eMMC или raw-NAND.
Объём >= 256 Мб.

4) На плате будут минимум три интерфейса для подключения к компьютеру:
  - debug-порт (UART). USB-UART не буду ставить.
  - USB-OTG. Устройство может изображать mass storage device (флешку) для компа либо сможет само скидывать файлы на
  подключенныю USB-флешку (после чтения данных с дисков).
  - Ethernet. Можно будет вывести устройство в проводную сеть и управлять им, а также обмениваться файлами.

5) Также на плате будет слот для SD-карт (скорее всего только для microSD, но дальше будет видно).
  Его тоже можно будет использовать для сохранеия образов, но основная задача это слота
  - обновление прошивки.

  Жирно подчеркну: такой богатый выбор интерфейсов связан не с тем, что мне охота поиграться,
  а просто потому, что imx6 является системой-на-кристале и там уже всё это есть, остаётся
  только предусмотреть на плате разъёмы и трансформатор развязки для Ethernet.

6) На плате будет минимум кнопок. Скорее всего это будут традиционные
стрелки влево-вправо-вверх-вниз, "ввод" и "отмена", а также "прочитать с дисковода A" (PC-совместимые)
и "прочитать с дисковода B" (ес5088, Apple][ - совместиые).
Ещё кнопка сброса, но это только для отладки.
Переключатель "работа" / "обновление ПО".

Сигналы выбора дисковода буду выставлять все доступные для данного интерфейса одновременно, чтобы
не было мороки с настойкой дисковода как DS0, DS1... Само собой - на кабеле будет допустим
только один дисковод.

Что делать с выбором скорости, если дисковод поддерживает 360 и 300rpm ? Вероятно,
будет автоматическое переключение: пробуем 360, если трек не читается на 10й оборот - переключаемся
на 300 и пробуем снова.

7) Индикаторы: OLED-дисплейчик мелкого размера и большая группа двухцветных и одноцветных SMD-светодиодов.
В чём смысл: дисплей - штука хрупкая, а устройство наверняка не будет храниться в металлическом
сейфе или дипломате. Поэтому делать крупный дисплей рискованно. Но мелкий дисплей плохо читается.
Поэтому дисплей оставляем для всяких тонких настроек (если нет возможности выполнить их с ноута)
и всякой вспомогательной информации.
А на светодиоды, размазанные по плате, выводим статус программы чтения:
номер текущей дороги, может быть номер прохода, а также информацию о прочитанных секторах
с текущей дороги (зелёные - успешно, красный - ошибка, оранжевый - не найден).
Драйвер светодиодов - max7219. Если одной вдруг не хватит - воткну две на отдельные i2c-шины.

Обязательно: светодиод, индицирующий отсутствие сигнала с флопа (т.е. когда висит константа
и линия никак не меняет значение. А также можно добавить какой-то режим индикации,
когда частота сигнала слишком низкая или слишком высокая (долгое время > 2 МГц или получаем константу > 100 мкс)).

8) Обязательно внешний RTC. imx имеет часы на борту, но они там объединены с подсистемой безопасности
и любят пожрать. Для LiPO-питания приемлимо, но тут его не будет,
а cr2032 будет чувствовать себя не комфортно. Так что ds1307 или что-то подобное будет отдельно.
Время нужно для того, чтобы ставить даты создаваемых файлов.

9) Питание устройства:
будет требоваться внешнее питание +5 и +12 в.
Мне не хочется делать понижайку с 12 в 5 из соображений уменьшения помех на плате.
А внешний блок питания на такие напряжения найти - не фокус.
Внутренняя схема будет питаться от 3.3в. Линейный регулятор - понижайка с 5в.
Возможно, также будет линейная понижайка с 12в в 5в для питания USB-флешки.

Можно предусмотреть на плате разъёмы "Molex" и "ATX-БП".

10) ПО: u-boot -> linux kernel (4.x или 5.x) -> busybox в качестве основы операционки.
Для ethernet web-интерфейс (Скорее всего только для настройки, не для управления съёмом.
Хотя тут как пойдёт). ftp/samba для обмена файлами, но возможно это будет тоже через web-интерфейс.
dhch-сервер, управляемый из меню на плате: можно будет включить для работы, например,
с ноутом через cross-кабель или выключить при подключении к локалке (тогда адрес устройство
будет получать от внешнего dhcp и выводить на экранчик).

Что-то надо будет подобрать для работы с USB-otg для режима Device.
Пока не имел дела с этим режимом.

ПО для обработки дисков: буду писать либо на C либо на Pascal либо на их смеси.
C хорош когда нужно много общаться с операционкой, но Pascal выигрывает
по встроенным в прогу self check. Или пойти совсем другим путём и изучать что-то другое ? Go ?

Скорее всего, диск нужно будет ставить в 840ку и логика ПО будет пытаться применить различные
алгоритмы к RAW-данным очередной дорожки и определить её формат.
Если на диске будут обнаружены следы формата Disk][,
то устройство будет явно просить переснять диск на ес5088, указывая какой именно стороной нужно установить диск.
Сохраняться будет, как обычно, максимум данных от обеих дисководов.
Вероятно, надо будет также поддержать формат PC-совместимых контроллеров.
Для декодеров будет какой-то api, позволяющих легко их дописывать по мере необходимости.

Запись на диски будет второстепенной задачей и появиться не сразу.
Вероятно, на плате будет переключатель, аппаратно запрещающий выдачу сигнала !WRITE на дисководы.

10) Интерфейс с флопами через 3.3в <-> 5в преобразователь, скорее всего SN74LVC4245DW.
Вероятно, оба флопа будут подключаться независимо, т.е. если по процу вывезу, то можно будет
снимать одновременно двумя. Если нет - значит только один в одно время. Но точно, что подключить
можно будет оба флопа одновременно.

11) Для заливки RAW-потока от флопика попробую задействовать SPI-интерфейсы на скорости 8 МГц.
Если он будет работать без разрывов синхронизации - самое то. !! Но вот это ещё предстоит проверить !!

Если нет - запахнет верилогом. Но возможно есть готовые микрухи с интерфейсами spi или i2c
(что-то вроде непрерывно работающих сдвиговых регистров, которые можно асинхронно читать и писать) ?

12) Возможно, предусмотрю "обратные" разъёмы для подключения устройства в качестве эмулятора флопиков.
Но это второстепенно, софт явно не будет поддерживать этого решения изначально.
Кроме того это потребует большего числа 5-3.3в преобразователей.

13) Печатку рисую сам, если уложусь - два слоя, если нет - 4.
Буду пробовать. Хотя могу и передать это кому-то.
Проц буду брать сразу на модуле вместе с памятью и обвесом, что-то вроде MYC-Y6ULX от MYiR.
Импонирует пайка модуля сразу на плату и широкий шаг выводов, дизайн mainboard попроще.

4

Re: Мост # 3

Notes:

1) Я понимаю, что этот проект не будет дешевым с точки зрения комплектухи.
Думаю, можно было бы выбрать и проц попроще и более тонко подобрать другие составляющие.
Но так как решение узкоспециализированное, то и число экземпляров вряд ли
превысит 10. Следовательно, R&D будет всё равно стоить больше чем комплектуха.
Очень приблизительно разработка+отладка вечерами займёт около года.
В общем-то, два моста # 2 потребовали сопоставимого времени.
Преимущество же imx6 для меня в том, что я достаточно хорошо знаю этот SoC.


2) Этот проект не будет showstopper'ом, подобно тому, как это планировалось для w5100 и как планируется для проекта, который я сейчас заканчиваю (там всё просто: ATMega128 + max240).
Возможно, я выпущу ролик по мосту # 3, но всё же основные подробности буду равномерно публиковать здесь, подобно тому как это было во время работы над "простым текстовым редактором" или адаптером ps/2-клавиатуры.

5

Re: Мост # 3

Володя, мы тут для своего MSX проекта откопали интересный SOM:

https://www.mouser.de/ProductDetail/MYI … jtzapkOQ==

Посмотри - может тебе пригодится.

6

Re: Мост # 3

Спасибо, но он чуть дороже и двухядерник. А два ядра тут, мне кажется, бессмысленны.
Ну и другой производитель проца. Хотя, может быть, это и не очень важно.

7 Отредактировано Voldemar0 (13-01-2022 20:24)

Re: Мост # 3

Сейчас самый важный вопрос по мосту: можно ли использовать встроенный SPI-контроллер как семплер для захвата данных чтения с флопа? Т.е. можно ли расчитывать на то, что хотя бы 200 мс он будет выдавать синхроимпульсы (и, соответственно, захватывать данные) без существенного джитера.

Что проще: запустить SPI на обмен и проверить что делает синхролиния? В инете пишут, что если SPI поддержан аппаратно, то, скорее всего, минимум одну страницу (сколько бы это ни было в байтах) он может протащить на максимальной скорости без пауз.

Но возникла первая проблема: оказалось, что вообще-то из пространства программ SPI-шина внезапно доступна только довольно нетривиальным путём. Второй день пытаюсь разобраться в доступе к ней. Есть драйвер SPIDEV, он должен предоставлять такой доступ. Но чтобы его запустить рекомендуется немного покопаться в исходниках ядра операционки. Что крайне странно для меня. I2C, к примеру, доступна всем и каждому без особого напряга, "из коробки". Причем разные проги могут общаться с разными устройствами на одной шине!

Как только я буду уверен, что SPI может быть использован для захвата - я могу рисовать плату. Либо, если SPI не может прочитать и сотни бит без разрыва в синхронизации, то тогда надо будет сперва придумывать какой-то другой промежуточный блок для семплирования.

8 Отредактировано Voldemar0 (15-01-2022 18:24)

Re: Мост # 3

Два дня разбора доков и ещё пара вечеров ковыряния исходников ядра и я получил доступ к SPI-шине.
Нет проблем, всякие демки работают.

Но облом 1 вышел всё равно эффектный: SPI-контроллер разделяет паузой синхро между словами. Слова могут быть разной длины (похоже, все степени двойки), но не более 32 бит. Между словами пауза примерно 5 бит.
До некоторых скоростей она меняется, но после десятка МГц практически не сокращается.

Интересная идея 1: слова размером 1 бит. Но при тактовой 8 МГц это даёт семпл-рейт 1.5 МГц. Причем каждый семпл падает в младший бит байта - т.е. один байт на семпл получается. Попытки задрать частоту до 60 МГц не дают возможности получить семплрейт выше ~2.5 МГц, так как растёт длительность задержки между 1-битными словами. Вроде бы она программируемая, но до какой степени и как - не ясно. Судя по тому, что я её не задаю, но она всё таки есть, вероятно, она минимально возможная. Облом 2.

Интересная идея 2: попробовать загнать SPI в slave mode. В этом случае он, теоретически, должен работать с произвольной внешней синхронизацией (например, с генератором 8.0 МГц). Но тут есть интересное: "When the ECSPI is configured as a slave (Mode = 0), software can configure the ECSPI Control register to match the external SPI master's timing." Вот это "can" меня смущает: типа, хочешь конфигурируй скорость, хочешь - нет?

Но со slave-mode есть другие сложности: 1) Его не поддерживает spidev - драйвер, через который я работаю сейчас, 2) Надо бы убедится, что в этом режиме действительно будут читаться все-все битики, которые я передам. Т.е. нужны более сложные тесты, чем потыкать в лапки логическим анализатором.

--

Ещё есть интерфейсы SAI (Synchronous Audio Interface) и ESAI (Enhanced Serial Audio Interface).
Но, скорее всего, тут ловить нечего, так как их скорость не слишком высокая.

--

Идея на крайняк: внешний семплер.

1) Это может быть матрица, LE которой работают как двухпортовая SRAM и хрянят сколько нибудь байт до того, как их прочитает ЦП,... ну, например, по spi-шине. Объём хранения будет небольшой (10-100 байт), это будет только выравнивание скоростей SPI ЦП и строго синхронного внешнего генератора 8.0 МГц. Но тогда нужно, как минимум, синхронизовать работу ЦП с матрицей, так как настройка SPI-контроллера ЦП на 8.0 МГц даёт только конкретный clock rate в момент чтения слова. Между словами пауза не особо чёткая. А нужно, чтобы SPI имел именно точно заданную (или синхронизованную) СРЕДНЮЮ скорость (на протяжении одного оборота диска).

2) Это может быть матрица, которая скидывает все семплированные байты в отдельную sram. Скидывание происходит весь оборот диска, после чего матрица отключается и ЦП выдёргивает данные из SRAM, используя хоть GPIO, с удобной ему скоростью. Или пусть это будет SRAM со SPI-шиной.

Можно прикинуть: оборот диска 0.2 c, т.е. 5 об/сек, тогда при sample rate 8 MHz получается 8/5 = 1.6 МБит = 200 КБайт. Вроде не много, но и не мало...

3) То же, что и 2, но матрица записывает в SRAM не буквально отсчёты, а что-то вроде RLE-кода: длительность интервала между фронтами импульсов. Допустим, что один байт достаточен для хранения длительности типичных интервалов между импульсами. Так как минимальный интервал между импульсами составляет 2 мкс, можно предположить, что для хранения трека в таком виде достаточно будет 0.2 с / 2 мкс = 100 КБайт.

Варианты 2-3 вкусные по причине относительной простоты конфигурации матрицы (а простота позволяет избавиться от замысловатых ошибок), но сложность в том, что SPI-SRAM на 256 КБайт найти немного не просто. На 32 КБайт - без проблем. Кстати, неплохо бы ещё, чтобы SPI-SRAM имела достаточную производительность. Параллельная SRAM снимет вопрос о производительности, но снимет ли вопрос по объёму ? Кроме того, с ЦП порулить большой параллельной SRAM - это много GPIO, которых всегда не хватает. Можно, конечно, воткнуть туда какой-нибудь i2c-GPIO-extender, хотя бы для старших адресных бит...

9

Re: Мост # 3

Voldemar0 пишет:

сложность в том, что SPI-SRAM на 256 КБайт найти немного не просто

Lyontek LY68L6400S - 8 Мегабайт за ~ 100р. на али.
https://datasheet.lcsc.com/szlcsc/Lyont … 261881.pdf

10 Отредактировано Voldemar0 (15-01-2022 20:15)

Re: Мост # 3

Спасибо, любопытная штука!
Есть ещё серия IS62WVSxxx - но там от 5 долларов за штуку. Зато это чисто SRAM, без "pseudo".
Но сперва попробую все способы по порядку перечисления.
==

Мне не очень хочется втыкать матрицу в схему, поскольку нужно будет либо уметь её прошивать прямо с ЦП (но тогда нужен протокол прошивки), либо устройство будет сложнее повторить (нужен внешний программатор).

==

Интересно, а если эту микру настроить на режим записи, а потом начать синхронизовать внешним генератором - она же будет как раз на каждый такт ловить отдельные биты с MOSI ?
Вроде по её протоколу это допустимо...

11 Отредактировано Voldemar0 (16-01-2022 11:33)

Re: Мост # 3

Покопался подробнее в доках на SPI и в исходниках линухового ядра, выкопал следующее:
1) Сам контроллер ECSPI в imx может работать как в slave так и в master mode. Нет проблем, дока особо никак не усложняет slave mode. Типа: битик один выставили в нолик и контроллер становится слейвом.
Кой какие битики другие при этом лучше бы поставить в определённые значения, хотя, более вероятно, что они просто не важны в slave-mode.
Теоретически, можно влезть в драйвер контроллера и просто поменять этот битик и, может быть, всё заработает. Судя по исходникам ядра, с которым я работаю, этот битик там явно hardcoded.

2) Но интересно, что ядро линуха, с которым я работаю, как сообщает документация, вообще не подразумевает spi как slave:
"Microcontrollers often support both master and slave sides of the SPI
protocol.  This document (and Linux) currently only supports the master
side of SPI interactions."

Инет намекает, что поддержка spi slave mode возникла не так уж давно - ей и 5 лет нет, похоже.
Как по мне - это странно, но так есть. Причем, копая исходники более поздних ядер, видно, что поддержка линуксом - это нисколько не поддержка драйверами. Условно, где-то в ядрах 4.1.x, в доках сообщили, что теперь слейв поддерживается, но при этом даже include/linux/spi.h не обновился. И драйвера никто не переписывал.
И только где-то к 4.20.x уже видны явные правки и конкретно в spi-imx.c уже появились упоминания slave, а главное - видно, что и битик режима зашевелился.

{ Возможно, причина в том, что в master-mode ПО задаёт количество передаваемых бит до начала транзакции и это позволяет драйверу сразу настроить все процессы, включая DMA-контроллер
(да, в больших процессорах DMA- наше всё и везде). А в slave, возможно, сделано динамическое выделение памяти, некий достаточно большой буфер и какая-то механника, контролирующая и сообщающая программе о его переполнении. Из-за этой сложности SPI-slave не вводился ранее. Но это только моё предположение. }

===

Тут надо пояснить: imx6 - это ARM как есть. Она очень сильно далека от plug'n'play, так сильно, что даже Агат на её фоне выглядит прогрессивной техникой. Если вы работаете с USB, то тут p-n-p живёт и здравствует - ибо в самом стандарте заложен pnp. Но остальные шины, как правило, требуют ручного конфигурирования устройств. Не потому, что это злобный заговор, а просто потому, что, как правило, ARM собран паяльником и никто ничего переставлять никуда не может. Так что и pnp не сильно нужен. С другой стороны - ну какой pnp, к примеру, на той же SPI-шине ? Она же тем и прелестна, что проста.
Но обратная сторона этого видна всем: вы не утащите прошивку от одного смартфона на другой.
Малейшее  изменение железа и прошивка уже не подходит. Всякие матрицы, тачскрины, камеры и прочее заточено под свои шины и никакого p'n'p там пока не просматривается. Драйвер заранее должен знать, что вы там воткнули.

==

Поэтому просто обновить ядро - это не скачать готовый билд и залить на устройство, а как следует посидеть и покрутить конфиги. А для userland SPI - ещё и маленько подправить исходники.
И единственное, что немного помогает: так называемый Device Tree Blob : специальный язык и файл, который частично описывает конфигурацию вашего железа. Частично. Т.е. не всё и не во всех случааях.
Например, если вы хотите на i2c повесить часики (ds1307) и в ядре у вас уже есть поддержка i2c и часиков, то в dtb вы можете указать, что припаяли часики на i2c N 2 и адрес микрухи будет 0x18.
Но если вы прилепили звуковой кодек, который использует i2c и SAI одновременно, и в его работе участвует и оба контроллера и ещё и к SAI привязан DMA ...... есть риск, что некоторых доработок ядра вам не избежать. Если их не сделал кто-то до вас: именно для сочетания браком вашего кодека & вашего ЦП.

В связи с этим, ставим дело на небольшой таймаут.
Соберу ядро 5.x, сконфигурирую его с учётом своих предположий о будущей схемотехнике, заряжу SPI и SPIDEV , разберусь как из своей проги дотянуться до переключателя master/slave, добуду внешний источник (тактовый генератор 7-9 МГц и какой нибудь предсказуемый сигнал MOSI)  и тогда будут новые результаты.

12 Отредактировано Voldemar0 (25-01-2022 18:16)

Re: Мост # 3

Сегодня только о Linux

Сборка ядра линуха на PC для PC не представляла, обычно, особых сложностей.
В период где-то с 2005 до 2015 я делал это неоднократно и схема всегда была довольно простой: качаем исходники ядра с сайта kernel.org (официальный сайт ядра), устанавливаем (если ещё не ставился) GCC и ещё кой какие пакеты (обычно перечисленные во всяких статьях и книжках). Потом распаковываем архив, делаем "make menuconfig" (при этом компилируется простенькая полноэкранная прога, которая позволяет настроить параметры ядра) и затем "make" - это уже компиляция ядра. На выходе получаем zImage - файл, который можно загрузить в память "пустой" машины разными загрузчиками, как автономными (типа lilo или grub), так и даже из под ms-dos (с выкидыванием ms-dos из памяти - привет агатовскому ПО).

Крайне редко бывало, чтобы этот процесс валился с какими-то ошибками.

Мороки было больше с настройками lilo или grub. Например, если нужна была какая-то замысловатая конфигурация загрузки: допустим, нужно было залить систему на пустой винт, который должен был в дальнейшем быть загрузочным, но подключенным на другой контроллер или другую позицию master/slave. В этом вопросе линух несколько менее очевиден, чем фряха.
К слову: ядро фряхи собирается примерно также, за исключением того, что там и настроек поменьше, так что их правят прямо в текстовом редакторе, в котором открыт файл конфига (файл небольшой, минут за 30 можно весь просмотреть, включая комментарии). И ставить для фряхи ничего не надо: source-base-операционка считает компилятор C неотъемлимой своей частью, как винда - свой IE.

Смысл кастомных ядер на PC был, в основном, в том, чтобы освободить ОЗУ: ядро грузится целиком в ОЗУ и если мильён драйверов в нём вам не нужны, то кастом позволяет резко уменьшить размер ядра. Актуально это было на компах с 8-32 Мб ОЗУ. И в дальнешем перестало играть существенную роль.
Разве что хотелось что нибудь этакого.... Ну, там, свой цвет системных сообщений или больше самодиагностики... Хотя многое из этого можно выкрутить настройками загрузки.

Для домашнего компа я также собирал фряху с двумя собственными патчами ядра:
1) снятие запрета на спецзначки в именах файлов на FAT (кавычки, звёздочки, вопросики..).
2) собственный формат таблицы разделов (когда был особо большой зоопарк операционок, уложиться в 4 записи MBR было сложно, кроме того была задача оградить некоторые ОС от возможности залезть в разделы других ОС, при этом сохранив классический MBR для M$-систем).

Года с 2015 всё стало немного шероховатее: бывает, что какая-то комбинация настроек внезапно приводит к сбою компиляции. Старожилы говорят, что так бывало и раньше, но я не сталкивался.
Эта проблема стала возникать и в линухе и во фряхе. Нередко это ошибки зависимостей: т.е. какая-то часть ядра A использует другую часть B, но в конфигураторе забыли указать эту зависимость A от B, в результате можно отключить сброку B при включенной сборке A. Но если в линухе это ошибка правил конфигуратора, то во фряхе ты вроде как сам правишь конфиг руками.... но порой трудно понять, как это самое A замысловато зависит от B.

--

Но когда делается кросс-компиляция (мне нужно собрать на PC ядро для ARM-A), всё происходит сложнее.

Кросс-компилятор включает в себя два набора элементов: компилятор + вспомогательные утилиты + ещё что нибудь для платформы сборки (т.е. x86), но также требуются и заголовки библиотек и всякое другое для целевой платформы (т.е. для arm). Если хотите статическую сборку (все библиотеки в один загрузочный файл), то, очевидно, нужны также и библиотки под целевую платформу.

Но и это ещё не всё: бывает так, что библиотеки со сложными, но легко автоматически проверяемыми алгоритмами (например, библиотеки расчёта хешей, архиваторы, шифрующее ПО, всевозможные аудио/видео конверторы и всякое такое) нередко пытаются в процессе сборки проверить сами себя. И у них это не получается: ведь мы собираем прогу для ARM, а работаем на PC: запустить собранную прогу или либу невозможно, разве что был бы какой-то стандартный механизм запуска внутри эмулятора.

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

Доходит до того, что сборщик просит запустить какой-то тест на целевой платформе, а потом вписать в какой нибудь файл результаты теста (увы, не помню сейчас, в какой проге я с этим сталкивался).

Всё это (наборы компиляторов для целевой платформы, библиотеки, заголовки...) называется toolchain.
Существует две широко известных toolchain (от Linaro и от Yocto). И куча инструментов вокруг них (poky, bitbake...) назначения которых для меня самого пока тёмный лес (да, я читал wiki, но пока это не подержишь в руках - всё равно больше вопросов, чем ответов).
Есть цепочки и от производителей процов. Возможно, это модификации той же linaro или yocto - не знаю, не понял пока.

--

Если для PC кастомное ядро в нынешнее время - дело необязательное, то для ARM дело выглядит сложнее: можно, конечно, найти собранное ядро какой-то версии для вашего проца (скорее всего на сайте производителя этого проца), но, скорее всего, в него будет включено ВСЁ что поддерживает этот проц.
Дрова (и вся инфраструктура) дисплейного контроллера, тачскрина, ... в общем, всего, что только можно и даже с горкой (драйвера каких нибудь файловых систем, которые нам не нужны, и что-то подобное). В то же время оперативы у нас на борту планируется 256 Мб. Не мало, но и не много.

По моему опыту, сборка кастомного ядра для bridge3 может уменьшить размер arm-ядра примерно с 20 Мб до 10 Мб (в ОЗУ).
Вроде не много, но вроде и не мало. Это - очень примерные цифры.
/ Тут ещё нужно учитывать, что ядро хранится в архиве и распаковывается только при загрузке в память.
Архивация уменьшает время загрузки ОС, но не уменьшает используемое ОЗУ. /

Ну и, вот уже на примере SPI (но и не только его), явно видно, что без пересборки ядра тут тоже трудно выкрутиться. Вы всегда можете взять готовое ядро от какой нибудь девборды, но как только схемотехника вашей платы начнёт отдаляться от девборды - рано или поздно (особенно, если вы добавляете новые элементы) вам придётся собирать своё ядро.

--

Итак, я захожу на kernel.org и выбираю 5.10.93. Создаю конфигурацию под imx6 (там уже есть готовые патчи для главного конфига от производителей кучи ядер) и пытаюсь его собрать.
У меня стоит toolchain от MYiR, но им я собирал только ядра 4.x.

Тут же начинают вылезать проблемы: компиляция ещё не дошла до самого ядра, а процесс уже не может найти какие-то заголовки. Причем строка в исходнике выглядит так: '#include "expr.h"'.
Кто не знает C: имя в кавычках означает файл, находящийся где-то вблизи вашей проги, а не общесистемный (общесистемные записываются в <>).

Начинаю поиски этого expr.h. Везде: в toolchain, в гугле, в исходниках ядра. Нахожу их кучу.
Не ясно - какой из них нужен и почему сборщик его не находит.
Копаюсь в настройках утилиты make, выкручиваю из неё вывод команд, которые выполняются, выясняю, что поиск делается внутри toolchain, причем в заголовках host-библиотек. Дальнейшие раскопки показали:
перед тем, как начнётся сама сброка ядра, для GCC собираются плагины. Вы слышали когда нибудь, чтобы программа требовала для себя кастомизации компилятора ? Я - нет.

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

Я попробовал найти именно эти заголовки именно для моей версии GCC, закинул их в toolchain (а почему их там нет - подумалось мне?), но, в итоге, всё закончилось ошибкой линкера: т.е. этих заголовков нет, потому что связанный с ними функционал был исключён из сборки конкретного toolchain. Как его включить? Пересборать GCC именно этой версии заного........... Не, это слишком тёмный лес для меня.

Хорошо, лезу на сайты linaro и yocto, качаю тулчейны оттуда.
Скорее всего, Yocto я скачал не весь, но что именно нужно брать с сайта - лень разбираться.
Во всяком случае там был небольшой архив и явно много чего не хватало. Самого GCC я там не нашел.
С Linaro вроде бы было всё,... но не всё: попытки найти там файлы, которые не нашлись в моей цепочке, показали их отсутствие и тут.
Возможно, эта та самая кошка, которую ещё нужно уметь готовить.

Поэтому я залез в архивы MyIR и выкопал там новую версию их toolchain. С ней 5.10.93 тоже не собирается - опять не хватает очередного хидера. Но зато с ней стала собираться (и даже собралась, пусть и изредка с warning'ами) версия 5.4.3. Я не волшебник - я только учусь (и всю жизнь учиться буду).

5.4.3 - вполне неплохо. Не исключаю, что будут собираться и другие 5.4.x.

--

Что стало плохо в 5.x ядрах: раньше с ядром шел Readme, в котором прямо сообщались требования к среде сборки: "Make sure you have at least gcc 3.2 available". В 5.x даётся только ссылка на https://www.kernel.org/doc/html/latest/ - и сам там ищи, что нужно конкретно твоей версии. Я пока не нашёл. Там очень много инфы, но, в основном, по внутренней структуре ядра.

--

Да, это всё занимает кучу времени. Но, как говорят студенты: "Первые два года ты работаешь на зачётку, потом зачётка работает на тебя". Так же и здесь: если ядро заработает, оно сразу даст огромное количество фич, которые на bare metal пришлось бы строгать и строгать. Это и стандартная работа с устройствами через драйвера (таймеры, ethernet, usb, готовое ПО для сети, i2c,...) и отладка прог, включая остановку прог, совершивших что-то недопустимое (вместо зависания всей системы). И удалённое управление устройством (сеть, com-порт, ssh...). В общем, почти все те же плюшки, которые имеет разработчик на обычной PC.

13 Отредактировано Voldemar0 (27-01-2022 07:32)

Re: Мост # 3

Ядра 5.4.3 и 5.4.173 собрались, но при попытке влоб их запустить - зависают при загрузке.
Коп-коп.... Коп-коп...
5.4.3 брал не на kernel.org, а у MYiR. Там добавлены файлы для MYiR 'овских SoM.
Попробовал собрать не универсальное ядро (по заветам NPX/FreeScale), а именно по конфигу MYiR.
Всё равно не работает.

Что ещё нужно ? Ещё есть важная штука - файл DTB. Его загрузчик грузит вместе с ядром в ОЗУ и ядру передаёт адрес, в которой DTB загружено.

Хм... ? Но DTB описывает оборудование. Но ведь оборудование у меня как бы не менялось вроде с 4.1.x ядер?

НО ! Это же opensource ! :)) Всё, что не ясно из теории и доков можно узнать в исходниках.

Лезем туда.... Жуть! Исходники DTB между 4.1.x и 5.4.x вообще почти не совпадают ....

Что там такое ? Ну, наверное, правдоподобное объясние может быть таким: драйвера сильно перерабатывались и им нужны теперь новые параметры. А возможно и как-то их взаимодействие перекроили. Синтаксис исходников похож на прежний, но построчное сравнение находит огромное количество различий.

Хорошо, пробуем собрать сначала то, что дают. Собирается. Скидываем новый DTB на карточку (Пока у нас для загрузки обычная LiveSD. Ну, насколько может быть обычной SD-шка, не содержащая FAT :). Да и загрузчик у неё не в MBR, а чуть дальше от начала диска. И ROM-loader читает не один сектор, а сколько надо. ... Но тех, кто видел разнообразие компов и их накопителей в 80-е - это всё не удивляет).

И да, теперь загрузка ядра явно дошла до конца (опустим тут ещё несколько занятных подробностей про девборду, с которой я это проверяю).

Но теперь нужно создать свой DTB: выкинуть всё лишнее, чтобы потом запихнуть всё нужное.
В чём суть: DTB от MYiR содержит описание всего фарша их девборд: со слотами для LCD, камер, звука, SIM card и прочей ереси. Нам же нужно будет зацепить управление дисководами, мелкий экранчик и прочее.
Сейчас пока цель: просто выкинуть всё лишнее и добиться того, чтобы DTB хотя бы компилялся без ошибок. А в идеале чтобы работало то, что я оставлю : Ethernet, USB, SPI, i2c, UART0.

Исходник DTB - это не один файл. Там используется структура, в основе которой лежат файлы от FreeScale, затем идут уже файлы от MYiR, всё это образует некую иерархию, от более абстрактных и обязательных частей (которые сидят внутри SoC) до более (уровень SoM) и более точного описания конкретной борды.
Это в идеале.

Но изучение текущего положения дел (после ядра 4.1.x) показало, что, похоже, у MYiR недавно сменились сотрудники :) Форматирование исходников корявое, добивка строк до 75 знаков пробелами слева (!!! походу, кто-то копипастил с терминала), структуру исходников переделали немного, так, чтобы мне было ещё неудобнее с ними работать.

В результате - первый блин комом. После моей первой же чистки это всё перестало компилироваться.
Потому что какой-то особо одарённый в описании SD-контроллера упомянул ножку с названием "xxx-WiFi-xxx". Явно же её там не должно быть... Вот так вот бывает. Но придётся разбираться: зачем ему это понадобилось ?

To be continue...

14 Отредактировано Voldemar0 (28-01-2022 21:17)

Re: Мост # 3

...можно выдохнуть: DTB запилил, пока приблизительный, наверняка (да точно совершенно!) придётся ещё править, но ядро грузится, комстрока есть. Даже вроде ethernet доступен (во всяком случае контроллер виден), debug-uart работает.

Зачем в настройках SD-контроллера упоминался WiFi?
Похоже, тут пытались примотать к борде WiFi контроллер bcm4329, а он подключается через SD-интерфейс. Видимо, эта лапка - какой-то особый сигнал, который отсутствует у обычной SD-карты. Reset, например.

В итоге сделал отдельную ветку в DTB-исходниках так, чтобы ничего лишнего в неё не попадало.
Так всё собралось без ошибок.

--

Теперь нужно проверить все ключевые контроллеры: i2c, ether, usb, маленько ещё подчистить DTB (там кой какие неясные мне устройства остались). Потом можно будет будет поизучать вопрос о выборе версии конфига ядра (FreeScale vs IMX, собираются оба, но конфиги имеют отличия. Запускаться должны оба, но надо проверить). И потом можно будет кастомить своё ядро. Сейчас ядро (архивированное) от FSL весит 10 мег, а MYiR - 9 мег. Хороший кастом, я надеюсь, даст мег 4-5 (тоже в архиве).

Также нужно постепенно собирать "мир" - это набор утилит, прог и прочего, что окружает ядро.
Что наверняка понадобится: утилиты управления SD-картами, управления файловыми системами EXT4 и FAT*, web-сервер, ssh-сервер, управление IP-стеком (iproute2), DHCP-клиент, базовые утилиты комстроки (diff, awk,cut, grep..... командный процессор... bash нужен или ash/tsh хватит?...). Нужно ли делить права на админа и непривелигированного пользователя ? Или всем админа дать ?... Если админ не у всех, например web-сервер с пониженными правами, то нужно sudo - без него, например, не получится изменить настройки сети из web-морды, или "отключить" SD-карту или USB-флешку, поправить время в часах...

Пароль на web-интерфейс будем ставить или ну его нафиг ?
HTTPS/TLS'а точно не будет :)

Работа не сложная (раз запускается - дальше будет проще), но действий много. Если не буду отвлекаться - за выходные какой нибудь рабочий черновик сделаю.

И потом возвращаюсь к изучению SPI. Хотелось бы до середины февраля всё таки понять: будет это работать или нет? Когда какой-то вариант семплирования заработает, дальше можно будет уже рисовать эскиз печатки (набор деталей и размещение на плате).

15 Отредактировано Voldemar0 (02-02-2022 10:39)

Re: Мост # 3

Собрал черновик мира, ядро задавил до 4.6 Мб в архиве, всё это работает.
От запуска ядра до готовности к работе (т.е. запуска первого процесса init) проходит всего 1.5 секунды.
Таким образом полный запуск ОС от включения питания составляет где-то секунда 5. Из которых пару секунд загрузчик ждёт press any key (можно прервать загрузку и что нибудь другое поделать, ОЗУ потестировать, например).

Но копание в SPI наводит на грустные мысли:

/* The maximum bytes that a sdma BD can transfer. */
#define MAX_SDMA_BD_BYTES (1 << 15)
#define MX51_ECSPI_CTRL_MAX_BURST       512
/* The maximum bytes that IMX53_ECSPI can transfer in slave mode.*/
#define MX53_MAX_TRANSFER_BYTES         512

Вопрос, что такое "транзакция" здесь? Что будет, если CLK будет идти непрерывно?
Возможно, что DMA-движку нужно время для того, чтобы скинуть всё в ОЗУ и потом продолжить работу.

Ну и другие сложности: формально slave -режим в новых ядрах есть, но такое ощущение, что только в отдельных форках для конкретных девборд его всё таки довели до ума. В основном дереве линуха всё пока как-то мутно для меня. То ли доков не хватает, то ли и кода тоже.

На всякий случай заказал LY68L6400, они до меня месяц-два будут идти, как раз если со SPI не получится то будут эти микрухи. Если бы не желание всё таки уменьшить число деталей, то, с точки зрения сложности разработки, наверное на внешней RAM было бы проще всё сделать.

Заодно заказал и всякой фурнитуры: кнопочки на плату (несколько разных видов), двухцветные светодиоды и белые семисегментные индикаторы, сразу в паре с контроллерами tm1637.
Вряд ли буду использовать их как модуль, скорее всего разберу на детали и соберу на своей плате.
Плюс tm1637 - поддержка клавиатуры на 8 кнопок. Минус - у него последовательная шина какая-то своя собственная. Была бы i2c, что ли, было бы попроще. Но это всё несущественно (по сравнению со SPI).

--

Ещё вопрос, который маячит впереди: формат образов, в который будет происходить запись?

- Мост один для всех форматов.
- Я уже сталкивался с дисками, у которых разные дорожки записаны в разных форматах.

Всё просто: форматнули B- сторону в 140, потом весь диск в 840.
В результате 0-3 трек на B- стороне в формате 140 (а 4 дорожки на агате - это целая операционка может влезть), а диск в целом - 840ка.

Или диск форматнули в 840, а потом на PC в 360 на 80-цилиндровом дисководе.
В результате через одну идут дороги двух форматов.

Мост не может тут принять решения о том, что какой-то из форматов предпочтительный.
Хотя бы потому, что в одну дорогу 840ки можно всунуть > 20 блоков - а это немаленький размер для агатовского файла. Даже если будет потёрт каталог - нередко такие файлы можно выдернуть, если есть TSL. Даже если файл размазало и часть его повреждена, если файл будет опознан, он всё равно может пойти на донорство, если в его составе сохранились сектора, которых нет в коллекции (есть тот же файл, но повреждённый).

Более-менее можно оценить тип диска только прочитав с десяток дорожек.
Ещё более простой случай: была 840ка, потом её хотели форматнуть в 140, форматтер вылетел по ошибке дорожке на 5-й. В итоге первые пять дорог - пустая 140ка, мы снимаем её мостом-140, а потом выясняется, что там ещё дофига файлов в формате 840ок, даже каталог живой.

Т.е. нужно хранить образ в каком-то битовом формате, не завязанном на конкретном формате записи дискеты. Из которого "на суше" конвертировать в EIM-140, EIM-840 или что-то ещё. Я склонен не сваливать на мост задачу получения сразу DSK, так как внесение исправлений в ПО моста всё таки будет сложнее, чем в PC-шной проге.
Т.е. как побочная функция - пусть генеряет DSK по какой-то упрощённой логике, но исходные данные должны сохранятся.

- Если выбрать формат широко поддерживаемый, то, если встретятся диски не агат и не PC, существующим ПО можно будет их декодировать (какие-то виды контроллеров ДВК, может быть что-то ещё).

- Если это будет собственный формат, то будет проще вписать в него 140ку (например, данные о "раскачке" головки - когда она стоит не точно на фазе). Да и своё всегда ближе.
Формат fluxы - как по мне - избыточен: GZIP-сжатие, SQLIte...
Формат SCP - немного неудобный для работы (у него заголовков много и они размазаны по файлу)...
Какие ещё есть?

16

Re: Мост # 3

Облом: LY68L6400 я заказывал у продавца, который выставлял ценник около 200р за 5 штук, в то время как у других было уже под 1000р.
Видать продаван, получив заказ, сообразил что чего-то недополучает и отморозился.
Потому что заказ не был отправлен, Али обещает возврат денег, а лот поднялся за 900р.

На али есть ещё такая штука - 23LC1024, надо почитать, может это будет лучше.

17 Отредактировано Voldemar0 (20-03-2022 18:43)

Re: Мост # 3

Заказал 23LC1024, с тех пор стоимость лота упала за несколько дней, но пока продавец не шевелится.
Остальная фурнитура пришла (кнопки, переключатели). Процы тоже уже есть.

Осваивал tm1637 - похоже, чисто китайское произведение - контроллер светодиодов.
Польстился, потому что продаётся недорого в сборе с индиком и заодно может обслуживать клавиатуру на 8 кнопок.

Дока всего 12 страниц, многого не хватает:
- Как задаётся ток через светодиоды ? Максимальный допустимый через ключи указан, но никакой стабилизации не упоминается.
- Протокол обмена - не i2c, как пишут везде в наших магазинах, а какая-то хитрая пародия на неё. В доке не указано даже, MSB first или LSB first.

В общем-то за день расковырял всё, но не без помощи инета. Работает :)

Post's attachments

IMG_20220320_213319.jpg, 50.83 kb, 700 x 322
IMG_20220320_213319.jpg 50.83 kb, 14 downloads since 2022-03-20 

18

Re: Мост # 3

Сухарики и чипсы приготовил.

19 Отредактировано Voldemar0 (21-03-2022 07:10)

Re: Мост # 3

> Сухарики и чипсы приготовил.

:)) Ты их пока не распаковывай - работы ещё выше крыши.
Пока семплер не будет работать, хотя бы на макетке, всё это - мечты.
А когда он будет работать, ещё будет огромная куча всякого разного:
1) дизайн (расстановка основных элементов управления: кнопки, светодиоды, переключатели, дисплеи; потом расстановка всех микрух, разъёмов...), схема, печатка.
2) ПО: вспомогательное (web-сервер: фронт-энд, бек-энд, эмуляция USB-флешки, управление индикаторами...), основное (управление дисководами, все эти алгоритмы выбора параметров декодеров, сами декодеры GCR- MFM-агат, ...).
Вроде почти всё это есть по частям, есть конкретные решения, но всё собрать в кучу - мрак сколько работы.

20

Re: Мост # 3

А не слишком крупная система получается? В смысле очень уж замысловатая.

21 Отредактировано Voldemar0 (21-03-2022 11:50)

Re: Мост # 3

Так и чтение дисков лучше чем это делал оригинальный контроллер, с распознаванием форматов - это уже усложнение. Плюс автономность. У моста #1 ПО было размазно между агатом и pc, у моста #2 - между мостом и pc. Здесь же всё одной куче. Причем в 1 и 2 версии не было программной эмуляции контроллеров дисководов - использовалось уже существующие или скопированные аппаратные решения.

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

Я почему про сухарики "не распаковывать" говорю:
по основной работе давно знаю: насколько бы задача не выглядела простой, всё равно всегда есть вероятность, что вылезет что-то, о чём даже не думал. Так что оцени потребное время и умнож на два.
Лучше сделать до срока (и оставшееся время потратить на дополнительные тесты), чем потом откусывать время от других дел.

Отладчик для агата это и показал: когда было сделано уже почти всё, оказалось, что кой где кой когда это всё практически перестаёт работать и надо ещё вбахать столько же времени.

22 Отредактировано Voldemar0 (15-05-2022 21:54)

Re: Мост # 3

Вроде микрухи SRAM поехали, наконец... Что-то там странное было, то что-то с почтой, то ещё какие-то не ясные проблемы. Всё остальное без проблем заказывается, только SRAM как заколдованная. Полгода уже скоро, как я её заполучить пытаюсь.

Надо понемногу начинать продумывать на чём сделать стык Флопик <-> SRAM <-> CPU. Какая-то мелкая, но быстрая логика, которая подключает управление SRAM либо от CPU либо от внешнего генератора и канала чтения дисковода. Генераторы 8.00 МГц  (тактирование чтения/записи) уже есть и проверены. Т.е. делаем так: CPU опускает !CS, выводит SRAM в режим записи с автоинкрементом, с нулевого адреса. Затем перещёлкивается логика и на CLK SRAM начинает лететь стабильные 8 МГц, а на MOSI вход подключается сигнал от дисковода. Через 200 мс всё перещёлкивается обратно (CPU всё это время мониторит edge сигнала Index и отмечает у себя время его переключения). CPU поднимает !CS, опускает обратно и затем считывает содержимое SRAM уже в свою DRAM для анализа, поднимает !CS.

Надо какую-то мелкую тестовую плату для этой логики придумать, чтобы обкатать идею.