[mitro 4]

Добрый день!
Пытаюсь собрать petalinux для Zynq7010. Который стоит на дешёвой плате от майнера с Алиэкспресс.

Как-то всё идёт очень тяжело. Мануала ug1144 и книжки Madieu J. Linux Device Drivers Development.2-nd.2022.pdf явно недостаточно.

Никто не подскажет, чего бы почитать популярного, чтобы как-то освоить u-boot и device tree? И сборку linux для Zynq?

Пытался переиспользовать чужой опыт - вязл пример с https://github.com/har-in-air/EBAZ4205_PETALINUX. Он для petalinux 2022.2. Порадовался, что там всё "с нуля" в части линкуса - просто несколько инструкций, что делать. Но только ничего не заработало. Дальше u-boot не пошло. Ethernet не видит, ядро не грузит...

Попробовал проект https://github.com/KeitetsuWorks/EBAZ4205. Не поленился, скачал для него petlinux 2021.2. Он хоть и с танцами, но похоже, заработает. Жалко, что там предлагается готовая папка с проектом petalinux, придётся делать "reverse engineering" - создавать самому пустой проект и сравнивать с этой папкой чтобы понять, что человек добавил.

Нельзя ли чего-нибудь почитать, чтобы как-то более осознано себя вести, уметь решать задачи типа:
"Вот у меня на плате Zynq7010, к определённым пинам подключена микросхема Ethernet IP101GA. Чего и как наконфигурировать в petalinux, чтобы это добро зарабоало?" Или:
"На той же плате стоит еще NAND память, подключена туда-то. Чего наконфигурировать в petalinux, чтобы можно было с ней работать?"
"Что изменить, чтобы грузиться не с SD-карты, а с NAND? Как разбить её на partitions, почему так?"

Пока какая-то каша в голове. Есть готовые ответы от "KeitetsuWorks", но шаг в сторону - и непонятно, чего делать. Как отлаживаться тоже непонятно.

Почему всё так сложно? Линукс же на МК придумали, чтобы было просто! Похоже, я что-то не так делаю. Поправьте, пожалуйста!

[Alex77 12]

оффтоп... какой наивный молодой вьюноша...

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

[mantech 139]

В 16.10.2025 в 17:09, mitro сказал:

Почему всё так сложно? Линукс же на МК придумали, чтобы было просто!

   Это точно...

Здесь есть линуксмегагуру sasamy у него поспрошайте, для него это все просто и понятно)))

[fguy 9]

В 16.10.2025 в 17:09, mitro сказал:

Линукс же на МК придумали, чтобы было просто!

Посмотрите на дроид смартфоны - за 15 лет из за "простоты" линукса для них так и не смогли осилить универсальный дистрибутив. При этом дистрибутив (прошивка) 15-го дроида под самсунг S24 FE занимает 18 Гб в архиве, а 11й винды которая ставится куда ни попадя меньше 10.

Линукс на плисах для проца имхо нужен если вы собираетесь подключать периферию с интерфейсами USB/exPCI/SATA и т.п. РС-шное наследие - в нем есть готовые драйвера и адекватная работа с любой фс на накопителях. Если такое не нужно, то для пинка своим ядрам хватит и натива.

[mantech 139]

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

15-го дроида под самсунг S24 FE занимает 18 Гб в архиве

Вот быдлокодеры развлекаются, такое впечатление, сколько б не дай памяти, они ее всю сумеют [censored] использовать))))))0

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

Линукс на плисах для проца имхо нужен если вы собираетесь подключать периферию с интерфейсами USB/exPCI/SATA и т.п.

использовать сетевые стеки с расширенным функционалом, какие-либо сложные протоколы, камеры, распознавание образов, ИИ и пр. Если все проще, ИМХО пишите на простом Си без ОС.

Edited October 20, 2025 by mantech

[dxp 211]

5 копеек про линукс.

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

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

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

На прошлой работе наблюдал ситуацию, когда прибыла новая плата от контрактного производителя (какая-то SoC на Rockchip там была), и на второй день она полностью работала -- вся периферия, память, сеть... Я был очень впечатлён! Да, она попала в руки человеку, который только этими вопросами (брингап линуксов на новых платах) и занимался, поэтому он чётко знал, что делать, сценарии отработаны: конфигурирование дистрибутива, сборка ядра, рекомендованного вендором с патчами от него, сборка uboot, корневой. Немножко возни с контроллером памяти (тайминги подобрать под конкретную планку), и всё подтяно. В случае с платами с МК на брингап уходит времени куда как больше -- там с периферией приходится возиться на низком уровне, а в случае с вендорской сборкой ембеддед линуха там вся эта работа уже проделана. Отсюда и скорость брингапа.

