|
|
  |
Linux не хочет работать на MPC8349-mITX-GP |
|
|
|
Apr 15 2008, 10:47
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 6-12-07
Из: Москва
Пользователь №: 33 045

|
Может быть кто-то сталкивался с этой платой от Freescale на базе PowerPC? К ней шёл т.н. BSP - уже откомпилированный Линукс, сделанный с помощью тула Ltib. Версия его довольно древняя - 2.6.13. Задача - поставить туда ядро посвежее, собранное самостоятельно, и научиться отлаживать программы в плате. Процесс сборки должен быть максимально прозрачен, поэтому всякие Ltib использовать нежелательно. Я откомпилировал ядро 2.6.24.4 под эту плату (благо в официальной ветке есть порт под неё), но оно отказывается работать. Точнее отказывается выдавать что-либо в консоль, что может быть не одно и то же. Подобраться к плате и понять, в чём дело, я не могу - JTAG, который мы купили у Freescale, хочет CodeWarrior - его у нас нет. Очень хочется использовать всё-таки gdb. Скорее всего, дело в каких-нибудь патчах или параметрах ядра. Патчи для меня вообще большая загадка - как понять, что и где брать. Параметры я передаю те же, что и старому ядру, возможно что-то изменилось с тех пор. Кстати, кто-нибудь в курсе, возможно ли при сборке ядра задать параметры по умолчанию?
|
|
|
|
|
Apr 15 2008, 11:42
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(guskov @ Apr 15 2008, 13:47)  Может быть кто-то сталкивался с этой платой от Freescale на базе PowerPC? К ней шёл т.н. BSP - уже откомпилированный Линукс, сделанный с помощью тула Ltib. Версия его довольно древняя - 2.6.13. Задача - поставить туда ядро посвежее, собранное самостоятельно, и научиться отлаживать программы в плате. Процесс сборки должен быть максимально прозрачен, поэтому всякие Ltib использовать нежелательно. Я откомпилировал ядро 2.6.24.4 под эту плату (благо в официальной ветке есть порт под неё), но оно отказывается работать. Точнее отказывается выдавать что-либо в консоль, что может быть не одно и то же. Подобраться к плате и понять, в чём дело, я не могу - JTAG, который мы купили у Freescale, хочет CodeWarrior - его у нас нет. Очень хочется использовать всё-таки gdb. Скорее всего, дело в каких-нибудь патчах или параметрах ядра. Патчи для меня вообще большая загадка - как понять, что и где брать. Параметры я передаю те же, что и старому ядру, возможно что-то изменилось с тех пор. Кстати, кто-нибудь в курсе, возможно ли при сборке ядра задать параметры по умолчанию? Конкретно по этому процессору и плате помочь не могу - не работал с такими. Патчи обычно есть на тематических сайтах. Есть ли такие сайты по Вашему железу - не знаю. Загрузчик должен был инициализировать последовательный порт перед стартом ядра. Это должен быть тот-же порт, что и параметр ядра console=. Тогда Вы увидите хотя бы строку вида Uncompressing linux ... done. Есть параметр с командной строкой по умолчанию. Но он существует не для всех архитектур. Параметр в .config Вот отрывок для ARM Код # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x21100000,3145728 root=/dev/ram0 rw" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set Если для Вашей архитектуры этого нет, то оно должно настраиваться в загрузчике.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Apr 15 2008, 14:23
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 6-12-07
Из: Москва
Пользователь №: 33 045

