Archive for the ‘Links die man kennen sollte’ Category

CP/M auf dem Arduino Due mit RunCPM bzw. CPMDunino

17. April 2017

CP/M auf kleinen Mikrocontroller-Systemen erregen immer meine Neugier – wie damals auch der AVR-„Stick“ den ich von Peter Sieg gekauft hatte:
http://petersieg.bplaced.com/?AVR_CP%2FM

Dieser war wohl mit aus dem Thread bei mikrocontroller.net entstanden:
https://www.mikrocontroller.net/topic/177481
https://www.mikrocontroller.net/articles/AVR_CP/M

Einige Experten haben den auch wohl weiterentwickelt und Platinen gebaut – aber es ging wohl nie in die Masse und selber bauen kann ich es nicht 😦

So fand ich es nun spannend vom CPMduino (RunCPM) zu lesen.

Da reicht ein „einfacher“ Arduino DUE (fuer bis zu 64K Ram unter CP/M 2.2) und ein SD-Reader per SPI und schon kann man CP/M nutzen.
Ein-/Ausgabe per seriellem Port bzw. virtueller serieller Port ueber den USB-Anschluss.

Weiterer Vorteil: keine DiskImages 🙂 Alles per FAT32 auf der SD-Karte. Laufwerke A: – P: sind Verzeichnissse auf der SD-Karte.

Mit ext. MicroSD-Reader Modul am DUE sieht es noch leicht fragil aus….

Leider etwas fragil – aber zum Glueck hat der SD-Card Shield da direkt die richtigen Kontakte

aber ein anderer User hat einfach ein SD-Card Shield genommen und so sieht es fuer mich schon ganz robust aus 🙂

So gefaellt mir das „Gespann“ schon besser 🙂

CPMduino Original-Seite mit dem ext . MicroSDS-Modul:
https://github.com/MockbaTheBorg/CPMduino
https://hackaday.io/project/19560-z80-cpm-computer-using-an-arduino
https://hackaday.io/project/3709-cpmduino

Nachbau mit dem SD-Card Shield:
http://weblambdazero.blogspot.com.tr/2016/07/cpm-on-stick_16.html

Aus dem CPMduino wurde dann auch RunCPM fuer Win, OSX, Linux, Arduino DUE, Teensy 3.5 & 3.6:#
https://github.com/MockbaTheBorg/RunCPM
https://hackaday.io/project/18291-runcpm

So habe ich mir aus England 2 Arduino DUE Clones bestellt und passende SD-Card-Shield wie im Beitrag gab es leider nur direkt aus China.

Die DUE aus England kamen natuerlich flotter an, als die SD-Shields aus China – aber heute war es dann soweit 🙂
Dafuer hatte ich beim Kauf nicht gesehen, dass der SD-Shield nicht nur einen grossen SD-Card-Slot hat, sondern auch einen Mico-SD-Card-Slot mit Federeauswurf.
Hersteller ist hier imall.iteadstudio.com fuer den „Stackable SD Card Shield V3.0“

Hardware „zusammengebaut“ bzw. zusammengesteckt – Schalter auf 3.3V neben dem 2ten Reset

Durch die grosse SD-Karte sieht man den Micro-SD-Slot nicht mehr

Hier sieht man einigermassen das Alignment der Pins der 2 Platinen

Nachdem ich meiner Arduino-IDE (unter Linux) den Arduino DUE bekannt gemacht hatte und den .ZIP Mirror des RunCPM-GitHub entpackt hatte, wurde RunCPM auf den DUE – nach dem compilieren- uebertragen ueber den „Programmier“-Port (denn der DUE hat auch noch einen „native“ Micro-USB-Port).

Zum Einsatz kam danach bei mir eine frische 4GB Micro-SD-Karte mit SD-Card-Adapter im FAT32-Format.
Darauf musste die Datei CCP-CCPZ.64K ins Root-Verzeichnis [1]
Die Laufwerke A: – P: werden normal mit Verzeichnissen mit den Namen A – P dargestellt.

Die vorgegebene Version nutzt „User-Space“ [2] , so dass die .COM-Dateien in ein Verzeichnis Namens 0 (=Null) muessen, damit diese ueber den Befehl DIR ausgegeben werden koennen

