Добрый день!

С линуксом почти не сталкивались, по ДСП работаем.
Есть своя плата: ОМАP-L138, NAND 4Gb Samsung K9F4G08U0D-SIB0000, DDR2 1Gb Samsung K4T1G164QF-BIE6T00, Ethernet, SATA, USB2.0 OTG, видеопорт, и др. периферия...
Хотим собрать своё ядро. При собственой конфигурации виснет после надписи "Starting kernel ..."
Может кто подсказать в чем дело?
Файл конфигурации прилагаю.


Благодарю.

Почему не взяли, например, OMAPL138 DVSDK от техаса?

Выложите лучше строку аргументов ядра.

Подозреваю что дело в файле борды. Файл борды правили?

Спасибо за ответы.
У нас есть отладочная плата Logic PD на базе OMAPL138.
На этой отладочной плате пересобирали все компоненты - все работает.
Но на ней загрузка из SPI flash, память mDDR, поэтому использовать файлы прошивки те же не получается.
Приходится пересобирать под нашу плату свои u-boot (с оберткой от AISGEN), uImage, Файловую систему.
Файл борды не правил, он остался неизменным - board-da850-evm.c.
Базовый конфигурационный файлом является da850_omapl138_defconfig.
В нем добавили поддержку NAND, отключили поддержку SD/MMC.
Аргументы bootargs
bootargs=console=ttyS2,115200n8 rootfstype=ubifs root=ubi0:rootfs ubi.mtd=ubi rw mem=128M
В данном случае загрузка идет через USB. Также пробовали через TFTP - результат тот же.
Нашли информацию о том, что с того момента как выводится надпись
"Starting kernel ..."
может быть неправильно настроен вывод в консоль (не тот ttySx).
http://processors.wiki.ti.com/index.php/FA...r_DaVinci_Linux
Проверили, убедились что настройки в исходниках ядра те (что для u-boot, что для uImage UART2).

Потом нашли документ
http://processors.wiki.ti.com/index.php/Ke...s_Booting_Linux
Буду проверять сегодня совпадение ID для u-boot и для uImage.

Возможно кто то проконсультирует или подготовит свои u-boot (до и после AISGEN) uImage и файловую систему с нашей конфигурацией (готов оплатить).
Хотя бы начать с минимальной конфигурацией - NAND 8bit, DDR2, USB, а дальше будем сами разбираться.

Попробуйте добавить к строке ядра еще "debug earlyprintk".
Еще, не так давно, omap переехал на нормальные названия tty. Попробуйте console=/dev/ttyO2... и далее по тексту. Хотя, если версия ядра не менялась - не имеет смысла.

Всем спасибо.
Скорее всего проблемы с ядром, оно попорчено. Есть желание пересобрать но последним SDK. Хотел бы спросить, каким образом сконфигурировать u-boot на 8 бит. В DA850 флэшь стоит 16 бит. Возможно с этим у нас также проблемы, поскольку не сохраняет настроечные переменные через saveenv. В AISGEN конечно указан размер 8 бит, но после загрузки u-boot он записывает данные скорее всего в 16-ти битном режиме.

Жду подсказок.

Первым делом об этом подумал, но не оно. Эта проверка в бутлоадере производится. Там еше проверка чексуммы делается.
Но после этого кернел распаковывается и стартует. Вот в какой момент появляется надпись не помню. завтра на работе посмотрю. Вот из интернета:

> 3122350 bytes read
> ## Booting image at 00800000 ...
> Image Name: Linux-3.11.0-rc3
> Created: 2013-07-30 18:56:55 UTC
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3122286 Bytes = 3 MB
> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... OK
> OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0

для проверки содержимого настроек юбута, остановите его и дайте команду:

посмотрите - соответствует ли содержимое bootargs нужным значениям..

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

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

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

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

вот очень дельно предложение:

там вроде надо еще пощелкать пунктами в Kernel Hacking чтобы ядро стало более говорливое..

ставлю на две версии - Id или tty, в резерве nand

Debug earlyprintk попробовали сразу же после предложения так сделать.
Соответствующий флаг в menuconfig в Kernel Hackin выставили. Все то же самое.
Как раз поэтому и появилось предположение, что с ядром что то не так.
Сейчас я ставлю вопрос по другому. Решил все пересобрать с самого начала в последней версии, начиная с u-boot.
Собирал на базе SDK для LCDK. Но у LCDK NAND 16 бит, а у нас 8. Я закрыл в их коде установку 16-ти битного NAND.
После AISGEN u-boot запустился, но перестал сохранять переменные после команды saveenv. После загрузки пишет всегда BAD CRC.
Есть основания считать, что NAND по прежнему остался 16 битным. Пока глубоко не исследовал,
возможно есть простой способ установки NAND в 8 бит, а SDRAM в DDR2 (не mDDR).

