Перейти к содержанию
    

Пока попытки загрузить нормально ядро не увенчались успехом.

 

1)Включить "раннюю" отладку не получилось, так как с включённой опцией ранней отладки всё зависает на стадии Starting the kernel.... что говорит о том что неправильно назначен UART для вывода отладочных сообщений на раннем этапе. Где это настраивается я так и не нашёл(в конфиге таких опций нет)

 

2) из http://processors.wiki.ti.com/index.php/Ke...ng_Kernel....22

я понял что скорее всего у меня проблема несовпадения machine id ядра и u-boot

Вопросы:

- где в ядре задаётся machine id?

 

В файле борды есть строка

 

MACHINE_START(DAVINCI_DA850_EVM, "DaVinci DA850/OMAP-L138/AM18x EVM")

 

стало быть machine id задаётся макросом DAVINCI_DA850_EVM . так ли это?

 

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

 

P.S. чем больше углубляюсь в это , тем больше думаю: зачем выдуманы такие сложности?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

- где в ядре задаётся machine id?

Вы не поверите - как правило в файле борды:-)

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

Там все может быть сложнее завязано. Может, например вычислять по комбинации перемычек на выводах контроллера, и тому подобное...., Куча подводных камней.

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

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

P.S. чем больше углубляюсь в это , тем больше думаю: зачем выдуманы такие сложности?

Это не сложности. Это стиль программирования :)

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

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

Я вот чистым временем около недели потратил на освоение того, как примерно работает ALSA на уровне ядра, и еще далек от завершения поставленной задачи. Из документации, на скорую руку слепленой жалким подобием doxygen мало что понятно. :) Но из того, что всплыло становится ясно, что при хорошей документации у меня ушло бы максимум 1 день на решение задачи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо. Весьма познавательно.

я узнал что machine id задаётся в файле mach-types.h

 

а как вы блокируете функции борды?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо. Весьма познавательно.

я узнал что machine id задаётся в файле mach-types.h

 

а как вы блокируете функции борды?

 

Более подробно

http://electronix.ru/forum/index.php?showtopic=118559

Это релевантно для kernel 2.6 Оно вроде поменялось. Поскольку вам надо из версии 2.6 переделать на более позднюю, то с версией 2.6 разобраться будет полезно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Более подробно

http://electronix.ru/forum/index.php?showtopic=118559

Это релевантно для kernel 2.6 Оно вроде поменялось. Поскольку вам надо из версии 2.6 переделать на более позднюю, то с версией 2.6 разобраться будет полезно.

Спасибо, познавательно. Честно говоря я так и знал что нигде кроме как в mach-type.h и при вызове MACHINE_START этот id не упоминается.

У меня ситуация такая: u-boot собран для одной машины (с конкретным id), а ядро новое не содержало такого machine id. Я просто взял и поменял руками номер для борды в файле mach-types.h

не помогло.

 

1 )Вопрос:

 

имеем MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board"). Проверяется ли где то второй аргумент? или это только для вывода на экран?

 

2) в новых версиях ядер файл борды разделён на две части (board_xxx.c и board_xxx.dts). Вижу что не для всех aайлов board_xxx.c, которые в ядре по умолчанию, есть соответствующий board_xxx.dts что странно...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

буду пробовать свои задумки на старом ядре. Оставлю в покое 3ю версию, пока разберусь в этом тёмном ящике (ядро Linux), уже глядишь и 4 выйдет с новыми фичами... а задачи надо решать сегодня.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

буду пробовать свои задумки на старом ядре. Оставлю в покое 3ю версию, пока разберусь в этом тёмном ящике (ядро Linux), уже глядишь и 4 выйдет с новыми фичами... а задачи надо решать сегодня.

По опыту: Пока сам не напишешь пару драйверов на имеющееся в наличии рабочее ядро - о портировании новой версии ядра на свою борду думать рановато :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

дело начало продвигаться. Собрал ядро тем же компилятором что и u-boot, загрузка остановилась на

 

 

PHY 0:00 not found
ata1: STAT link down (SStatus 0 SControl 300)
net eth0: could not connect to phy 0:00
IP-Config: Failed to open eth0
IP-Config: device 'eth0' not found
VFS: cannot open root device "ubi0:rootfs" or unkown-block(0,0)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

 

не находит PHY

ясно что не может найти рутовую, вопрос: где задаётся расположение рутовой (можно подумать что в строке загрузки ядра, но в старой версии ядра в строке указывалась только консоль, а рутовая грузилась с nand, значит где-то это прописывалось дополнительно)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ясно что не может найти рутовую, вопрос: где задаётся расположение рутовой (можно подумать что в строке загрузки ядра, но в старой версии ядра в строке указывалась только консоль, а рутовая грузилась с nand, значит где-то это прописывалось дополнительно)

Именно там (в bootargs) и задавалось: root=... В 3.x, как я понимаю, ничего не изменилось в этом плане.

 

Кстати вопрос: а что, собственно, побудило к переходу на новое ядро?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пересев на новое ядро, хочу попробовать новый RT-патч и сравнить поведение.

 

Про строку загрузки ядра, ниже скриншот строки, которая присутствует в конфиге ядра рабочей системы, которая берёт рутовую из NAND, а значит этот параметр задаётся где-то ещё:

post-52195-1396598280_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а значит этот параметр задаётся где-то ещё:

судя по снятой галке - в переменных окружения u-boot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Верно. Скопировал строку из переменной окружения в bootargs ядра.

не помогло. в чём может быть дело?

 

рутовая на NAND, поддержка ubifs включена в ядре

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

regulator_init_complete: VDCDC1: incomplete constraints, leaving on

davinci_emac davinci_emac.1: using random MAC addr: 3a:23:26:bb:75:7a

omap_rtc omap_rtc: setting system clock to 2000-01-01 01:13:21 UTC (946689201)

ata1: SATA link down (SStatus 0 SControl 300)

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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...