Nachdem nun Arduino und SD-Karte vorbereitet waren konnte der Rechner gestartet werden – OK erst nach der Installation von minicom bei meinem Linux Mint Mate 18.1….bei Windows koennte man sich mit puTTY zum virtuellen COM-Port verbinden.
Bei Linux startet man die Verbindung mit
minicom -b 9600 -o -D /dev/ttyACM0

Dazu nutzt man auch wieder den „Programmier-Port“ des Arduino DUE und nicht den „native“ Mico-USB-Port.

Und schon kann man loslegen, CP/M zu nutzen 🙂
Ulkigerweise zeigt RunCPM als „Build“ den Zeitpunkt an, zu dem die Arduino-IDE das .INO compiliert hat, so muss man sich – fuer alles andere – auf die RunCPM Version (hier 2.8) verlassen.

PS: Die Consolen-Geschwindigkeit kann man direkt in der RunCMD.ino editieren, in dem man die Baudrate von 9600 Baud:
Serial.begin(9600);
auf 19200 Baud erhoeht:
Serial.begin(19200);

Mehr habe ich noch nicht getestet, da ich mir nicht sicher bin ob es dabei einen Handshake gibt oder ob bei hoeheren Baudraten Zeichen verschluckt werden.

RunCPM nach dem Start

[1] diese Version deshalb, weil diese in dem runtergeladenen Source-Code (Datei globals.h) eingestellt war.
Lieber haette ich die CCP-DR.60K genutzt, eine Version von Digital Research mit „nur“ 60Kb RAM, aber dafuer mit einer kompatibleren Speicher-Map.

[[EDIT]]
Die Anpassung kann man machen, wenn man die RunCPM.ino geladen hat und dann in die include-Datei globals.h geht und dort die entsprechenden Aktivierungs-/Konfigurationszeilen (de-)aktiviert.

Ich habe hier mal beispielhaft die DR-Version und 60Kb Speicher aktiviert und die anderen Konfigurationen durch // auskommentiert:


/* Definition of which CCP to use: INTERNAL, DR or ZCPR (must define only one) */
// #define CCP_INTERNAL // If this is defined, CCP will be internal
#define CCP_DR
// #define CCP_CCPZ
// #define CCP_ZCPR2
// #define CCP_ZCPR3
// #define CCP_Z80

#define SIZEK 60
// #define SIZEK 64
// Can be 60 for CP/M 2.2 compatibility or more, up to 64 for extra memory
// Can be set to less than 60, but this would require rebuilding the CCP
// For SIZEK<60 CCP ORG = (SIZEK * 1024) – 0x0C00


The 64K version provides the maximum amount of memory possible to CP/M application, but its addressing ranges are unrealistic in terms of emulating a real CP/M computer.
The 60K version provides a more realistic addressing space, keeping the CCP on the same loading address it would be on a similar CP/M computer.
Other amounts of memory can be used, but this would require rebuilding the CCP binaries (available on disk A.ZIP). The CCP binaries are named with their extensions being the amount of memory they run on, so for example, DRI’s CCP runnin on 60K memory would be named CCP-DR.60K. RunCPM looks for the file accordingly depending on the amount of memory selected when it is built.

[2] RunCPM can emulate the user areas as well (this is the default), so to create the disk drives use the following procedures:

  • when using user areas – Create subfolders under the executable folder named „A“, „B“, „C“ and so on, for each disk drive you intend to use, each one of these folders will be one disk drive, and under folder „A“ create a subfolder named „0“. This is the user area 0 of disk A:, extract the contents of A.ZIP package into this „0“ subfolder.

 

Sheevaplug im Jahr 2017

18. Januar 2017

Vor langer Zeit hatte bei einem Angebot zugeschlagen und eine Reserve-Sheeva angeschafft.
Die lag nun eine lange Zeit rum und nun packte mich kurz die Installationslust 🙂

Als erstes wurde wie bei meinem ersten Sheevaplug das „U-Boot“ upgedated auf die Version
https://people.debian.org/~tbm/u-boot/2013.10-2/sheevaplug/

u-boot.kwb              2013-10-21 21:13  374K  
uboot.elf               2013-10-21 21:13  406K

[EDIT]
Martin Michlmayr told me via eMail that a newer u-boot does exist:
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 – 21:57:04)