|
Цитата(amw @ Apr 15 2008, 15:42)  Загрузчик должен был инициализировать последовательный порт перед стартом ядра. Это должен быть тот-же порт, что и параметр ядра console=. Тогда Вы увидите хотя бы строку вида Uncompressing linux ... done. Загрузчик я пока не менял, он работает (u-boot), общается со мной через консоль, так что она настроена. Сообщение о распаковке Линукса выдаётся, как я понимаю, его рисует как раз загрузчик. Ведь ядро хранится практически как ZIP файл, само себя оно распаковать не может. Или я не прав? Цитата(amw @ Apr 15 2008, 15:42)  Есть параметр с командной строкой по умолчанию. Но он существует не для всех архитектур. Параметр в .config Вот отрывок для ARM Спасибо за наводку. Нашёл опцию # CONFIG_CMDLINE_BOOL is not set в оригинальной конфигурации - видимо дело не в параметрах. Попробовал перекомпилировать ядро из их исходников своим компилятором - ядро опять же не работает (плата рестартует). Надо сказать, что я компилятор собирал для платформы powerpc-linux, а в ядре 2.6.13 была только платформа ppc. Кто-нибудь может объяснить, в чём между ними разница?
|
|
|
|
|
Apr 16 2008, 07:32
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(guskov @ Apr 15 2008, 17:23)  Загрузчик я пока не менял, он работает (u-boot), общается со мной через консоль, так что она настроена. Сообщение о распаковке Линукса выдаётся, как я понимаю, его рисует как раз загрузчик. Ведь ядро хранится практически как ZIP файл, само себя оно распаковать не может. Или я не прав? Нет, ядро распаковывает себя само. Так что ядро стартует и распаковывается. Уже что-то. После этого ядро проводит инициализацию подсистемы памяти, некоторого оборудования (перечень зависит от архитектуры) и потом консоль. Видимо что проблема возникает до инициализации консоли. Uncompressing Linux ... done выводится тупо, а позже ядро переинициализирует порт и запускает уде полновесный протокол консоли. Собственно вариантов может быть два. Плохой и хороший. Хороший - ядро стартует, но для консоли использует либо другой порт, либо не последовательный порт (ttyS*) а виртуальную консоль (tty*). Плохой - Kernel panic до инициализации консоли.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Apr 17 2008, 10:44
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 6-12-07
Из: Москва
Пользователь №: 33 045

|
Цитата(amw @ Apr 16 2008, 11:32)  Нет, ядро распаковывает себя само. Так что ядро стартует и распаковывается. Уже что-то. После этого ядро проводит инициализацию подсистемы памяти, некоторого оборудования (перечень зависит от архитектуры) и потом консоль. Видимо что проблема возникает до инициализации консоли. Uncompressing Linux ... done выводится тупо, а позже ядро переинициализирует порт и запускает уде полновесный протокол консоли. К сожалению, сообщение выглядит несколько не так и выдаёт именно u-boot, проверено в его исходниках: Uncompressing Kernel Image... OK Есть подозрение, что неправильно собраны ядро или тулы. А Вы не в курсе, какая разница между таргетами ppc и powerpc?
|
|
|
|
|
Apr 18 2008, 13:22
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(guskov @ Apr 17 2008, 13:44)  К сожалению, сообщение выглядит несколько не так и выдаёт именно u-boot, проверено в его исходниках: Uncompressing Kernel Image... OK Есть подозрение, что неправильно собраны ядро или тулы. Действительно, это сообщение выдается загрузчиком. Ядро выдает своее сообщение. См. файл arch/<АРХИТЕКТУРА>/boot/compressed/misc.c Сообщение выглядит так (если все в порядре конечно) Код Uncompressing Linux... Ok, booting the kernel. Цитата А Вы не в курсе, какая разница между таргетами ppc и powerpc? Не в курсе. А как называется файл компилятора? ppc-linux-gcc? Что говорит $ ppc-linux-gcc -v Потом смотрите в ядре наличие папки arch/ppc ну или той, что выведет компилер. Посмотрите Makefile на предмет ARCH=?. Посмотрите на перечень процессоров в arch/ppc/Kconfig arch/powerpc/Kconfig Только что глянул, arch/ppc/boot/simple/misc.c
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Apr 19 2008, 18:13
|
Частый гость
 
Группа: Свой
Сообщений: 114
Регистрация: 10-05-05
Пользователь №: 4 893