Есть предположение насчет неработоспособности ядра uImage, заключающееся в том,
что SDRAM сконфигурировано как mDDR, а не как DDR2 (у нас именно DDR2).
Пока не ясно, память SDRAM конфигурируется в ядре uImage
или настройки памяти берутся возложены только на u-boot.
Возможно кто то подскажет что то на этот счет.

В большинстве случаев настраивается в u-boot. Во всяком случае какой-то минимум сообщений от ядра вы должны получить.

Есть "тупой" способ проверить. В у-буте загружаете ядро в память и запускаете его. Плата предположительно зависает. Даете ей ресет. И без повторной загрузки ядра в памяти делаете ему bootm. Или iminfo. Обычно, нсли с памятью все ок, ее содержимое сохраняется. Правда есть варант, что ядро при загрузке могло затереть эту облась после релокации.

Если консоль не сломалась

Даже со сломанной консолью вывод можно посмотреть вот таким вот изящным способом.

C u-boot разобрались. С uImage пока нет. Останавливается здесь:

netconsole: network logging started
davinci_emac davinci_emac.1: using random MAC addr: 76:f7:52:75:1e:d8
omap_rtc omap_rtc: setting system clock to 2000-01-13 23:12:09 UTC (947805129)
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Будем дальше копать.

У вас в командной строке что написано? Можете ее опубликовать?
Не может смонтировать рут файловую систему.
Либо диск недоступен, либо системы там нет, либо неправильно указана партишн в командной строке. На каком устройстве ваша рут файловая система?

У меня раз была такая ситуация.
На одних бордах монтировалось, а на других нет. Засада была в том, что перешли с СД карточки на тест борде на микро СД на продукте. У микро СД нет сенсора защиты от записи, а в кернеле такой пин и его обработка присутствовали. Монтировали как RW, а если состояние пина, который был в воздухе показывало, что СД карточка защищена, то возникала точно та же проблема что и у вас.


Раскопал у себя на этом процессоре есть борд LogicPD купил у TI.
Посмотрел конфигурацию бутлоадера, чтобы узнать какая командная строка:

У меня с СД карточки грузится поэтому mmcblk, у вас другое устройство и я не знаю какое и какое у него имя.

К вашей проблеме относится вот этот фрагмент:
root=/dev/mmcblk0p2 rw rootwait

mmcblk0p2 значит mmc диск драйв номер 0 партишн 2.
Вы должны определить какой у вас диск и какой партишн.
Для рут партишн на скази было бы что-то вдоде /dev/sdb1. sdb1 значит диск b партишн 1
Разбирайтесь. Все что нужно найти как в вашей системе называется ваш диск с рут файловой системой,
если устройство не одно, то какое оно по счету (смотреть схему и даташит процессора). На каком партишне находится ваша файловая система. Запишите это правильно в конфигурации бутлоадера и сохраните.
Должно заработать.


Вот вам пример моей конфигурации U-Boot:
U-Boot > printenv
bootargs=mem=32M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off
bootcmd=if mmc rescan 0; then if fatload mmc 0 0xc0600000 boot.scr; then source
0xc0600000; else fatload mmc 0 0xc0700000 uImage; bootm c0700000; fi; else sf pr
obe 0; sf read 0xc0700000 0x80000 0x220000; bootm 0xc0700000; fi
bootdelay=3
baudrate=115200
bootfile="uImage"
stdin=serial
stdout=serial
stderr=serial
ethaddr=00:08:ee:05:8d:71
ver=U-Boot 2009.11 (Jan 13 2011 - 01:05:37)

Environment size: 461/65532 bytes
U-Boot >

Судя по ругани на ubi0:rootfs, рутовый раздел на нанд. А т.к. они сменили 16 битную нанд на 8 битну, то и в ядре надо править.

И не издевайтесь над нами, тут нет телепатов - выложите весь лог загрузки от старта у-бута и до остановки.

временно сгенерите рутовую на sd или usb-flash и загрузитесь нее..
так комфортнее разбираться с нандом..

Ещё раз спасибо за подсказки. Выложим всё что надо сегодня вечером или завтра.
У нас НАНД-8.

