Cross Toolchain для вопросов сборки ARM U-Boot

Я пытаюсь создать свой собственный набор инструментов для Raspberry-Pi. Я знаю, что существует множество готовых цепочек инструментов. Эта работа носит образовательный характер. Я слежу за встроенным arm linux с нуля. И пока удалось построить gcc и uClib. Я строю для целевой arm-unknown-linux-eabi.

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

Часть о загрузчике для этой системы кажется неполной. Теперь я спрашиваю себя, как мне создать uboot для этой Системы с помощью набора инструментов arm-unknown-linux-eabi.

Нужно ли мне создавать цепочку инструментов, не зависящую от вызовов ядра Linux. Мое первое исследование привело меня к тому, что существует отдельный вид цепочки инструментов, зависящий от ОС (системные вызовы ядра Linux и т. Д.), И те, для которых не требуется ядро. Иногда называется набором инструментов «Bare-Metal» или «автономным» набором инструментов.

В некоторых источниках упоминается, что можно было бы создать U-Boot с помощью инструментария linux. Если это правда, почему и как это должно работать?

И если мне нужно создать вторую цепочку инструментов для «Bare Metal» Toolchain, где я могу найти информацию о разнице между этими двумя. Нужен ли мне еще один libstdc?


bootloader arm cross-compiling toolchain u-boot
person DavidRam    schedule 13.12.2012    source источник
comment
Вы могли попробовать сценарий Buildroot. Я считаю, что в сети есть один или два файла конфигурации для RPI.   -  person sawdust    schedule 14.12.2012

Ответы (2)


arrow_upward
2
arrow_downward

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

Загрузчик по определению является самодостаточным и не заботится о вашем выборе библиотеки времени выполнения C, потому что он не использует ее. Поэтому вопрос о системных вызовах здесь не идет.

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

person marko    schedule 13.12.2012

arrow_upward
1
arrow_downward

Практически всеми возможными способами нет никакой разницы между встроенной цепочкой инструментов и цепочкой инструментов Linux. Но есть одно исключение.

Этим исключением является __clear_cache - функция, которая может быть сгенерирована компилятором и в цепочке инструментов "Linux" включает системный вызов для синхронизации кешей инструкций и данных. (См. http://blogs.arm.com/software-enablement/141-caches-and-self-modifying-code/ для получения дополнительной информации об этом бите.)

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

person unixsmurf    schedule 15.12.2012