|
У меня плата на близком CPU 8347. Тоже Линукс 2.6.13 Я не рискнул переходить на более новое, нет времени и пока не вижу смысла. Маловероятно что именно эти изменения нужны, хотя по Power PC их было и достаточно. Может стоит сначала потренираваться на перекомпилляции стартового ядра? Покрайнее мере Вы убедитесь что toolchain настроен и сиcтема переконфигурируется как Вам надо. Это необходимый минимум. А потом можно браться за другое ядро, но подумайте - стоит ли, особенно если у Вас нет хорошо настроенного BSP именно под Вашу плату - просто это может занять очень много времени. Если есть на плате Ethernet (а на 8349 он не может не быть) - то лучше сразу настройте/примонтируйте NFS, может это проще, и позволит обойтись без JTAG, я им по крайней мере до сих пор не пользовался.
>А Вы не в курсе, какая разница между таргетами ppc и powerpc? подозреваю что они могут быть alias. Я заметил, что здесь еще много путаницы, не все прикладные либы нормально кросс-перекомпилируются, приходится вручную править Makefile, которые сгенерились по configure. Хорошо, чо один автор в одной либе в readme предупредил, чо переменные на некоторых платформах сбрасываются. В общем, засад может быть много...
Тем не менее, у Вас в BSP должны быть скрипты которые экспортируют все нужные переменные для кросс-компилляции ядра. А если их нет, то надо начать с них настройку тулчейна - правильно поставить все НУЖНЫЕ переменные. Потом контрольная компилляция исходного ядра 2,6,13. Потом можно поиграть с параметрами ядра и модулями и т.п.
Посмотрите, что-то подобное: ------------------------ export CROSS_COMPILE=/opt/crosstool/powerpc-e300-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/powerpc-e300-linux-gnu-
export AS="${CROSS_COMPILE}as" export LD="${CROSS_COMPILE}ld" export CC="${CROSS_COMPILE}gcc" export CPP="${CC} -E" export AR="${CROSS_COMPILE}ar" export NM="${CROSS_COMPILE}nm" export STRIP="${CROSS_COMPILE}strip" export OBJCOPY="${CROSS_COMPILE}objcopy" export OBJDUMP="${CROSS_COMPILE}objdump"
export ARCH=ppc
Это для приложения и ядра. Для ядра дополнительно: export TARGET="powerpc-linux" export ARCH_NAME="ppc_e300_linux" export ROOT_DIR="$BOARD_DIR/root_fs/" export CROSS_COMPILE="/opt/crosstool/powerpc-e300-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/powerpc-e300-linux-gnu-" export ARCH_DIR="/opt/crosstool/powerpc-e300-linux-gnu/gcc-3.4.1-glibc-2.3.3/powerpc-e300-linux-gnu/" # EXTRA_CC_FLAGS is used to set special flags for compiler export EXTRA_CC_FLAGS="-O5 -Wall -fomit-frame-pointer -funroll-loops -Wa -fforce-mem -falign-loops=2 -falign-functions=2 -falign-jumps=2 -ffast-math"
# This flag is used to deliver Busybox aplications external library. # It's used in /src/busybox-1.0/Rules.mak export EXTRA_LIBRARY="-lm"
и т. п. Как видите, ARCH=ppc а TARGET="powerpc-linux, плюс еще ARCH_NAME="ppc_e300_linux" так что связи могут быть достаточно сложные и надо долго ползать по Makefile и конфигам. Одному модулю надо одна переменная, другому вторая, третьему обе. Надо правильно поставить все. И еще корневые модули ядра для платы могут варьироваться (кстати после 2.6.13 их в ядре ПЕРЕНОСИЛИ В ДРУГИЕ ПАПКИ !) Например в 2.6.13 были в \linux\arch\ppc\platforms\83xx\ а в более позних версиях некотрые платы на конкретных 83xx перенесены на более высокий уровень в дереве ядра/выделены отдельно от 83xx Но подозреваю что и ..\platforms\83xx\ все равно должен существовать.
|
|
|
|
|
Apr 24 2008, 10:06
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 6-12-07
Из: Москва
Пользователь №: 33 045

|
Нашёл очень интересную ссылку по теме, видимо проблема где-то рядом. Тут же объясняется отличие ppc и powerpc. http://www.mail-archive.com/linuxppc-embed...g/msg07359.html
Сообщение отредактировал guskov - Apr 24 2008, 10:06
|
|
|
|
|
Apr 28 2008, 07:10
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 6-12-07
Из: Москва
Пользователь №: 33 045

|
Коллеги, спасибо за помощь - проблема решилась. Заключалась она, как ни странно, не в ядре и не в настройках компилятора, а в генерации образа для загрузки. U-boot 1.1.3 не жуёт образ uImage, который генерит процесс сборки ядра. Зато в ядре 2.6.25 появился дополнительно новый формат образа, который в аккурат загрузился. В подробностях этого явления ещё предстоит разобраться, скорее всего дело в том самом device tree, о котором был предыдущий пост.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|