Благодарю.

И конфигурацию U-Boot.

Ответьте на вопросы:
1. Вы давали имя борду сами? Если не понимаете о чем речь -- значит нет. http://electronix.ru/forum/index.php?showtopic=118559
2. Найдите файл борда и сообщите его имя.
Процедура простая:
а. Постройте кернел
б. В директории arch/arm/mach-omap2/ найдите все файлы *.о и дайте их имена. Мы разберемся.

Выкладываю что нужно для разъяснения ситуации(в архиве).
Ждем ваших советов. Если ещё что нужно - скинем.

Благодарю.

Я не совсем ту конфигурацию имел ввиду. Покажите, что печатает u-boot по команде printenv.

Для удобства файл борда прицепим так:
http://lxr.free-electrons.com/source/arch/...ard-da850-evm.c

Да, вот ещё лог, забыли в архив включить. Здесь полный лог старта u-boot, вывод данных через printenv и процесс загрузки uImage до момента остановки.

В Вашем .config

Т.е. драйвер не включен.

Включали, такая же ерунда. Сейчас приложим конфиг и лог.

запись uImage и файловой системы происходит через tftp. Эти файлы сохраняются на NAND и оттуда уже стартуют.

//Установка переменных в u-boot

nand erase 0 0x20000
setenv hostname Politeh
setenv ethaddr 00:24:37:26:15:05
setenv ipaddr 192.168.0.111
setenv serverip 192.168.0.103
setenv gatewayip 192.168.0.1
setenv netmask 255.255.255.0
setenv bootargs console=ttyS2,115200 ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname} rootfstype=jffs2 root=mtd:filesystem rw,noatime mem=128M
setenv bootcmd 'nand read.e 0xc0700000 0xa0000 0x300000; bootm 0xc0700000'
saveenv


//Запись uImage
nand erase 0xa0000 0x300000
tftp 0xc0700000 uImage
nand write.e 0xc0700000 0xa0000 ${filesize}

//Запись файловой системы
mw.b 0xc0700000 0xFF 0xE00000
tftp 0xc0700000 rootfs.jffs2
nand erase 0xB60000 0xE00000
nand write.e 0xc0700000 0xB60000 0xE00000

после этого даем перезагрузку. Конфиг и лог прикрепил.

я полагаю, что причина тут (из лога):


если заглянуть в файл борды (приведен выше), то там есть структура:



и после нахождения этих устройств идет цепочка вызовов. включая:

где происходит инит пинов NOR/NAND, заполнение структур и регистрация драйвера NOR/NAND

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

еще раз повторюсь - для отладки удобнее использовать любой доступный накопитель - sd, usb, sata..
и получив приглашение "login" отдебажить "кто виноват и что делать"
в конце концов - нет желания возится с накопителем, при живой сети можно забодяжить NFS и рутовую держать на сетевом ресурсе..

Пожалуй наилучшее решение. Добавлю еще одну возможность rootfs на NFS.

Приветствую, т.к. Ваша топик очень подходит к моей ситуации, опишу здесь и вместе с вами буду искать ответ.
В моём расположении IP камера DM369IPMC-IMX104, на процессоре TI Davinci DM369, суть всё та же, собираю своё ядро и файловую систему, но в моём случае есть готовый RDK с описаними, описания очень скудные, т.к. следуя только им, с места не сдвинуться.

Собрал своё ядро и файловую систему, меняю заводской bootcmd и bootargs (взял из описания к камере), подсовываю всё через TFTP
Лог загрузки:

Нажмите для просмотра прикрепленного файла

Версию ядра поменял в Makefile на 3.6.37, чтобы можно было отличать грузит он своё или моё ядро
В общем в итоге Starting kernel ... и тишина
Поделитесь пожалуйста, как лечили?

Товарищи, спасайте, так и сижу на этом Starting Kernel ... уже ядро несколько раз пересобирал с разными кросскомпиляторами, суть та же на выходе
Скажите какие файлы выложить чтобы легче было идентифицировать проблему?

Была похожая проблема, когда записывал ядро в SPI-флешку, при этом я не заметил, что размер ядра был больше, чем раздел под ядро на флешке. В итоге, когда U-boot грузил ядро он мне выкидывал ошибку CRC при загрузке ядра и в выводе так же было "Starting kernel ..." и тишина.
Могу посоветовать начать с U-boot'а - проверьте, полностью ли он грузит ядро или нет.

А как это можно проверить? После этого "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:

У меня ядро 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?