Posts by Dieter

Hallo Zillerbär,

Hast du das ganze Crosskopiliert?

Das wollte ich jetzt auch angehen mit deinem Plugin und Kernel 5.17 auf dem Amlogic.

PS: Die T95max ist ausverkauft.

Aber die hier ist sogar noch billiger:

35€

An die Runde:

hat schon jemand den VDR mit plugins cross-kompiliert?

Ich hat schon einmal woanders gefragt, aber keine Antwort bekommen.

Makefile von VDR habe ich mal angesehen, sollte machbar sein (wenn auch nicht so schön wie im Linux Kernel).

Hi jojo61,

bei mir steht in vdec.h:

#define MAX_INSTANCE_MUN  9

Die Patches von CE werden nur beim original CE Buildsystem verwendet.

Hi jojo61,

full ack. Verzetteln ist immer schlecht.

Ich packe noch die media-module rein. Als "out of tree" build wie bei CE.

Vielleicht kann happe60 noch seinen Weg genauer beschreiben oder scripts bereitstellen.

Den Beta68/HK kernel have ich vorerst aufgeben. Den Crash zu reparieren ist mir noch nicht gelungen. Und was kommt danach? HK hat da ziemlich schmutzing gearbeitet. Eine CONFIG_XX ändern und es kommen Fehler. Selbst Mergekonflikte sind da noch im Text.

Aber ich habe wieder viel gelernt (auch was ich schon wieder vergessen hatte). Kernelland ist immer interessant.

Auf Github habe ich meine U-boot-Scripte mit Erklärungen aufgefrischt.

Nochwas:

Vielleicht ist die von zillerbaer gezeigt Lösung für Allwinner SOCs auch hier machbar.

Kernel 5.17 und softhddevice-drm wäre mein zweiter Ansatz gewesen.

Das ist zumindest ein zukunftsicherer Weg. Kernel 4.x wird irgendwann sterben.

(5.17-RC5 booted perfect mit den Armbian U-Boot-Scripts)

Was mit Amlogic bei 5.17 geht und nicht geht ist mir nicht bekannt. Aber es wurde viel nach Mainline portiert.

Ich stecke aber lieber Zeit in die Verbesserung des 5.17 als den alten Mist 4.9 zu reparieren.

Hi,

Bist du sicher das der Name T95 max ist. Damit finde ich nur eine Amlogic S905x3 Box.

Oder ist es die TX6 ?

Hi,

Das Temperaturproblem dürften alle diese Boards haben.

Sie sind nicht dafür gebaut etwas zu compilieren

Als ich testweise einen Kernel auf der TX3 gebaut habe musste ich ihr zufächeln damit die Temperatur unter 80°C blieb.

Normalerweise compiliere ich cross, das geht erheblich schneller und ist nicht schwer.

Hi,

60MB auf meinem gdrive.

(ExperimentalCE_Kernel_WithUbuntuRamdisk.tar.bz2)

Mehr Details im Ordner Hints/Readme.txt.

Kernel source muss per git clone von GitHub geholt werden (würde Größe vervielfachen).

Es sind auch die originale Ramdisk (initrd) von CE und originale Ramdisk von Ubuntu vorhanden.

Ich hoffe das nichts vergessen wurde.

Es sollte funktionieren einen Armbian Ubuntu-Stick zu machen und

das Kernel image (nach bauen in linux-amlogic_boot zu finden. Ca. 100MB. Dort sind auch to dtb files)

u-boot:

Die u-boot scripts sind in Hints/Experiments/scripts/.

uEnv.txt anpassen nicht vergessen!

Dann an die Box und toothpick....

PS: Ob Ubuntu-Basis besser ist als CE? Zumindest zum Bauen und testen ja.

Meine Hoffnung ist ein Plugin zu CE.

Hi,

@JoeBar:

Ja aktueller CE 4.9. Hab den nur wegen Fehlersuche angefasst damit ich vergleichen kann.

Der Plan war die YA-Sachen zu nehmen (und ev. einen Ansible-"Script" aufsetzen damit auch die Installation Dokumentiert ist.)

(Danke nochmals an Seahawk der hat mich damals zu Ansible gebracht. Super Werkzeug, verwende es für fast alle Maschinen)

