Matrix ARM Mini PC (TBS)

Zitat von Uwe

Dazu wollte ich ein System von Grund auf selber erstellen und auch verstehen, was ich dabei mache.

Da kann ich nur empfehlen, mit dem TBS-Matrix-Ubuntu_12.04_V1.0.0.1-V21 anzufangen (Installation mit dem Windows-Tool, wie bei TBS beschrieben). Da hast Du erstmal eine Build-Umgebung auf dem Board und kannst darauf zuerst das u-boot bauen, wie oben beschrieben. Dann installierst Du das mit

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=u-boot.imx of=/dev/mmcblk0boot0 bs=1K seek=1

Wenn alles geklappt hat, dann sollte nach einem reboot das Ubuntu genau so starten wie vorher, aber mit dem neuen u-boot. Nun kommt der erste interessante Teil: Verstehen, was das u-boot macht. Dazu eine USB-Tastatur (am besten englisch, sonst sind wie bei einem PC-BIOS die Tasten vertauscht) und einen HDMI-Monitor anschliessen und einschalten. Dann solltest Du die u-boot-Boot-Meldungen sehen und wenn Du schnell genug eine Taste drueckst, dann bekommst Du einen u-boot-Prompt. (Wenn der Monitor nicht schnell genug synchronisiert, dann schadet es auch nichts, ein paar mal blind enter zu druecken.) Der wichtigste u-boot-Befehl ist printenv, der gibt das u-boot-Environment aus, also auch das Bootskript (nach der Variable bootcmd suchen). Eine Uebersicht ueber die Befehle gibt help. Das default-Environment sucht erstmal nach einem Update-Image, bevor es den Kernel startet, ist kompatibel zu dem originalen MatrixSystem_V1.0.1.0/TBS-Matrix-Ubuntu_12.04_V1.0.0.1-V21 und ein bisschen unuebersichtlich.
Edit: Vielleicht noch wichtig: mit boot startest Du das System ganz normal vom u-boot-Prompt, mit reset startet das u-boot nochmal komplett von vorne...

Im naechsten Teil dieser Fortsetzungsserie kommt, wenn gewuenscht, wie man sich selbst ein sinnvolles u-boot-Environment zusammenstellt. Kannst dann ja in der Zwischenzeit schon mal anfangen, den Kernel zu bauen...

Gruss,
S:oren

Edit 01.01.2015: TBS-Matrix-Ubuntu_12.04_V1.0.0.1-V21 statt MatrixSystem_V1.0.1.0 verwenden, force_ro abschalten!

Zitat von S:oren

Im naechsten Teil dieser Fortsetzungsserie kommt, wenn gewuenscht, wie man sich selbst ein sinnvolles u-boot-Environment zusammenstellt.

Ist gewünscht, auch wenn ich an einer völlig anderen Baustelle zugange bin.

Gerald

Na gut, ich gehe also mal davon aus, dass das neue u-boot wie oben beschrieben funktioniert. (Kann das bitte mal jemand testen? Ich habe diese Neuinstallation vor Monaten auf meinem Board gemacht (auch etwas anders, mit serieller Konsole) und schreibe hier aus der Erinnerung. Gut moeglich, dass ich das eine oder andere Detail vergessen habe...)

Einen Kernel haben wir nun auch wie oben beschrieben gebaut. Wir installieren jetzt die beiden benoetigten Dateien fuer das u-boot:

cp arch/arm/boot/zImage /boot/zImage-3.19-rc2
cp arch/arm/boot/dts/imx6q-tbs2910.dtb /boot/imx6q-tbs2910.dtb-3.19-rc2
cd /boot
ln -s zImage-3.19-rc2 zImage
ln -s imx6q-tbs2910.dtb-3.19-rc2 dtb

Wir haben nun in der ersten Partition der eMMC-Karte (/dev/mmcblk0p1, EXT3-Partition) in einem Verzeichnis /boot die beiden Links zImage und dtb, die wir vom u-boot aus laden wollen. (Ich habe hier gerne Links, da kann man bequem andere Kernel- und Devicetree-Versionen daneben legen und durch Umsetzen der Links ohne Aenderungen am u-boot-Environment mal schnell einen anderen Kernel booten. Es liegen dann da auch gleich ein paar Backup-Kernel, wenn mal irgendwas nicht laeuft.)

Im naechsten Schritt koennen wir uns wieder dem u-boot zuwenden.

Gruss,
S:oren

Zitat von S:oren

