Rockchip Linux 4.4 Camera: Fehlerbehebung

Plattformreferenz: Hersteller V1.0.1, RK3xxx; Linux 4.4+. Die vollständigen Kapitel behandeln Kameratreiber, Sensoranbindung, Erfassung und Fehlersuche. Konkrete ArmSoM-Board/BSP/SDK/Kernel-Kombinationen sind nicht validiert; Schaltplan, Schnittstellen, Versorgung/Takte, Treiber und IQ-Dateien prüfen. Beispiele/Messwerte stammen vom Hersteller, nicht von ArmSoM; keine Hardwarebefehle ausgeführt. ZH nutzt chinesische Originalbilder, EN/RU/DE englische.

ArmSoM Docs · Rockchip Linux

1. Sensor in Betrieb nehmen

1.1 Sensor-ID fehlt: I2C-Kommunikationsfehler

Wird die Sensor-ID nicht erkannt, führt die Quelle dies nicht auf RKISP/RKCIF, sondern auf die Einschaltsequenz zurück. In folgender Reihenfolge prüfen:

1. Stimmt die 7-Bit-i2c-slave-id? Wurde versehentlich eine 8-Bit-Adresse eingetragen?

1. Liegt 24M-mclk mit korrekter Spannungsamplitude an?

1. Entspricht die Einschaltfolge für avdd, dovdd, dvdd, power down, reset usw. den Vorgaben?

1.1.1 Was ist eine 7-Bit-Adresse?

Das niederwertigste Bit LSB der 8-Bit-Angabe bezeichnet R/W; die oberen sieben Bits sind die benötigte i2c slave id.

1.1.2 Nach dem Einschalten fehlen 24M-mclk und vdd

Der Treiber aktiviert Takt und Versorgung normalerweise nur bei Bedarf; nach dem Booten sind sie standardmäßig aus. Zum Messen kann die Implementierung von power_off() vorübergehend auskommentiert werden, damit die Versorgung eingeschaltet bleibt.

1.1.3 24M-mclk weiterhin nicht messbar

Die Oszilloskopbandbreite prüfen; die Quelle empfiehlt mindestens 48M.

1. Aktiviert der Sensor mclk nicht korrekt, die Taktoperationen in drivers/media/i2c/ov5695.c vergleichen.

1. Ein anderes Modul kann den GPIO belegen; normalerweise erscheint ein Hinweis im Kernel-Log. Mit io lassen sich pin-ctrl-Register prüfen.

1.1.4 mclk vorhanden, aber falsche Spannungsamplitude

Ursache ist eine falsche io-domains-Konfiguration. Üblich sind 1.8v oder

3.3v, abhängig vom Schaltplan. Schaltplan prüfen und io-domains entsprechend anpassen:

&io_domains {
    status = "okay";

    vccio1-supply = <&vcc1v8_soc>;
    vccio2-supply = <&vccio_sd>;
    vccio3-supply = <&vcc1v8_dvp>;
    vccio4-supply = <&vcc_3v0>;
    vccio5-supply = <&vcc_3v0>;
};

Im Beispiel wird vccio3 von vcc1v8_dvp versorgt. Seine Spannungsdomäne beträgt

1.8v; daher muss mclk ebenfalls 1.8v haben. io_domains kann beim Booten später als der Sensor initialisiert werden. Schlägt die ID-Abfrage fehl, probe erneut versuchen:

diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
index e0c608f..7842812 100644
--- a/drivers/media/i2c/ov7251.c
+++ b/drivers/media/i2c/ov7251.c
@@ -961,7 +961,8 @@ static int ov7251_check_sensor_id(struct ov7251 *ov7251,
                              OV7251_REG_VALUE_16BIT, &id);
        if (id != CHIP_ID) {
                dev_err(dev, "Unexpected sensor id(%06x), ret(%d)\n", id, ret);
-               return -ENODEV;
+               return -EPROBE_DEFER;
        }

Ist io_domains beim Sensorstart noch nicht initialisiert, gelten Standardwerte. Weichen diese von der realen Versorgung ab, stimmt mclk nicht. -EPROBE_DEFER lässt das System probe später erneut ausführen.

1.1.5 Einschaltsequenz des Sensors prüfen

