А как это можно проверить? После этого "Starting kernel ..." в U-boot можно добраться только после перезагрузки

В код u-boot'а добавить вывод отладочной информации в предполагаемых проблемных местах возле вывода "Starting kernel ...", пересобрать и залить на железку.

если выводит эту строчку, то ядро загрузилось в память и контрольная сумма (CRC) бинарника сошлась..

у вас вероятно срабатывает система "свой-чужой" от юбута до ядра.
юбут при переходе на начало кода ядра передает некие параметры, в т.ч. mach type
если код не совпадает, то ядро останавливает дальнейшую работу..
попробуйте проверить, включив выхлоп отладки в разделе Kernel Hacking->Low level debug..

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

-CONFIG_DEBUG_LL включил, по прежнему после Starting kernel ничего не показывает, либо ошибки нет, либо что то я не так сделал (делал через menuconfig -> Kernel Hacking -> Kernel debugging -> Kernel low-level debugging functions -> Early printk)
-Пробовал данный способ, по этому поводу U-boot выдаёт нечитабельную билеберду
-Конфиги пробовал davinci_dm368_ipnc_nfs_defconfig и davinci_dm368_ipnc_ubifs_defconfig, ничего в них не менял
-Есть ещё вопросы, по поводу адреса в который записывается ядро по TFTP у меня качается в 80700000, а ядро пишет Load Address и Entry Point 80008000 это на что то влияет?
-Как понять какой должен стоять console=ttyS в U-boot? С каждым ядром перебираю от 0 до 2, но хотелось бы точно знать что писать (версии с сайта TI, даташита и в документах производителя прошивки разнятся)
-Ещё вопрос: использовал и штатный кросскомпилятор от Arago Project и от CodeSourcery, при сборке ядра, они требуют некие файлы (cmemk.o, edmak.o, irqk.o, dm365mmap.o, drv.o, csl.o), в makefile из штатного RDK, подглядел откуда они берутся, после того, как копирую данные файлы в kernel/drivers/char, ядро успешно собирается, вопрос в том, что ни в одной инструкции по сборке ядра не видел упоминания об этих файлах, это нормально что он их требует?

в старых ядрах можно было применить "грязный хак" - в асмовом файле в районе arch/arm/kernel/head.$ блокировалась проверка на mach id, ядро грузилось не глядя ни на что и можно было понять происходящее. сейчас даже и не знаю, заглянул в 3.2.0 от ti, ничего похожего..


уверены? белиберда структуирована? может скорость порта меняется..


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


это нормально


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


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

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

update
да, дома посмотрел, вот начало строки для ядра dm8148:


Сообщение отредактировал Jury093 - Apr 21 2015, 19:07

У меня ядро 2.6.37, тройку в названии я сам поставил в makefile, чтобы отличать, что грузится моё ядро
Файл arch/arm/kernel/head.$ есть, можно пожалуйста про это по подробнее? Где вообще править этот mach id?



скорость порта стоит 115200n8, или она как то ещё может менятся?



Вроде конфиг для dm368 подразумевает, что выбран пункт dm368? Посмотрел в System type -> TI DaVinci Implementations -> там вижу ***DaVinci core type*** -> DaVinci 365 based system; ***DaVinci Board Type*** -> TI DM368 IPNC



У меня есть штатный SDK, только называется RDK (Reference Design Kit, так и не понял как переводится), там лежат кросскомпилятор штатный от Arago Project, файловая система, документация, схематика и прочее, только с ней я бьюсь уже несколько месяцев, т.к. описания порой не совпадают с действительностью

Как посмотреть какой номер у вашей борды:
http://electronix.ru/forum/index.php?showtopic=118559

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

Будут вопросы -- спрашивайте.

В общем с ядром и файловой системой всё было в порядке, так же подсунул ядро и ФС через TFTP, после чего записал в нанд и всё запустилось, без записи в нанд почему то не работало, это нормально?

Если у вас UBIFS и писали с помощью mtd утилит то не затруднит выложить последовательность записи NAND начиная со стирания?
В системе сборки rootfs как-то указывали характеристики конкретной NAND типа PEB LEB?