Metis M.2 bricked two host systems...

Hey ​@moderately_disgruntled!

Oof, yeah, sorry to hear you've had such a rough start! Two systems down on day one is not fun. Let's see if we can get it back on its feet.

First, really good news to hear the mini PC isn't damaged. What you're describing there sounds a lot like that issue where the host hangs during boot while it tries to enumerate the card. The Metis requests a fairly large PCIe memory window (32MB on BAR2), and some BIOSes don’t like that. A couple of things usually sort it:

1. With the Metis installed, go into the BIOS and enable Above 4G Decoding (sometimes called "Above 4G MMIO" or similar) if it's available
2. If there's a Resizable BAR option, try that
3. Never hurts to check it’s the latest BIOS version for the system

The LattePanda is another matter... No power at all, fans spin but no display, or does it hang at the logo? If it powers up but won't POST, we might get lucky and find it’s just be stuck in a bad UEFI state from the failed boot attempt. LattePandas can be a bit precious about this. With the Metis removed, I don’t suppose a disconnect power, clear CMOS per the LattePanda docs, then reboot does anything? From what I’ve found online that can bring these boards back sometimes.

That being said, I completely get it if you're not keen to plug the card into a third system right now. I’d likely feel the same. If you'd rather have the card checked over before going any further, raise a ticket at support.axelera.ai and the team can arrange a return so it can be tested at this end. Better safe than sorry, and if there is a fault with the card, that's the best way for us all to find it.

Either way, let me know how you get on. 👍

Thanks for the reply! Yeah, I cleared the CMOS on LattePanda and it didn’t fix anything, unfortunately. The fans do come on and the power LED looks normal, it just seems like it won’t POST as you suggested. I will have to spend some time debugging it later on.

I actually did get the M.2 up and running on my Orange Pi 5 max with some manual DT modifications. The only issue I’m having with it now is that the compiler always fails with the same error when I use the inference.py script on a new model. For example,

./inference.py resnet18-imagenet usb:0

always gives me this error:

ERROR: only 0-dimensional arrays can be converted to Python scalars

ERROR: Failed to deploy network

(...) deploy.py returned non-zero exit status 1.

I wonder if I am doing something wrong or failing to provide a proper config to the compiler? This same error happened even for the yolov5-v7-onnx model that you suggest running as a first inference test in the docs. 

If I download the precompiled model using `axdownloadmodel`, it works fine. But I want to understand where compilation/deployment is going wrong when starting with ONNX format. Eventually, I will need to use my own custom models...

Thanks again!

That’s hopefully taken a turn for the better!

Metis running on an Orange Pi 5 Max with manual device tree modifications is great work. We know it runs great on the OPi5 Pro, so it’s cool to know the Max is viable too. If you'd ever be up for writing up those DT changes as a post here, it would be hugely valuable. Orange Pi + Metis is a really popular combo and I don't think anyone's documented the 5 Max specifically yet.

Anyway, glad the LattePanda is at least showing signs of life. Power and fans but no POST could yet mean it's recoverable, so fingers crossed for your debugging session. And the offer from my last reply still stands if you'd like the card checked over or returned via support.axelera.ai. 👍

There might be a clue here, in that you get the same failure on both resnet18-imagenet and yolov5, which are two completely different zoo models. Something in the compilation environment sounds like it’s unhappy, and it's failing in the quantisation step first. The precompiled models working fine backs that up, since those skip the compiler entirely.

That specific error ("only 0-dimensional arrays can be converted to Python scalars") is a numpy error, and one common cause is a numpy version the compiler doesn't expect, which can happen in hand-built environments on ARM64. But rather than guessing, let's get the actual failure point. Could you run Running the deploy step directly with verbose logging might give us more clues as to the exact point of failure:

./deploy.py resnet18-imagenet -v

And while you're in the venv, this too:

python -c "import numpy; print(numpy.__version__)"

With the full traceback we might be able to see which line is throwing, rather than just deploy.py's summary of the failure. Also useful: which SDK version you're on, and whether you installed with ./install.sh --all or assembled things more manually. 👍

One other option to keep in your back pocket is that if you have an x86 Ubuntu machine available, you can compile models there and copy the build output across to the Orange Pi, which sidesteps on-device compilation entirely. But that’s just a tip, not a necessity. 😁

The custom model tutorial will be your friend when you get to your own models, by the way: https://github.com/axelera-ai-hub/voyager-sdk/blob/release/v1.5/docs/tutorials/custom_model.md

Keep us posted!

SDK v1.7.0 is what I’m working with.

numpy version 2.5.1

torch version 2.12.1+cu130

I followed your Python pip installation instructions verbatim (in a fresh venv), including the installation of dependencies via the bash script provided in the repository (fresh clone). What should the numpy version be? Given what I read here, I figured my 2.5.1 installation should be fine. Thanks!

Howdy! Thanks for the details!

Let’s click through them in turn:

torch 2.12.1: I think you're fine here. The v1.7.0 release notes confirm "axelera-devkit now supports PyTorch versions 2.7–2.12." (Though might be worth checking the +cu130 tag matches your actual CUDA.)

NumPy 2.5.1: NumPy’s not my speciality, admittednly, but as I understand it, since you installed axelera-devkit[all] that's not what a clean install should give you. Those same release notes say:

axelera-devkit[all] still pins NumPy to < 2.0.0 … axelera-devkit supports only NumPy 1.x APIs and is not compatible with NumPy 2.x.

So on Linux I’d expect you to be seeing NumPy 1.x. Perhaps the pin didn't hold? ften scipy dragging NumPy up, which is a known v1.7.0 issue (module 'numpy' has no attribute 'long'), fixed with pip install "numpy<2.4".

If NumPy is 2.5.1 under devkit[all], are you able to try re-pinning it with pip install "numpy<2.0", to see if that does anything to help us?