@jojo61 und beta:

Bereitstellen: Ja, muss aber Saubermachen.

Wo stellt man die Decoder auf 2.

Was interessant wäre ob mein Kompilat des Beta68Kernels auf Odroid läuft.

Ich baue Cross mit dem selben Compiler wie CE (GCC 10.2).

Habs aber auch mit dem GCC 10.3 und 632 versucht.

Der CE hat die Media-Moduls extern (out of tree), die habe ich noch nicht gebaut - soweit war ich noch nicht.

Vielleicht zippe ich einfach - mal sehen wie groß es wird.

Später soll es aber sauber in github sein.

Hi,

wieder mal ein Statusupdate:

Mit dem Kernel von Hardkernel/Beta68 bin ich noch nicht viel weitergekommen. Der Crashed an verschiedenen Stellen. Könnte IRQ oder DMA sein (oder Takt, Regulators).

Um anderes auszuschliesen habe ich versucht den Kernel von CE mit dem rootfs von Ubuntu zu verbinden.

Dazu musste ich eine andrere initrd für Ubuntu erzeugen. Es brauchte dann doch ein paar Anpassungen im initrd, aber jetzt rennt es.

Endlich!

zillerbaer: Habe verschieden Einstellung der kernel cmd versucht. Mit 5.16 habe ich ja earlyprintk (oder earlycon wie es bei arm64 heisst).

Die habe ich gerade in den tests (war mal länger wie von Armbian eingestellt):

APPEND=earlyprintk root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 systemd.debug_shell=ttyAML0 udbg-immortal tp_printk

Bei Amlogic soll dieser Teil wichtig sein :

console=ttyAML0,115200n8