Im naechsten Teil dieser Fortsetzungsserie kommt, wenn gewuenscht, wie man sich selbst ein sinnvolles u-boot-Environment zusammenstellt.

Darauf bin ich auch sehr gespannt. Vor allem würde mich interessieren wie man ein komplettes eigenes Image auf den internen Speicher eMMC bekommt. Du hast Jessie drauf oder?

Hallo Sören,
sehr schön beschrieben, werde ich die Tage testen. (Aktuell zerlege ich gerade mein HauptVDR. Ich überlege nun die FF-HD 6400 mit dem MatrixBoard zu betreiben. Welchen PCIe Adapter kann ich dafür nochmal verwenden.)

Viele Grüße, Uwe

Zitat von wino

Vor allem würde mich interessieren wie man ein komplettes eigenes Image auf den internen Speicher eMMC bekommt.

Kopieren
Aber bis dahin fehlen noch ein paar Folgen in unserer Serie...

Zitat von wino

Du hast Jessie drauf oder?

Ja.

Gruss,
S:oren

Zitat von Uwe

Ich überlege nun die FF-HD 6400 mit dem MatrixBoard zu betreiben.

Dann probiere erstmal aus, ob das Board zuverlaessig funktioniert. Auch das Aufwachen fuer Aufnahmen musst Du vorher mal testen...

Zitat von Uwe

Welchen PCIe Adapter kann ich dafür nochmal verwenden.

"Delock 41305" (41370 oder 41851 gehen auch). Habe aber lange nicht gesucht, ob es mittlerweile irgendwas Guenstigeres gibt...

Gruss,
S:oren

Danke Sören, habe den Delock 41305 mal geordert.
Eine RTC ist glaube ich auch verbaut. Funktioniert dieses Modul schon? Ich glaube nicht, aber die kleine Batterie habe ich schon entdeckt.
Das wird dann erstmal ein "Nebenprojekt". Den HauptVDR werde ich mit softhddevice aufsetzen.
Danke erstmal! Guten Rutsch!

Zitat von Uwe

Eine RTC ist glaube ich auch verbaut. Funktioniert dieses Modul schon? Ich glaube nicht, aber die kleine Batterie habe ich schon entdeckt.

Naja, auf meinem 2.1er Board ist eine DS1307 RTC drauf. Die funktioniert soweit einwandfrei, hat aber keinen Alarm-Support. Ich habe die deshalb gegen eine MCP79410 getauscht, mit einigen weiteren kleineren Anpassungen, damit die das Board auch aufweckt. Das waere eine weitere Sache, die ich irgendwann auch mal hier beschreiben kann.

Ebenfalls Guten Rutsch,
S:oren

Zitat von S:oren

Naja, auf meinem 2.3er Board ist eine DS1307 RTC drauf. Die funktioniert soweit einwandfrei, hat aber keinen Alarm-Support. Ich habe die deshalb gegen eine MCP79410 getauscht, mit einigen weiteren kleineren Anpassungen, damit die das Board auch aufweckt. Das waere eine weitere Sache, die ich irgendwann auch mal hier beschreiben kann.

Das wird immer Interessanter!
Ich bin noch dabei einen Radiowecker mit einen ATmega8, SI4703, RTC-DS3231, TFT und 7Segment Anzeige zu bauen, läuft alles schon, nur Gehäuse fehlt noch. Da habe ich wie gesagt einen DS3231 verbaut. Wie du den DS1307 ausgetauscht hast, würde mich sehr dolle Interessieren. Aber erstmal "rutschen".

Hallo S:oren,

Zitat von S:oren

Da kann ich nur nochmal empfehlen, mit dem MatrixSystem_V1.0.1.0 anzufangen. Da hast Du erstmal eine Build-Umgebung auf dem Board und kannst darauf zuerst das u-boot bauen, wie oben beschrieben.

Was genau ist mit MatrixSystem_V1.0.1.0 gemeint? Die Version TBS-MatrixTV-V1.0.1.1-V21 hat doch keine Build-Umgebung, oder? Ich dachte die wäre aus dem Quellcode von hier git://git.code.sf.net/p/matrixtv/code matrixtv-code gebaut worden.

Auch von mir einen Guten Rutsch ins neue Jahr.

MfG
wino

OK, zurueck zum u-boot. Um zu verstehen, woher das u-boot Dateien laed, erstmal ein Blick auf die verschiedenen MMC-Devices.

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

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