This version for the SheevaPlug can be found at
http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/u-boot/sheevaplug/u-boot.kwb

u-boot.kwb 2017-01-10 21:38 419K

as stated on this u-boot Upgrade-Page
http://cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/

The file ist timestamp 2017 , but its the last version from 2014 🙂

After updating my SheevaPlug with this version I had to reconfigure it to boot from SD-Card:

setenv bootargs_console console=ttyS0,115200
setenv bootcmd_mmc 'ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd'
setenv bootcmd 'setenv bootargs ${bootargs_console}; run bootcmd_mmc; bootm 0x00800000 0x01100000'
saveenv
reset

After using the u-boot from 2014 I hadnt to include the  „mmc init“ in front of my bootcmd_mmc.


Das musste ich mit einem Windows XP Rechner machen, da Windows 10 die veraenderten .inf Dateien fuer den seriellen USB-Port nicht mochte.

Danach habe ich mit dem debian-Installer

uImage 2017-01-10 21:34 2.0M
uInitrd 2017-01-10 21:34 5.1M

vom USB-Stick auf die 8GB Sandisk-SD-Karte installiert per
usb start
fatload usb 0:1 0x00800000 /uImage
fatload usb 0:1 0x01100000 /uInitrd 

Nach der Installation muss man zum booten noch einige env-Variablen setzen/speichern.
Gesagt getan, aber leider blieb die Sheeva beim laden des uImage mit dem Fehler
** Bad device size – mmc 0 **
stehen 😦

Nun kam mir in den Sinn, dass es aehnliche Meldungen/Probleme gab, wenn man den Installer von USB starten will, aber kein
usb start
der Sheeva mitgegeben hat.

Ein aehnlicher Befehl fuer den SD-Slot lautet
mmc init

Nach dem „mmc init“ konnte ich manuell das uImage erfolfgreich laden 🙂

So lag es nahe den env-Eintrag fuer die Boot-Commandos vorne zu erweitern um das mmc init:
setenv bootcmd_mmc ‚mmc init; ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd‘

(Hochkommata am Anfang auch oben… WordPress macht es hier in der Ansicht vorne nach unten.
Kann es leider hier nicht als „Code“ formatieren)

Danach ein
saveenv
reset

Und schon bootete die Sheevaplug brav direkt in ihr Debian:

Linux sheevatwo 3.16.0-4-kirkwood #1 Debian 3.16.39-1 (2016-12-30) armv5tel GNU/Linux

 

Samsung SM-T900 Tab Pro mit CyanogenMod 13 und 14.1

29. Dezember 2016

Mein 12.2″  Samsung Galaxy TabPRO SM-T900 hatte lange Zeit CyanogenMod 12 drauf und es tat sich nicht mehr viel bei den Updates (ausser Fehlerbereinigung).

War nicht schlimm, denn das Geraet lief ja prima damit.

Nun sich der User „thompatry darum gekuemmert, dass das SM-T900 auch
CyanogenMod 13 aka Android 6.0 bekommt:
http://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/rom-6-0-xsm-t900-unofficial-cyanogenmod-t3472393

Hierzu hatten einige Forum-User (inkl. mir) ihm Geld fuer ein SM-T900 spendiert (donated), da er „nur“ ein aehnliches Modell (SM-P900) hatte.

Jetzt war er so fleissig, dass kurz nach den ersten Fehlerbehebungen fuer CM13 nun schon
– quasi als Weihnachtsgeschenk 2016 –
CyanogenMod 14.1 aka Android 7.1.1 fertig ist:
http://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/rom-7-1-xsm-t900-unofficial-cyanogenmod-t3524853

Dieses habe ich nun installiert und es laeuft fuer das erste Release praechtig 🙂

CyanogenMod 14.1 auf dem SM-T900

CyanogenMod 14.1 auf dem SM-T900

Risc OS Pi: 10″ WaveShare HDMI-Display und analog Audio

27. November 2016

Nachdem ich mein 10″ Waveshare-Display

10" IPS WaveShare Display

10″ IPS WaveShare Display

http://www.waveshare.com/product/mini-pc/raspberry-pi/expansions/10.1inch-hdmi-lcd-b-with-case.htm
mit der Aufloesung 1280×800 am Raspberry Pi mit Risc OS in voller Aufloesung zum laufen bekommen habe, war es nun etwas ruhig – da das WaveShare-Display kein HDMI-Audio unterstuezt 😦

