How to use an own kernel configuration for a raspberry pi in yocto? - linux

I like to remove some unused drivers for my RPI2 + custom board. For that I am creating an own configuration via:
bitbake linux-raspberrypi -c menuconfig
and save the new kernel preset to the file defconfig.
After this I created an append file for the linux-raspberryp recipe.
So I created the file
linux-raspberrypi%.bbappend
and filled it with:
FILESEXTRAPATHS_prepend := "${THISDIR}/linux-raspberrypi:"
SRC_URI += "file://defconfig"
PACKAGE_ARCH = "raspberrypi2"
I put the defconfig file to:
<meta-mylayer>/recipes-kernel/linux/linux-raspberrypi/raspberrypi2/defconfig
When recompiling the kernel via:
bitbake linux-raspberrypi -c clean
bitbake linux-raspberrypi
The standard RPI2 configuration is taken.
Any idea how to overcome this problem?
I am working on the "actual" pyro branch of meta-raspberrypi and yocto.

Well, unfortunately, the easiest way is probably to patch the kernel source... Or copy your defconfig over the in kernel-tree one.
The meta-raspberrypi layer does some unfortunate things in their kernel recipes, and even though this has become better with time, they're still not really nice...
If you take a look at recipes-kernel/linux/linux-raspberrypi.inc, the following lines explains the issue:
KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
do_kernel_configme_prepend() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG} available."
}
Thus,they're copying the in-tree defconfig to ${WORKDIR}/defconfig, thereby overwriting your own defconfig.
You in you .bbappend, you could try to add:
do_kernel_configme_prepend() {
install -m 0644 ${WORKDIR}/defconfig ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} || die "No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG} available."
}
Thus, first overwriting the in-kernel-tree one with your own defconfig.

Please take a look at how to use devtool to modify source code for the jethro:
http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#using-devtool-in-your-workflow
I would start by having a fork at the git repository that it is using;
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi_4.9.bb
Using devtool in Yocto;
in your build directory: create a my-linux-raspberry folder;
mkdir linux-raspberry-test
devtool modify -x linux-raspberry ./my-linux-raspberry
This will put unpack the source code into my-linux-raspberry for you to modify; It also create the git repository in there;
Then, modify the code in my-linux-raspberry; To test build, run devtool build linux-raspberry; Once you are satisfied, add this git repository to your fork;
git add .
git commit -m "my-linux-raspberry"
devtool update-recipe linux-raspberry
Optional: run devtool reset linux-raspberry to remove the bbappend file;

Related

ESP32: gn.py: Could not find checkout in any parent of the current path. This must be run inside a checkout

