Добрый день.

Сделали плату на процессоре TI am3359zcz. Основный компоненты (memory, nand, power managent) как у фирменного Evaluation Module.
Не установили I2C EEPROM, содержащую конфигурационную информацию платы. Взяли исходники u-boot 2011.09 из SDK, убрали чтение этой EEPROM, на всякий случай присвоив соответствующей идентификационной структуре все значения, которые должны считываться в случае платы am335x EVM.

Получившиеся после сборки MLO (spl) и u-boot.img образы прекрасно грузятся на beaglebone, наличие каких-то конфигов под nand, видимо, его не волнуют.
В случае собственной борды SPL загружается внутренней прошивкой проца, выполняется, но неверно.
При загрузке с MMC0 симптомы у spl проявляются в виде ругани на файловую систему FAT самой карточки.
При загрузке по UART spl пишет в терминал CCC.., но образ u-boot по ymodem отправить не получается.

Портировал ли кто-нибудь с u-boot вообще, или конкретно работал с этим процессором?
Есть ли идеи на счет того, что было сделано неправильно?
Спасибо.

я возился с китом am3359-iceboard..
взял с их сайта ближайший по идеологии BSP и путем пилежки и заточки успешно запустил линукс, к сожалению этот кит (ice) проектировался под другие задачи и поднять сетевые интерфейсы не удалось.. и дальнейшие исследования были свернуты..
финальная цепочка по загрузке - через xmodem грузил MLO, который через ymodem тянул u-boot, который интил sd-карточку, с которой грузил ядро и содержал рутовую..
iceboard был слегка подпилен аппаратно.. у техасовцев есть тред с ребятами, которые стартовые бинарники сложили в spi-flash и грузятся с него..


это к телепатам..

С этим-то всё ясно. Путем отладки u-boot'а вроде бы выяснили, проблемы при записи в sdram.
Например функция int omap_mmc_init() из файла omap_hsmmc.c содержит такую строку:
sprintf(mmc->name, "OMAP SD/MMC");
После этого проверка вышеупомянутой в контексте функции sprintf() стуктуры, находящейся по адресу 0x80000500 не дает ожидаемого результата. Вместо нормальной строки там появляется мусор. Продолжаю разбираться.

Как не удалось? ICE - это же сетевой девайс.

ну в первом приближение да, похож.. 2х100Мбит хидеры, двупортовый АРМ.. да вот соединение Phy и АРМа зело неудачно, с т.з. ядра.. или я сильно криворук..

речь о такой плате (та что есть у меня):

Прочитал Ваш тред на e2e. Да, похоже, ICE вещь действительно малопригодная, а я всё думал, почему на него сорцов в am335x-evm.c нет.

не очень уловил. юбут таки стартует или нет?
если стартует, то у него есть встроенный тест памяти - надо "на совесть" погонять оперативку
если юбут не стартует, то возможно битая/неправильно_подключенная память или тайминги неправильные в загрузчике 0-го уровня..

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

Главный u-boot не стартует - первый лоадер, который должен грузить основную часть, виснет при копировании образа u-boot из SD/MMC в SDRAM, а так же при получении u-boot.bin по UART.
Написал небольшой код, который выполняется во внутренней RAM, гружу из него во внешнюю память (0х80000000 и выше) несколько ассемблерных команд и передаю им управление - это выполняется.
Компилятор нормальный, если тот же загрузчик спокойно работает на BeagleBone.

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

Сделал тест, только на Си. Ошибок не обнаружено.
Могут ли быть какие-то другие аппаратные причины, например флешка? Конфигурация pinmux влияет только на периферийные интерфейсы, но не может ли быть тут какой-то связи?

По иронии судьбы так вышло, что статикой повредил рабочий девайс - beaglebone. У него появились проблемы с SDRAM, которые этот тест находит.

легко и запросто - от ошибок чтения из-за питания до ошибок при обмене между флешкой и АРМом.. еще неплохо для мажоритарности попробовать сменить флешечку..
поэтому я и посоветовал вывести на консоль то, что читает SPL - хоть пару байт..
можно для подстраховки потыкать осциллом по пинам MMC кроватки в момент обмена - мало ли питание грязное или контакт не припаян..


ого! как удалось столько статики набрать для запаянной платы?

Доброго здоровья!
Существует ли способ залить U-Boot в чистую NAND, используя UART и не имея SD карты? Процессор AM3354 в составе VAR-SOM-AM33.
По глупости душевной через U-Boot стер NAND, сижу оплакиваю труп.
Каким образом первоначально в NAND заливается U-boot?

