Рецепт модуля yocto linux ошибка do_package_qa

Рецепт модуля ядра Linux, который отлично работал в Yocto-версии Freescale / NXP SDK v1.8, вызывает ошибку в do_package_qa при использовании Yocto-версии Freescale / NXP SDK v2.0. Как следует из ошибки:

ОШИБКА: QA. Проблема: ФАЙЛЫ в рецепте kernel-module-r8168 не должны содержать переменную $ {D}, поскольку она ссылается на локальный каталог сборки, а не на целевую файловую систему. Лучшее решение - удалить ссылку $ {D} [расширенный-d]
ОШИБКА: при тестировании были обнаружены фатальные ошибки. Пожалуйста, подумайте об их исправлении.
ОШИБКА: Сбой функции: do_package_qa

Сам рецепт модуля ядра не содержит $ {D}, но он используется в module.bbclass, от которого мой рецепт модуля наследуется

Вот мой рецепт модуля:

SUMMARY = "Realtek r8168 family driver Linux kernel module" 
LICENSE = "GPLv2" 
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

inherit module

PN = "r8168" 
PV = "8.041.01"

SRC_URI = "file://r8168-8.041.01.tgz \
           file://COPYING \
          "

SRC_URI[md5sum] = "f3fd1530132ed1b64345698f89beea0f"

S = "${WORKDIR}"

KERNEL_MODULE_AUTOLOAD += "r8168"

Я обнаружил, что проверка переменной $ {D} была добавлена ​​в версию insane.bbclass SDK 2.0 Yocto по сравнению с версией SDK 1.8 Yocto.

У меня следующие вопросы:

  1. Это ошибка Yocto?
  2. Как я могу это обойти или исправить?

log.do_package_qa.526:

DEBUG: Executing python function sstate_task_prefunc
DEBUG: Python function sstate_task_prefunc finished
DEBUG: Executing python function do_package_qa
NOTE: DO PACKAGE QA
DEBUG: Executing python function read_subpackage_metadata
DEBUG: Python function read_subpackage_metadata finished
NOTE: Checking Package: r8168
NOTE: Checking Package: r8168-doc
NOTE: Checking Package: r8168-dbg
NOTE: Checking Package: r8168-staticdev
NOTE: Checking Package: r8168-locale
NOTE: Checking Package: r8168-dev
NOTE: Checking Package: kernel-module-r8168
NOTE: arm-fsl-linux-gnueabi-objdump -p /local/ctrommel/QorIQ-SDK-V2.0-20160527-yocto/build_ls1021atwr/tmp/work/ls1021at
wr-fsl-linux-gnueabi/r8168/8.041.01-r0/packages-split/kernel-module-r8168/lib/modules/4.1.8-rt8+gbd51baf/local/ctrommel
/QorIQ-SDK-V2.0-20160527-yocto/build_ls1021atwr/tmp/work/ls1021atwr-fsl-linux-gnueabi/r8168/8.041.01-r0/image/r8168.ko
ERROR: QA Issue: FILES in kernel-module-r8168 recipe should not contain the ${D} variable as it references the local bu
ild directory not the target filesystem, best solution is to remove the ${D} reference [expanded-d]
ERROR: QA run found fatal errors. Please consider fixing them.
DEBUG: Python function do_package_qa finished
ERROR: Function failed: do_package_qa

