Странная вещь с do_patch
Dmitry Vinokurov
Все еще занимаюсь сборкой OE для LPC3250 (local.conf приложен) и
столкнулся со следующим:
На основе работающих на моей плате исходников ядра 2.6.27.8 сделал патч
(make distclean и diff -Nurd), переместил его в
'recipes/linux/linux-2.6.27.8/phy3250/', скопировал рабочий .config в
'recipes/linux/linux-2.6.27.8/phy3250/defconfig', создал 2.6.27.8 рецепт
на основе 2.6.27 (приложен). Когда после этого я собираю ('bitbake
virtual/kernel') и запускаю ядро на плате, возникает kernel panic (not
syncing: Attempted to kill init). Покопавшись немного, обнаружил, что
стандартный исходный код 2.6.27.8 с примененным патчем отличается от
исходников, пропатченных bitbake и расположенных в
tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1/linux-2.6.27.8. Мне
это показалось достаточно странным, так как последние строки 'bitbake
virtual/kernel -v -DD -c patch' следующие:
------------
NOTE: Running task 36 of 36 (ID: 3,
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb, do_patch)
DEBUG: Parsing
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb (full)
DEBUG: BB
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb:
handle(data)
DEBUG: BB linux.inc: handle(data, include)
DEBUG: BB :0: inheriting classes/kernel.bbclass
DEBUG: BB classes/kernel.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/linux-kernel-base.bbclass
DEBUG: BB classes/linux-kernel-base.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/module_strip.bbclass
DEBUG: BB classes/module_strip.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/kernel-arch.bbclass
DEBUG: BB classes/kernel-arch.bbclass: handle(data, include)
DEBUG: setVarFlag(kernel_do_compile, depends, ${INITRAMFS_TASK}, data)
DEBUG: setVarFlag(do_menuconfig, nostamp, 1, data)
DEBUG: BB :0: inheriting classes/cml1.bbclass
DEBUG: BB classes/cml1.bbclass: handle(data, include)
DEBUG: setVarFlag(do_deploy, dirs, ${S}, data)
DEBUG: update_data()
DEBUG: update_data()
DEBUG: Executing task do_patch
DEBUG: update_data()
DEBUG:
mkdirhier(/home/raydan/work/oe/build/tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1)
DEBUG:
mkdirhier(/home/raydan/work/oe/build/tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1)
NOTE: Applying patch 'phy3250.patch'
(../openembedded/recipes/linux/linux-2.6.27.8/phy3250/phy3250.patch)
DEBUG:
mkdirhier(/home/raydan/work/oe/build/tmp/stamps/phy3250-oe-linux-gnueabi)
NOTE: Tasks Summary: Attempted 36 tasks of which 35 didn't need to be
rerun and 0 failed.
------------
То есть похоже что bitbake не делает ничего кроме применения патча, но
на самом деле получается что очень даже делает (diff между пропатченными
вручную исходниками и пропатченными bitbake включает около 30000 строк,
и я решил не присоединять его:)) и в результате получается kernel panic.
Судя по результатам diff, создается директория '.pc' в корне исходного
кода ядра (причем некоторые файлы в ней имеют права 0000), но не только
-- некоторые файлы в arch/arm и sound/soc/lpc3xxx/ и другие тоже
различаются. Удалял tmp/ и пересобирал -- тот же результат.
Кто-нибудь может подсказать, с чем связана эта странность? Мне казалось
что задача patch должна только вызывать утилиту 'patch'.
P.S.: openembedded stable/2009, bitbake 1.8.12-1 из репозитория Debian.
--
С уважением,
Дмитрий Винокуров
<d.vino...@gmail.com>
Anatoly Shipitsin
У меня есть дурацкий вопрос. У вас платформа определена? Я вот что-то не наблюдаю.
Dmitry Vinokurov
>
>
> 2009/8/26 Dmitry Vinokurov <d.vino...@gmail.com
> <mailto:d.vino...@gmail.com>>
>
> Приветствую!
>
> Все еще занимаюсь сборкой OE для LPC3250 (local.conf приложен) и
> столкнулся со следующим:
>
> На основе работающих на моей плате исходников ядра 2.6.27.8 сделал
> патч
> (make distclean и diff -Nurd), переместил его в
> 'recipes/linux/linux-2.6.27.8/phy3250/', скопировал рабочий .config в
> 'recipes/linux/linux-2.6.27.8/phy3250/defconfig', создал 2.6.27.8
> рецепт
> на основе 2.6.27 (приложен). Когда после этого я собираю ('bitbake
> virtual/kernel') и запускаю ядро на плате, возникает kernel panic (not
> syncing: Attempted to kill init). Покопавшись немного, обнаружил, что
> стандартный исходный код 2.6.27.8 с примененным патчем отличается от
> исходников, пропатченных bitbake и расположенных в
> tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1/linux-2.6.27.8.
> Мне
> это показалось достаточно странным, так как последние строки 'bitbake
> virtual/kernel -v -DD -c patch' следующие:
> ------------
> NOTE: Running task 36 of 36 (ID: 3,
> /home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb
> DEBUG: Parsing
> /home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb
> <http://linux_2.6.27.8.bb> (full)
> DEBUG: BB
> /home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb
> <http://linux_2.6.27.8.bb>:
-- то определена, конфиг во вложении. Тут в английском списке рассылки
посоветовали посмотреть с помощью программы quilt, какие патчи
применялись -- попробую сейчас.
Anatoly Shipitsin
Если платформа в смысле конфигурационный файл для платы (machine config)
-- то определена, конфиг во вложении. Тут в английском списке рассылки
посоветовали посмотреть с помощью программы quilt, какие патчи
применялись -- попробую сейчас.
У вас в файле платформы указана архитектура, скорее всего накладываются патчи специфичные для нее.
Denys Dmytriyenko
> Приветствую!
>
> То есть похоже что bitbake не делает ничего кроме применения патча, но
> на самом деле получается что очень даже делает (diff между пропатченными
> вручную исходниками и пропатченными bitbake включает около 30000 строк,
> и я решил не присоединять его:)) и в результате получается kernel panic.
> Судя по результатам diff, создается директория '.pc' в корне исходного
> кода ядра (причем некоторые файлы в ней имеют права 0000), но не только
> -- некоторые файлы в arch/arm и sound/soc/lpc3xxx/ и другие тоже
> различаются. Удалял tmp/ и пересобирал -- тот же результат.
>
> Кто-нибудь может подсказать, с чем связана эта странность? Мне казалось
> что задача patch должна только вызывать утилиту 'patch'.
Директории .pc (и права 0000) - это результат работы quilt/patch:
http://www.mail-archive.com/quil...@nongnu.org/msg01091.html
Как выглядит diff, если убрать эти директории?
find . -type d -name '.pc' -exec rm -rf {} \;
--
Denys
Dmitry Vinokurov
невнимательно смотрел вывод diff -- спутал отличающиеся строки в файлах
и имена отличающихся файлов. Сейчас столкнулся с тем, что bitbake вносит
изменения в указанный мною конфиг (на основе do_configure_prepend() в
linux.inc), но с этим все вроде понятно и исправимо.
Denys Dmytriyenko
Изменения в defconfig для предотвращения глупых ошибок - автоматом включить
NFS опции в ядре, если они включены в системе. И тому подобное...
--
Denys