Leider gibt es wenige Seiten, auf denen genau dieses Problem zu finden ist und meist haben die User keine Loesung gefunden, denn entweder gibt es
– HDMI und digitalen Ton ueber den HDMI-Stecker
oder
– Composite-Video und analog-Audio ueber die 3.5mm Audio-Buchse

aber HDMI-Bild und analoges Audio? Da wird es wohl fuer viele kniffelig, auch wenn man sich die gute Uebersicht der in der CONFIG.TXT moeglichen Befehle ansieht auf:
http://elinux.org/RPiconfig

Nach waelzen vieler Seiten und Suchen ueber Google, fand ich dann doch am Ende dieses Threads
https://www.riscosopen.org/forum/forums/11/topics/1865?page=2
meine Loesung 🙂

An die vorhanden Zeilen in der CONFIG.TXT der RC14-Distribution von
Risc OS Pi werden folgende Zeilen angehaengt:

# Start – CONFIG.TXT Erweiterung
# ———————————————————-
hdmi_force_hotplug=1
hdmi_group=2
# mode 17 = 1024×768
#hdmi_mode=17
# mode 28 = 1280×800 60Hz
hdmi_mode=28
#Uncomment lines below for analog audio output
hdmi_ignore_edid_audio=1
disable_audio_dither=1
#Uncomment lines below for HDMI audio output
#hdmi_drive=2
#hdmi_force_edid_audio=1
# ———————————————————-
# Ende – CONFIG.TXT Erweiterung

Damit bekommt man beim Start von Risc OS und dem BeebIt-Emulator auch immer gleich den
„BEEB“/“BEEP“ zu hoeren….. natuerlich geht auch dann ansonsten der Ton in Risc OS 🙂

 

 

1280×800 Aufloesung fuer Waveshare 10 Zoll IPS Display mit dem Raspberry Pi unter RiscOS Pi

23. November 2016

RiscOS RC14 ist zur Zeit nur fuer den Raspberry Pi2, kann aber auch durch patchen mit dem Raspberry Pi 3 genutzt werden.
Die wird ja auch demnaechst noetig, wenn der Pi2 mit der CPU des Pi3 daher kommt.

Das 10 Zoll Waveshare-IPS-Display ( http://www.waveshare.com/wiki/10.1inch_HDMI_LCD_(B)_(with_case) ) hat eine Aufloesung von 1280×800, aber RiscOS Pi bietet bei dem „Generic“-Monitor nur die Aufloesungen 1280×720 und 1280×1024.

Wenn man also mit dem normalen 1280×720 Einstellungen den Waveshare Monitor benutzt, bekommt man oben und unten einen Trauerrand 😦

Also habe ich mich auf die Suche gemacht, wie ein Teil eines MDF (Monitor Definition File) aussehen muss um 1280×800 bei 60 Hz darstellen zu koennen.

Nachdem ich diese gefunden habe, hier nun eine kleine Anleitung, wo man welches File editiert und die Aufloesung dann auswaehlt:

– Doppel-Klick auf die SD-Card
 
– Nun Shift gedrueckt halten und folgende Ordner oeffnen:
1.) !Boot
2.) Resources
3.) Configure
4.) Monitors
5.) Other
 
Nun die Shift-Taste loslassen und per Doppel-Klick das MDF „Generic“ zum editieren oeffnen (oeffnet sich im StrongEd)
 
Folgenden Definitionsblock am besten hinter die Definition des 1280×720 Monitor-Aufloesungseintrages kopieren:
# 1280 x 800 Waveshare 10 Zoll
startmode
mode_name:1280 x 800 Waveshare 10
x_res:1280
y_res:800
pixel_rate:71000
h_timings:32,80,0,1280,0,48
v_timings:6,14,0,800,0,3
sync_pol:2
endmode
 
Auf das Diskettensymbol zum speichern druecken
 
Reboot des RiscOS (mittlere Maustaste auf die Himbeere – Shutdown -> Restart)
 
Um den neuen Screen-Mode nun auszuwaehlen geht Ihr folgenden Weg:
 
