Пытаюсь собрать 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.

Если у Вас все работает, что мы тогда тут обсуждаем?

Если верить Вашему описанию выше, работает не все. В частности, Unaligned access exceptions в ядре возникать не должны. По крайней мере, мы в Emcraft Systems этого не наблюдаем ни на LPC1788, на на какой-либо из других Cortex-M3 / M4, которые мы поддерживаем.

Мы действительно добавили в ядро конфигурационную опцию, позволяющую отключать в ядре процессора генерацию Unaligned access exceptions, однако, назначение ее - заставить работать пользовательские приложения, которые по каким-то своим соображениям лезут в память по невыровненным адресам (код Qt/Embedded этим грешит, в частности). Использовать эту опция для того, чтобы обойти проблемы в ядре, я бы не стал; это лечение симптомов, а не проблемы. В лучшем случае, потеряете в производительности, в худшем - просто маскируете какую-то проблему.

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

- неверная конфигурация ядра. Если работает код, предназначенный для другой конфигурации или даже для другого процессора, ничего хорошего не получится.

- не та версия toolchain. Код Emcraft Systems работает с конкретной версией GNU Toolchain. Мы пробовали более поздние версии, с ними возникли проблемы. Естественно, их тоже можно заставить работать, но пока не дошли руки.

- какая-то несовместимость с U-boot от NXP (lpcware.com). На самом деле, у нас есть клиент (тоже LPC1788), который тоже взял порт U-boot от lpcware (ему была нужна поддержка NAND Flash, а мы это пока не поддерживаем в U-boot для LPC1788), и он тоже видит похожие проблемы.

Обсуждаем вроде как, почему странные вещи приходится писать, чтобы заработало. Я же emcraft не обвиняю - просто описываю, какие проблемы возникали и как я их решал.


- ядро однозначно то самое.
- тулчейн G++ Lite 2011.03.46 uclinux, 2011.03.41 linux gnueabi, 2011.03.42 arm none.
- вот несовместимость с u-boot - это внезапно. Я думал, что u-boot тупо копирует софт и отдаёт управление и дальше никак не влияет (ну где-то environment передаёт ещё)... Но ваш u-boot крайне странно себя вёл, когда я его пытался запустить. То есть как есть он работал нормально, но при любых попытках что-то подправить, всё валилось со странными симптомами. Как-то смахивало на порченую память, что и не удивительно для софта заточенного под работу из внешней озу.

Просто из любопытства, какой конфигурационный файл Вы используете для сборки ядра?



Emcraft Systems использует другую версию тулчейн. Я бы начал с того, чтобы перейти на эту версию, про которую известно, что с ней U-boot и Linux работают правильно.



Наш порт U-boot работает из внутренней памяти (код из embedded Flash, данные и стек - в eSRAM).

Приятно знать, что как есть он все же работал нормально.

ea-lpc1788_defconfig


Возможно из-за другой версии memcpy неверно обрабатывает невыровненный доступ к памяти...

В частности, падает с ошибкой невыровненного доступа вот на этом коде:


Если поменять на:

То в этом месте падать перестаёт.


Я имел в виду, что софт изначально был заточен под релокацию.


Точно не помню, в чём были проблемы, но, кажется, CONFIG_ALTMEMTEST вешал систему.

UPD: О чудо, сборка g++ lite 2010q1-189-arm-uclinuxeabi решила проблему с невыровненным доступом! Свежая версия g++ lite вероятно поломана. Насчёт того, какой u-boot использовать: стандартный или emcraft, надо будет поразмыслить как следует.

Привет!

Помоги пожалуйста :
Есть плата от starterkit с lpc1788 + sdram k4s561632N - не запускается UBOOT взятый с LPCware...
Пробовал сам компилировать - такая же беда.. Может просто консоль не работает...
В файле в исходнике есть еще строчка не понятная -
Файл mem.c
/* Enable clock for EMC */
lpc17_clk_enable(LPC17_CLK_ADC, 1);

Разве клок на EMC включается через регистр ADC ?

Я так понял проблема в SDRAM, точнее в настройках задержек?

Emcraftовский запускается, но тест sdram не проходит((

Как решить?