Если сравнивать подходы с периферией в МК (baremetal) и SoC (embedded linux), то в первом случае оно намного проще в реализации -- вся работа напрямую, а не через кучу условностей (модули ядра, их загрузка, всякие device tree и т.п.), но во втором получается почему-то быстрее и проще в использовании. А дело в том, что в этом случае просто вся эта работа уже на 90-99% выполнена кем-то (вендором, например), а методика использования формализована (например, через концепцию файлов). А учитывая, что периферия SoC обычно изрядно посложнее таковой в MK, то способ, применяемый в линухе (драйвера устройств) начинает рулить ещё больше.

В итоге, нравится это кому-то или нет, но этот подход доказал на практике свою состоятельность. Да, за это тоже есть цена -- например, никакой линух не сможет посоперничать с baremetal по времени реакции на события, где даже средний МК будет куда увереннее, чем жирная SoC, но во многих случаях это оказывается не критичным, а задачи, требующие жёсткого реального времени, решаются соответствующей аппаратурой SoC -- именно поэтому она такая предметно-ориентированная (в отличие от таковой в МК).

[alexadmin 2]

On 10/21/2025 at 9:27 AM, dxp said:

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

Я почти согласен за одним исключением. Свои форки - это не способ поддержания прямоты и стабильности, а следствие необходимости внедрять свою кривизну и уродливость, шансы просунуть которую в основное ядро и вовсе нулевые 😉 

[dxp 211]

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

следствие необходимости внедрять свою кривизну и уродливость

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

 

[Alex77 12]

В 21.10.2025 в 09:27, dxp сказал:

5 копеек про линукс.
память, сеть... Я был очень впечатлён! Да, она попала в руки человеку, который только этими вопросами (брингап линуксов на новых платах) и занимался, поэтому он чётко знал, что делать, сценарии отработаны: конфигурирование дистрибутива, сборка ядра, рекомендованного вендором с патчами от него, сборка uboot, корневой. Немножко возни с контроллером памяти (тайминги подобрать под конкретную планку), и всё подтяно. В случае с платами с МК на брингап уходит времени куда как больше -- там с периферией приходится возиться на низком уровне, а в случае с вендорской сборкой ембеддед линуха там вся эта работа уже проделана. Отсюда и скорость брингапа.
 

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

[sasamy 15]

1 hour ago, dxp said:

Линукс внутри местами (много где) весьма уродлив. Причина этого, имхо, в т.н. "базарном" стиле разработки, когда его пилят все, кому не лень.

сильно устаревшее впечатление - линукс уже давно пилят только корпорации и околкорпоративные конторы типа  Collabora, Bootlin, Pengutronix etc. 

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

[dxp 211]

10 минут назад, Alex77 сказал:

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

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

[sasamy 15]

18 minutes ago, Alex77 said:

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

если драйвер периферии/внешнего устройства в основной ветке или есть драйвер со стандартным интерфейсом никаких проблем не бывает как правило - берешь пример и адаптируешь его для своего дизайна

[dxp 211]

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

сильно устаревшее впечатление - линукс уже давно пилят только корпорации и околкорпоративные конторы типа  Collabora, Bootlin, Pengutronix etc. 

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

 

[sasamy 15]

6 minutes ago, dxp said:

Это фундаментальный косяк линуха!

это фича  - внешний интерфейс стабилен а внутренний нет потому что это монолитное ядро - модули только формально внешние для ядра 

6 minutes ago, dxp said:

Т.е. базовый принцип грамотного проектирования "Отделение интерфейса от реализации" создатели линуха не знают.

а смысл морозить внутренние интерфейсы в чём ? кроме торможения развития

Edited October 21, 2025 by sasamy

[dxp 211]

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

это фича  - внешний интерфейс стабилен а внутренний нет потому что это монолитное ядро

При чём тут монолитность ядра? Монолитность ядра -- это про модель памяти, а не про интерфейсы к драйверам. Не фича это, а отмазка. Не подумали в своё время, а теперь уже поздно -- такое легаси стало. 

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

а смысл морозить внутренние интерфейсы в чём ? кроме торможения развития

Какие-такие внутренние интерфейсы? Драйвера устройств разрабатывают вендоры этих устройств, а это совсем посторонние люди и организации. Поэтому для них надо предоставить DDK, как это сделала M$, и пилите себе ядро, сколько влезет, DDK не трогайте только. Интерфейсы трогать только при переходе к новой мажорной версии. Это как бы азы разработки ПО.

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