Komplizierter ist die Sache noch mit eMMC-Karten. Die haben mehrere Hardwarepartitionen, in unserem Fall eine User-Partition und 2 Bootpartitionen. Die User-(Hardware-)Partition ist wiederum mit einer DOS-Partitionstabelle ausgeruestet (das u-boot kommt auch mit EFI klar), die wiederum auf eine Ext3-Partiton verweist. Wichtig ist hier, nie die Hardware-Partitionen mit den Softwarepartitionen durcheinander zu bringen. Die Nummerierung ist zwischen u-boot und kernel nicht konsistent, hier mal eine Uebersicht:

u-boot		kernel
mmc 2 1		mmcblk0boot0 (erste Boot-Partition)
mmc 2 2		mmcblk0boot1 (zweite Boot-Partition)
mmc 2		mmcblk0      (User-Partition)
mmc 2:1		mmcblk0p1    (Ext3-Partition in der User-Partition)

Edit 20160916: Diese Zuordnung geht davon aus, dass keine (micro)SD-Karte beim Linux-Boot steckt. Ohne SD-Karte ist das eingebaute eMMC-Modul mmcblk0, sonst mmcblk1 bzw. mit 2 gesteckten Karten mmcblk2. Gesteckte Karten draengeln sich in Linux also vor, zuerst die microSD, dann die "normale" SD, dann eMMC.

Edit 20160922: Ab linux-4.6 gibt es eine feste Zuordnung der mmcblk-Devices zu den Kartenslots, aehnlich wie im u-boot:

microSD     mmcblk0
SD          mmcblk1
eMMC        mmcblk2

\Edit

Nach dieser laenglichen Vorrede koennen wir uns demnaechst dann endlich dem u-boot-Environment zuwenden...

Gruss,
S:oren

Zitat von S:oren

Nach dieser laenglichen Vorrede koennen wir uns demnaechst dann endlich dem u-boot-Environment zuwenden...

Nee, nee, das ist alles hoch interessant.

Zitat von wino

Was genau ist mit MatrixSystem_V1.0.1.0 gemeint? Die Version TBS-MatrixTV-V1.0.1.1-V21 hat doch keine Build-Umgebung, oder?

Ich meinte, man soll dieses komplette TBS-System in der Version 1.0.1.0 auf dem Board installieren (keine Ahnung, ob die Version 1.0.1.1 mit dem u-boot noch kompatibel ist) und hat dann dort in diesem System einen Compiler und andere Build-Tools, um wie hier beschrieben u-boot und Kernel zu bauen. (Oder muss man die Tools noch nachinstallieren? Waere dann aber nicht kompliziert.)

Gruss,
S:oren

So, nun zum u-boot-Environment.

Das "Boot-Script" (bootcmd, mit weiteren verwendeten Variablen) im Default-Environment im neuen u-boot sieht so aus:

bootcmd=mmc rescan; if run bootcmd_up1; then run bootcmd_up2; else run bootcmd_mmc; fi
bootargs_mmc1=console=ttymxc0,115200 di0_primary console=tty1
bootargs_mmc2=video=mxcfb0:dev=hdmi,1920x1080M@60 video=mxcfb1:off video=mxcfb2:off fbmem=28M
bootargs_mmc3=root=/dev/mmcblk0p1 rootwait consoleblank=0 quiet
bootargs_mmc=setenv bootargs ${bootargs_mmc1} ${bootargs_mmc2} ${bootargs_mmc3}
bootargs_upd=setenv bootargs console=ttymxc0,115200 rdinit=/sbin/init enable_wait_mode=off
bootcmd_mmc=run bootargs_mmc; mmc dev 2; mmc read 0x10800000 0x800 0x4000; bootm
bootcmd_up1=load mmc 1 0x10800000 uImage
bootcmd_up2=load mmc 1 0x10d00000 uramdisk.img; run bootargs_upd; bootm 0x10800000 0x10d00000

Das u-boot hat eine hush shell, einfache Scripte sind also moeglich.

Hier wird nach dem Scannen nach SD-Karten zunaechst versucht, ein uImage von der SD-Karte (mmc 1) zu laden (implizit aus dem Wurzelverzeichnis der ersten Partition). Im Gegensatz zu aelteren u-booten muss man jetzt nicht mehr angeben, ob es sich um eine FAT- (fatload) oder ext-Partition (ext2load) handelt, es gibt jetzt ein generisches load-Kommando. Klappt das Laden dieses uImage, dann wird noch ein uramdisk.img geladen, die bootargs passend fuer den Update-Kernel gesetzt und dieser Kernel mit seiner initrd geladen. Wird kein Update-Kernel gefunden, dann laed das u-boot einen Kernel von der eMMC, ohne Filesystem, einfach roh von Offset 0x800, und startet den. In der Umgebungsvariable bootargs muessen die commandline-Parameter liegen, die an den Kernel uebergeben werden. Dass es hier drei bootargs_mmc-Variablen gibt, die dann zusammengefuegt werden, hat einfach nur den Vorteil, dass sie in einer seriellen Konsole ohne automatische Zeilenumbrueche bei einem printenv noch lesbar bleiben.

