Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Cubieboard2
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Отладочные платы
berkl
Привет форумчане,

Вот хочу начать юзать эту http://docs.cubieboard.org/products/start#a20-cubieboard плату но не могу разобраться с кросскомпиляцией. У меня инструменталка - Убунта, на кубике предполагается юзать Lubuntu. Нужен кросскомпилятор (тулчейн), но на сайте производителя я нашел только вот эту статейку http://docs.cubieboard.org/tutorials/cb1/d...on_ubuntu_12.04 Там предлагается использовать Sourcery CodeBench Lite, и в качестве примера компилируется HelloWorld! незамысловатой командой
Цитата
arm-none-linux-gnueabi-gcc–static –o first first.c

То есть скачали тулчайн и сразу компилируем, и пофиг какое у нас железо 05.gif ? Настраивать gcc не надо, хотя бы указать какая архитектура у нашего камешка (ARMv7-A) ?

Дальше нашел форум forum.xda-developers.com/showthread.php?t=2098133http://forum.xda-developers.com/showthread.php?t=2098133 Тут один товарищ Christopher83 настрочил кучу тулчайнов тулзом CrossTool-NG для разных версий линаровских gcc и gdb. Примечательно, у него часть тулчайнов собрано для конкретного проца (какой та там Самсунг). Другая часть - так называемые "generic". Типа куда угодно подойдут, как есть, включая тот же кубик ?

Проясните пожалуйста, как пользоваться "generic" кросскомпиляторами, вроде CodeSourcery, Linaro. Неужели просто брать и компилить, и пофиг что у меня: кубик, малина, или еще какой-нибудь бигль ?

Заранее благодарен
psL
Цитата(berkl @ Jan 4 2014, 11:32) *
и пофиг что у меня: кубик, малина, или еще какой-нибудь бигль ?

пофиг. Поскольку пример собирается под linux к томуже без зависимости от динамических библиотек
berkl
Цитата(psL @ Jan 4 2014, 12:41) *
пофиг. Поскольку пример собирается под linux к томуже без зависимости от динамических библиотек


Интересно. Разве кросскомпиляция не настраивается на конкретный процессор ? Да, скомпилированная программа будет работать под управлением Линукса, но всё таки она скомпилирована в набор команд, инструкций целевого чипа. Или как? Тот же Codesourcery Lite (arm-none-linux-gnueabi-gcc) поддерживает сразу 3 архитектуры: armv5, armv6, armv7-a. Неужели ему не интересно хотя бы для какой из перечисленных архитектур мне щас надо компилировать мои сишники ?

Спасибо!
mdmitry
Цитата(berkl @ Jan 4 2014, 13:13) *
Разве кросскомпиляция не настраивается на конкретный процессор ? Да, скомпилированная программа будет работать под управлением Линукса, но всё таки она скомпилирована в набор команд, инструкций целевого чипа. Или как? Тот же Codesourcery Lite (arm-none-linux-gnueabi-gcc) поддерживает сразу 3 архитектуры: armv5, armv6, armv7-a. Неужели ему не интересно хотя бы для какой из перечисленных архитектур мне щас надо компилировать мои сишники ?

Кросскомпиляция настраивается на конкретный процессор и с конкретными опциями, в том числе и линкера. Делается это чаще в Makefile.
psL
Цитата(berkl @ Jan 4 2014, 13:13) *
Неужели ему не интересно хотя бы для какой из перечисленных архитектур мне щас надо компилировать мои сишники ?

Ему - нет. Вам интересно, вы и задавайте, например через -march
berkl

Цитата
Кросскомпиляция настраивается на конкретный процессор и с конкретными опциями, в том числе и линкера. Делается это чаще в Makefile.


Понятно.

То есть нельзя делать как тут http://docs.cubieboard.org/tutorials/cb1/d...on_ubuntu_12.04 рекомендуют. Типо скачал кросскомпилятор, подсунул его make'у вместо нативного gcc инстументалки и привет.
psL
Цитата(berkl @ Jan 5 2014, 16:46) *
То есть нельзя делать как тут http://docs.cubieboard.org/tutorials/cb1/d...on_ubuntu_12.04 рекомендуют. Типо скачал кросскомпилятор, подсунул его make'у вместо нативного gcc инстументалки и привет.

ссылка не открывается.
Без указания архитектуры сборка будет производится под generic arm, т.е. без использования характерных комманд и оптимизации. Линукс как раз и портируют на другие архитектуры, чтобы обеспечить однотипную среду выполнения и инструменты сборки в независимости от архитектуры, т.е. чтобы "подсунул и привет"
mdmitry
Цитата(psL @ Jan 5 2014, 20:12) *
Без указания архитектуры сборка будет производится под generic arm, т.е. без использования характерных комманд и оптимизации. Линукс как раз и портируют на другие архитектуры, чтобы обеспечить однотипную среду выполнения и инструменты сборки в независимости от архитектуры, т.е. чтобы "подсунул и привет"

Именно ARM????
Сборка должна идти для системы в которой выполнен запуск, если в makefile не указан кросскомпилятор и ARCH явно.
psL
Цитата(mdmitry @ Jan 5 2014, 23:14) *
Именно ARM????
Сборка должна идти для системы в которой выполнен запуск, если в makefile не указан кросскомпилятор и ARCH явно.