Der Uarttreiber registriert sich auch bei 4.9 als earlycon. Zumindest sind die Aufrufe/macros im Quelltext (aber wird es compiliert? Das muss ich nochmals prüfen.

Und ich sehe gerade ich habe kein EARLYCON in der cmd line (habe ich gestern gelesen das man das bräuchte - wird aber viel Mist geschrieben).

Edit:

earlycon hat nichts gebracht.

Aber ich habe gesehen dass es zwei Treiber für den AMLOGIC UART gibt.

1. linux-6a7cecbf10be7a12672b5295aef4c042addce1c6/drivers/tty/serial/meson_uart.c
2. linux-6a7cecbf10be7a12672b5295aef4c042addce1c6/drivers/amlogic/uart/meson_uart.c

Werde es hier reinschreiben wenn ich was positives finde.

Edit2:

EIner der Treiber war nicht im .config. Es braucht 3 settings um es zu aktivieren.

Mist, beim Bauen ist er jetzt auf einen Fehlergelaufen

Irgendwo im PINCONTROL. Komme ich heute nicht mehr dazu.

Edit3 (14.03.2022):

Earlycon funktioniert jetzt mit dem CE-Kernel. Es fehlte noch ein Eintrag im Device Tree (chosen.... ).

Und man kann alles was early* betriff aus der kernel cmdline entfernen. Ebenso dieser Teil: "console=ttyAML0,115200n8" das war für Kernel 5.x.

In den Quellen kann man finden dass ttyAMLx beim 4.9 nicht existiert. Dort heißt es ttySx.

Es wird auch nur einer der beiden Uart-Treibern verwendet (drivers/amlogic/uart/meson_uart.c).

Meine aktuell Appendzeile: "APPEND=root=LABEL=ROOTFS rootflags=data=writeback rw"

Damit kann ich jetzt auch den Kernel von Beta untersuchen.

Edit4 (16.03.2022):

Auch mit dem Beta68-Kernel habe ich jetzt Earlycon. Auch da ist die Schnittstelle dafür TTYS0.

Es sind eine ganze Reihe Änderungen notwendig. Ich habe den Kernel von Beta68 "geforked": github. Soll aber später wieder zusammengeführt werden (Mein Wunsch). Es wird aber verschiedene Konfigurationen geben (müssen).

Momentan crashed dieser Kernel, aber jetzt kann ich etwa sehen wo. Ist ein großer Fortschritt.

Hi,

status:

• fatload (u-boot 2015) hat limit 32Mib mit loadaddr 0x3080000
• fatload parameter pos und bytes crashen
• img mit split in 2 Teilen laden funktioniert (img0 und img1).
• mit loadaddr 8080000 kann ich auch am Stück 50MiB laden. Juhu.
• initrd von Ubuntu funktioniert nicht (kernel crash)

Next Steps, bin für alle Tips dankbar.

1. Wie bekomme ich earlyprintk mit 4.9 ans laufen (mit V5.x geht es)?
   Hatte bei meinen Kernel/Treiber-Projekten nie Problem damit, aber das ist auch schon etwas her (vor DT).
   Könnte am dtb liegen, habe gelesen dass es ein anderes device braucht.
   .config sollte alles enthalten was es anschaltet.
   Kernel cmd line auch, aber das muss ich nochmals überprüfen.
2. U-Boot! Mainline kann keine Kernel <4.14 booten.
   Habe noch keine Docs diesbezüglich gefunden.
   Was wurde geändert im Kernel und U-Boot und warum um Himmelswillen macht man sowas?
   Man könnte dem Kernel oder U-Boot wieder beibringen mit dem Anderen zusammenzuarbeiten.
   Ich tendiere das dem 4.9 beizubringen.

Hi,

Der CE-Kernel hat Version 4.9.269. Es gibt aber "Unterversionen".

Das Kernelimage ist im Androidformat.

Habe jetzt ein Androidimage erzeugt mit dem initrd von Ubuntu. Ist aber 90MB.

Das U-Boot von der Box hat Probleme mit der Größe. Irgendwo bei 25MB ist Schluss.

Ich kann es sicher noch etwas schrumpfen. 25MB ist aber heftig.

Werde morgen die Grenze besser erforschen.

Es ist ist "fatload"-Funktion.

Plan B könnte sein: Kernelimage auf zwei Teile splitten und in zwei Schritten laden.

Mit secondary bootloader (u-boot.ext) kann och die Android Images nicht laden.

Hi,

Ich baue diese Kernel alle selbst.

Betas Kernel baut auf den von Hardkernel auf. Und dort sind halt einige Dinge nicht sauber gemacht.

Wenn man die CONFIG_AMLOGIC_ODROID_COMMON raus nimmt knallt es an vielen Stellen beim Bau.

War ja auch nicht deren Ziel.

Ich werde jetzt versuchen den CE-Kernel mit dem rootfs von Ubuntu zu vereinen.

Hatte ich schon früher versucht, aber jetzt weiss ich mehr über das initrd von CE...

Hi,

Der Kernel von Beta / Hardkernel hat leider einige Probleme wenn man die .config verändert.

Ich habe versucht, die Bootprobleme zu analysieren indem ich die Config untersucht habe.

Das Meiste habe ich gefixed. Da waren auch Mergekonflikte dabei (<<<<<< head ....).

Aber vor einer Stunde habe ich beschlossen mit dem CE-Kernel weiter zu machen. Der scheint etwas besser zu sein.

Wenigstens weiss ich jetzt wie man CE erfolgreich baut. Ist doch etwas anders als LE.

hape60,

welche Box hast du?

Paulaner:

Ich habe VDR headless in zwei Containern am Laufen.

Einen für Astra 19.2, den zweiten für Astra 28.8 English.

Empfang via SatIP.

Allerdings auf X86.

Auf meiner N2+ laufen auch 11 Container, aber kein VDR.

@Alle

Habe herausgefunden wie der CE kernel.img gebaut wird.

Es gibt ein Tool mkbootimg, das macht das aus dem arch/arm64/boot/Image.

Quelle ist dabei.

PS: Das Buildsystem ist sagen wir mal verbesserungswürdig.

Baut hier auch nicht durch, es fehlen Dateien auf den Servern (falsche SHA1 in den configs - einmal hat sogar das Verzeichnis gefehlt).

Hallo Allerseits,

Hier ist mein Status bezüglich U-Boot:

• Kernel 4.9 bootet einfach nicht (Alle x Varianten, auch von CE, aber separat übersetzt).
• Kernel 5.x bootet. (über u-boot.ext, siehe unten)
• Habe gelesen dass Mainline U-Boot alles älter als 4.14 nicht mehr booten kann. Das würde es erklären.
  Dies betrifft den "Chainloaded U-Boot.exe". Ist ja Mainline von 2021.
• Weder bootm noch booti gehen mit 4.9. Auch nicht die paar Zeilen vom CE-Script.
• CE Kernel kann ich booten. (Der bricht dann irgendwann ab weil ich system.img und die Storage-Partition nicht habe).
  War ja auch nur ein Test der Boot-Fähigkeit. Dafür muss ich aber sehr in die Details der U-Boot-Scripte gehen.
  Meine Testscript ist ürsprünglich von Armbian abgeleitet und mit den bootm-Zeilen von CE, aber kein u-boot-exe.
• Der CE-Kernel (kernel.img) hat die "Magic" "ANDROID!!". Das ist vermutlich der Schlüssel für 4.9. Alle anderen Kernels hatten das nicht.
• Bin gerade am Suchen wie die CoreElec-Kernel gebaut werden. Vermutlich ist da sowas with ein mkimage am Schluss (mkimage kann aber dieses Format wohl nicht). Dann könnte ich das auf den Kernel von Beta68 anwenden und Booten.
• Der CE-Kernel hat CONFIG_ANDROID=y in der .config

Nach diesem Post werde ich das "make image" von CE anstoßen.

@ Dr. Seltsam: Das war als zweite Stufe geplant. VDR als Pluging zu CE. Wäre ein sehr schlankes System.

Da ich mit dem 4.9 Kern noch nicht weiter gekommen bin, habe ich zunächst die Details des Bootvorganges dokumentiert:

amlogic-u-boot-scripts

Danke, schaue ich mir an.

Alle 4.x Kernel starten nicht. Alle 5.x die ich gebaut habe laufen.

Das muss ein systemischer Fehler sein.

Habe heute viele Versuche mit U-Boot gemacht.

Auch Sourcen analysiert, aber noch kein Durchbruch.

Die 4.x haben eine reloc section. Die 5.x nicht.

Könnte sein dass da der Hase liegt. U-boot?

Edit: Dein Kern baut nicht in der Umgebung von Armbian (ophub). Dort wird clang benutzt. Habe den Script angepasst damit gcc verwendet wird, dann baut es. Clang motzt an verschiedenen arrays in structs herum. Sollen angeblich keine size haben. Ist aber "unrelated".

(Diese Umgebung damit ich eine uinitrd bekomme.)

Die Sourcen der u-boot.ext (chainloaded simplified u-boot) habe ich noch nicht gefunden.

Hi,

Jungfräuliches printenv habe ich jetzt. Der Befehl defenv setzt alles zurück.

Ophub kenne ich. Dort habe ich auch schon geclont

Habe heute den Bootvorgang nochmals genauer analysiert und eigene aml_autoscript, s905_autoscript, boot.scr gebaut.

Jetzt stört die Variable bootfromsd (von CoreElec) nicht mehr.

Der Versuch den Kern von CoreElec über meine scripts zu booten hat bisher noch nicht geklappt. WIP

Den Kern von Beta68 bekomme ich auch noch nicht gebootet (deshalb der Versuch mit CE).

Aber ich habe die DTs con CE in den Kern von Beta68 eingebaut. Da fehlt mir jetzt plötzlich die Initrd. Dachte immer die wird automatisch vom Kerenl Makefile gebaut. War aber wohl der Armbian-Build der mir die für 5.x gebaut hatte.

Falls Beta68 mitliest: Wie baust du die Initrd? Oder brauchst du die nicht? Dann müsste ich die Bootscripts anpassen.

(meine Kerne für Embedded brauchten nie eine Initrd ).

Hallo Jojo,

bin nicht so sicher das nur wenig im Upstream ist. Es gibt einen Menge Patches für die Kernel seit 4.9.

In drivers/media gibt es einiges zu Amlogic, ist aber total anders structuriert als bei Odroid.

Daher meine Annahme dass dein plug angepasst werden müsste. In dem Fall sollte man es umbenennen mit Amlogic im Namen.

Unter dem /sys-Verzeichnis gibt es ein Gerät das "Decoder" im Namen hat.

/driver/media war ja mal meine "Heimat" im Kern (neben arch/arm). War aber mehr die Kamera-Seite und lange vor DT, so um 2006.