[RV1106] How to install a RKNN v6-compatible runtime on the official Luckfox Buildroot (SD image)

  • olivier wrote: 2025-11-02 13:12 Hi everyone,
    I’m currently working on several AI models (YOLOv8 / ReXNet / MobileNet) that I convert using rknn-toolkit2 v2.2 and v2.3, which generate RKNN v6 models.
    However, on my Luckfox Pico Max (RV1106) running the official Buildroot SD image (SDK 1.3), the default runtime only supports RKNN v5.
    When trying to load v6 models, I get this error:
    E RKNN: incompatible model version (expected v5, got v6)
    🔍 Goal
    I’d like to:
    Update only the RKNN runtime on the official Buildroot (SD-based image)
    so that it can run RKNN v6 models,
    without having to rebuild a build root image.

    ❓ Questions :
    Is there a runtime package (v1.9 or v2.0) that supports RKNN v6 and can be installed manually on the Buildroot SD image?

    If yes, which files exactly should be replaced?

    (e.g. /usr/lib/librknn_api.so, /lib/firmware/npucode.bin, etc.)

    Does Luckfox plan to release a new Buildroot SDK (1.4 or 2.0) including the updated runtime?

    If rebuilding the SDK is required, which Git branch or menuconfig option should be enabled to include rknn_runtime v1.9+?

    💡 Final goal
    Run models exported with rknn-toolkit2 v2.3.2 (RKNN v6 format)
    on the Luckfox Pico Max without losing camera / ISP / network compatibility from the current official SD image.

    Thanks in advance to the Luckfox and Rockchip teams —
    and to anyone who already migrated the runtime from RKNN v5 → v6 on the RV1106 platform 🙏

    Olivier Q.
    AI & Embedded Vision Engineer – ODC
    I have successfully ported YOLO11 to my own Python library. I used a development board that I designed myself, with the firmware from Luckfox-Pico-Pro-Max, and didn't encounter the issues you mentioned. Regarding the Pro-Max firmware, the pre-installed version of librknnmrt.so is 1.6.0 (located in the /oem/usr/lib folder). You might try downloading the latest version of librknnmrt.so (2.3.2) to replace the factory version.https://github.com/airockchip/rknn_mode ... rknnmrt.so
  • Still getting ‘E RKNN: incompatible model version: 6’ — tested with every Toolkit (1.6 → 2.3.2), nothing works!”
    Hi everyone,
    I’m posting this after days of testing and debugging, trying to convert ONNX models to RKNN for the RV1106 / Luckfox Pico platform — and honestly, I’m out of ideas at this point.
    I’ve tested every possible RKNN Toolkit version:
    rknn-toolkit2 v1.6.0 (from the official Rockchip SDK)
    rknn-toolkit2 v2.1.0
    rknn-toolkit2 v2.2.0
    rknn-toolkit2 v2.3.2
    Every single time, the conversion process completes successfully:
    ✅ RKNN model exported successfully
    But when I run the model on the board (Luckfox Pico, official firmware, runtime 1.6), I always get this error:
    E RKNN: incompatible model version: 6
    rknn_init fail! ret=-1
    It happens no matter which model I use — YOLOv5, YOLOv8, YOLOv11, RetinaFace, RexNet — or which conversion script I run.
    I’ve tried forcing the config with:
    model_type='rknn_v5'
    enable_model_version='RKNN_MODEL_VERSION_V5'
    target_platform='rv1106'
    and multiple variants of the official convert.py and my own convert2.py scripts
    Nothing helps...

    The runtime on the Luckfox board (librknnrt.so) is clearly limited to V5, meaning it’s literally impossible to run any model generated by newer toolkits, even when using Toolkit 1.6!

    Can someone please clarify this mess once and for all:

    Which toolkit version is the last one that can generate RKNN_MODEL_VERSION_V5 models for RV1106?

    Is there any way to update the runtime (librknnrt.so) on the board to support V6 models?

    And why does the toolkit labeled 1.6.0 still output model version 6?

    I’ve tested everything — different platforms, toolkits, and configs — and it’s getting ridiculous to spin in circles with no combination working on the official runtime.
    Please, I need a definitive answer on this version mismatch issue.
    Thanks,
    Olivier
  • Wow, that’s impressive — you even designed your own RV1106-based board! 🔥

    You’re clearly on another level 👏

    I’m really curious about your setup, because I’ve been stuck for days with this issue.
    You mentioned that you successfully ported YOLO11 on your board using the Luckfox Pico Pro Max firmware (which includes librknnmrt.so version 1.6.0), without getting the “incompatible model version: 6” error.

    Could you please share a few details about your conversion process?
    Which RKNN toolkit version did you use — the old rknn-toolkit 1.x, or rknn-toolkit2 (v2.x)?
    What Python version and OS?

    And if possible, your conversion script or command line — especially the rknn.config() and rknn.build() settings.
    We’ve tried converting from ONNX with multiple toolkits (1.6.0, 2.1.0, 2.2.0, and 2.3.2), but all generate RKNN v6 models that fail on the factory runtime (1.6.0).
    If you managed to get YOLO11 running directly with the stock 1.6.0 runtime, that’s a huge breakthrough — it means you found a way to generate true RKNN v5 models still compatible with Luckfox’s firmware.
    Any details you can share would be greatly appreciated 🙏
  • olivier wrote: 2025-11-03 21:13 Wow, that’s impressive — you even designed your own RV1106-based board! 🔥

    You’re clearly on another level 👏

    I’m really curious about your setup, because I’ve been stuck for days with this issue.
    You mentioned that you successfully ported YOLO11 on your board using the Luckfox Pico Pro Max firmware (which includes librknnmrt.so version 1.6.0), without getting the “incompatible model version: 6” error.

    Could you please share a few details about your conversion process?
    Which RKNN toolkit version did you use — the old rknn-toolkit 1.x, or rknn-toolkit2 (v2.x)?
    What Python version and OS?

    And if possible, your conversion script or command line — especially the rknn.config() and rknn.build() settings.
    We’ve tried converting from ONNX with multiple toolkits (1.6.0, 2.1.0, 2.2.0, and 2.3.2), but all generate RKNN v6 models that fail on the factory runtime (1.6.0).
    If you managed to get YOLO11 running directly with the stock 1.6.0 runtime, that’s a huge breakthrough — it means you found a way to generate true RKNN v5 models still compatible with Luckfox’s firmware.
    Any details you can share would be greatly appreciated 🙏
    Actually, I have used both versions 1.6.0 and 2.3.2 (Python 3.8) of rknn-toolkit without making any modifications to convert.py, relying instead on the official repository at https://github.com/airockchip/rknn_model_zoo/. I converted YOLOv5 with version 1.6.0 and YOLO11 with version 2.3.2. Even for YOLO11, no errors occurred under the initial librknnmrt.so from version 1.6.0. I'm not sure if you have tried the Luckfox examples, but the YOLOv5 demo included there should run successfully: https://github.com/LuckfoxTECH/luckfox_ ... nn_example.

    Of course, if you'd like to try the Python library I developed, you can find the relevant content and download the attachments from the page at https://oshwhub.com/salieri_coin/visiong_se.
  • Hi Salieri,
    I tried to download your VisionG_SE attachments from OSHWHub but OSHWHub doesn’t accept non-Chinese phone numbers to subscribe.
    Would it be possible for you to share the files (especially librknnmrt.so, test_rknn.py, and the YOLOv11 model) via GitHub or Google Drive?
    I’d really like to test your runtime on my Luckfox Pico Max — I believe it’s the key to running my RKNN v6 models directly.
    Thanks a lot for your help and your amazing work 🙏
    — Olivier
  • olivier wrote: 2025-11-11 16:10 Hi Salieri,
    I tried to download your VisionG_SE attachments from OSHWHub but OSHWHub doesn’t accept non-Chinese phone numbers to subscribe.
    Would it be possible for you to share the files (especially librknnmrt.so, test_rknn.py, and the YOLOv11 model) via GitHub or Google Drive?
    I’d really like to test your runtime on my Luckfox Pico Max — I believe it’s the key to running my RKNN v6 models directly.
    Thanks a lot for your help and your amazing work 🙏
    — Olivier
    Currently, I have not added RTSP functionality. The default DisplayUDP directly transmits JPEG images. You can view them using the VSCode plugin I developed (vigide-0.0.6.vsix), or you can use the DisplayHTTP function to view them via a webpage (default address: http://board_ip:8080). All of this requires the RNDIS IP to be correctly configured. For details, refer to: https://wiki.luckfox.com/Luckfox-Pico-P ... in-windows. Additionally, here is the cloud storage link you requested: https://drive.google.com/drive/folders/ ... drive_link
  • Thanks a lot for your share !!

    I don't need the libra.so to get all working ?

    Thank so much for your help and your python lib !
  • Hi Salieri,
    I confirmed that visiong works perfectly (YOLOv11n, camera, NPU, Vigide handshake OK).
    The only blocking issue is that DisplayUDP destination IP is hardcoded to 172.32.0.100 in visiong.so.
    Even when setting:
    DISPLAY_UDP_IP=xxx.xxx.xxx.xxx
    DISPLAY_UDP_PORT=xxxx
    the runtime still prints:
    DisplayUDP initialized, ready to stream to 172.32.0.100:8000
    This works only over RNDIS USB, but I need to net my luckfox by ethernet in my box.
    Could you please:
    Allow overriding the DisplayUDP IP/port via environment variables, or
    Expose a Python API like DisplayUDP(ip, port), or
    Provide a build of visiong.so where the IP is not hardcoded.
    This would make visiong usable over standard Ethernet/Wi-Fi without RNDIS.
    Thanks again for your great work
  • olivier wrote: 2025-12-18 12:01 Hi Salieri,
    I confirmed that visiong works perfectly (YOLOv11n, camera, NPU, Vigide handshake OK).
    The only blocking issue is that DisplayUDP destination IP is hardcoded to 172.32.0.100 in visiong.so.
    Even when setting:
    DISPLAY_UDP_IP=xxx.xxx.xxx.xxx
    DISPLAY_UDP_PORT=xxxx
    the runtime still prints:
    DisplayUDP initialized, ready to stream to 172.32.0.100:8000
    This works only over RNDIS USB, but I need to net my luckfox by ethernet in my box.
    Could you please:
    Allow overriding the DisplayUDP IP/port via environment variables, or
    Expose a Python API like DisplayUDP(ip, port), or
    Provide a build of visiong.so where the IP is not hardcoded.
    This would make visiong usable over standard Ethernet/Wi-Fi without RNDIS.
    Thanks again for your great work
    In fact, all the features you mentioned have already been implemented. I previously forgot to upload the API documentation to the cloud drive, but I have now uploaded all the relevant content. You can download and review it here:
    https://drive.google.com/drive/folders/ ... drive_link
    (The documentation is in Chinese, so you may need to translate it.)
    Additionally, I recently optimized the visiong.so library to reduce its file size. This update also includes the previously ported versions of opencv-python and numpy. For further details, please refer to my earlier post:
    viewtopic.php?p=6957