Пытаюсь поднять Linux, а для начала стартануть U-Boot, на плате от Стартеркита EV-iMX287-NANO. Скачал предложенный на сайте образ виртуальной машины, перетащил в свою VM всё содержимое SDK, в том числе и U-Boot 2014.01.
Ещё решил грузиться не с NAND, как предлагается по умолчанию, а с SD/MMC карты, для чего соответствующим образом перепаял резисторы, определяющие источник загрузки. Разметил нужным образом SD-карту, запустил скрипт config_mmc.sh, собрал U-Boot 2014.01 до уровня u-boot.sb, затем превратил его в u-boot.sd (mxsboot sd u-boot.sb u-boot.sd), и наконец, залил образ на SD-карту (dd if=./u-boot.sd of=/dev/sdc1 bs=512).
Плата стартует, начинается загрузка U-Boot, но в какой-то момент уходит в перезагрузку, и все начинается с начала. Вот лог:

Примечательно, что какой-то из скачанных мною бинарных образов U-Boot нормально прогружает плату, и доходит до своей командной строки.
Из чего следует вывод, что плата исправна.
Но хочется загрузить собственно-собранный U-Boot.
Куда копать?

Сообщение отредактировал gerber - Jun 23 2016, 17:16

вот тут обсуждают схожую ошибку
https://community.nxp.com/thread/306491
там то ли с памятью, то ли с питанием проблемы.. это семейство (imx28) достаточно капризно в настройках..

раз уж вы самостоятельно собираете, то попробуйте в файле конфигурации прописать
#define DEBUG
тогда юбут будет поразговорчиее при загрузке, может там что увидите полезного..

ЗЫ странно, что у вас комплект "из коробки" не собрал исправные бинарники, мелкие глючки бывали, но запускались всегда..
может в этом проблема:

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

