Hi guys, i have a complete guide on how to get the NPU running with the fastrpc test pass.
DOKUMENTACJA TECHNICZNA INTEGRACJI
Piotr Osmałek
*Uruchomienie podsystemów NPU (CDSP),
GPU i VPU na platformie Radxa Dragon Q6A
System: Debian 13 (Trixie) | Architektura: Qualcomm QCS6490 / SC7280*
|
|
|----|
**Status Końcowy
Setupu:
**
Sukces operacyjny. Koprocesory
obliczeniowe Hexagon NPU (CDSP) oraz Audio (ADSP) zostały w pełni
zainicjalizowane w jądre systemu (remoteproc up). Wyeliminowano błędy
translacji SMMU oraz braki mikrokodów graficznych GMU. Surowy test
komunikacyjny FastRPC wykazuje pełną sprawność stosu (3/3 Passed, 0 Failed).
System jest w 100% gotowy do obsługi akceleracji detekcji AI w środowisku
Frigate NVR.
1. Istota Problemu i Stan Początkowy
Podczas wdrażania
zaawansowanej akceleracji lokalnej AI dla Frigate NVR na platformie Radxa
Dragon Q6A (opartej o SoC Qualcomm QCS6490 / SC7280) pod kontrolą dystrybucji
Debian 13 (Trixie), system napotkał krytyczną barierę na poziomie warstwy
abstrakcji sprzętowej (HAL). Oficjalne pakiety firmware dostarczane przez
repozytoria Radxa (bookworm/noble) okazały się niekompletne lub błędnie
zlinkowane strukturalnie.
Główne symptomy
awarii obejmowały:
·
Brak
mikrokodu GMU (Graphics Management Unit): Jądro zgłaszało błąd -2 (ENOENT)
podczas próby wczytania qcom/a660_gmu.bin, co paraliżowało układ graficzny
Adreno 643 oraz koprocesor wideo Venus.
·
Pętle zegarów
systemowych: Brak inicjalizacji GMU powodował zawieszenie kontrolera zasilania
jądra (gcc-sc7280) w nieskończonej pętli sync_state pending.
·
Blokada
sprzętowa SMMU (IOMMU): Po podrzuceniu pierwszych plików binarnych, jednostka
zarządzania pamięcią Qualcomma blokowała zapytania alokacyjne GPU, generując
lawinę błędów Translation Fault (FSR = 80000402).
·
Uszkodzona
struktura Remoteproc: Usunięcie uszkodzonych pakietów przez menedżer APT
pozostawiło w systemie zapętlone, ślepe linki symboliczne, w których pliki
adsp.mbn i cdsp.mbn wskazywały same na siebie, uniemożliwiając rozruch
koprocesorów.
2. Przełomowa Architektura Rozwiązania – Krok po Kroku
Krok 1:
Pozyskanie czystego firmware z CodeLinaro (CLO)
Kluczowym elementem
naprawy było porzucenie wadliwych repozytoriów producenta SBC i sięgnięcie
bezpośrednio do oficjalnych źródeł upstreamowych CodeLinaro (CLO) dedykowanych
dla platformy wideo QCM6490. Pobrano i podmieniono surowe, zweryfikowane pliki
binarne:
• a660_gmu.bin – Odpowiedzialny za mikrokod zarządzania energią grafiki.
• a660_zap.mbn – Odpowiedzialny za strefę zaufaną (TrustZone) i zabezpieczenia
GPU.
Krok 2:
Ominięcie restrykcji pamięciowych (SMMU Bypass)
Aby zmusić jednostkę
IOMMU do akceptowania żądań alokacji pamięci na wczesnym etapie bootowania
przez koprocesory Qualcomma, zmodyfikowano parametry startowe jądra. W pliku
/boot/armbianEnv.txt dopisano dyrektywę passthrough:
extraargs=iommu.passthrough=1
arm-smmu.disable_bypass=0
Krok 3:
Rekonstrukcja segmentów binarnych (Splitbins)
Sterownik podsystemu
Qualcomm PAS (qcom_q6v5_pas) wymaga pociętych na segmenty plików binarnych.
Usunięto wadliwe linki symboliczne i wgrano pełen komplet surowych splitbinów z
gałęzi budowania do właściwego katalogu jądra:
/lib/firmware/qcom/qcs6490/radxa/dragon-q6a/
Katalog został zasilony
pełnym zestawem plików nagłówkowych (.mdt/.mbn) oraz wszystkimi stowarzyszonymi
segmentami obliczeniowymi (adsp.b00, adsp.b01, adsp.b02… do cdsp.bXX).
Krok 4:
Wdrożenie modułów dynamicznych (Wytyczne Qualcomm)
Zgodnie z oficjalną
architekturą Qualcomm Linux, koprocesory sygnałowe wymagają runtime’u rejestru
usług. Utworzono dedykowane struktury katalogów i wdrożono pliki konfiguracyjne
JSON oraz biblioteki dynamiczne:
• /usr/lib/dsp/adsp/
• /usr/lib/dsp/cdsp/
3. Przepływ Komend Wdrożeniowych (Ściąga na Przyszłość)
Poniższy skrypt
reprezentuje kompletną i chronologiczną sekwencję komend, które doprowadziły
system do stanu pełnej sprawności. Służy jako oficjalna
instrukcja odtworzeniowa (Disaster Recovery):
|
|
|----|
# 1. Czyszczenie uszkodzonej struktury katalogów
cd /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/
sudo rm -f adsp.mbn adsp.mdt cdsp.mbn cdsp.mdt
2. Kopiowanie czystego firmware i kompletnych segmentów (splitbins)
sudo cp -r
/home/radxa/fastrpc/test/radxa-firmware/radxa-firmware-qcs6490/lib/firmware/qcom/qcm6490/*
\
/lib/firmware/qcom/qcs6490/radxa/dragon-q6a/
sudo cp -r
/home/radxa/fastrpc/test/radxa-firmware/radxa-firmware-qcs6490/lib/firmware/qcom/qcm6490/*
\
/lib/firmware/qcom/qcs6490/
3. Nadpisanie mikro kodu GMU sprawdzonymi binarami z CodeLinaro (CLO)
sudo wget -O /lib/firmware/qcom/a660_gmu.bin
" Making sure you're not a bot! "
sudo chmod 644 /lib/firmware/qcom/a660_gmu.bin
cd /lib/firmware/qcom/
sudo ln -sf a660_gmu.bin a663_gmu.bin
4. Wdrożenie sygnatur i rejestru usług dynamicznych DSP
sudo mkdir -p /usr/lib/dsp/adsp/ /usr/lib/dsp/cdsp/
sudo cp -v /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/*.jsn
/usr/lib/dsp/adsp/ 2>/dev/null || true
sudo cp -v /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/*.jsn
/usr/lib/dsp/cdsp/ 2>/dev/null || true
5. Konfiguracja bootloadera - Bypass SMMU
Należy dopisać do /etc/armbianEnv.txt lub /boot/armbianEnv.txt:
extraargs=iommu.passthrough=1 arm-smmu.disable_bypass=0
6. Krytyczna
regeneracja obrazu startowego RAM-dysku dla wszystkich jąder
sudo update-initramfs -u -k all
sudo reboot
4. Status Operacyjny Urządzeń (Bootlog Verification)
Po restarcie podsystemy
Qualcomm wstały w trybie natywnym, rezerwując odpowiednie przestrzenie adresowe
pamięci RAM i uruchamiając powiązane demony komunikacyjne za pośrednictwem
krawędzi GLINK:
|
|
|----|
[ 0.934571]
remoteproc remoteproc0: adsp is available
[ 0.946219] remoteproc remoteproc0:
powering up adsp
[ 0.947265] remoteproc remoteproc1:
cdsp is available
[ 0.953254] remoteproc remoteproc0:
Booting fw image qcom/qcs6490/radxa/dragon-q6a/adsp.mbn…
[ 0.957233] remoteproc remoteproc1:
powering up cdsp
[ 0.967938] remoteproc remoteproc1:
Booting fw image qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn…
[ 1.050116] remoteproc remoteproc1:
remote processor cdsp is now up
[ 1.050780] remoteproc remoteproc0:
remote processor adsp is now up
5. Kolejny Krok: Integracja z Frigate NVR (Docker Runtime)
Mając w pełni stabilną
warstwę sprzętową (Hardware Layer) oraz pomyślnie zaliczony test FastRPC,
kolejnym etapem rozwoju architektury jest konteneryzacja środowiska Frigate.
Aby kontener Docker miał dostęp do pełnej mocy 12 TOPS procesora Hexagon NPU, w
konfiguracji docker-compose.yml należy uwzględnić passthrough urządzeń
systemowych:
|
|
|----|
version: “3.9”
services:
frigate:
container_name: frigate
image:
privileged: true # Wymagane dla
niskopoziomowego dostępu RPC
devices:
- /dev/bus/usb
- /dev/ion:/dev/ion # Zarządzanie
pamięcią współdzieloną DMA
-
/dev/fastrpc-cdsp:/dev/fastrpc-cdsp # Interfejs obliczeniowy NPU
- /dev/video10:/dev/video10 #
Sprzętowy dekoder wideo Venus (H.264/H.265)
volumes:
- /usr/lib/dsp:/usr/lib/dsp:ro #
Mapowanie bibliotek i rejestru usług DSP
- /path/to/config:/config