Общие знания по Linux/ARM Опции

[RadiatoR]

Всем доброго дня.
Около года назад вооружился платкой DE0-nano-SOC с cortex-a9 на борту. С тех пор при не особо резвом курении платки удалось помигать светодиодом на HPS, потестить периферию.
В процессе курения у меня вылезла куча вопросов, аля:

1. Линукс, работа в нем, его сборка и прочее
2. Компиляторы, линковщики и прочие утилиты которые я знаю только по названию и тому, зачем они нужны
3. Make файлы, scatter файлы и прочие файлы, необходимые для сборки чего-либо.
4. Процесс создания ПО на такого рода ядра (cortex-axx) в большинстве случаев выглядит как "скачиваем -> make -> заливаем бинарник на флешку -> вуаля, линукс забутился". Не совсем ясен процесс создания например чистого baremetal приложения (с помощью него я уже помигал светиком, но за основу брался GoldRef) с нуля.
5. Заливку бинарника на флешку, файловые системы, благо более менее понял.
6. Какое-то время назад узнал, что, например андроид можно собрать только под линуксом - непонятно почему.

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

В общем есть большая пропасть, а вместе с ней есть вопрос - есть ли какая-то общая точка входа по изучению этих вопросов (полагаю все крутится именно вокруг самого линкуса)? Или какого-то общего описания нету и придется все по кусочкам изучать?

Спасибо.

[RadiatoR]

6. Так в том то и вопрос - почему его нельзя собрать, например в винде. Компилятор есть, что не так то...
(кстати по поводу для чего - у нас на работе для некоторых целей используется в данный момент обычный китайский планшет к которому приделан переходник SPI->CAN, так как хардварного CAN нету в проце (rockchip какой-то). Работа самого SPI осуществляется из операционки, что тормознуто. Вот и хочется сделать нормальную оболочку (драйвер) для переходника и, более того, собрать свою платформу на одной плате в нормальном корпусе, а не сопливую железяку, как сейчас).

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

Вообще из всего этого непонятным больше всего остается даже не сама ось и работа в ней и не ее сборка, а все те makefile, scatter file и подобные + настройки среды для компиляции какого-либо кода

[Jury093]

6. Так в том то и вопрос - почему его нельзя собрать, например в винде. Компилятор есть, что не так то...

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

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

к вопросу о вышеупомянутом SoC, если я правильно помню, то в среде Quartus и Co под винду можно сгенерить вплоть до u-boot без всяких линуксов, т.е. ваш стендалоне вполне тоже можно сделать не погружаясь в линуксы

(чуть в сторону) если честно, я не очень понимаю тенденцию брать FPGA+ARM в одном кузове и пилить туда бареметал, делая восход солнца вручную..

[RadiatoR]

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

просто не ясно что именно является препятствием...

к вопросу о вышеупомянутом SoC, если я правильно помню, то в среде Quartus и Co под винду можно сгенерить вплоть до u-boot без всяких линуксов, т.е. ваш стендалоне вполне тоже можно сделать не погружаясь в линуксы

(чуть в сторону) если честно, я не очень понимаю тенденцию брать FPGA+ARM в одном кузове и пилить туда бареметал, делая восход солнца вручную..

Так я выше написал, что на HPS сделал бареметал, но он был по голдрефу.
Не придерживаюсь какой-либо тенденции. Просто хочу изучить и ПЛИС и ARM процы и их связку. Если с ПЛИС порядком попроще и порог входа поменьше (в сети достаточно много примеров всех мастей), то с микропроцессорами обстоит дело сложнее. По крайней мере для меня, т.к. в основном работа связана только с программированием либо на микроконтроллерах (опять же из готовой, настроенной среды), либо для десктопа (утилиты для работы с девайсами на C#). Так и выходит, что процессоры никогда не затрагивал. Для саморазвития, тем более в наше время с их тотальным заполнением считаю необходимым. При этом не просто уметь скомпилить и залить что-то готовое, но и самому разобраться в недрах процесса создания ПО с 0, его граблей и прочего...

В общем я понял - начну курить про сборку + использование линукса, а там по дороге зацеплю и всякие makefile...

[Jury093]

просто не ясно что именно является препятствием...

неохота влезать в эти бессмысленные войны, но кто будет этим заниматься? майкрософт - ей это не нужно, чистая поддержка конкурента.. линуксоиды? а кто им даст исходники платной операционки? а под какую версию делать 7, 8, 10, 15?
как выше написали, даже поддержать NTFS венды не могут полноценно, видимо нет полноценной доки..

Не придерживаюсь какой-либо тенденции. Просто хочу изучить и ПЛИС и ARM процы и их связку. Если с ПЛИС порядком попроще и порог входа поменьше (в сети достаточно много примеров всех мастей), то с микропроцессорами обстоит дело сложнее. По крайней мере для меня, т.к. в основном работа связана только с программированием либо на микроконтроллерах (опять же из готовой, настроенной среды), либо для десктопа (утилиты для работы с девайсами на C#). Так и выходит, что процессоры никогда не затрагивал. Для саморазвития, тем более в наше время с их тотальным заполнением считаю необходимым. При этом не просто уметь скомпилить и залить что-то готовое, но и самому разобраться в недрах процесса создания ПО с 0, его граблей и прочего...

всегда полезно почитать и поизучать, особенно если в дальнейшем пригодится..
я стараюсь получить ключевые бинарники из исходников, начиная от прелоадера и до драйвером, ну и рутовую свою сгенеренную, чоуж мелочиться..
в бареметал на SoC должен быть какой-то скрытый смысл, иначе проще взять обычную ФПГА и к ней прикруть хоть stm32, благо их дофига разных.. но сильной стороной HPS под линукс будет коммуникативные возможности (терминалы, сеть, юсб) и шустрый интерфейс с фпга
успехов в освоение!

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

[mantech]

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

Скажем так, с нуля тут тоже никто не изобретает, ибо на "правильные" чипы идет planform SDK, где уже практически на все железо есть драйвера, да, протоколы надо реализовывать, но большой сложности в этом нет.
А насчет кучи багов, которые якобы отлавливаются кем-то... Во первых, отлавливается то, что использует большинство, например сетевые стеки, ФС и т.д. Но в задачах, особенно нетривиальных, приходится писать свои драйвера, возможно протоколы и программы, и не на баше и пр. скриптах, а на чистом Си, как правило, и вот тут все куда хуже, надо знать все закоулки ОС, в которой будет работать программа, отлавливать те же глюки и никакое сообщество тут не поможет...
Просто в большинстве своем, на том же линуксе сделают какой-то скрипт, подсунут стандартный драйвер и ба, заработало...Так это типичный подход ардуинщика... А реально программировать на нем умеют единицы.

ЗЫ. Ну и сам столкнулся в свое время с проблемой. На сд-карте, кде была основная часть линуксовых файлов, с корневой ФС и т.д. У клиента слетела ФС, то-ли при отключении питания и происходила запись логов, то=ли еще что, но перестала загружаться система, клиент полный дуб в линуксе и вообще неуверенный пользователь ПК. Вот как мне ему объяснить все процессы восстановления линуксовой системы??? Проще приехать через пол-страны и сделать самому... Вот тогда и решил, что на сд-карте будет только бинарь программы, конфиг и все под фат32, которую можно использовать на любом компе. Проблема исчезла сама собой

Сообщение отредактировал mantech - Mar 15 2018, 08:30

[RadiatoR]

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

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