Oeffenen von (ohne Shift zu halten) 
1.) !Configure
2.) Screen
dann auswaehlen
Montortype : Generic
Colours    : 16 Million
Resolution : 1280 x 800 Waveshare 10
Frame rate : 60 Hz
 
Nun klicken auf  „Try“, „Continue“, „Keep“, „Set“
Fertig 🙂 dann sollte es wie folgt aussehen….
RiscOS auf dem WaveShare 10 Zoll Display

RiscOS auf dem WaveShare 10 Zoll Display

Source for buying a Raspberry Pi in Turkey

5. Juli 2016

After asking in a german Raspberry Pi Group where to buy a Raspberry Pi in Turkey someone told me the following good link:

samm teknoloji

samm teknoloji

http://www.samm.com/tr/raspberry-pi.html

Address:

Samm Technology Communications Industry and Trade Inc.

Gebze Organize Sanayi Bölgesi (GOSB) İhsandede Cd. 800. Sok No: 802

41430 Gebze-Kocaeli, Turkey

Tel: 444 17 26
Tel: +90 (262) 751 25 62
Fax: +90 (262) 751 25 62

At this time this seems for me the only company which sells the Raspberry Pi 3 for a good price against the prices on the turkish „ebay“ http://www.gittigidiyor.com

If someone knows some better stores please tell me your suggestions 🙂

CyanogenMod 12.1 fuer das Samsung Galaxy Tab Pro 12.2 in 2016

14. Februar 2016

In 2015 gab es schon mal eine Version 12.1, die nun aktualisiert wurde.

Vor langer Zeit hatte ich mein Samsung Galaxy Tab Pro 12.2 (SM-T900) mit CyanogenMod versehen:
https://lehwalder.wordpress.com/2014/11/25/cyanogenmod-11-fuer-samsung-galaxy-tab-pro-12-2-sm-t900/

Die Version 12.1 (Android 5.1.1) aus 2015 war schon gut, diese neue Version aus 2016 wird laut Forum evtl. die letzte vor der CyanogenMod Version 13 sein (soll vom SM-P900 herueber portiert werden).

Die 12.02.2016er Version (auch 237MB) liegt unter
https://drive.google.com/folderview?id=0BxqoBZiUYroBT25FQ2lNVS1jbzQ&usp=sharing

Jetzt gibt es auch eine Version vom 03.404.2016:
cm-12.1-20160403-UNOFFICIAL-v2wifixx.zip
3 April  zuletzt bearbeitet von Thomas Patry

Der Eintrag im Forum zur Version liegt unter
http://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/cyanogenmod-tab-pro-12-2-sm-t900-t2914975/page71
CyanogenMod 12.1 2016er Version

CyanogenMod 12.1 2016er Version

Link fuer Konfigurationsdateien WLAN mit dem RPi

10. Januar 2016

https://www.datenreise.de/raspberry-pi-wlan-einrichten-edimax/

sudo nano /etc/modprobe.d/8192cu.conf
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "DEIN-WLAN-NAME"
wpa-psk "DEIN-WLAN-SCHLÜSSEL"

sudo nano /etc/resolv.conf
domain fritz.box
search fritz.box
nameserver 192.168.6.1

 

EDIMAX EW-7811UN Schlafmodus ausschalten in Raspbian

7. Februar 2015