Das Datasheet beschreibt Reihenfolge und Abstände der Versorgungsspannungen; mit dem Oszilloskop prüfen. Manche Sensoren wie ov5695 verlangen keine Reihenfolge für vdd und verwenden regulator_bulk. Andere wie ov2685.c benötigen getrennte Regler, etwa avdd_regulator und dovdd_regulator. Nach tatsächlichen Anforderungen auswählen.

1.2 Standardwerte exp_def, hts_def und vts_def

Werte beim Sensorhersteller erfragen oder Register und Initialisierungswerte im Datasheet bzw. Registersatz suchen. Beispiel ov2685.c:

#define OV2685_REG_VTS                  0x380e

...

        {0x380e, 0x05},
        {0x380f, 0x0e},

...

                .vts_def = 0x050e,

0x380e und 0x380f sind die vts-Register. Wird 0x050e initialisiert, ist vts_def=0x050e. exp und hts verwenden Standardwerte aus dem Datasheet. Soll die Anwendung Belichtung und Bildrate nicht ändern, sind exp, hts und vts unnötig; RAW-Sensoren benötigen sie normalerweise.

1.3 Werte für link_freq und pixel_rate

link_freq ist die reale MIPI-Taktfrequenz, nicht 24M-mclk, sondern MIPI dn/dp clk. Hersteller oder Datasheet prüfen. Der Wert ist normalerweise mindestens so groß wie das Ergebnis folgender Formel in Hz:

width * height * fps * bits_per_pixel / lanes / 2

Ist link_freq unbekannt, mit dem Oszilloskop messen. pixel_rate bezeichnet Pixel pro Sekunde und ergibt sich aus link_freq wie folgt:

link_freq * 2 * lanes / bits_per_pixel

1.4 Erfolgreichen Sensorstart bestätigen

Zuerst muss die Sensor-ID lesbar sein, also I2C fehlerfrei arbeiten. media-ctl -p -d /dev/media0 sollte Name, Auflösung und weitere Sensordaten anzeigen.

Beim Erfassen muss MIPI Daten ohne MIPI-/ISP-Fehler liefern und die Anwendung Frames empfangen.

1.5 Sensor-AVL

RGB-Sensor-AVL: https://redmine.rockchip.com.cn/projects/rockchip_camera_module_support_list/camera. Dort stehen Moduldaten. Für andere Sensoren, etwa YUV, im Kernel unter drivers/media/i2c suchen; laut Quelle wurden diese Treiber von Rockchip abgestimmt.

2. MIPI-/ISP-Fehler

Bei der ersten Sensorabstimmung treten häufig auf:

1. Keine Frames und keine ISP-/MIPI-Fehler.

1. Fortlaufende MIPI-Fehlermeldungen.

1. ISP meldet PIC_SIZE_ERROR.

1. Gelegentliche MIPI-Fehler.

1. MIPI-Fehler bis zum Systemabsturz.

2.1 Welche MIPI-Parameter einstellen?

Vier Parameter zwischen Sensor und ISP prüfen:

1. Sensor-Ausgabeauflösung.

1. Bildformat YUV oder RGB RAW und 8/10/12 Bit.

1. MIPI-Ausgangsfrequenz: Hier schreibt die Quelle ink_freq, sonst link_freq.

1. Anzahl der Sensor-MIPI-Lanes und richtige DTS-Konfiguration.

2.2 Keine Frames und keine ISP-/MIPI-Fehler

1. Kernel-Log prüfen, etwa mit dmesg | grep MIPI.

1. I2C-Lese-/Schreibfehler suchen. Fehlt die Registerkonfiguration, wurden Initialisierung und Ausgang eventuell nicht aktiviert.

1. MIPI-clk- und Datenleitungen messen. Fehlt ein Signal, Sensorinitialisierung und Hardware untersuchen.

1. Gibt es MIPI-Signal, aber weder Fehler noch Daten: Parameter aus §2.1 erneut prüfen; fehlerfreie I2C-Kommunikation und vollständige Registerinitialisierung sicherstellen. Erst s_stream() darf MIPI aktivieren; davor, insbesondere in s_power(), darf kein Signal anliegen. Der Empfänger ist vorher nicht bereit und kann den SOT-Protokollanfang verlieren. Sensor-clock-lane von continuous auf non-continuous umstellen.

2.3 MIPI-Fehler

2.3.1 MIPI-Fehlertabellen

