Пытаюсь собрать u-boot, но постоянно натыкаюсь на различные трудности. Нужна помощь по следующим вопросам:

1. В start.S есть такая запись



Зачем тут прибавляется 1 к каждому адресу?
Если оставить как есть, то при запуске сразу сваливается в usagefault_handler, насколько я понимаю.

2. u-boot всегда пытается переместить себя во внешнюю ОЗУ при запуске? Он не умеет работать без релокации с использованием раздельной RAM и ROM?

1. Я бы понял это так, что в каждой строке вписывается смещение на адрес обработчика относительно метки _start, а единичку прибавляют потому что метка написана выше первой строки.
2. Копирование в ОЗУ настраивается. Ю-бут может исполняться напрямую из NOR-Flash, тогда копирование не нужно. В общем, есть там дефайн на это дело.

Если б почитали документацию на архитектуру ARM, а не пытались бы учиться по готовым примерам, то знали б, что младший разряд адреса подпрограммы указывает систему команд -- 0 для ARM и 1 для Thumb/Thumb-2. Поскольку LPC1788 имеет ядро Cortex-M3, у него реализована только система команд Thumb-2, а посему и нужно указывать единичку в младшем разряде.

Погуглил на тему релокации u-boot. Всё-таки он не умеет работать из флэш...

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

Флешь флеши рознь. Из nand флеша не работает потому что технология NAND этого не позволяет, а из NOR прекрасно себе работает. Поищите по Вашим исходникам CONFIG_SKIP_RELOCATE_UBOOT и добавьте такий define в файл конфигурации Вашей платы.
Линукс не всю периферию инициализирует, кое-что настраивается только в u-boot, например частоту работы проца можно установить в u-boot и Линукс ничего не будет менять (это как пример). И конечно можно написать свой загрузчик, если существующие U-Boot, Red Boot, не устраивают.

Спасибо, не знал. Век живи - Век учись.

Я искал CONFIG_SKIP_RELOCATE_UBOOT и гуглил про него. По поиску показывает только в двух местах определение и никак не влияет на реализацию. В инете пишут, что это устаревший параметр и реально он разрешал не запускать релокацию только если u-boot уже находится в ОЗУ.
Насчёт своего загрузчика, пожалуй, пока всё-таки не актуально - всё-таки сумел заставить u-boot выдавать в терминал отладочную информацию - теперь проще будет.

Возможно, это просто не реализованно в конкретной архитектуре.

Ещё подниму тему.

В конфигурации u-boot под lpc1788 установлено значение CONFIG_SYS_TEXT_BASE = 0xA1F80000. Как это может работать, если стартовать u-boot должен для начала из флэша, а этот адрес в sdram?

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

Обновлю тему для потомков.

Итак, emcraft выложил исходники их u-boot и linux на гитхаб. Их u-boot как раз не требует наличия внешней озу для запуска и не релоцируется во внешнюю озу. В то же время, работает с какими-то странными глюками и так толком у меня и не поехал. Зато удалось запустить исходный u-boot с сайта lpcware (в виде патча поверх оригинального). Так что потомками впредь рекомендуется для ненапряжного запуска u-boot сперва портировать тот или иной тест памяти на свой процессор, проверить память на отсутствие косяков (да, у меня была изначально ошибка на плате), перетащить настройки памяти в u-boot и тогда, скорее всего, релокация выполнится успешно.

Далее, по линуксу. Емкрафтовский линукс содержит несколько косяков, с которыми неизвестно как вообще они могут компилироваться. В частности, в файле head.S некорректная инструкция для thumb2 mode - невозможно создать сжатый образ ядра. В конфигурации нужно разрешить невыровненный доступ, иначе софт валится на генерировании псевдослучайных чисел.

Остались нерешённые вопросы:
1. Не работает вывод отладочной информации в консоль. Ничего не видно, если не вставить в printk код printascii. Кто-нибудь знает как пофиксить?
2. Не видит initramfs. Есть где-то пример создания initramfs и конфига под него? Если не использовать initramfs, то что вместо него?

Возможно, это потому, что uClinux использует head-nommu.S, а не head.S?

"Возможно, это потому, что uClinux использует head-nommu.S, а не head.S?"
Не знаю, у меня он пытается линковаться с head.S. В сборках типа linaro этот баг исправлен.

Ну и заодно отвечу на свои же предыдущие вопросы.

1. Не работает вывод отладочной информации в консоль. Ничего не видно, если не вставить в printk код printascii. Кто-нибудь знает как пофиксить?
Ответ: добавить к bootargs значение earlyprintk
2. Не видит initramfs. Есть где-то пример создания initramfs и конфига под него? Если не использовать initramfs, то что вместо него?
Ответ: нужно скомпилировать busybox в формате bflt (для проверки формата файла выполнить команду file). В файлик initramfs-list-min напихать символических ссылок на busybox как на утилиты линукс, а также накидать там структуру файловой системы. После этого всё заведется.

Теперь новые вопросы:
Я так понимаю, что пихать в initramfs всё подряд не принято. Нужно делать отдельно образ rootfs. Как это делается и как из инициализации перескочить в rootfs?

Добрый день, а почему бы не передать ядрышку загрузочную строку, который прикажет RootFS сразу грузить с накопителя?
Например, так

У меня на большом линуксе под ARM9 работало)
Может быть Вы знаете, но на всякий случай: в ядре включите поддержку файловой накопителя. У меня, к примеру, была ext3...
Сори, если чего-то не понял, и ляпнул прописную истину....

Спасибо, попробую. Я просто осваиваю эту тему постепенно и нужно постоянно видеть какой-то результат. Для загрузки с накопителя нужен во-первых сам накопитель (пока не запаян на плате ), во-вторых собрать u-boot с его поддержкой, в-третьих вроде как надо его разметить с нужной файловой системой (тут вообще хз как), собрать образ файловой системы (тоже незнакомая область. может сборка busybox подойдет). В общем вот-вот начну этим заниматься, но пошаговой инструкции не наблюдаю - только buildroot, в котором нет поддержки кортексов м3.

++++++++++++++++++++++++++++
"Возможно, это потому, что uClinux использует head-nommu.S, а не head.S?"
Не знаю, у меня он пытается линковаться с head.S. В сборках типа linaro этот баг исправлен.
++++++++++++++++++++++++++++

Это означает, что Вы строите ядро для другого процессора, не Cortex-M3. Так, конечно, можно долго "косяки и глюки" в коде Emcraft находить.

Глупости пишете. Как он у меня работает, если я строю ядро под другой процессор?
А файл head.S есть в разных директориях. Я говорю о том, который в каталоге /arch/arm/boot/compressed. И там нет никаких head-nommu.