yocto bitbake
person Kees Trommel    schedule 29.06.2016    source источник
comment
Не могли бы вы дать нам ссылку на Freescale NXP SDK? Желательно репозиторий git, если он доступен. Нет никаких проблем со сборкой внешних модулей ядра в стандартной версии YP 2.0, о которой я знаю.   -  person Anders    schedule 29.06.2016
comment
Не могли бы вы также предоставить содержимое файла журнала: log.do_package_qa для соответствующего рецепта?   -  person iksajotien    schedule 30.06.2016
comment
QorIQ SDK можно загрузить с веб-сайта NXP после регистрации в NXP. Я не могу предоставить ссылку, вам нужно выполнить поиск QorIQ SDK, чтобы найти страницу загрузки.   -  person Kees Trommel    schedule 01.07.2016
comment
Эту проблему можно воспроизвести с помощью YP Core - Krogoth 2.1. Таким образом, добавление NXP SDK не является основной причиной.   -  person Kees Trommel    schedule 01.07.2016
comment
Я проверил, где в rootfs добавлен модуль, и обнаружил, что путь к модулю включает расширенный $ {D} (./lib/modules/4.1.8-rt8+gbd51baf / local / ctrommel / QorIQ-SDK-V2. 0-20160527-yocto / b‌ uild_ls1021atwr / tmp / work / ls1021atwr-fsl-linux-gnueabi / r8168 / 8.041.01-r0 / image / r81‌ 68.ko). Таким образом, сообщение об ошибке правильное, но, похоже, оно не вредит, потому что модуль все равно загружается по нелепому длинному пути. Остается вопрос: это ошибка или я неправильно добавил модуль ядра?   -  person Kees Trommel    schedule 01.07.2016

Ответы (3)


arrow_upward
0
arrow_downward

Где-то вы найдете ссылку на ${D} в значении FILES для одного из пакетов - это неверно. FILES предназначен для указания путей в том виде, в каком они будут отображаться на целевом компьютере, поэтому вы не должны указывать в качестве префикса временный установочный каталог ${D}.

Я не могу точно сказать, где это будет - вряд ли это будет частью предоставленных Yocto Project метаданных, но bitbake -e yourrecipe | less, а затем выполните поиск (используя '/') для \$\{D\}, и вы сможете точно увидеть, где установлено недопустимое значение.

person bluelightning    schedule 01.07.2016
comment
$ {D} используется в module.bbclass, который унаследован моим r8168_8.041.01.bb. module.bbclass - это стандартный слабый класс (не специфичный для NXP SDK). - person Kees Trommel; 01.07.2016
comment
Эту проблему можно воспроизвести с помощью YP Core - Krogoth 2.1. Итак, $ {D} каким-то образом должен быть предоставлен метаданными Yocto, но я не могу понять, как это сделать. Вывод bitbake -e не помог. - person Kees Trommel; 01.07.2016

arrow_upward
0
arrow_downward

Добавление следующей строки в рецепт модуля поможет обойти эту проблему:

INSANE_SKIP_kernel-module-${PN} = "expanded-d"

Поскольку сборка прошла успешно (модуль был добавлен в образ) после пропуска проверки QA, я более убежден, что это ошибка.

person Kees Trommel    schedule 01.07.2016
comment
Мое определение обходного пути таково: решение, которое скрывает проблему, но позволяет вам достичь цели, которую вы хотите достичь. Поскольку в результате получается изображение с функциональным драйвером, у меня это работает. Так что я согласен, что это скрывает проблему, но я не согласен, что это не работа :) - person Kees Trommel; 06.07.2016
comment
Честно говоря, я хотел написать (хотя по какой-то причине не стал), что это не было решением ... И такое сокрытие таких проблем вполне могло вызвать проблемы. - person Anders; 06.07.2016

arrow_upward
0
arrow_downward

Это не ошибка Yocto. Это была проблема в Makefile добавленного модуля. Этот Makefile представляет собой модифицированную версию Makefile драйвера, предоставленную производителем устройства. Исходный Makefile содержал флаг make INSTALL_MOD_DIR, а значение было изменено на INSTALL_MOD_DIR = $ (INSTALL_MOD_PATH). Предполагалось, что путь установки целевого модуля был INSTALL_MOD_PATH, однако это путь установки хост-модуля, содержащий $ {D}. Итак, ошибка, выдвинутая Йокто, была правильной. Удаление флага make из Makefile устранило проблему.

person Kees Trommel    schedule 04.07.2016