выставляете режим загрузки через УАРТ и подпихиваете бинарники через xmodem - сначала MLO, потом U-BOOT, потом из юбута размечаете НАНД и по сетке подтягиваете ядро и рутовую, которые заливаете в НАНД..

Благодарю! Используя утилиту TeraTerm удалось залить SPL и U-boot. Однако возникла проблема, не определяется NAND:

Причем U-boot собирал из LSP packages, предоставленного фирмой изготовителя модуля, строго по инструкции и для обозначенной целевой платформы.
На http://e2e.ti.com нашел аналогичную проблему, по видимому, проблемам в PIN mux. Другими словами, на ножки процессора, ответственные за работу с NAND назначены по умолчанию другие (альтернативные) функции. А вот где в исходника U-boot настраивается PIN mux я найти не могу. Нужна помощь.

поздравляю, половина дела сделана..
в теории может нанд погореть - всякое бывает.. будем надеятся на лучшее..
посмотрите в
include/configs/конфиг-платы
прописан ли там нанд, мало ли..
мукс пинов вроде вот тут лежит
board/ti/am335x/mux.c
смотрите логику дефайнов и инита нужных веток подсистем АРМа

исходников для som-var у меня нет, смотрю в юбутские 2012 от BeagleBone - поэтому могу где-то заблуждаться..

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

Спасибо за ответ!
Проверил мукс ножек, ошибок не нашел.
Вычитал файл конфигурации \include\configs\var_am335x.h, сравнил с am335x_evm.h, принципиальных различий в конкурировании NAND не нашел.
Сам чип NAND скорее жив, чем мертв. Взял другую плату с предустановленным U-boot, если грузится с NAND, то NAND определяется (логично), если загружаю свой U-boot через UART, то "No NAND device found!!!".
Вопрос остается открытым. Как получить рабочий U-boot?

Еще помогите разобраться, в чем отличие файла MLO(36477байт) от u-boot-spl.bin (35927 байт). Спрашиваю, потому как в SDK от Variscite лежит помимо u-boot-var-som-am33.img еще файл MLO-var-som-am33. Через UART MLO запустить не удается. При компиляции U-boot получается и файл MLO, и файл u-boot-spl.bin.

P.S.: написал в техподдержку Variscite, жду ответа.

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


имхо, вы что-то не то берете.. у меня в архиве от ice-board лежать бинарники u-boot-spl.bin (~33kB) и u-boot.bin (~180kB)..
на BB содержимое раздела загрузки выглядит вот так:

идеология следующая: в АРМе есть встроенная статическая память (примерно 32-64кбайта), туда встроенный нестираемый загрузчик считывает с носителя бинарный образ и отдает ему управление (для внешних носителей имя прописано жестко и навсегда - MLO), далее - этот маленький загрузчик интит PLL, контроллер SDRAM и остальную необходимую периферию, потом ищет на заданном носителе бинарник uboot-a, грузит в SDRAM и запускает.. далее юбут и тыпы..
отсюда вывод - смотрите что за бинарники у вас генерятся..

Спасибо за ответ!
Проблему удалось решить с помощью модуля MTAX-SOM-AM335x, вернее его поддержки.
В сопутствующих документах на это модуль нашлись:
1. MLO
2. u-boot.img
3. u-boot-spl.bin
4. uImage
5. ramdisk

В поставке от variscite файла u-boot-spl.bin не было.
При загрузке модуля подсунул ему u-boot-spl.bin, затем u-boot.img, загрузился U-boot и определился NAND. Следующим шагом загрузил MLO-var-som-am33, прошил в NAND, затем загрузил uImage-var-som-am33, прошил в NAND. После рестарта системы U-boot загрузилась с NAND и все определилось.
От тех поддержки variscite ответа я так и не получил.
Сложилось впечатление, что u-boot-spl.bin и MLO -- одна суть, но разные формы. u-boot-spl.bin -- исполняемый файл, а MLO -- образ, включающий исполняемый файл. Может быть наоборот.
Сейчас бодаюсь с зависающим при старте ядром, но это уже другая тема.

P.S.: получил ответ от техподдержки:

Буду думать.

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


зависание реальное или мнимое?
достаточно указать неправильный порт для дебага или MachId - и будет иллюзия зависания..
или валится в кору в процессе загрузки?