После этого (#define DEBUG) u-boot вообще перестает собираться, не находит функции типа mxs_serial_putc() (или что-то в этом духе, завтра уточню, если нужно). Не помогает даже #define CONFIG_SPL_SERIAL_SUPPORT, как пишут на некоторых форумах.

Компилятор я тоже перетащил, благо, он лежит там же, в домашнем каталоге, а все пути к нему при сборке прописаны в сборочных скриптах. Ну, привык я к Debian-у, и другие дистрибутивы нервируют
Да и запустилась ихняя виртуалка у меня под VMware кривовато, рабочий стол искажен. При работе в Linux нервы и так на пределе, а тут ещё и это

Пересобраться попробую, хотя имеющийся там собранный образ u-boot.sb ведёт себя также. Правда, он собирался для загрузки с NAND, но как мне кажется, это должно касаться только места расположения переменных environments, и при их отсутствии u-boot должен загрузить их значениями "по умолчанию", и выйти в командную строку. В остальном, u-boot в моем понимании представляет собой линейный участок байтов, а откуда его загрузит ROM процессора, будет определяться BOOT-пинами, из NAND, с SD-карты или по USB - процессору должно быть фиолетово.
Я, конечно, понимаю, что загрузка идёт двухступенчатая - сначала SPL, он инитит DDR-память, потом в DDR грузится основной u-boot. Но у меня-то эти ступени проходят - я же вижу приветствие, I2C, DRAM ... следущей строкой должна быть NAND ... но перезагрузка.

Есть у меня такое ощущение, что у u-boot'а почему-то оказывается хвост отрезан.

врядли, если это вариант монолитного юбута, то он бы молча вис.. если ребут по вачдогу, то что-нить бы писал по таймауту..
если цепочка прелоадер, а потом юбут, то прелоадер обычно смотрит CRC бинарника юбута и выводит диагностику при неудаче..
мне кажется надо смотреть ветку где выводится "HTLLCLLC" - это явно статусная диагностика..
это семейство (imx28) с поддержкой батарейного (аккумуляторного) питания и чувствительны к уровняи напряжения на определенных контактах (как пишут на форумах, есть "версии для 5в"), а значит есть и другие варианты..

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


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


угу, я тоже исторически предпочитаю Дебьян и так же стараюсь мигрировать SDK под этот дистрибутив..
но тут есть проблема - для простых процов это легко, а вот для медийных чаще всего требуется Ubuntu, а в последние годы еще и x86-64. Особенно для сборки Одроедов..
у меня почти десяток плат от SK, но таких проблем нет.. к киту на imx287 я присматривался, но посчитал его неинтересным..


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

на форуме starterkit.ru смотрели, ничего полезного нет?
http://starterkit.ru/html/index.php?name=s...view&id=124
в мане на железку?
http://starterkit.ru/html/doc/user_manual_...NANO_Rev1.0.pdf
на сайте поддержки и его форуме?
http://otladka.com.ua/index.php?page=shop....t&Itemid=71

если это не заводской брак или дефект платы, то все должно работать. более вероятно, что вы где-то что-то недоглядели..

Это выхлоп bootlets, он выводится еще до старта u-boot.

попробуйте исходники юбута посвежее..
из ссылки приведенной выше: глючный юбут

а вот этот запустился:

а это ваш:

Несколько лет назад я работал с iMX53. Фрискейл предлагали LTIB, который скачивал правильный uboot, kernel, патчил все, потом строил файловуыу систему. Исходники оставались на рабочем компьютере. Поищите на вашей виртуальной машине может есть что-то подобное. Если старое, то LTIB если новое, то Yocto.
Постройте систему по инструкции (LTIB или YOCTO), а потом оттуда и возьмите исходники.

Методом расстановки отладочных печатей локализовано место, где падает u-boot. Там есть участок кода, где u-boot (уже после перемещения в самый топ DDR2-памяти) выделяет участок в DDR2 порядка 4 Мбайт для динамического выделения malloc(), и зануляет его с помощью memset(...). То есть, если поставить бесконечный цикл while(1); до зануления - не падает, если после него - падает.
Если же просто закомментировать memset(...) - прогружается и доходит до командной строки, попутно поднимая всю заявленную в конфиге периферию. Правда, не всегда, каждый раз по-разному и иногда как-то кривовато
Из всего этого делаю вывод, что есть-таки аппаратная проблема с DDR2, какой-нибудь непропай адресной линии, из-за которой происходит перекрытие участков, и обычный memset(...) зануляет не то, что нужно, а рабочий код или стек, и всё падает.
Также на это указывает тот факт, что скачанная виртуалка прошлой версии с u-boot 2013, собранный там u-boot ведёт себя точно также и падает на том же месте.
Уменьшение частоты DDR2 в 2 раза проблему не изменило, так что всё-таки непропай.

Интересно, что я тоже несколько лет назад довольно много работал с iMX51, и весь путь через LTIB мне хорошо известен. Но насколько я помню, LTIB сам скачивал только пакеты (packages), а u-boot, kernel с необходимыми патчами всё же предлагался Freescale как приложение к отладочной плате.
Меня всегда напрягало в той истории, что LTIB - это очень жестко очерченый путь сборки системы в целом, в том наборе, который предоставлен. А чтобы собрать стороннее приложение, поставляемое в исходниках+configure+make, приходилось очень долго затаскивать его в идеологию LTIB, писать какие-то файлы-оболочки наподобие скриптов и т. п.

Сообщение отредактировал gerber - Jun 25 2016, 09:48

Значит у вас происходит исключение (exception) записи по неразрешенному адресу. Скорее всего несоответствие настройки MMU области памяти, которую инициализируете при помощи memset. Как припаяно скорее всего пофиг. Ведь вы не пользуетесь содержимым памяти. Падает до того. Хотя я не знаю если может придумали способ обнаруживать это и вызывать исключение. Но не думаю.
Поставьте отладочную печать в обработчики exception. Замените memset циклом и в обработчике напечатаете какая операция записи в какой адрес вызывает исключение. Заодно и какое исключение узнаем. Может у вас неправильный указатель на область памяти, которую инициализируете? Попробуйте записать число в первый адрес этой области.

Я не предлагал пользоваться LTIB, а лишь скачать бутлоадер, а потом модифицировать рабтающий код как вам надо.