This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Compile pc-ble-driver-py for arm (just compile pc-ble-driver-py and not the driver itself)

Hello,

I am trying to install the pc-ble-driver-py for my buildroot arm-board.

After some struggle I was able to compile the pc-ble-driver for it, however the python tool for it "pc-ble-driver-py" gives me some headache now.

For some reason pc-ble-driver-py builds its own drivers, which basically will be the false in the buildroot toolchain. (ERROR: architecture for "/usr/lib/python3.8/site-packages/pc_ble_driver_py/lib/_nrf_ble_driver_sd_api_v5.so" is "Advanced Micro Devices X86-64", should be "ARM") Although I dont want to use these anyways since I have my already compiled driver... Is there a way I can tell pc-ble-driver-py to stop compiling this pc-ble-drivers and just prepare the python tools and use the precompiled drivers instead?

I already tried to just delete the wrong drivers after the building process... sadly the program is to clever at that point and just rebuilds the wrong drivers...

EDIT: pc-ble-driver version: 4.1.2
         pc-ble-diver-py version: 0.14.2

Regards

F

Parents
  • I've tested the pc-ble-driver and the pc-ble-driver-py using nrfutil and it seems to work. Flashing a firmware with it worked. Still I cant stop pc-ble-driver-py to build the wrong drivers... someone got ideas how? The issue I have is that python scikit build is used which uses multiple other libraries (cmake-ninja, python extensions, python) and I dont know how to trick/tell pc-ble-driver-py to not build these wrong drivers...

  • Hi,

    Poteis said:
    Still I cant stop pc-ble-driver-py to build the wrong drivers...

    It is a bit unclear to me when this happens. When compiling or installing pc-ble-driver-py, when trying to run a pc-ble-driver-py project, or are you compiling a pc-ble-driver-py project into an executable? Other?

    I have had a chat with one of our developers. Assuming that you are cross compiling, you can try the following approach (although untested by us):

    1) Unset env variable VCPKG_ROOT
    2) Cross compile pc-ble-driver deps as you have already done
    3) Compile and install pc-ble-driver for ARM architecture (I'm assuming cross compilation on Intel platform to ARM), add flag -DCMAKE_INSTALL_PREFIX=<directory for RPI cross compiled binaries> and any other flags you use for cross compiling
    4) Run python setup.py bdist_wheel --build-type Release -- -DCMAKE_MODULE_PATH=<directory for RPI cross compiled binaries>/share/nrf-ble-driver <any other flags you use for cross compiling>

    I am sure we make a lot of assumptions here, so more info on your setup, toolchains, what build/install instructions you follow, etc. would help if the above does not lead you in the right direction.

    Regards,
    Terje

  • Hey Terje,

    Thank your for your reply!
    Tried the steps but they haven't effected the out coming drivers. They still are for x86_64 and not ARM.

    It already was quiet some work to "simply" cross compile the pc-ble-driver for ARM, as vcpkg isnt suited for ARM very well, and even less for cross compilation. My target with pc-ble-driver-py is to just obtain the cross compiled .py files. The .so files arent needed at all. I am not too sure what information could be of help so I may try to explain a "bit" more:

    Downloaded the latest git version and build it into our buildroot toolchain (ARMv7). My PC is running with x86_64 Arch Linux. Buildroot than simply executes the setup.py with its toolchain:

    (cd /buildroot/buildroot-2019.02.8.1/output/build/python-pc-ble-driver-py-0.14.2//; _PYTHON_SYSCONFIGDATA_NAME="" PATH="buildroot/buildroot-2019.02.8.1/output/host/binbuildroot/buildroot-2019.02.8.1/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl" PYTHONPATH="/buildroot/buildroot-2019.02.8.1/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/lib/python3.8/" PYTHONNOUSERSITE=1 _python_sysroot=/buildroot/buildroot-2019.02.8.1/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot _python_prefix=/usr _python_exec_prefix=/usr  /buildroot//buildroot-2019.02.8.1/output/host/bin/python setup.py build  -Dnrf-ble-driver_DIR:PATH="/buildroot/buildroot-2019.02.8.1/output/host/usr/share/vcpkg/installed/arm-linux/share/nrf-ble-driver")

    Builds all elements, with a lot of magic thanks to all those different builders (scikit, python, cmake (ninja) and make) that pc-ble-driver-py uses, where I couldn't find out how to stop the .so-element building process.

    The reason I want to get rid of these is that  buildroot runs into the following issue:

    ... (copying files)
    running install_egg_info
    running egg_info
    creating pc_ble_driver_py.egg-info
    writing pc_ble_driver_py.egg-info/PKG-INFO
    writing dependency_links to pc_ble_driver_py.egg-info/dependency_links.txt
    writing requirements to pc_ble_driver_py.egg-info/requires.txt
    writing top-level names to pc_ble_driver_py.egg-info/top_level.txt
    writing manifest file 'pc_ble_driver_py.egg-info/SOURCES.txt'
    reading manifest file 'pc_ble_driver_py.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no previously-included files matching '__pycache__' found under directory '*'
    warning: no previously-included files matching '*.py[co]' found under directory '*'
    writing manifest file 'pc_ble_driver_py.egg-info/SOURCES.txt'
    Copying pc_ble_driver_py.egg-info to /buildroot/buildroot-2019.02.8.1/output/target/usr/lib/python3.8/site-packages/pc_ble_driver_py-0.14.2-py3.8.egg-info
    running install_scripts
    copied 0 files
    ERROR: architecture for "/usr/lib/python3.8/site-packages/pc_ble_driver_py/lib/_nrf_ble_driver_sd_api_v2.so" is "Advanced Micro Devices X86-64", should be "ARM"
    ERROR: architecture for "/usr/lib/python3.8/site-packages/pc_ble_driver_py/lib/_nrf_ble_driver_sd_api_v5.so" is "Advanced Micro Devices X86-64", should be "ARM"
    make: *** [package/pkg-generic.mk:340: /buildroot/buildroot-2019.02.8.1/output/build/python-pc-ble-driver-py-0.14.2/.stamp_target_installed] Fehler 1

    The python-pc-ble-driver-py.mk

    ################################################################################
    #
    # python-pc-ble-driver-py
    #
    ################################################################################
    
    PYTHON_PC_BLE_DRIVER_PY_VERSION = 0.14.2
    PYTHON_PC_BLE_DRIVER_PY_SOURCE = pc_ble_driver_py-$(PYTHON_PC_BLE_DRIVER_PY_VERSION).tar.gz
    PYTHON_PC_BLE_DRIVER_PY_SITE = $(call github,NordicSemiconductor,pc-ble-driver-py,v$(PYTHON_PC_BLE_DRIVER_PY_VERSION))
    PYTHON_PC_BLE_DRIVER_PY_LICENSE = Other/Proprietary License (Modified BSD License)
    PYTHON_PC_BLE_DRIVER_PY_DEPENDENCIES = host-python-scikit-build host-python-packaging host-python-wheel host-python-pyparsing host-python-distro pc-ble-driver
    PYTHON_PC_BLE_DRIVER_PY_SETUP_TYPE = setuptools
    PYTHON_PC_BLE_DRIVER_PY_BUILD_OPTS +=-Dnrf-ble-driver_DIR:PATH="$(HOST_DIR)/usr/share/vcpkg/installed/arm-linux/share/nrf-ble-driver"
    $(eval $(python-package))
    
    

  • The chip that is used on the board is the nRF52840 and should be used to update other bluetooth devices through nrfutil. We use a better patched buildroot version (2019.11) now. With changing the buildroot version I somehow ran into a new issue which only occures on the newer version but not on the before tested 2019.02:

    --------------------------------
    -- Trying "Ninja" generator - success
    --------------------------------------------------------------------------------

    Configuring Project
      Working directory:
        /buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/_skbuild/linux-x86_64-3.8/cmake-build
      Command:
        cmake /buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2 -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/_skbuild/linux-x86_64-3.8/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/buildroot/buildroot-2019.02.11.1/output/host/bin/python -DPYTHON_VERSION_STRING:STRING=3.8.2 -DPYTHON_INCLUDE_DIR:PATH=/buildroot/buildroot-2019.02.11.1/output/host/include/python3.8 -DPYTHON_LIBRARY:FILEPATH=/buildroot/buildroot-2019.02.11.1/output/host/lib/libpython3.8.so -DSKBUILD:BOOL=TRUE -DCMAKE_MODULE_PATH:PATH=/buildroot/buildroot-2019.02.11.1/output/host/lib/python3.8/site-packages/skbuild/resources/cmake -Dnrf-ble-driver_DIR:PATH=/buildroot/buildroot-2019.02.11.1/output/host/usr/share/vcpkg/installed/arm-linux/share/nrf-ble-driver -DCMAKE_BUILD_TYPE:STRING=Release

    CMake Error at CMakeLists.txt:29 (find_package):
      Could not find a configuration file for package "nrf-ble-driver" that is
      compatible with requested version "4.1.1".

      The following configuration files were considered but not accepted:

        /buildroot/buildroot-2019.02.11.1/output/host/usr/share/vcpkg/installed/arm-linux/share/nrf-ble-driver/nrf-ble-driverConfig.cmake, version: 4.1.1 (64bit)



    -- Configuring incomplete, errors occurred!
    See also "/buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/_skbuild/linux-x86_64-3.8/cmake-build/CMakeFiles/CMakeOutput.log".
    Traceback (most recent call last):
      File "/buildroot/buildroot-2019.02.11.1/output/host/lib/python3.8/site-packages/skbuild/setuptools_wrap.py", line 582, in setup
        env = cmkr.configure(cmake_args,
      File "/buildroot/buildroot-2019.02.11.1/output/host/lib/python3.8/site-packages/skbuild/cmaker.py", line 229, in configure
        raise SKBuildError(

    An error occurred while configuring with CMake.
      Command:
        cmake /buildroot/dimm/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2 -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/_skbuild/linux-x86_64-3.8/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/buildroot/buildroot-2019.02.11.1/output/host/bin/python -DPYTHON_VERSION_STRING:STRING=3.8.2 -DPYTHON_INCLUDE_DIR:PATH=/buildroot/buildroot-2019.02.11.1/output/host/include/python3.8 -DPYTHON_LIBRARY:FILEPATH=/buildroot/buildroot-2019.02.11.1/output/host/lib/libpython3.8.so -DSKBUILD:BOOL=TRUE -DCMAKE_MODULE_PATH:PATH=/buildroot/buildroot-2019.02.11.1/output/host/lib/python3.8/site-packages/skbuild/resources/cmake -Dnrf-ble-driver_DIR:PATH=/buildroot/buildroot-2019.02.11.1/output/host/usr/share/vcpkg/installed/arm-linux/share/nrf-ble-driver -DCMAKE_BUILD_TYPE:STRING=Release
      Source directory:
        /buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2
      Working directory:
        /buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/_skbuild/linux-x86_64-3.8/cmake-build
    Please see CMake's output for more information.
    make: *** [package/pkg-generic.mk:255: /buildroot/buildroot-2019.02.11.1/output/build/python-pc-ble-driver-py-0.14.2/.stamp_built] Fehler 1

    Anyone got an idea why cmake got an issue with the nrf-ble-driverConfig.cmake here? I already replaced it with the "arm-linux" one from buildroot-2019.02 sadly with the same outcome. (Its the same cmake version: 3.18.1 and ninja version: 1.10.0)

  • Hi,

    I am afraid we do not have much further advice. This is an area that we have not been looking into previously, and it seems to be more of a general cross compile issue related to skbuild/cmake and correctly setting up a cmake toolchain. I recommend consulting e.g. the cmake documentation, and/or use support channels / forums dedicated to the toolchains, for how to set up existing projects for cross compilation. There are other resources better suited for getting help, when things go sufficiently far from our officially supported platforms.

    Regards,
    Terje

Reply
  • Hi,

    I am afraid we do not have much further advice. This is an area that we have not been looking into previously, and it seems to be more of a general cross compile issue related to skbuild/cmake and correctly setting up a cmake toolchain. I recommend consulting e.g. the cmake documentation, and/or use support channels / forums dedicated to the toolchains, for how to set up existing projects for cross compilation. There are other resources better suited for getting help, when things go sufficiently far from our officially supported platforms.

    Regards,
    Terje

Children
No Data
Related