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 (Сегодня 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.