Problems building tpu-mlir for Radxa Fogwise Airbox (TPU-MLIR build errors & Flux 1 Krea conversion)

Hello Radxa Community,

thank you for the Fogwise Airbox hardware.
I really appreciate the product and the documentation.
Also, thank you very much for the Fogwise® AIRbox Q900. I didn’t expect such a significant increase in performance.

I’m working on getting TPU-MLIR running to compile models for the Airbox, and I’ve hit multiple build issues that I’d like to ask for guidance on. I’ve been stuck on this for a while and feel like I’m missing something obvious. Perhaps the error lies with my environment.

Goal: Convert FLUX.1-Krea

I want to convert the model FLUX.1-Krea (Hugging Face: https://huggingface.co/black-forest-labs/FLUX.1-Krea-dev) to run on the Radxa Fogwise Airbox using the TPU-MLIR toolchain described here:
https://docs.radxa.com/en/sophon/airbox/model-compile/tpu_mlir_env

Also, the docs mention Flux model conversion as TODO:
https://docs.radxa.com/en/sophon/airbox/local-ai-deploy/text-to-image/flux_1

There is no step-by-step guide for Flux models. I would greatly appreciate any guidance or example conversion commands.
As I understand it, the conversion should be possible, since only the LoRA parts in Flux 1 Krea differ from Flux 1 Dev.

Environment & setup

  • Host: Windows 11 (using Docker Desktop)
  • Docker image used: sophgo/tpuc_dev:latest (running inside WSL2 Docker)
  • Cloned repo: https://github.com/sophgo/tpu-mlir
  • CMake: 3.25.x (from container)
  • Compilers seen during build: clang 14 (container image), gcc 11 (used when using Unix Makefiles)
  • Tried both Ninja and Unix Makefiles (Ninja had a lexing error with this container; switching to Unix Makefiles avoided that specific issue)

What I tried (summary)

  1. Cloned sophgo/tpu-mlir
  2. Fixed Windows CRLF problems.
  3. Ninja produced ninja: error: build.ninja:37: lexing error in this image; switching to cmake -G "Unix Makefiles" helped get past that.
  4. Several missing directories/files were created as a workaround to continue the build:
    • mkdir -p /usr/local/python/debugger (to allow generated bmodel python output)
    • Created a small stub /usr/local/python/utils/tpuc_cmd_builder.py because the builder script attempted to write/read it and failed in the container image.
  5. Many C++ warnings were being treated as errors (-Werror), and several third-party files (e.g. cnpy) required exception support (-fexceptions) or suppression of specific warnings. I adjusted CMake flags and added local patches to:
    • add -fexceptions
    • add -Wno-error / -Wno-unused-variable / -Wno-return-type for problematic targets
  6. Changed a naming conflict in include/tpu_mlir/.../LayerGroupDefs.h where a variable had the same name as a class; renamed the variable to avoid compile error.

Current state & blocking errors

After many fixes we are further but still blocked by the following build errors (examples copied from the build log):

  1. Missing python utility generation (I already worked around this by creating a stub file):

2025-10-12 05:53:14.394 | ERROR    | **main**:generate_builder:195 - Generation failed: [Errno 2] No such file or directory: '/usr/local/python/utils/tpuc_cmd_builder.py'
FileNotFoundError: [Errno 2] No such file or directory: '/usr/local/python/utils/tpuc_cmd_builder.py'

  1. Exception-handling disabled in some translation units (e.g. cnpy and other code using throw or catch):

/workspace/tpu-mlir/third_party/cnpy/cnpy.cpp:163:66: error: exception handling disabled, use ‘-fexceptions’ to enable
163 |         throw std::runtime_error("parse_npy_header: failed fread");

  1. Later in the build a std::bad_variant_access catch fails due to exceptions disabled in RewriterConfigUtils.cpp:

/workspace/tpu-mlir/lib/Support/RewriterConfigUtils.cpp:215:5: error: exception handling disabled, use ‘-fexceptions’ to enable
215 |   } catch (const std::bad_variant_access &) {
|     ^~~~~

I tried forcing -fexceptions and -Wno-error via:

cmake .. -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CXX_FLAGS="-O2 -fPIC -fexceptions -Wno-error -Wno-unused-variable -Wno-return-type"

and also added CMake-level add_compile_options(-fexceptions -Wno-error ...), but the build still surfaces files that appear to be compiled without exception support — this suggests some targets or third-party CMakeLists may explicitly set flags that override mine, or there are compile rules that need per-target fixes.

My Questions

  1. Is there an officially recommended branch/commit/tag of tpu-mlir that Radxa uses and verifies for the Fogwise Airbox environment?

  2. Is there any prebuilt toolchain ? (That would tremendously speed things up).

  3. Flux 1 Krea conversion guide: The docs mention Flux but the page is TODO — is there an internal / example workflow for converting Flux/FLUX.1 models to the Radxa/Tpu-mlir pipeline? Specifically:

Thank you very much for your help and support.

Best regards,
Matthias

Hi Matthias,

For Q1 & Q2:
You don’t need to build TPU-MLIR manually — it should be used within the Docker environment.
Please refer to this guide to configure the TPU-MLIR environment.
After entering the sophgo/tpuc_dev:latest Docker container, simply run the following command to install TPU-MLIR:

pip3 install tpu_mlir

This will install the stable v1.2.3 release of TPU-MLIR, and you can start using it right after installation.

For Q3:
We haven’t uploaded the conversion guide yet, but it will be available soon.

Best regards,
Morgan

Hi Morgan,

Thank you very much for your quick help! I’ve got the environment up and running now. I probably should have checked GitHub directly first, as it might have been clearer from the start.

I have a couple of follow-up questions, but they relate to other Radxa AI products and are therefore a bit off-topic.

  • Radxa AICore AX-M1 VPU Offloading
    My Radxa AICore AX-M1 is set to arrive in the next few days. I’m very interested not only in its AI performance but also in its promising VPU capabilities. My question is: Can the video decoding functions of the AICore be used directly from a host system (in my case, an RK3588-based board), preferably with FFmpeg? While the RK3588’s native VPU is already excellent, offloading this task would be a very interesting use case for me. So far, I’ve only found these instructions, but they seem to describe running Linux and FFmpeg on the AICore itself, rather than using it as an accelerator from a host.

  • Radxa Rock 5 & RKLLM Roadmap
    Are you familiar with the product roadmap for RKLLM? Specifically, I’m wondering if there are plans to add support for Mixture of Experts (MoE) models. That would be a great addition to the many Rock5b boards I have lying around :slight_smile:

  • Future Fogwise® AIRbox Q900 Revisions
    I recently saw the announcement for the Radxa O6N, which features 45 TOPS. This is a significant upgrade compared to my Radxa Orion O6 (64 GB RAM model) that I purchased mid-year. This leads me to ask about the Fogwise® AIRbox Q900: Are there any plans for a hardware revision with more RAM or higher TOPS performance in the near future? I’m hesitant to purchase the release version if a more powerful model is expected to be released shortly after.

Thanks in advance for any insights you can provide!

And I would like to express my gratitude once again for the great Radxa products. Many projects would simply not be possible for me without the Radxa products.

Best regards,
Matthias

Hi Matthias,

We really appreciate that you’ve successfully set up your TPU-MLIR environment.

Regarding your further questions:

  • Q1: Yes, you can still use the video decoding capability from the host. The axcl_ffmpeg binary is located at /usr/bin/axcl/ffmpeg . and need to configure the LD_LIBRARY_PATH . If you don’t modify it, the default FFmpeg from the host system will still be used.
  • Q2: The RKLLM EXPERT_MOE_FF setting is not yet exposed in the latest release for custom model conversion.
  • Q3: Let’s check with @Jack on this one.

Best,
Morgan

Hi Morgan,

That’s fantastic news regarding both the VPU offloading and the status of RKLLM MoE support! Thank you for the quick and clear answers.

Perfect, thank you for forwarding the question about the Airbox. I’ll look forward to hearing from @Jack.

On a related note, I’m quite happy with my Orion O6. It has been very well-suited for my needs, especially as a development machine for programming, even though the AI stack was in a very early stage the last time I checked. The new O6N looks very interesting as well, so I’ll be keeping an eye on it.

Fun fact: I noticed that Qwen3-VL is already available for the Fogwise Airbox, while on Ollama, it’s still cloud-only. That’s very impressive!

Best regards,
Matthias