Wir wollen nun aber weder einen Kernel mit Ramdisk von der SD-Karte, noch einen Kernel roh (in uImage-Format) von der eMMC laden, sondern einen Kernel im zImage-Format plus einen zugehoerigen Devicetree. Dazu modifizieren wir das bootcmd:

setenv bootcmd 'run bootargs_mmc; load mmc 2 0x10800000 boot/zImage; load mmc 2 0x10700000 boot/dtb; bootz 0x10800000 - 0x10700000'

Der neue Kernel braucht noch eine kleine Aenderung, damit das Root-Filesystem read/write eingebunden wird:

setenv bootargs_mmc3 'root=/dev/mmcblk0p1 rootwait rw consoleblank=0 quiet'

Nachdem wir mit

printenv

nochmal kontrolliert haben, dass das bootcmd und bootargs richtig eingetippt wurden und so aussehen:

bootcmd=run bootargs_mmc; load mmc 2 0x10800000 boot/zImage; load mmc 2 0x10700000 boot/dtb; bootz 0x10800000 - 0x10700000
bootargs_mmc3=root=/dev/mmcblk0p1 rootwait rw consoleblank=0 quiet

koennen wir das geaenderte Environment dauerhaft speichern

saveenv

Nun sollte das u-boot den neuen Kernel mit Devicetree starten...

Ein Frohes neues Jahr 2015!
S:oren

Edit 20150106: rw in bootargs_mmc3 eingefuegt.
Edit 20161019: Fuer neue Settings zum root-Device siehe auch hier.

Zitat von S:oren

Ich meinte, man soll dieses komplette TBS-System in der Version 1.0.1.0 auf dem Board installieren (keine Ahnung, ob die Version 1.0.1.1 mit dem u-boot noch kompatibel ist) und hat dann dort in diesem System einen Compiler und andere Build-Tools, um wie hier beschrieben u-boot und Kernel zu bauen. (Oder muss man die Tools noch nachinstallieren? Waere dann aber nicht kompliziert.)

Weder die Version 1.0.1.0 noch die Version 1.0.1.1 haben Compieler und andere Build-Tools. Die Systeme beruhen auf das Projekt OpenPCTV (Opembricks). So in etwa wie OpenELEC. Bin gespannt wie man daraus eine Build-Umgebung machen kann.

Zitat von S:oren

Nun sollte das u-boot den neuen Kernel mit Devicetree starten...

Vielen Dank für die Ausführungen. Ohne diese wäre ich als normaler Anwender nicht weit gekommen.

Zitat von wino

Weder die Version 1.0.1.0 noch die Version 1.0.1.1 haben Compieler und andere Build-Tools.

Hm. Dann habe ich das falsch in Erinnerung, tut mir leid. Dann muss ich wohl eines der Ubuntu-Systeme benutzt haben. Ist schon lange her, sorry!

S:oren

Hallo S:oren,

Zitat von S:oren

Hm. Dann habe ich das falsch in Erinnerung, tut mir leid. Dann muss ich wohl eines der Ubuntu-Systeme benutzt haben. Ist schon lange her, sorry!

Kein Problem. Werde bei dem TBS-Matrix-Ubuntu_14.04_V1.0.0.1 System das rootfs gegen das von Debian Jessie ersetzen und die ucl2.xml anpassen. Das sollte gehen.

MfG
wino

Ich habe mir gerade nochmal das TBS-Matrix-Ubuntu_12.04_V1.0.0.1-V21 installiert, das war vermutlich das System, was ich damals benutzt habe. Ist ja jetzt auch anscheinend noch das neueste stabile Ubuntu-System von TBS. Vielleicht will ja jemand nochmal damit probieren, ob alles so wie beschrieben funktioniert.

Aber he, wir wissen ja jetzt alle, wie man u-boot und Kernel installiert und zum Laufen bringt, auch auf beliebigen anderen Systemen

Gruss,
S:oren