Für RK3288/RK3399/RK3368:

Für RK3326/PX30/RK1808 gelten drei Fehlertabellen:

Typische Fehler werden nachfolgend erläutert.

2.3.2 SOT/SOT_SYNC-Fehler

SOT muss MIPI_D-PHY_Specification entsprechen. Für tiefere Analyse die PDF-Spezifikation heranziehen, insbesondere:

1. High-Speed Data Transmission — Hochgeschwindigkeits-Datenübertragung.

1. Start-of-Transmission Sequence — Übertragungsstartsequenz.

1. HS Data Transmission Burst — HS-Datenburst.

1. High-Speed Clock Transmission — Hochgeschwindigkeits-Taktübertragung.

1. Global Operation Timing Parameters — globale Zeitparameter. Lief der Sensor auf anderen Plattformen bereits, ist ein grundsätzlicher MIPI-Protokollverstoß unwahrscheinlich. Empfehlungen:

1. Beim Hersteller erfolgreichen MIPI-Datentransfer bestätigen lassen.

1. link_freq erneut prüfen: Ths-settle der SOT-Sequenz muss am Empfänger richtig eingestellt sein.

1. Bei mehreren Lanes mit dem Hersteller einen Ein-Lane-Test durchführen.

2.3.3 CRC/CheckSum(CS)- und ECC/ECC1/ECC2-Fehler

ECC- und CS-Fehler bedeuten unvollständige/fehlerhafte Übertragungsdaten. Empfehlungen:

1. Zuerst Hardware-Signale prüfen.

1. Bei mehreren Lanes eine Lane testen; unzureichende Synchronisation kann ECC verursachen.

2.3.4 ERR_PROTOCOL/ERR_F_BNDRY

Erwartetes EOT/SOT fehlt; beide müssen paarweise auftreten. Signalverlauf prüfen.

2.3.5 Frames vorhanden, aber gelegentliche MIPI-Fehler

Fehlertabellen beachten und Signalfehler hardwareseitig prüfen. Nur beim Aufnahmestart auftretende Fehler können von ungültigen MIPI-Signalen beim Einschalten stammen. Versuchen:

1. Vollständige Registerinitialisierung in s_power() verlegen: Der MIPI-Empfänger ignoriert zu diesem Zeitpunkt noch alle Daten.

1. Am Ende von s_power() den Ausgang mit stop_stream() ausschalten.

1. In start_stream() und stop_stream() ausschließlich MIPI-Ausgabe ein-/ausschalten.

2.3.6 Viele MIPI-Fehler bis zum Absturz

Dies kann der verschärfte Fall aus §2.3.5 sein: Ungültige Signale verursachen pegelgesteuerte Interrupts, einen Interrupt-Sturm und schließlich den Absturz. Maßnahmen aus §2.3.5 testen. Das englische „voltage interruptions“ wird gemäß der chinesischen Erklärung als pegelgesteuerte Interrupts wiedergegeben.

2.3.7 ISP PIC_SIZE_ERROR

Der ISP erhält nicht die erwartete Anzahl Zeilen/Spalten. Auflösung auf allen Stufen prüfen. Meldet bereits MIPI einen Fehler, zuerst diesen beheben. Prüfpunkte:

1. Ist die DDR-Frequenz zu niedrig? Fehlende Reaktionsgeschwindigkeit kann den Fehler verursachen. Bei maximaler Frequenz testen: echo performance > /sys/class/devfreq/dmc/governor.

1. Ist eine nachfolgende Stufe größer als die vorherige? media-ctl -p -d /dev/media0 zeigt die Topologie. Es muss Sensor == MIPI_DPHY >= isp_sd input >= isp_sd output gelten; ohne manuelle Änderung normalerweise erfüllt.

1. Gibt der Sensor die richtige Auflösung aus? Deklarierte Größe im Treiber verkleinern. Beispiel ov7251.c mit 640x480:

static const struct ov7251_mode supported_modes[] = {
        {
                .width = 640,
                .height = 480,

width/height etwa auf 320x240 reduzieren, ohne Register zu ändern; damit prüfen, ob die konfigurierte Größe die tatsächliche Sensorausgabe übersteigt.

static const struct ov7251_mode supported_modes[] = {
        {
                .width = 320,
                .height = 240,

3. Bilder erfassen

Dieses Kapitel behandelt typische Fragen zur Bilderfassung.

3.1 Aufnahmemethoden

RKISP/RKCIF unterstützen V4L2. Folgende Wege sind möglich:

1. v4l2-ctl aus v4l-utils. Bei der Fehlersuche zuerst damit die Bildausgabe prüfen. Das Werkzeug speichert Frames, dekodiert oder zeigt sie aber nicht. Zur Anzeige mplayer unter Ubuntu/Debian oder 7yuv unter Windows nutzen.

Details stehen in Rockchip_Developer_Guide_Linux_Camera_CN.pdf; außerdem v4l2-ctl –help.

1. qcamera aus dem Linux-SDK: Kamera-App auf dem Desktop öffnen, Videogerät wählen und Vorschau starten. Es handelt sich um ein Qt-Beispiel; für Produkte eine eigene Anwendung entwickeln.

1. GStreamer v4l2src erfasst /dev/video und zeigt die Bilder. Zuerst SDK-Skripte unter /rockchip_test/camera/ ansehen. Alte rkisp-/rkv4l2src-Plug-ins werden nicht mehr unterstützt; das normale v4l2src verwenden. Gründe: 3A muss nicht mehr in diesen Plug-ins angepasst werden (Kapitel 4), und die rkisp-V4L2-Schnittstelle ist standardkonformer.

1. Unter Debian können VLC und andere Open-Source-Werkzeuge genutzt werden. Nach apt-Installation zeigt folgender Befehl die Kamera:

vlc v4l2:///dev/video1:width=640:height=480

Berechtigung der Gruppe video oder root ist erforderlich.

3.2 Falsche Farben, zu dunkles oder helles Bild

Nach Sensortyp unterscheiden:

1. RAW RGB wie RGGB/BGGR benötigt funktionierendes 3A, siehe Kapitel 4. Läuft 3A, Dekodier-/Anzeigeformat und vertauschte UV-Komponenten prüfen.

1. Bei YUV oder RGB565/RGB888 läuft ISP im Bypass. Bei falscher Farbe Sensor-Ausgabeformat und UV-Reihenfolge prüfen; sind diese korrekt, den Sensorhersteller kontaktieren. Bei deutlich falscher Helligkeit ebenfalls den Hersteller fragen.

3.3 ISP-Topologie und media-ctl

RKISP/RKCIF können mehrere Sensoren zeitlich abwechselnd nutzen; RKISP bietet zudem mehrstufiges Cropping. Die Knoten bilden eine Topologie und lassen sich einzeln mit media-ctl konfigurieren. Details in Rockchip_Developer_Guide_Linux_Camera_CN.pdf.

3.3.1 Mehrere Sensoren an einem ISP

Nur zeitlich abwechselnder Betrieb ist möglich. Sensoren in DTS mit MIPI DPHY verbinden und über media-ctl umschalten.

3.4 Entsprechen RAW-Aufnahmen exakt dem Original?

Im RAW-Bypass (RGGB/BGGR) ist 8-Bit-Ausrichtung erforderlich; fehlende niederwertige Bits werden mit null ergänzt. Originale 8-/16-Bit-Bilder bleiben unverändert. Bei 10/12 Bit wird jeder Pixel unten auf 16 Bit aufgefüllt. Nur MP kann RAW ausgeben, SP nicht.

3.5 MP und SP gleichzeitig ausgeben

SP und MP können dasselbe Sensorbild unabhängig zuschneiden und umformatieren. Fähigkeiten siehe Rockchip_Developer_Guide_Linux_Camera_CN.pdf. Gleichzeitige Ausgabe ist nur bei RGB/YUV auf beiden Pfaden möglich. Gibt MP RAW aus, entfällt SP.

3.6 Vergrößerung durch ISP

Hardwareseitig vorhanden, aber nicht empfohlen und im Treiber standardmäßig deaktiviert.

3.7 Drehung durch ISP

Nicht unterstützt. Für Flip/Mirror zunächst die Sensorfunktion prüfen; dies ist am effizientesten. Andernfalls RGA nutzen: Code/Beispiele unter external/linux-rga/, Dokumentation unter docs/.

3.8 Graubild GREY aufnehmen

Bei YUV-Ausgabe des ISP oder Y8 des Sensors kann die Anwendung direkt V4L2_PIX_FMT_GREY (FourCC GREY) aufnehmen.

3.9 Unterstützte RGB-Formate

Nur SP unterstützt RGB: V4L2_PIX_FMT_XBGR32 und V4L2_PIX_FMT_RGB565. XBGR32 (FourCC XR24) enthält R/G/B/X; X ist immer 0. RGB888 beziehungsweise 24-Bit-Ausgabe wird nicht unterstützt.

3.10 Vorschau ohne Bildschirm

SDK external/uvc_app/ lässt das Board als UVC-Kamera auftreten. Beschreibung und Code im Verzeichnis beachten. Am PC wird es als USB-Kamera erkannt und kann Vorschau liefern.

3.11 SP und MP unterscheiden

Topologie mit media-ctl -p -d /dev/media0 anzeigen; bei mehreren Geräten /dev/media1 oder /dev/media2 versuchen. Auszug:

# media-ctl -p -d /dev/media0
...
- entity 2: rkisp1_mainpath (1 pad, 1 link)              //Means the entity is
MP(MainPath)
            type Node subtype V4L flags 0
            device node name /dev/video1                 //The corresponding
device node is/dev/video1
        pad0: Sink
                <- "rkisp1-isp-subdev":2 [ENABLED]

- entity 3: rkisp1_selfpath (1 pad, 1 link)              //Means the entity is
SP(SelfPath)
            type Node subtype V4L flags 0

            device node name /dev/video2                 //The corresponding
device node is/dev/video2
        pad0: Sink
                <- "rkisp1-isp-subdev":2 [ENABLED]
...

Fehlt media-ctl, kann über /sys/ gesucht werden:

# grep '' /sys/class/video4linux/video*/name
/sys/class/video4linux/video0/name:stream_cif
/sys/class/video4linux/video1/name:rkisp1_mainpath       # Corresponding MP
node/dev/video1
/sys/class/video4linux/video2/name:rkisp1_selfpath       # Corresponding SP
Node/dev/video2
/sys/class/video4linux/video3/name:rkisp1_rawpath
/sys/class/video4linux/video4/name:rkisp1_dmapath
/sys/class/video4linux/video5/name:rkisp1-statistics
/sys/class/video4linux/video6/name:rkisp1-input-params

4. 3A-Verarbeitung

RAW BAYER RGB wie RGGB/BGGR benötigt 3A und RKISP-Bildverarbeitung. Das Verfahren hängt von camera_engine_rkisp ab; eine aktuelle kompatible Version ist empfohlen. Modul in der Unterstützungsliste prüfen: Unterstützte Module haben XML unter external/camera_engine_rkisp/iqfiles/. Andernfalls Modul-Tuning über den geschäftlichen Herstellerkontakt anfragen.

4.1 Version von camera_engine_rkisp

1. Aus dem Quellcode:

  # grep CONFIG_CAM_ENGINE_LIB_VERSION interface/rkisp_dev_manager.h
  define CONFIG_CAM_ENGINE_LIB_VERSION "v2.2.0"           # The output v2.2.0 is
the version number of librkisp.so

1. Aus dem Laufzeit-Log:

  # persist_camera_engine_log=0x4000 rkisp_3A_server --mmedia=/dev/media1 | grep
"CAM ENGINE LIB VERSION"
        CAM ENGINE LIB VERSION IS v2.2.0                # The output v2.2.0 is
the version number of librkisp.so

Unter v2.2.0 ein Update auf v2.2.0 oder neuer erwägen.

4.1.1 Erforderliche rkisp-Kerneltreiberversion

camera_engine_rkisp stellt Anforderungen an den Kerneltreiber; rkisp muss ausreichend aktuell sein.

1. ISP-Version aus dem Kernelquellcode:

  # grep RKISP1_DRIVER_VERSION drivers/media/platform/rockchip/isp1/version.h
  define RKISP1_DRIVER_VERSION KERNEL_VERSION(0, 1, 0x5) # The output v0.1.5 is
the version number of the rkisp driver

1. ISP-Version aus dem Kernel-Log:

# dmesg  | grep "rkisp1 driver version"
[    0.867864] rkisp1 ff4a0000.rkisp1: rkisp1 driver version: v00.01.05

4.2 camera_engine_rkisp aktualisieren

Drei Teile:

1. Hauptcode unter external/camera_engine_rkisp separat mit git/repo aktualisieren, ohne die übrigen SDK-Verzeichnisse anzutasten.

1. Kernel passend zu camera_engine_rkisp aktualisieren. Benötigte rkisp-Version über git log dieses Verzeichnisses ermitteln. Beispiel:

# git log
commit e456a50a5524792d64dac384604d4136a697deac
Author: ZhongYichong <zyc@rock-chips.com>
Date:   Mon Jul 1 11:26:32 2019 +0800

    librkisp: v2.2.0

    (BY ZSQ: UPDATE v2.2.0 iq version: from v1.4.0 to v1.5.0)

    3A lib version:
      af:  v0.2.17
      awb: v0.0.e
      aec: v0.0.e
    iq version: v1.5.0
    iq magic version code: 706729

matched rkisp1 driver version:
  v0.1.5                 # The needed kernel driver version is v0.1.5

Change-Id: I3d2adb949dadec259b9ba587a3e3b2770a1c155d
Signed-off-by: ZhongYichong <zyc@rock-chips.com>
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>

1. Buildroot-Bauskript unter buildroot/package/rockchip/camera_engine_rkisp. Ist ein komplettes Buildroot-Update unpraktisch, nur dieses Verzeichnis aktualisieren.

4.3 Funktion von 3A prüfen

Nach Bestätigung von camera_engine_rkisp v2.2.0 oder neuer ein Bild erfassen und Farbe/Belichtung prüfen. Zusätzlich nach rkisp_3A_server im Hintergrund suchen:

# ps -ef | grep rkisp_3A_server
  706 root      9176 S    /usr/bin/rkisp_3A_server --mmedia=/dev/media1
  746 root      2408 S    grep rkisp_3A_server
# pidof rkisp_3A_server
706

Im Beispiel gehört PID 706 zu rkisp_3A_server.

4.3.1 rkisp_3A_server fehlt

1. /usr/bin/rkisp_3A_server prüfen. Fehlt die Datei, Version und Build von camera_engine_rkisp prüfen.

1. /var/log/syslog nach rkisp_3A-Fehlern durchsuchen, insbesondere fehlendem oder unpassendem Sensor-XML.

1. In einer Shell rkisp_3A_server –mmedia=/dev/media0 starten, das zu /dev/video passende media-Gerät wählen. In einer anderen Shell Bilder erfassen, um Serverfehler zu erhalten.

4.3.2 rkisp_3A_server starten

Im SDK startet /etc/init.d/S40rkisp_3A den Server im Hintergrund. Fehlt das Skript, camera_engine_rkisp und Buildroot-Paketbauskripte prüfen.

4.3.3 Name und Pfad der IQ-XML-Datei

Der Name hat drei Bestandteile:

1. Sensortyp, etwa ov5695 oder imx327.

1. Modulname aus DTS. RK3326/PX30-EVB-Beispiel: rockchip,camera-module-name = “TongJu”;

1. Objektivname aus DTS: rockchip,camera-module-lens-name = “CHT842-MD”; Daraus entsteht ov5695_TongJu_CHT842-MD.xml unter /etc/iqfiles/. Groß-/Kleinschreibung beachten.

4.4 Manuelle Belichtung

Zuerst rkisp_3A_server beenden, dann rkisp_demo.cpp oder den librkisp_api.so-Quellcode verwenden.

4.5 librkisp-Log aktivieren

Umgebungsvariable persist_camera_engine_log setzen. Bitbelegung:

bits:    23-20   19-16 15-12  11-8  7-4   3-0
module: [xcore]  [ISP] [AF]   [AWB] [AEC] [NO]

0: error
1: warning
2: info
3: verbose
4: debug

Beispiel: Debug für ISP und AWB:

# /etc/init.d/S40rkisp_3A stop
# export persist_camera_engine_log=0x040400
# /usr/bin/rkisp_3A_server --mmedia=/dev/media0

5. Anwendungsentwicklung

5.1 C-Beispiel

1. Das SDK enthält rkisp_demo samt Quellcode. Wie v4l2-ctl erfasst es Bilder, zeigt sie aber nicht; es dient vor allem als Codevorlage. Code unter external/camera_engine_rkisp/apps, bei älteren Versionen unter external/camera_engine_rkisp/tests.

1. SDK enthält rkisp_api.so samt Quellcode zum Anpassen oder zur direkten C-Entwicklung. Code unter external/camera_engine_rkisp/apps; fehlt der Ordner in einem alten Stand, aktualisieren.

5.2 DMA buffer und Vorteile

DMA buffer ist vom Treiber allokierter Speicher, den mehrere Kernelmodule gemeinsam nutzen können. Dies reduziert Kopien, verbessert Bildverarbeitung und entlastet DDR. Beispiel: Kamera über MPP kodieren:

RKISP → gemeinsam genutzter DMA buffer → MPP-Kodierung.

RKISP kann DMA buffer von MPP/RGA übernehmen oder Speicher selbst allokieren und an andere Module exportieren. Details im Quellcode von librkisp_api.so.

Unterschiede des Quellcodes

Der Haupttext folgt der jeweiligen Sprachquelle, RU/DE dem EN-Original. Abweichende Fragmente der anderen Quelle einschließlich Kommentar-/Layoutabweichungen bleiben unten erhalten. Unabhängige Beispiele, kein zusammenhängendes Skript; Quellparameter wurden nicht stillschweigend überschrieben.

CN PDF p.13 · 108

# media-ctl -p -d /dev/media0
...
- entity 2: rkisp1_mainpath (1 pad, 1 link)              //表⽰该entity是
MP(MainPath)
            type Node subtype V4L flags 0
            device node name /dev/video1                 //对应的设备节点
是/dev/video1
        pad0: Sink
                <- "rkisp1-isp-subdev":2 [ENABLED]

- entity 3: rkisp1_selfpath (1 pad, 1 link)              //表⽰该entity是
SP(SelfPath)
            type Node subtype V4L flags 0
            device node name /dev/video2                 //对应的设备节点
是/dev/video2
        pad0: Sink
                <- "rkisp1-isp-subdev":2 [ENABLED]

CN PDF p.14 · 109

...

CN PDF p.14 · 111

# grep '' /sys/class/video4linux/video*/name
/sys/class/video4linux/video0/name:stream_cif
/sys/class/video4linux/video1/name:rkisp1_mainpath       # MP节点对应/dev/video1
/sys/class/video4linux/video2/name:rkisp1_selfpath       # SP节点对应/dev/video2
/sys/class/video4linux/video3/name:rkisp1_rawpath
/sys/class/video4linux/video4/name:rkisp1_dmapath
/sys/class/video4linux/video5/name:rkisp1-statistics
/sys/class/video4linux/video6/name:rkisp1-input-params

CN PDF p.14 · 116

  # grep CONFIG_CAM_ENGINE_LIB_VERSION interface/rkisp_dev_manager.h
  define CONFIG_CAM_ENGINE_LIB_VERSION "v2.2.0"           # 输出的v2.2.0是
librkisp.so的版本号

CN PDF p.14 · 118

  # persist_camera_engine_log=0x4000 rkisp_3A_server --mmedia=/dev/media1 | grep
"CAM ENGINE LIB VERSION"
        CAM ENGINE LIB VERSION IS v2.2.0                # 输出的v2.2.0是librkisp.so
的版本号

CN PDF p.15 · 122

  # grep RKISP1_DRIVER_VERSION drivers/media/platform/rockchip/isp1/version.h
  define RKISP1_DRIVER_VERSION KERNEL_VERSION(0, 1, 0x5) # 输出的v0.1.5是rkisp驱动的
版本号

CN PDF p.15 · 129

# git log
commit e456a50a5524792d64dac384604d4136a697deac
Author: ZhongYichong <zyc@rock-chips.com>
Date:   Mon Jul 1 11:26:32 2019 +0800

    librkisp: v2.2.0

    (BY ZSQ: UPDATE v2.2.0 iq version: from v1.4.0 to v1.5.0)

    3A lib version:
      af:  v0.2.17
      awb: v0.0.e
      aec: v0.0.e
    iq version: v1.5.0
    iq magic version code: 706729

    matched rkisp1 driver version:
      v0.1.5                 # 所需要的kernel驱动版本为v0.1.5

    Change-Id: I3d2adb949dadec259b9ba587a3e3b2770a1c155d
    Signed-off-by: ZhongYichong <zyc@rock-chips.com>
    Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>