Da ich nun bei meinem Raspberry Pi2 mit dem vorhandenen EDIMAX EW-7811UN wieder das WLAN auf einmal ausgehen sah, hier eine kleine Notiz an mich:
(zum einfacheren finden fuer mich hier anstatt auf der Original-Seite
http://www.datenreise.de/raspberry-pi-wlan-einrichten-edimax/ )

Der  EDIMAX EW-7811UN hat ein RTL8188CUS Chipset, welches unter Raspbian mit dem Treiber RTL8192cu bedient wird.

Um nun das Power-Management zusaetzlich zur /etc/networrk/interfaces im Treiber auszuschalten erzeugt man unter /etc/modprobe.d die Datei 8192cu.conf die folgenden Inhalt haben sollte:
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

Hat man diese mit vi oder nano erstellt, bootet man noch mal den Pi(2) und die
USB-Netzwerkkarte sollte nicht mehr in den Schlafmodus gehen.
Links hierzu:

http://www.stumpe.de/Raspberry-PI-WLAN-Einrichten.html
http://www.datenreise.de/raspberry-pi-wlan-einrichten-edimax/
http://raspberrypi.stackexchange.com/questions/6957/how-to-disable-raspberry-pi-power-management
http://www.raspberrypi.org/forums/viewtopic.php?t=51543&p=397663

Cyanogenmod 11 fuer Samsung Galaxy Tab Pro 12.2 SM-T900

25. November 2014

Da ich die Woche wegen Husten/Grippe etwas ausspannen muss, aber die gute Zwischenzeit nutzen moechte, hatte ich heute mal nach dem Stand von Cyanogenmod fuer mein Tab Pro 12.2 geschaut.
Bis jetzt hatte mich die Samsung-Bloatware und die ganzen Begrenzungen/Einschraenkungen doch sehr geaergert bei einem (als ich kaufte) hochpreisigen Geraet, so dass ich dagegen was tun wollte – wie auf meinem Note2.

So bekam ich zu lesen, dass am 20.11.2014 die Version 4 des unofficial CyanogenMod 11 fuer das Tab Pro 12.2 die Welt erblickte und auf dem stable Milestone M12 basiert:

Version 4 Released
http://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/cyanogenmod-tab-pro-12-2-sm-t900-t2914975
Version 4 is updated with working auto-rotate (thanks hondong) , and working native cyanogenmod camera app (thanks crpalmer). Source is updated to CyanogenMod 11.0 M12.

Die Version 4 ist zu finden als Download unter:
https://www.androidfilehost.com/?fid=95784891001614294

Natuerlich ist es mit dieser Datei nicht getan 🙂
Als erstes braucht man den Flasher Odin in der Version 3.07 um damit das Custom Recovery auf das Tab Pro 12.2 zu flashen.

Da ich mit dem ClockworkMod, der in dem Thread oben bei der Version 4 genannt wurde als Recovery, nicht so gut zurecht komme nutze ich lieber den Custom Recovery TWRP 2.8.0.0 – den gibt es nun auch fuers Tab Pro 12.2

Odin 3.07 bekommt man unter
http://forum.xda-developers.com/attachment.php?attachmentid=1168421

TWRP 2.8.0.0 bekommt man unter
http://www.techerrata.com/file/twrp2/v2wifixx/openrecovery-twrp-2.8.0.0-v2wifixx.img.tar

Am besten laedt man als „Vorarbeit“ die Version 4 des unoffical Cyanogenmod 11 und die „aktuelle“ Google-Apps-Datei  fuer Kitekat Android 4.4.x auf die (externe) SD-Karte des Tab Pro 12.2.
normale Verision mit „vielen“ Google-Apps:
http://itvends.com/gapps/gapps-kk-20140606-signed.zip

oder die „small“-Version, die nur die wichtigsten Google-Apps beihaltet, wie den Google Market bzw. Play Store:
http://itvends.com/gapps/gapps-kk-20140105-signed.zip

Nun geht man nach folgender Odin-Flash-Anleitung vor und ersetzt beim auswaehlen die Root-Datei durch das TWRP-Custom Recovery:
http://androidcentral.us/2014/05/root-galaxy-tab-pro-12-2-sm-t900/

Rooten braucht man ja bei CyangenMod ja nicht mehr 🙂

Wenn man so nun den TWRP 2.8.0.0 installiert hat und das Tab aus ist, dann drueckt man (wie immer bei einem Custom-Recovery) Volume-UP/Home und Power zusammen und laesst Power los, wenn das TWRP Logo erscheint.

Nun kann man Dalvik, Cache, Data und System im Advanced Wipe loeschen.
Danach installiert man die Version 4-Datei und die Google-Apps.ZIP Datei.

Nach der Installation der 2 Dateien rebootet man ueber das Menue das „System“.

Danach bootet das Tab Pro 12.2 nicht mehr, nach dem SM-T900 Einschalt-Model-Logo, nicht mehr mit der Samsung Boot-Animation – sondern der bekannten vom CyanogenMod.

Hat man alles (Google und CyanogenMod-Konto) eingerichtet, dann kann man in den Einstellungen sich ueber Android 4.4.4 freuen:

Version 4 auf dem SM-T900

Version 4 auf dem SM-T900

hier noch eine groesser Anzeige der Versionsnummer

hier noch eine groesser Anzeige der Versionsnummer