Matrix ARM Mini PC (TBS)

Zitat von Zille

Die Tatatur funktioniert nur am U-Boot prompt nicht!

Kannst Du mal probieren, ob ein Revert von diesem Patch Dein Tastaturproblem loest?

Danke,
S:oren

Zitat von wino

hast Du die imx_v6_v7_defconfig so belassen oder mit make menuconfig Veränderungen bzw. Erweiterungen vorgenommen?

Normalerweise benutze ich einen 3.18er Kernel mit angepasster config. Ich teste diese defconfig - wie bereits geschrieben - naechste Woche nochmal...

Gruss,
S:oren

Da kann man nur mit dem Kopf schütteln. Die Mac Tastatur die beim Beschreiben der u-boot Parameter funktioniert, funktioniert nicht mehr nach dem Bootvorgang. Jetzt habe ich die Tastatur, die nicht bei u-boot, funktionierte wieder angeschlossen, damit gibt es keine Probleme mehr auf der Console.

Also das neue u-boot, 3.19 Kernel und Jessie tun ihre Dienste tatelos. Prima! Wie schon geschrieben, klasse Arbeit von Dir S:oren!

MfG
wino

Zitat von S:oren

Normalerweise benutze ich einen 3.18er Kernel mit angepasster config. Ich teste diese defconfig - wie bereits geschrieben - naechste Woche nochmal...

Ich werde wohl, auch wegen der vpu Geschichte den 3.18ner von Archlinux nehmen, oder gleich auf Archlinux umstellen. Mein VDR-Server läuft unter Archlinux sehr gut. Allerdings müsste ich diesen für TBS-2010 wohl patchen. Schöner wäre es wenn Du Deinen 3.18 überlassen würdest. Möglicherweise kann man ein Diff für vpu der beiden Kernels erstellen.

MfG
wino

Zitat von S:oren

Kannst Du mal probieren, ob ein Revert von diesem Patch Dein Tastaturproblem loest?

Hallo S:oren,

wenn ich den Patch zurücksetze wird hier keine Tastatur vom U-Boot erkannt. Ich kann auf die Tastatur hämmern, autoboot läuft durch.

Gruss zille

Zitat von Zille

wenn ich den Patch zurücksetze wird hier keine Tastatur vom U-Boot erkannt.

Wie jetzt, mit CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE gehen keine Shift-Zeichen und andere Tasten nur ohne Wiederholung, mit CONFIG_SYS_USB_EVENT_POLL geht dagegen die Tastatur ueberhaupt nicht? Das kann ich nicht glauben...

Gruss,
S:oren

Zitat von S:oren

Wie jetzt, mit CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE gehen keine Shift-Zeichen und andere Tasten nur ohne Wiederholung, mit CONFIG_SYS_USB_EVENT_POLL geht dagegen die Tastatur ueberhaupt nicht? Das kann ich nicht glauben...

Gruss,
S:oren

Ich hab hier eine Tastatur und 2 Adapter PS2 / USB. Mit CONFIG_SYS_USB_EVENT_POLL konnte ich mit keinem Adapter autoboot unterbrechen und die U-Boot shell öffnen. Mit CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE kann ich mit beiden Adaptern autoboot unterbrechen. Ein Adapter funktioniert komplett und einer hat keine Shift Zeichen und 2x das gleiche Zeichen nacheinander geht auch nicht. Hat das System gebootet funktionieren beide Adapter. An allen anderen Rechnern hier gab es mit beiden Adaptern keine Probleme. Wenn Du das weiter untersuchen möchtest schick ich Dir den nicht funktionierenden Adapter gern zu. Für mich ist das OK so. Ich weiss welchen Adapter ich nehmen muss und gut.

Gruss zille

Zitat von S:oren

Das Board hat drei verschiedene SD/MMC-Karten, fuers u-boot ist das alles ein mmc device:

Quellcode

1 mmc 0 microSD (SD2)
2 mmc 1 SD (SD3)
3 mmc 2 eMMC (SD4)

Hallo S:oren,

existiert auch eine Einstellung für SATA? IMX6 sollte direkt von SATA booten können.

Gruss zille

Zitat von Zille

Ich hab hier eine Tastatur und 2 Adapter PS2 / USB. Mit CONFIG_SYS_USB_EVENT_POLL konnte ich mit keinem Adapter autoboot unterbrechen und die U-Boot shell öffnen. Mit CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE kann ich mit beiden Adaptern autoboot unterbrechen. Ein Adapter funktioniert komplett und einer hat keine Shift Zeichen und 2x das gleiche Zeichen nacheinander geht auch nicht.

Es waere ja mal fair gewesen, beim Bug-Report auf dieses extrem spezielle Setup hinzuweisen. Einen USB-Adapter fuer eine PS2-Tastatur habe ich noch nie gesehen, ist sowas nicht teurer als eine neue USB-Tastatur?
Fuer mich hat ein Fix fuer dieses spezielle Setup keine Prioritaet, muss wohl damit zusammenhaengen, dass diese Adapter-Tastatur-Kombi selbst laenger zum Booten braucht als das u-boot.

Gruss,
S:oren

Zitat von Zille

existiert auch eine Einstellung für SATA?

Natuerlich, probier's mal mit sata 0 (was waere naheliegender?).

Zitat von Zille

IMX6 sollte direkt von SATA booten können.

Auf dem 2.1er Board konnte man das einstellen. Diese Moeglichkeit hat TBS beim 2.3er wieder wegerfunden, Gratulation TBS!
(Es geht hier wirklich darum, auch das u-boot von SATA zu booten, das u-boot kann immer auf SATA zugreifen.)

