Перенос ядра на разрабатываему плату.

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

Изменять ничего не нужно, и так заработает.

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

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

Пока вопрос драйверов для нового железа не затрагиваем.

В сложных случаях допиливать нужно именно их.

Это очень радостные новости. Спасибо.))

Зависит. Если есть порт ядра на целевую архитектуру, то его обычно пилить не надо.

Целевая архитектура - это процессор?

В сложных случаях допиливать нужно именно их.

Это да. Но пака мне хотя бы запустить просто ядро на новой плате, а потом уже заниматься драйверами.

Целевая архитектура - это процессор?

В данном случае скорее «референсная плата», т.е. процессор и некоторый набор периферии.

Целевая архитектура - это процессор?

ISA.

дооо. даже с другим загрузчиком и архитектурой

есть процессорный модуль и есть отладночная плата
На это дело так же имеется адаптированное ядро и u-boot.

И объясни мне, где здесь другой загрузчик и архитектура, если

этот модуль будет вставляться в новую плату разрабатываемую для него

Если будет вставляться тот же модуль, то кроме вероятного подпилинга dts фаила с периферией, нигде.

А заработает скорее всего из коробки.

Если будет вставляться тот же модуль, то кроме вероятного подпилинга dts фаила с периферией, нигде.

Ой не факт. Эти «новые платы» могут быть очень серьезным геморроем.

Если это что-то типа SoM в виде so-dimm, там всё критичное на модуле и запускается обычно с полтычка.

У меня тут китайский модуль с mt7620 взлетел с минимальной правкой dts в openwrt, чо уж там/

Если это что-то типа SoM в виде so-dimm

Если. А если там на плате флеши, ПЛИСы, PHY и хоть немного нестандартной периферии - геморрой более чем вероятен.

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

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips...

Вот в этом коде могут потребоваться изменения.

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

Так оно и есть. Вот этот модуль https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-...

Спасибо. В периферии изменения есть. Но они такие...Например используется другой USB хаб нежели тот, что стоит у них на родной отладочной плате. И все в таком духе.

так в новую или такую же, блаждж?

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

чтобы они хотя бы просто запустились на новой плате?

Это уже разработка нового устройства и там да, «своя атмосфера». А спрашивали про «завести» на модуле.

А спрашивали про «завести» на модуле.

«чтобы они хотя бы просто запустились на новой плате» же.

Процессорный модуль устанавливается на материнскую плату. Материнская плата отличается от платы которая поставляется вместе с модулем по железу. То, что придется писать драйвера для поддержки нового железа - это мне понятно. Но пока мне непонятно может ли ядро и загрузчик поставляемые производителем для модуля завестись на плате отличной от той, которую поставляет тот же производитель.

Т.е. если я правильно понимаю, то чтобы удачно запустить тот же U-Boot в новом окружении, то нужно как минимум переконфигурировать Device Tree, я прав?

Извиняюсь за ламерские вопросы, но я только-только вступаю на этот извилистый путь.))

u-boot в общем случае переделывать вообще не надо. Там всё прибито гвоздями и в рамках модуля всё необходимое(serial port, ethernet, flash) тебе должно взлететь без проблем, потому что ничего не меняется.

В частном случае, когда в u-boot надо запихать что-то из того что не предусмотрел вендор - там начинается развлекуха. Если понадобится такое, рекомендую сразу же разжиться jtag адаптером, благо они нынче недорогие.

device tree использует linux, а u-boot его ему может передать разве что. Может новый u-boot и умеет что-то с ним делать, но я совсем свежак не копал.

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

Могут. Но могут и не завестись. Например, если на твоей плате NAND, а на плате производителя - NOR. Или на твоей плате другой RAM. Или тебе нужна загрузка по сети, а на плате другие PHY.

чтобы удачно запустить тот же U-Boot в новом окружении, то нужно как минимум переконфигурировать Device Tree, я прав?

Зависит от различий между референсной платой и реальной. Может быть, даже этого не понадобится.

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

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

Понял, спасибо. Есть большая надежда избежать геморроя ибо везде используется NAND.))

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