complying an ESP32 project using the MATTER protocol from the github project: Connectedhomeip (https://github.com/project-chip/connectedhomeip/tree/master/examples/all-clusters-app/esp32)
im using ubuntu 20.02, tried using python 3.8 and 3.9 no difference to error.
i followed the following instructions from the above link, the instruction as pasted below
Building the Example Application
Building the example application requires the use of the Espressif ESP32 IoT Development Framework and the xtensa-esp32-elf toolchain for ESP32 modules or the riscv-esp32-elf toolchain for ESP32C3 modules.
The VSCode devcontainer has these components pre-installed, so you can skip this step. To install these components manually, follow these steps:
Clone the Espressif ESP-IDF and checkout v4.4 release
$ mkdir ${HOME}/tools
$ cd ${HOME}/tools
$ git clone https://github.com/espressif/esp-idf.git
$ cd esp-idf
$ git checkout v4.4
$ git submodule update --init
$ ./install.sh
Install ninja-build
$ sudo apt-get install ninja-build
Currently building in VSCode and deploying from native is not supported, so make sure the IDF_PATH has been exported(See the manual setup steps above).
Setting up the environment
$ cd ${HOME}/tools/esp-idf
$ ./install.sh
$ . ./export.sh
$ cd {path-to-connectedhomeip}
To download and install packages.
$ source ./scripts/bootstrap.sh
$ source ./scripts/activate.sh
If packages are already installed then simply activate them.
$ source ./scripts/activate.sh
Target Set
To set IDF target, run set-target with one of the commands.
$ idf.py set-target esp32
$ idf.py set-target esp32c3
Configuration Options
To build the default configuration (sdkconfig.defaults) skip to building the demo application.
To build a specific configuration (as an example m5stack):
$ rm sdkconfig
$ idf.py -D 'SDKCONFIG_DEFAULTS=sdkconfig_m5stack.defaults' build
Note: If using a specific device configuration, it is highly recommended to
start off with one of the defaults and customize on top of that. Certain
configurations have different constraints that are customized within the
device specific configuration (eg: main app stack size).
To customize the configuration, run menuconfig.
$ idf.py menuconfig
Select ESP32 based Device Type through Demo->Device Type. The device types that are currently supported include ESP32-DevKitC (default), ESP32-WROVER-KIT_V4.1, M5Stack and ESP32C3-DevKitM.
To build the demo application.
$ idf.py build
After building the application, to flash it outside of VSCode, connect your device via USB. Then run the following command to flash the demo application onto the device and then monitor its output. If necessary, replace /dev/tty.SLAB_USBtoUART(MacOS) with the correct USB device name for your system(like /dev/ttyUSB0 on Linux). Note that sometimes you might have to press and hold the boot button on the device while it's trying to connect before flashing. For ESP32-DevKitC devices this is labeled in the functional description diagram.
$ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor
When use >>idf.py to build the project i get the follow error
>>idf.py build
Executing action: all (aliases: build)
Running ninja in directory /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build
Executing "ninja all"...
ninja: warning: bad deps log signature or version; starting over
[0/1] Re-running CMake...
-- Building ESP-IDF components for target esp32
-- Found Python3: /home/csir/.espressif/python_env/idf5.0_py3.8_env/bin/python3.8 (found version "3.8.10") found components: Interpreter
-- Project sdkconfig file /home/csir/connectedhomeip/examples/all-clusters-app/esp32/sdkconfig
Loading defaults file /home/csir/connectedhomeip/examples/all-clusters-app/esp32/sdkconfig.defaults...
-- App "chip-all-clusters-app" version: TE8/rc2-7-gf32685f35-dirty
-- Adding linker script /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/esp-idf/esp_system/ld/memory.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_system/ld/esp32/sections.ld.in
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.api.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.newlib-time.ld
-- Adding linker script /home/csir/esp/esp-idf/components/soc/esp32/ld/esp32.peripherals.ld
-- Components: QRCode app_trace app_update asio bootloader bootloader_support bt chip cmock coap console cxx driver efuse esp-tls esp32 esp32_mbedtls esp_adc_cal esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_netif esp_phy esp_pm esp_ringbuf esp_rom esp_serial_slave_link esp_system esp_timer esp_websocket_client esp_wifi espcoredump esptool_py fatfs freemodbus freertos hal heap http_parser idf_test ieee802154 iperf json led_strip log lwip main mbedtls mdns mqtt newlib nvs_flash openssl openthread partition_table pcap perfmon pid_ctrl protobuf-c protocol_examples_common protocomm pthread qrcode screen-framework sdmmc soc spi_flash spidriver spiffs tcp_transport tcpip_adapter tft tinyusb ulp unity usb vfs wear_levelling wifi_provisioning wpa_supplicant xtensa
-- Component paths: /home/csir/connectedhomeip/examples/common/QRCode /home/csir/esp/esp-idf/components/app_trace /home/csir/esp/esp-idf/components/app_update /home/csir/esp/esp-idf/components/asio /home/csir/esp/esp-idf/components/bootloader /home/csir/esp/esp-idf/components/bootloader_support /home/csir/esp/esp-idf/components/bt /home/csir/connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/config/esp32/components/chip /home/csir/esp/esp-idf/components/cmock /home/csir/esp/esp-idf/components/coap /home/csir/esp/esp-idf/components/console /home/csir/esp/esp-idf/components/cxx /home/csir/esp/esp-idf/components/driver /home/csir/esp/esp-idf/components/efuse /home/csir/esp/esp-idf/components/esp-tls /home/csir/esp/esp-idf/components/esp32 /home/csir/connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/config/esp32/components/esp32_mbedtls /home/csir/esp/esp-idf/components/esp_adc_cal /home/csir/esp/esp-idf/components/esp_common /home/csir/esp/esp-idf/components/esp_eth /home/csir/esp/esp-idf/components/esp_event /home/csir/esp/esp-idf/components/esp_gdbstub /home/csir/esp/esp-idf/components/esp_hid /home/csir/esp/esp-idf/components/esp_http_client /home/csir/esp/esp-idf/components/esp_http_server /home/csir/esp/esp-idf/components/esp_https_ota /home/csir/esp/esp-idf/components/esp_https_server /home/csir/esp/esp-idf/components/esp_hw_support /home/csir/esp/esp-idf/components/esp_lcd /home/csir/esp/esp-idf/components/esp_local_ctrl /home/csir/esp/esp-idf/components/esp_netif /home/csir/esp/esp-idf/components/esp_phy /home/csir/esp/esp-idf/components/esp_pm /home/csir/esp/esp-idf/components/esp_ringbuf /home/csir/esp/esp-idf/components/esp_rom /home/csir/esp/esp-idf/components/esp_serial_slave_link /home/csir/esp/esp-idf/components/esp_system /home/csir/esp/esp-idf/components/esp_timer /home/csir/esp/esp-idf/components/esp_websocket_client /home/csir/esp/esp-idf/components/esp_wifi /home/csir/esp/esp-idf/components/espcoredump /home/csir/esp/esp-idf/components/esptool_py /home/csir/esp/esp-idf/components/fatfs /home/csir/esp/esp-idf/components/freemodbus /home/csir/esp/esp-idf/components/freertos /home/csir/esp/esp-idf/components/hal /home/csir/esp/esp-idf/components/heap /home/csir/esp/esp-idf/components/http_parser /home/csir/esp/esp-idf/components/idf_test /home/csir/esp/esp-idf/components/ieee802154 /home/csir/esp/esp-idf/examples/common_components/iperf /home/csir/esp/esp-idf/components/json /home/csir/esp/esp-idf/examples/common_components/led_strip /home/csir/esp/esp-idf/components/log /home/csir/esp/esp-idf/components/lwip /home/csir/connectedhomeip/examples/all-clusters-app/esp32/main /home/csir/esp/esp-idf/components/mbedtls /home/csir/esp/esp-idf/components/mdns /home/csir/esp/esp-idf/components/mqtt /home/csir/esp/esp-idf/components/newlib /home/csir/esp/esp-idf/components/nvs_flash /home/csir/esp/esp-idf/components/openssl /home/csir/esp/esp-idf/components/openthread /home/csir/esp/esp-idf/components/partition_table /home/csir/esp/esp-idf/examples/common_components/pcap /home/csir/esp/esp-idf/components/perfmon /home/csir/esp/esp-idf/examples/common_components/pid_ctrl /home/csir/esp/esp-idf/components/protobuf-c /home/csir/esp/esp-idf/examples/common_components/protocol_examples_common /home/csir/esp/esp-idf/components/protocomm /home/csir/esp/esp-idf/components/pthread /home/csir/esp/esp-idf/examples/common_components/qrcode /home/csir/connectedhomeip/examples/common/screen-framework /home/csir/esp/esp-idf/components/sdmmc /home/csir/esp/esp-idf/components/soc /home/csir/esp/esp-idf/components/spi_flash /home/csir/connectedhomeip/examples/common/m5stack-tft/repo/components/spidriver /home/csir/esp/esp-idf/components/spiffs /home/csir/esp/esp-idf/components/tcp_transport /home/csir/esp/esp-idf/components/tcpip_adapter /home/csir/connectedhomeip/examples/common/m5stack-tft/repo/components/tft /home/csir/esp/esp-idf/components/tinyusb /home/csir/esp/esp-idf/components/ulp /home/csir/esp/esp-idf/components/unity /home/csir/esp/esp-idf/components/usb /home/csir/esp/esp-idf/components/vfs /home/csir/esp/esp-idf/components/wear_levelling /home/csir/esp/esp-idf/components/wifi_provisioning /home/csir/esp/esp-idf/components/wpa_supplicant /home/csir/esp/esp-idf/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build
[7/1126] Generating ../../partition_table/partition-table.bin
Partition table binary generated. Contents:
*******************************************************************************
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs,data,nvs,0x9000,24K,
otadata,data,ota,0xf000,8K,
phy_init,data,phy,0x11000,4K,
ota_0,app,ota_0,0x20000,1500K,
ota_1,app,ota_1,0x1a0000,1500K,
ot_storage,data,58,0x317000,8K,
*******************************************************************************
[261/1126] Performing configure step for 'bootloader'
-- Building ESP-IDF components for target esp32
-- Project sdkconfig file /home/csir/connectedhomeip/examples/all-clusters-app/esp32/sdkconfig
-- Adding linker script /home/csir/esp/esp-idf/components/soc/esp32/ld/esp32.peripherals.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.api.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script /home/csir/esp/esp-idf/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Adding linker script /home/csir/esp/esp-idf/components/bootloader/subproject/main/ld/esp32/bootloader.ld
-- Adding linker script /home/csir/esp/esp-idf/components/bootloader/subproject/main/ld/esp32/bootloader.rom.ld
-- Components: bootloader bootloader_support efuse esp32 esp_common esp_hw_support esp_rom esp_system esptool_py freertos hal log main micro-ecc newlib partition_table soc spi_flash xtensa
-- Component paths: /home/csir/esp/esp-idf/components/bootloader /home/csir/esp/esp-idf/components/bootloader_support /home/csir/esp/esp-idf/components/efuse /home/csir/esp/esp-idf/components/esp32 /home/csir/esp/esp-idf/components/esp_common /home/csir/esp/esp-idf/components/esp_hw_support /home/csir/esp/esp-idf/components/esp_rom /home/csir/esp/esp-idf/components/esp_system /home/csir/esp/esp-idf/components/esptool_py /home/csir/esp/esp-idf/components/freertos /home/csir/esp/esp-idf/components/hal /home/csir/esp/esp-idf/components/log /home/csir/esp/esp-idf/components/bootloader/subproject/main /home/csir/esp/esp-idf/components/bootloader/subproject/components/micro-ecc /home/csir/esp/esp-idf/components/newlib /home/csir/esp/esp-idf/components/partition_table /home/csir/esp/esp-idf/components/soc /home/csir/esp/esp-idf/components/spi_flash /home/csir/esp/esp-idf/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/bootloader
[270/1126] Performing build step for 'bootloader'
[1/1] cd /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/bootloader/esp-idf/esptool_py && /home/csir/.espressif/python_env/idf5.0_py3.8_env/bin/python /home/csir/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/bootloader/bootloader.bin
Bootloader binary size 0x6360 bytes. 0xca0 bytes (11%) free.
[585/1125] Performing configure step for 'chip_gn'
FAILED: esp-idf/chip/chip_gn-prefix/src/chip_gn-stamp/chip_gn-configure
cd /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/esp-idf/chip && /home/csir/depot_tools/gn --root=/home/csir/connectedhomeip/config/esp32 gen --check --fail-on-unused-args /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/esp-idf/chip && /usr/bin/cmake -E touch /home/csir/connectedhomeip/examples/all-clusters-app/esp32/build/esp-idf/chip/chip_gn-prefix/src/chip_gn-stamp/chip_gn-configure
gn.py: Could not find checkout in any parent of the current path.
This must be run inside a checkout.
[586/1125] Building C object esp-idf/esp_serial_slave_link/CMakeFiles/__idf_esp_serial_slave_link.dir/essl_spi.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
I can see that the problem is in the file ~/depot_tools/gn.py
with the line 50: bin_path = gclient_paths.GetBuildtoolsPlatformBinaryPath()
gclient_paths.GetBuildtoolsPlatformBinaryPath() returns "none"
what should the value be?
Some hours ago I had exactly the same problem.
In my case, I didn't run $ source ./scripts/bootstrap.sh because I didn't worked, but I clone the whole git again in my home folder, lauched the command and (after almost an hour) run idf.py set-target esp32 and idf.py build and it finally worked.
I followed more or less the following steps from this issue in Matter repo and it helped a lot:
https://github.com/project-chip/connectedhomeip/issues/15562#issuecomment-1057750597
Hope this works for you!

How to add header file to /usr/include in Yocto

I am working with Linux built with Yocto. I would like to add to the image my app to /bin and some header file to /usr/include. I have no problem with adding the app to /bin, but I am not able to add the header file to my rootfs. The .h file is added to a proper package, but it is not copied to rootfs.
Here is my recipe:
bindir = "${localdir}/bin"
incldir = "${localdir}/usr/include"
FILESEXTRAPATHS_prepend := "${THISDIR}/files/:"
SRC_URI = "file://My_app_dir/* \
\
"
S = "${WORKDIR}"
FILES_${PN} += "${incldir}/*"
do_compile() {
cd My_app_dir/src
make
}
do_install() {
install -d ${D}${bindir}
cp "${S}/My_app_dir/src/my_app" "${D}${bindir}/my_app"
install -d ${D}${incldir}
cp "${S}/My_app_dir/some_lib.h" "${D}${incldir}/some_lib.h"
}
After building the image, the include file exists in /build/tmp/work/<machine>/<my_app>/image/usr/include.
Do you have any idea why I cannot add .h file to /usr/include in rootfs? Thank you in advance for any help.
The header files (among other files like pkgconfig and shared library symlinks) are not added to the main package (say foo), but to the development package (e.g. foo-dev). This is called package split and you can learn more in the Package Splitting of the official documentation. The development packages (and BTW also the debug foo-dbg) are not installed by default.
But please be aware that adding the development package may pull other dependencies (because of various runtime dependencies) and files (there are other files in the development package).
Please note that your line FILES_${PN} += "${incldir}/*" has no effect, as the files in $includedir (i.e. FILES_${PN}-dev) are split before the FILES_${PN} are processed. The order is defined in the variable PACKAGES (check the official documentation).
BTW, there are minor things in the recipe which you can update (unrelated to your question though):
You can use location of standard system paths in the respective variables bindir, includedir etc.
install is preferred over the cp in do_install.
The line FILESEXTRAPATHS_prepend := "${THISDIR}/files/:" is needed only in bbappends. The files directory inside the recipe's directory is in the standard search path of files (among other paths like ${PN} etc.).

How to apply patch file of dtsi(or dts) in yocto

I'm using yocto(ver.rocko) on ubuntu 18.04 and trying to apply patch file but I can't...
My target machine is qemuarm64 and linux kernel is linux-yocto.
Once do $ bitbake core-image-base, kernel source files are unpacked then target dtsi file is located at poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.12-r0/linux-4.12/arch/arm64/boot/dts/arm/juno-base.dtsi
And my custom meta-data files to patch are below:
poky/meta-custom/recipes-kernel/linux/linux-yocto_4.12.bbappend
poky/meta-custom/recipes-kernel/linux/files/juno-base.dtsi.patch
# poky/meta-custom/recipes-kernel/linux/linux-yocto_4.12.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/files"
SRC_URI += "file://juno-base.dtsi.patch"
But after bitbake, patch file is created at poky/build/tmp/work/qemuarm64-poky-linux/linux-yocto/4.12.28+gitAUTOINC+2ae65226f6_e562267bae-r0/juno-base.dtsi.patch and patch-application doesn't work
I don't know what's wrong, what to do...
Plz let me know what should I do?
To create a simple patch for Yocto recipe sources, you can use git command in a simple way:
Your Linux work directory is:
poky/build/tmp/work/qemuarm64-poky-linux/linux-yocto/4.12.28+gitAUTOINC+2ae65226f6_e562267bae-r0
as you can see it is already a "git" directory which means that it is intialized with git already.
Here are clear steps for you to understand the method:
After adding your patch(juno-base.dtsi.patch) to SRC_URI I think your linux-yocto work directory is messed up, so follow me:
Clean the build
bitbake linux-yocto -c cleansstate
Remove the patch from SRC_URI
Apply any default patches
bitbake linux-yocto -c patch
Go to
poky/build/tmp/work/qemuarm64-poky-linux/linux-yocto/4.12.28+gitAUTOINC+2ae65226f6_e562267bae-r0
Make your modifications on
poky/build/tmp/work/qemuarm64-poky-linux/linux-yocto/4.12.28+gitAUTOINC+2ae65226f6_e562267bae-r0/arch/arm64/boot/dts/arm/juno-base.dtsi
and not in
poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.12-r0/linux-4.12/arch/arm64/boot/dts/arm/juno-base.dtsi
Now, open a terminal and change directory to
poky/build/tmp/work/qemuarm64-poky-linux/linux-yocto/4.12.28+gitAUTOINC+2ae65226f6_e562267bae-r0
Run: git status (You should see something like: modified arch/arm64/boot/dts/arm/juno-base.dtsi)
Run: git add arch/arm64/boot/dts/arm/juno-base.dtsi
Run: git commit -m "Patch for juni base dtsi"
Run: git format-patch -1
Now a new patch is created with the name "Patch-for-juni-base-dtsi.patch",
Now you can add it to linux-yocto_%.bbappend:
SRC_URI_append = " file://Patch-for-juni-base-dtsi.patch"
If the dtsi is not exist and you want to add it as a patch, do the same thing, when you run "git status" you will see a new added file, add it with "git add" and continue the commands.
After all of this, you can continue the build process with:
bitbake linux-yocto -C patch
Or, if you add the patch to SRC_URI the linux-yocto build will start from do_fetch.

Testing a Buildroot external package fails on a defconfig entry

I'm trying to add an br2-external package to a Buildroot build for a sama5d4_xplained board. I'm testing it using the utils/test-pkg utility and with every toolchain it fails on BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y, according to the missing.config file. It's an entry in the sama5d4_xplained_defconfig, which is used in the build.
I attempted to find what does the option mean in the manual and by googling, but any information is nowhere to be found. It doesn't seem to be related to the version of kernel headers installed on my machine, since my headers are 4.15.
The exact command used is:
./utils/test-pkg -c ../../config/sama5d4_xplained_defconfig -p {package}
The sama5d4_xplained_defconfig has the problematic entry:
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
logfile content:
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
What does this entry mean, and what do I do to fix the build problems?
You have to make a configuration file that enables just your package. With recent Buildroot, you can also use test-pkg -p <pkg> without -c option.
test-pkg will do a build-test of one or more packages with a collection of different toolchains (by default, a subset of the toolchains used for the autobuilders). The configuration file you supply with -c is supposed to select the package(s) that you want to test. Any toolchain that does not satisfy the dependencies of those packages will be skipped.
The board defconfigs (like sama5d4_xplained_defconfig) build a toolchain as part of their configuration. This toolchain always differs from the toolchains used in the autobuilders. Therefore, if you supply one of the defconfigs as the -c option, all toolchains will always be skipped.
However, if you are only interested in the sama5d4 Xplained board, there is no real need to use test-pkg to test your package with all toolchains. Just enable the package to a custom configuration.

How avoid recompile different targets in different paths using autotools?

I already could compile different targets or flavours(debug release), but the problem is when I make: make debug or make release this generate objects and the library in the respective folder folder.
This is the Makefile.am:
AM_CXXFLAGS = #AM_CXXFLAGS#
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
lib_LIBRARIES = libInitDB.a
libInitDB_a_SOURCES = \
InitDB.cpp
.PHONY: debug release
debug:
make CXXFLAGS='$(CXX_DEBUG_FLAGS) $(CXXFLAGS)'
mkdir -p $(DEBUG_DIR)
mv $(lib_LIBRARIES) $(DEBUG_DIR)/$(lib_LIBRARIES)
mv *.o $(DEBUG_DIR)
release:
make CXXFLAGS='$(CXX_RELEASE_FLAGS) $(CXXFLAGS)'
mkdir -p $(RELEASE_DIR)
mv $(lib_LIBRARIES) $(RELEASE_DIR)/$(lib_LIBRARIES)
mv *.o $(RELEASE_DIR)
but the problem is when I make: make debug or make release again, as I move the objects and the library, that generates again the objects and the library that already stored in the debug or release folder.
Could someone help me to find how to avoid this and when I compile that search in the correct folder?
Instead of having one Makefile generating both flavours of your targets, you could have two separate build directories configured with different options.
For example:
mkdir debug
(cd debug && ../configure --enable-debug)
mkdir release
(cd release && ../configure --enable-release)
This way, you can go to either directory and recompile only what is needed simply typing make.

Resources