Gruss,
S:oren

Zitat von wino

Ich werde wohl, auch wegen der vpu Geschichte den 3.18ner von Archlinux nehmen, oder gleich auf Archlinux umstellen. Mein VDR-Server läuft unter Archlinux sehr gut. Allerdings müsste ich diesen für TBS-2010 wohl patchen. Schöner wäre es wenn Du Deinen 3.18 überlassen würdest. Möglicherweise kann man ein Diff für vpu der beiden Kernels erstellen.

Wenn das Archlinux sehr gut funktioniert, dann nimm doch das. Ich habe keinen besonders tollen 3.18er Kernel auf dem Board (besonders keinen mit vpu, fuer den ich irgendwelchen Support leisten will).

Gruss,
S:oren

Habe Archlinux installiert und dessen Kernel 3.14.27 mit den beiden Patches für tbs-2910 aus OpenELEC (ist der gleiche Kernel) gepatcht. Xbmc läuft damit recht gut.

Wollte eigentlich Deinen Patch nehmen, der auch ohne Fehler durchlief. Leider bekomme ich diese Fehlermeldung und kann damit nichts anfangen.

Error: arch/arm/boot/dts/imx6q-tbs2910.dts:131.2-3 label or path, 'hdmi', not found
Error: arch/arm/boot/dts/imx6q-tbs2910.dts:350.2-3 label or path, 'snvs_poweroff', not found
FATAL ERROR: Syntax error parsing input tree
  DTC     arch/arm/boot/dts/imx6sl-evk.dtb
scripts/Makefile.lib:274: die Regel für Ziel „arch/arm/boot/dts/imx6q-tbs2910.dtb“ scheiterte
make[1]: *** [arch/arm/boot/dts/imx6q-tbs2910.dtb] Fehler 1
make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet...
  DTC     arch/arm/boot/dts/vf610-cosmic.dtb
/root/linux-3.14.27/arch/arm/Makefile:315: die Regel für Ziel „dtbs“ scheiterte
make: *** [dtbs] Fehler 2
make: *** Es wird auf noch nicht beendete Prozesse gewartet...
[root@humming linux-3.14.27]#

Zitat von wino

Leider bekomme ich diese Fehlermeldung und kann damit nichts anfangen.

Es gibt in diesem Kernel offenbar keinen Devicetree-Support fuer HDMI und Poweroff. Poweroff ist erst in 3.19 drin, HDMI wird anscheinend anders gehandhabt (vielleicht von den OpenELEC-Patches, kannst Du mir da einen Link schicken?). Nimm doch einfach den imx6q-sabresd.dtb aus diesem Kernel.

Gruss,
S:oren

Zitat von S:oren

...(vielleicht von den OpenELEC-Patches, kannst Du mir da einen Link schicken?).

Hier sind sie.
https://github.com/OpenELEC/Op…_from_imx6q-sabresd.patch
https://github.com/OpenELEC/Op…device_tree_updates.patch

MfG
wino

Zitat von wino

Hier sind sie.

Danke!

Diese Patches erzeugen doch selbst ein imx6q-tbs2910.dtb, mit welchem Patch von mir hast Du die denn zusammen benutzt?
(Du musst dann natuerlich den imx6q-tbs2910.dtb ohne irgendwelche Patches von mir mit dem 3.14er Kernel benutzen).

Gruss,
S:oren

Das ist ein Missverständnis. Mit diesen beiden Patches lies sich der Kernel compilieren. Danach habe ich den Kernel anstelle dieser Patches mit Deinen Patch aus dem Thread hier versucht zu bauen. Natürlich mit sauberen Quellcode. Also nicht etwa gleichzeitig.

Ach so. Das geht so leider nicht.
(Ich wusste gar nicht, dass schon jemand ein imx6q-tbs2910.dts gebaut hat. Meins gefaellt mir aber besser. Geht dafuer erst ab 3.19...)

Gruss,
S:oren

Hallo S:oren,

Weißt Du wie der WLAN Treiber heißt und kann man auf der Konsole mit einem Befehl den Lüfter laufen lassen? Habe das Gefühl das der nicht geht. Habe testweise zwei Kernels gleichzeitig und Xbmc mit einem HD Sender laufen lassen. Der Lüfter lief bei diesem "Stresstest" nicht an aber ich hatte das Gefühl dass es eine Notabschaltung(?) gab, als plötzlich das Bord sich ausschalten wollte. Sah aber eher wie ein Kernel Problem aus.

Gruß
wino

Zitat von wino

Weißt Du wie der WLAN Treiber heißt

Auf meinem 2.1er Board heisst der Chip RTL8188EU, das Kernel-Modul r8188eu.

Zitat von wino

kann man auf der Konsole mit einem Befehl den Lüfter laufen lassen?

In meinem u-boot

run fan

Mit meinem Kernel

echo 255 > /sys/class/hwmon/hwmon0/pwm1

Zitat von wino

Der Lüfter lief bei diesem "Stresstest" nicht an aber ich hatte das Gefühl dass es eine Notabschaltung(?) gab

Bei meinem Kernel taktet sich der Chip einfach runter, wenn's zu heiss wird. Wie das bei OpenELEC aussieht, weiss ich nicht.

Gruss,
S:oren

Hallo S:oren,

Danke für die Antworten. Das WLAN Modul war nicht aktiviert und ein pwm1 unter /sys/class/hwmon/hwmon0/ gab es nicht. Habe eine Einstellung gpio_fan bei dem Kernel gefunden und hoffe das diese die richte für den Lüfter ist.

MfG
wino