в случае:
Код
arm-none-linux-gnueabi-gcc –static –o first first.c

именно ARM
mdmitry
Цитата(psL @ Jan 6 2014, 00:11) *
в случае:
Код
arm-none-linux-gnueabi-gcc –static –o first first.c

именно ARM

Это явно набранная командная строка и сомнений нет, что arm.
Если хочется десятки файлов большого проекта так собирать, то конечно можно - дело вкуса.
Пакеты linux`а все же обычно собираются с помощью утилиты make. При сборке ядра (с помощью make) для платформы отличной от текущей, необходимо явно указывать архитектуру и кросскомпилятор.
berkl
Цитата
ссылка не открывается.


Извиняюсь, вот
http://docs.cubieboard.org/tutorials/cb1/d...on_ubuntu_12.04

Цитата
Без указания архитектуры сборка будет производится под generic arm, т.е. без использования характерных комманд и оптимизации.


Собственно я и тему поднял потому что не понятно что есть "generic arm" . Значит "generic" собирается из набора инструкций, совместимого со всеми архитектурами, входящими в данный тулчейн, так? В этом случае, вероятно программа будет работать относительно не оптимально или даже неприемлемо медленно. Зато она запустится и на кубике и на планшете из соседнего ларька. Так?

Цитата
Пакеты linux`а все же обычно собираются с помощью утилиты make. При сборке ядра (с помощью make) для платформы отличной от текущей, необходимо явно указывать архитектуру и кросскомпилятор.


Для кросскомпиляции обычных приложений, под конкретное железо, наверное тоже надо взять за правило настраивать gcc, а не использовать "generic" ?
psL
Цитата(mdmitry @ Jan 6 2014, 00:23) *
Это явно набранная командная строка и сомнений нет, что arm.
Если хочется десятки файлов большого проекта так собирать, то конечно можно - дело вкуса.
Пакеты linux`а все же обычно собираются с помощью утилиты make. При сборке ядра (с помощью make) для платформы отличной от текущей, необходимо явно указывать архитектуру и кросскомпилятор.

Явно набранная кем? Разве при обработке makefile будут выполняться какие-то другие команды?
Но мне понятно о чем вы пишете.
Видимо вопрос ТС не в том, как перенести программу с x86 на arm, вопрос в том, обязательно ли задавать архитектуру для тулчейна или достаточно того, что сборка будет производится под платформу (generic).
Для программ типа first.c, да и для многих других задавать архитектуру необязательно.
berkl
Цитата(psL @ Jan 6 2014, 02:26) *
Видимо вопрос ТС не в том, как перенести программу с x86 на arm, вопрос в том, обязательно ли задавать архитектуру для тулчейна или достаточно того, что сборка будет производится под платформу (generic).
Для программ типа first.c, да и для многих других задавать архитектуру необязательно.


Как переносить с х86 на arm я дейсвительно не спрашивал.
Кроме задания архитектуры (-march) есть и другие опции определяющие целевую платформу (-mfpu, -mfloat-abi, -mcpu, может еще какие) Я понял, далеко не везде обязательно их указывать. А поконкретнее можно сказать когда недостаточно собирать для generic linux arm?
Или может просто, чтоб не думалось, изначально как можно больше прописывать уточняющих опций кросскомпилятору в makefile?

Я не хочу ничего нового придумывать, хочу знать как делается

Спасибо
mdmitry
Цитата
Явно набранная кем? Разве при обработке makefile будут выполняться какие-то другие команды?

Предлагается набирать в терминале (см. указанную ТС ссылку) без использования make.
Что в Makefile указано при сборке, то и будет выполняться, в том числе вызов сторонних программ (например, для подсчета контрольной суммы и ее записи в бинарный файл, что необходимо для LPC17xx).

Цитата(berkl @ Jan 6 2014, 10:10) *
Кроме задания архитектуры (-march) есть и другие опции определяющие целевую платформу (-mfpu, -mfloat-abi, -mcpu, может еще какие) Я понял, далеко не везде обязательно их указывать. А поконкретнее можно сказать когда недостаточно собирать для generic linux arm?
Или может просто, чтоб не думалось, изначально как можно больше прописывать уточняющих опций кросскомпилятору в makefile?

В зависимости от цели при разработке программы опции могут меняться. Например, U-Boot для BeagleBoard собирается с опциями, позволяющими запускать его на любой плате серии. Если же необходимо сжимать видео, то надо учитывать особенности конкретной аппаратной конфигурации и из железа выжимать максимальную производительность. Соответственно, необходима тонкая настройка на максимальную производительность.
berkl
Цитата(mdmitry @ Jan 6 2014, 21:40) *
В зависимости от цели при разработке программы опции могут меняться. Например, U-Boot для BeagleBoard собирается с опциями, позволяющими запускать его на любой плате серии. Если же необходимо сжимать видео, то надо учитывать особенности конкретной аппаратной конфигурации и из железа выжимать максимальную производительность. Соответственно, необходима тонкая настройка на максимальную производительность.


Ясно, понятно.

Пасибочки
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.