Beiträge von rell

zillerbaer

Was ist der Hintergrund hinter use_zpos? Korrigier mich, wenn ich es falsch verstehe:

use_zpos wird gesetzt, wenn das NV12 plane das OVERLAY_PLANE ist und das ARGB plane das PRIMARY_PLANE ist, also standardmäßig OSD unter VIDEO liegt.

In VideoOsdDrawArgb wird das dann getauscht und in VideoOsdClear wieder zurückgetauscht.

In OsdDrawArgb wird zusätzlich das plane mit memcpy beschrieben, in OsdClear mit memset auf 0 gesetzt.

Warum ist das Löschen mit memset notwendig, wenn das OSD eh wieder unter das VIDEO gelegt wird und nicht sichtbar ist?

Falls NV12 bereits unten liegt, wird use_zpos nicht gesetzt, ChangePlanes wird dann auch nicht ausgeführt. Beide Male (OsdDrawArgb und OsdClear) setzen mit drmModeSetPlane die Properties. Diese werden in OsdClear so gesetzt, dass die SRC* Properties auf 0 gesetzt werden. Bewirkt das, dass das Plane "geschlossen" wird und im Endeffekt nicht sichtbar ist, obwohl es oben liegt?

Anders gefragt, könnte man nicht 1x die planes so einstellen, dass OSD über VIDEO liegt und dann "nur" den Puffer löschen oder hat das Performancegründe?

Schön. Das Schlimmste hast du hinter dir und vielleicht sogar noch was über Allwinner gelernt

Jetzt ist's “nur“ noch VDR

Vielleicht musst du einfach mal einen Kernel ohne Patches und nur mit der defconfig testen und das Board erstmal zum Booten kriegen.

Evtl. stimmt auch am Rootfs was nicht? Hast du ein Kabel um den UART anzuzapfen? https://linux-sunxi.org/PineH64#Locating_the_UART

Ich glaube ja.

Hm, keine Ahnung wie weit er da bootet. Ich sehe bei mir am Anfang etwas UBoot Gedöns und dann kommt irgendwann "Starting Kernel", dann wirds schwarz und irgendwann taucht die Konsole auf... Letztendlich sollte irgendwann die Konsole kommen... wohl abhängig vom RootFS.

Zitat von JoeBar

Die boot.cmd hab ich mal so gemacht. Die Speicheradresse hab ich hier her

Stimmt das so annähernd?

Versuchs einfach. Sieht gut aus.

Zitat von JoeBar

rootfs kann ich arm64 von ubuntu focal von hier nehmen oder?

Da hab ich mich vertan das schein wohl irgendwas für's windows sub system zu sein.

Dann von hier

Wenn das root fs sind, ja. Ich hab mir bisher immer ein Debian selbst gemacht.

Ja.

Zitat von JoeBar

rell Bei dem U-boot Teil brauch ich ein wenig Unterstützung, da steig ich nicht so richtig durch. Aktuell bin ich bei Abschnitt Bootloader bei Bootable SD Card.

u-boot-sunxi-with-spl.bin habe ich bereits mit dd auf die SD Karte geschrieben. Muss ich für den nächsten Schritt U-boot auf dem Pine64 starten und die Befehle dort in der Konslole eingeben?

Dir reicht der dd Befeh, dann kannst du mit dem Partitionieren weitermachen.

Nein, du musst die SD Karte so herrichten, dass sie auf Konsole bootet.

Kurzanleitung:

- SD Karte partitionieren (am besten / und /boot)

- U-Boot auf SD-Karte schreiben

- SD Karte mounten

- boot.cmd/boot.scr erstellen und nach /boot kopieren

- Kernel nach /boot kopieren

- *.dtb nach /boot kopieren

- Rootfs auf die Karte schreiben

- Kernel-Module nach /lib/modules schreiben

- SD Karte unmounten

- Booten (hoffentlich)

Weiß ich nicht, sollte beides kein Problem sein. Du kannst ja mit <HELP> schauen, was für H6 überhaupt relevant ist...

CONFIG_DRM_DW_HDMI_I2S_AUDIO

CONFIG_SND_SIMPLE_CARD

CONFIG_VIDEO_SUNXI_CEDRUS

CONFIG_CMA_SIZE_MBYTES auf ca. 256

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE

(CONFIG_DRM_LIMA) für späteres OpenGL evtl.

sind so die ersten, die mir einfallen. Ich weiß es zwar nicht, hoffe aber, dass der Rest in der defconfig schon drin ist.

Du kannst ja einfach mal nur die defconfig bauen, damit du etwas hast, das startet... In der Zwischenzeit überleg ich mir, was du brauchst

git config --global user.name "Your Name"

git config --global user.email mail@example.com

Ich habe mir das LE Verzeichnis geklont, kopiere die Patches je Verzeichnis in das Kernel Hauptverzeichnis und dann kannst du sie mit "git am *.patch" auf einmal einpielen und jeder Patch wird zu einem Commit. Das vereinfacht die Sache.

Scheint so, als würden die nur passen, wenn man die Crust Patches mit drauf nimmt.

EDIT: Ja, dann gehts. https://github.com/LibreELEC/L…inner/patches/linux/crust vorher, dann klappen die von H6.

Hast recht, der geht nicht, scheint ein LE bug zu sein...

soll ja auch nicht!? “git checkout v5.10.4“ sollte dich auf den Stand bringen, die mit den Patches zusammenpassen.

Welcher master?

Nimm https://git.kernel.org/pub/scm…nel/git/stable/linux.git/ und checke v5.10.4 aus. Darauf dann die Patches mit “git am“ anwenden.

5.10.4 und https://github.com/LibreELEC/L…ages/linux/package.mk#L31

LE's Version mit Patches.