KPEKEP 0 20 апреля, 2015 Опубликовано 20 апреля, 2015 · Жалоба Была похожая проблема, когда записывал ядро в SPI-флешку, при этом я не заметил, что размер ядра был больше, чем раздел под ядро на флешке. В итоге, когда U-boot грузил ядро он мне выкидывал ошибку CRC при загрузке ядра и в выводе так же было "Starting kernel ..." и тишина. Могу посоветовать начать с U-boot'а - проверьте, полностью ли он грузит ядро или нет. А как это можно проверить? После этого "Starting kernel ..." в U-boot можно добраться только после перезагрузки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BaN 0 20 апреля, 2015 Опубликовано 20 апреля, 2015 · Жалоба А как это можно проверить? После этого "Starting kernel ..." в U-boot можно добраться только после перезагрузки В код u-boot'а добавить вывод отладочной информации в предполагаемых проблемных местах возле вывода "Starting kernel ...", пересобрать и залить на железку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 20 апреля, 2015 Опубликовано 20 апреля, 2015 · Жалоба В общем в итоге Starting kernel ... и тишина если выводит эту строчку, то ядро загрузилось в память и контрольная сумма (CRC) бинарника сошлась.. у вас вероятно срабатывает система "свой-чужой" от юбута до ядра. юбут при переходе на начало кода ядра передает некие параметры, в т.ч. mach type если код не совпадает, то ядро останавливает дальнейшую работу.. попробуйте проверить, включив выхлоп отладки в разделе Kernel Hacking->Low level debug.. самая частая причина - использован конфиг не от той борды.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KPEKEP 0 20 апреля, 2015 Опубликовано 20 апреля, 2015 · Жалоба если выводит эту строчку, то ядро загрузилось в память и контрольная сумма (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, ядро успешно собирается, вопрос в том, что ни в одной инструкции по сборке ядра не видел упоминания об этих файлах, это нормально что он их требует? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 21 апреля, 2015 Опубликовано 21 апреля, 2015 (изменено) · Жалоба -CONFIG_DEBUG_LL включил, по прежнему после Starting kernel ничего не показывает, либо ошибки нет, либо что то я не так сделал (делал через menuconfig -> Kernel Hacking -> Kernel debugging -> Kernel low-level debugging functions -> Early printk) в старых ядрах можно было применить "грязный хак" - в асмовом файле в районе arch/arm/kernel/head.$ блокировалась проверка на mach id, ядро грузилось не глядя ни на что и можно было понять происходящее. сейчас даже и не знаю, заглянул в 3.2.0 от ti, ничего похожего.. -Пробовал данный способ, по этому поводу U-boot выдаёт нечитабельную билеберду уверены? белиберда структуирована? может скорость порта меняется.. -Конфиги пробовал davinci_dm368_ipnc_nfs_defconfig и davinci_dm368_ipnc_ubifs_defconfig, ничего в них не менял а в менюконфиг проверяли? например, вы натянули конфиг для семейства dm368, а пункт с вашей бордой выключен - ядро работать не будет.. -Есть ещё вопросы, по поводу адреса в который записывается ядро по TFTP у меня качается в 80700000, а ядро пишет Load Address и Entry Point 80008000 это на что то влияет? это нормально -Как понять какой должен стоять console=ttyS в U-boot? С каждым ядром перебираю от 0 до 2, но хотелось бы точно знать что писать (версии с сайта TI, даташита и в документах производителя прошивки разнятся) не знаю, что там у семейства dm368, но помнится, что для dm8148 и am33xx имя портов начиналось с ttyO (тут могу подвирать, вечером дома посмотрю). номера вроде как задаются в боард файле (в старых ядрах) -Ещё вопрос: использовал и штатный кросскомпилятор от Arago Project и от CodeSourcery, при сборке ядра, они требуют некие файлы (cmemk.o, edmak.o, irqk.o, dm365mmap.o, drv.o, csl.o), в makefile из штатного RDK, подглядел откуда они берутся, после того, как копирую данные файлы в kernel/drivers/char, ядро успешно собирается, вопрос в том, что ни в одной инструкции по сборке ядра не видел упоминания об этих файлах, это нормально что он их требует? да, нормально.. раньше к платам можно было скачать полный пакет sdk, который включал в себя кросскомпилятор, исходники (лоадеров, юбута, ядра, утилит для dsp), комплект документации по сборке, скрипты. иногда отдельно шел графический sdk для поддержки графики и видео итого: 1. поискать, как обойти проверку типа борды 2. проверить типы включенных плат в менюконфиге 3. там же поотключать все в разделе драйверов - оставить только работу с консолью и поддержку портов update да, дома посмотрел, вот начало строки для ядра dm8148: bootargs_mmc=console=ttyO0,115200n8 rootwait root=/dev/mmcblk0p2 Изменено 21 апреля, 2015 пользователем Jury093 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KPEKEP 0 27 апреля, 2015 Опубликовано 27 апреля, 2015 · Жалоба в старых ядрах можно было применить "грязный хак" - в асмовом файле в районе arch/arm/kernel/head.$ блокировалась проверка на mach id, ядро грузилось не глядя ни на что и можно было понять происходящее. сейчас даже и не знаю, заглянул в 3.2.0 от ti, ничего похожего.. У меня ядро 2.6.37, тройку в названии я сам поставил в makefile, чтобы отличать, что грузится моё ядро Файл arch/arm/kernel/head.$ есть, можно пожалуйста про это по подробнее? Где вообще править этот mach id? уверены? белиберда структуирована? может скорость порта меняется.. скорость порта стоит 115200n8, или она как то ещё может менятся? а в менюконфиг проверяли? например, вы натянули конфиг для семейства dm368, а пункт с вашей бордой выключен - ядро работать не будет.. Вроде конфиг для dm368 подразумевает, что выбран пункт dm368? Посмотрел в System type -> TI DaVinci Implementations -> там вижу ***DaVinci core type*** -> DaVinci 365 based system; ***DaVinci Board Type*** -> TI DM368 IPNC раньше к платам можно было скачать полный пакет sdk, который включал в себя кросскомпилятор, исходники (лоадеров, юбута, ядра, утилит для dsp), комплект документации по сборке, скрипты. иногда отдельно шел графический sdk для поддержки графики и видео У меня есть штатный SDK, только называется RDK (Reference Design Kit, так и не понял как переводится), там лежат кросскомпилятор штатный от Arago Project, файловая система, документация, схематика и прочее, только с ней я бьюсь уже несколько месяцев, т.к. описания порой не совпадают с действительностью Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 15 июня, 2015 Опубликовано 15 июня, 2015 · Жалоба У меня ядро 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 В конфигурации бут лоадера должен быть выбран именно он и хедер файл с его определением должен быть в правильном месте бут лоадера -- иначе не скомпилируется. Будут вопросы -- спрашивайте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KPEKEP 0 10 июля, 2015 Опубликовано 10 июля, 2015 · Жалоба В общем с ядром и файловой системой всё было в порядке, так же подсунул ядро и ФС через TFTP, после чего записал в нанд и всё запустилось, без записи в нанд почему то не работало, это нормально? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MIKS 0 28 июля, 2015 Опубликовано 28 июля, 2015 · Жалоба В общем с ядром и файловой системой всё было в порядке, так же подсунул ядро и ФС через TFTP, после чего записал в нанд и всё запустилось, без записи в нанд почему то не работало, это нормально? Если у вас UBIFS и писали с помощью mtd утилит то не затруднит выложить последовательность записи NAND начиная со стирания? В системе сборки rootfs как-то указывали характеристики конкретной NAND типа PEB LEB? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
