Wie Apple Lightning funktioniert





Dies ist mein kleiner Artikel, der (fast) alles beschreibt, was ich über die Apple Lightning-Oberfläche und verwandte Technologien weiß: Tristar, Hydra, HiFive, SDQ, IDBUS usw. Aber zuerst eine kleine Warnung ...



Lesen Sie diesen Artikel auf eigenes Risiko! Die Informationen basieren auf vielen internen Apple-internen Materialien (Datenlecks, Schaltpläne, Quellcodes), die ich diagonal gelesen habe. Und natürlich auf meine eigene Forschung. Ich muss Sie warnen, dass ich noch nie zuvor solche Nachforschungen angestellt habe. Daher verwendet dieser Artikel möglicherweise falsche oder einfach seltsame Begriffe und ist teilweise oder vollständig falsch!



Bevor wir tiefer eintauchen, wollen wir kurz die Begriffe verstehen:



Was ist Blitz?







Lightning ist die digitale Schnittstelle, die seit Ende 2012 in den meisten Apple iOS-Geräten verwendet wird. Es ersetzte den alten 30-poligen Stecker.



Das Bild oben zeigt die Anschlussbuchse und das Bild unten zeigt die Pinbelegung:







Bitte beachten Sie, dass im Anschluss die Stifte auf beiden Seiten des Anschlusses nicht in derselben Reihenfolge angeschlossen sind. Daher muss das Host-Gerät die Ausrichtung des Kabels bestimmen, bevor etwas unternommen wird.



Dies ist zwar nicht immer der Fall. Viele Lightning-Zubehörteile, auf die ich gestoßen bin, haben gespiegelte Pinbelegungen in den Anschlüssen.



Was sind Tristar und Hydra?







Tristar ist eine integrierte Schaltung, die in jedes Gerät mit einem Lightning-Anschluss integriert ist. Es handelt sich im Wesentlichen um einen Multiplexer: Der







Hauptzweck besteht unter anderem darin, die Verbindung zum Lightning-Stecker herzustellen, sobald dieser eingesteckt ist - um die Ausrichtung, die Zubehör-ID zu bestimmen und interne Schnittstellen wie USB, UART und SWD ordnungsgemäß zu verlegen.



Hydra ist eine neue Variante von Tristar, die seit dem iPhone 8 / X verwendet wird. Die wahrscheinlich bedeutendste Änderung ist die Unterstützung des kabellosen Ladens, dies muss jedoch noch überprüft werden:







Mir sind fünf Hauptvarianten des Tristar / Hydra bekannt:



  • TI THS7383  - Tristar der ersten Generation in iPad mini 1 und iPad 4

  • NXP CBTL1608A1  - Tristar der ersten Generation für iPhone 5 und iPod touch 5

  • NXP CBTL1609A1  - mysteriöser Tristar der ersten Generation in iPod nano 7 - Quelle

  • NXP CBTL1610Ax  - TriStar der zweiten Generation, seit dem iPhone 5C / 5S verwendet und anscheinend in allen anderen Bereichen , die das kabellose Laden nicht unterstützen. Es gibt mehrere Generationen (x ist die Generationsnummer)

  • NXP CBTL1612Ax  - Hydra wird mit dem iPhone 8 / X und anscheinend allem anderen verwendet, das das kabellose Laden unterstützt. Es gibt mehrere Generationen (x ist die Generationsnummer)


Von nun an werde ich nur noch den Begriff TriStar verwenden, aber denken Sie daran, dass er auch für Hydra steht, da sie in den meisten Aspekten, die in diesem Text behandelt werden, sehr ähnlich sind.



Was ist HiFive?







HiFive ist ein Kind von Lightning, dh ein Steckverbinder. Es enthält auch ein Logikgatter - dieser Chip ist als SN2025 / BQ2025 bekannt.



Was sind SDQ und IDBUS?







Die beiden Begriffe werden oft als Synonyme angesehen. Der Einfachheit halber werde ich nur den Begriff IDBUS verwenden, da er mir korrekter erscheint (und so wird die Technologie in der THS7383-Spezifikation genannt).



IDBUS ist also ein digitales Protokoll für die Kommunikation zwischen Tristar und HiFive. Sehr ähnlich dem Onewire-Protokoll .



Jetzt können wir anfangen



Hören wir uns die Kommunikation mit Tristar und HiFive an. Besorgen Sie sich einen Logikanalysator, einen Lightning-Riser mit Buchse und Stecker, ein Zubehör (ein normales Lightning-zu-USB-Kabel funktioniert hervorragend) und natürlich ein Gerät mit einem Lightning-Anschluss.



Verbinden Sie zuerst die Logikanalysatorkanäle mit beiden ID-Leitungen des Risers (Pins 4 und 8) und verbinden Sie die Karte mit dem Gerät, schließen Sie das Zubehör jedoch noch nicht an:







Beginnen Sie unmittelbar danach mit der Abtastung (jede Frequenz von 2 MHz oder höher reicht aus). Sie werden so etwas sehen:







Wie Sie sehen können, fragt Tristar nacheinander jede ID-Zeile ab. Da wir jedoch kein Zubehör angeschlossen haben, ist die Umfrage eindeutig fehlgeschlagen. Irgendwann wird das Gerät diesen endlosen Strom von Fehlern satt und stoppt ihn. Lassen Sie uns zunächst sehen, was genau während der Umfrage passiert:







Zuerst sehen wir ein langes Intervall (ca. 1,1 Millisekunden), in dem der Pegel nur hoch ist, aber sonst nichts passiert:







Anscheinend wird diese Zeit verwendet, um den internen HiFive-Kondensator aufzuladen - die Energie daraus wird dann verwendet, um die internen Logikchips mit Strom zu versorgen.



Viel interessanter ist, was als nächstes passiert:







Offensichtlich ist dies ein Datenstrom. Aber wie ist es zu interpretieren? Wie entschlüsseln? Teilen wir es virtuell in minimale signifikante Teile auf - was ich Wörter nenne :







Tatsächlich ist ein Wort eine Kombination aus Fallen, Steigen, Fallen:







  • Inhaltsphase - das Intervall, das die Bedeutung des Wortes bestimmt

  • Wiederherstellungsphase - das Intervall, das anscheinend erforderlich ist, um die Inhaltsphase auf der Empfängerseite zu verarbeiten und / oder das nächste Wort in der Sendephase vorzubereiten


Hier ist eine Tabelle berühmter Wörter mit ihrem Abstand für beide Stufen, die wir oben besprochen haben (alle Einheiten in Mikrosekunden):



Inhalt Wiederherstellung
Wort Mindest Typ Max Mindest Typ
BRECHEN 12 vierzehn Sechszehn 2.5 4.5
AUFWACHEN 22 24 27 1100?
NULL 6 7 8 3
EINER 1 1.7 2.5 8.5
NULL und STOP * 6 7 8 Sechszehn
ONE und STOP * 1 1.7 2.5 21
* STOP wird verwendet, wenn dies das letzte Bit in einem Byte ist. Aus



der obigen Tabelle können wir nun einen einfachen Protokolldecoder erstellen:







Wie Sie sehen, sendet der Host zuerst einen BREAK - wenn Tristar eine neue Anforderung senden möchte, beginnt der Host immer mit diesem Wort. Dann kommt die Datenübertragungsphase. Bitte beachten Sie, dass das letzte (8.) Bit in einem Byte eine längere Wiederherstellungsphase hat. Wenn die Datenübertragungsphase endet, sendet der Host einen weiteren BREAK. Das Kind muss dann eine Antwort senden (nach einer Verzögerung von mindestens 2,5 Mikrosekunden - siehe Tabelle). Tristar wartet ca. 2,2 ms auf eine Antwort. Wenn innerhalb dieses Zeitraums keine Antwort erfolgt, versucht Tristar, eine andere ID-Zeile abzufragen.



Betrachten wir nun die Datenphase anhand des obigen Beispiels 0x74 0x00 0x02 0x1f:



  • 0x74 - Art der Anfrage / Antwort. Immer gerade für eine Anfrage und ungerade für eine Antwort (Anfragetyp +1)

  • 0x00 0x02 - Sachdaten. Kann leer sein

  • 0x1f - Dies ist der CRC8 sowohl des Anforderungstyp-Bytes als auch aller Daten (Polynom - 0x31, Anfangswert - 0xff).


Lassen Sie uns ein Zubehörteil an unser Rig anschließen und sehen, was passiert. Ich werde Apples originales Lightning-to-USB-Kabel verwenden:







Und hier ist, was auf IDBUS nach der 0x74-Anfrage erscheint:







HiFive hat geantwortet! Wenn Sie weiter scrollen, werden viele andere Anforderungs- / Antwortpaare angezeigt:







Einige Anforderungen benötigen keine Antwort:







IDBUS-Anfragen und -Antworten interpretieren



Die wichtigste IDBUS-Anforderung ist 0x74. Sie wird für zwei Zwecke verwendet: um HiFive anzuweisen, die volle Spannung und Stromstärke einzuschalten (sofern dies vom Zubehör unterstützt wird), um die vom Kabel unterstützte Pin-Konfiguration und einige andere Metadaten zu erfragen.



Es ist nicht viel darüber bekannt, wie die 0x75-Antwortdaten codiert werden. In der alten Tristar-Spezifikation sind jedoch einige Bits verfügbar:



Erstes Antwortdatenbyte 0x75

7 6 fünf 4 3 2 1 0
ACCx Dx DATEN [43:40]


ACCx-Konfiguration, wenn ID auf ID0 gefunden wird

ACCx [1: 0] ACC1 ACC2 HOST_RESET
00 Hi-Z (IDBUS) Hi-Z Hi-Z
01 UART1_RX UART1_TX Hi-Z
zehn JTAG_DIO JTAG_CLK Hi-Z
elf Hi-Z Hi-Z HOCH


ACCx-Konfiguration, wenn ID auf ID1 gefunden wird

ACCx [1: 0] ACC1 ACC2 HOST_RESET
00 Hi-Z Hi-Z (IDBUS) Hi-Z
01 UART1_RX UART1_TX Hi-Z
zehn JTAG_DIO JTAG_CLK Hi-Z
elf Hi-Z Hi-Z HOCH


Dx-Konfiguration, wenn ID auf ID0 gefunden wird

Dx [1: 0] DP1 DN1 DP2 DN2
00 Hi-Z Hi-Z Hi-Z Hi-Z
01 USB0_DP USB0_DN Hi-Z Hi-Z
zehn USB0_DP USB0_DN UART1_TX UART1_RX
elf Hi-Z Hi-Z Hi-Z Hi-Z


Dx-Konfiguration, wenn ID auf ID1 gefunden wird

Dx [1: 0] DP1 DN1 DP2 DN2
00 Hi-Z Hi-Z Hi-Z Hi-Z
01 Hi-Z Hi-Z USB0_DP USB0_DN
zehn USB0_DP USB0_DN UART1_TX UART1_RX
elf Hi-Z Hi-Z Hi-Z Hi-Z


Entschlüsseln wir anhand dieser Tabellen die ID unseres Kabels ( 10 0C 00 00 00 00) unter Berücksichtigung der Tatsache, dass sich die ID-Leitung am ID0-Pin befindet:



Das erste Byte der 0x75-Kabelantwort

7 6 fünf 4 3 2 1 0
ACCx Dx DATEN [43:40]
0 0 0 1 0 0 0 0


ACCx ist also 00. Dies bedeutet, dass der ID0-Pin einfach mit IDBUS verbunden ist, und Dx = 01 bedeutet, dass die DP1 / DN1-Pins als USB0_DP / USB0_DN konfiguriert sind. Genau das, was wir von einem Standard-USB-Kabel erwartet haben.



Lassen Sie uns nun etwas Interessanteres abfangen:



Zubehörteil ID (HOSTID = 1)
DCSD 20 00 00 00 00 00
KongSWD (kein Astris läuft) 20 02 00 00 00 00
KongSWD (mit Astris läuft) A0 00 00 00 00 00
KanziSWD (kein Astris läuft) 20 0E 00 00 00 00
KanziSWD (mit Astris läuft) A0 0C 00 00 00 00
Haywire (HDMI) 0B F0 00 00 00 00
UART wird aufgeladen 20 00 10 00 00 00
Blitz auf 3,5 mm / EarPods mit Blitz 04 F1 00 00 00 00


Hier ist eine vollständige (?) Liste der IDBUS-Anforderungen von @spbdimka :







Tipp 1 : Mit accctl:





Dies ist ein internes Apple-Dienstprogramm, das mit NonUI / InternalUI-Assemblys geliefert wird, können Sie problemlos die Eigenschaften eines Zubehörs einschließlich seiner ID abrufen . Sie können es jedoch nach dem Jailbreak problemlos auf jedem Gerät ausführen.



Tipp 2 : Mit diags können Sie ganz einfach die Pin-Konfiguration eines Kabels abrufen:



tristar -p




Bitte beachten Sie, dass dieser Befehl nur unter iOS 7+ verfügbar ist.



Tipp 3 : Sie können 0x74 / 0x75-Anforderungen / Antworten, die von SWD-Sonden generiert wurden, einfach verfolgen, indem Sie debugenv var auf 3 setzen:



astrisctl setenv debug 3


Dann sehen Sie auf dem virtuellen COM über das Kabel Folgendes:





HOSTID



In einer der obigen Tabellen sehen Sie die Erwähnung einer bestimmten HOSTID. Dies ist der 16-Bit-Wert, der in der 0x74-Anforderung übergeben wird. Es sieht so aus, als würde es auch die Antwort von HiFive beeinflussen. Zumindest wenn Sie einen ungültigen Wert festlegen (ja, dies ist bei Diags möglich), funktioniert HiFive nicht mehr damit:





Die KongSWD / KanziSWD-Firmware verfügt jedoch über eine Umgebungsvariable disableIdCheck, die Sie so konfigurieren können, dass die ungültige HOSTID ignoriert wird.



Wichtiger Hinweis: Kong und Kanzi haben HiFive nicht als dedizierten nicht programmierbaren Chip. Dieses Zubehör emuliert es mit einem Mikrocontroller und / oder FPGA, wodurch es einfach zu aktualisieren / neu zu programmieren ist.


AUFWACHEN



In der obigen Tabelle mit der Zubehör-ID können Sie sehen, dass Kong und Kanzi unterschiedliche Antworten senden, je nachdem, ob Astris ausgeführt wird oder nicht. Dies ist Apples interne Software zum Debuggen mit SWD-Sonden (oder Sonden). Wenn Sie diese Antworten anhand der obigen Tabellen entschlüsseln, werden Sie feststellen, dass sich die Sonde beim Start von Astris genau wie DCSD - USB auf D1-Leitungen verhält und UART auf D2-Leitungen debuggt. Wenn die Debug-Software ausgeführt wird, wechseln die ACCID-Leitungen zu SWD.



Was aber, wenn wir Astris starten möchten, nachdem die Sonde bereits mit dem Gerät verbunden ist? Was macht das Kabel? Wie wird zwischen ACC- und SWD-Leitungen umgeschaltet? Hier WAKE ins Spiel! HiFive (oder ein Gerät, das es emuliert) kann initiierenWAKE - und der IDBUS-Aufzählungsprozess wird erneut gestartet: Tristar sendet eine Anfrage 0x74, Kong / Kanzi antwortet mit einer neuen ID, Tristar bestätigt diese und sendet die ACC-Leitungen an die internen SWD-Leitungen (SoC muss dies natürlich auf physischer Ebene unterstützen).





Power Handshake



Das Letzte, was ich mir ansehen werde, sind die Power-Handshakes. Dies ist ein IDBUS-Anforderungs- / Antwortalgorithmus, den die Tristar-Kerneltreiber verwenden, bevor das Aufladen von Zubehör zugelassen wird.



Wenn das Lightning-Kabel nur irgendwo liegt, an das Ladegerät / den Computer angeschlossen, aber nicht an das Gerät angeschlossen ist, begrenzt HiFive den Strom auf dem PWR auf einen wirklich kleinen Wert (ca. 10-15 mA nach meinen Messungen). Um den vollen Strom zu aktivieren, muss die Anforderung 0x74 von Tristar ausgegeben und von HiFive verarbeitet werden. Für SecureROM / iBoot ist dies ausreichend, aber beim Laden des Kernels müssen zusätzliche Schritte unternommen werden:



  1. TriStar gibt zwei 0x70-Anforderungen aus

  2. Sobald die zweite Anfrage von HiFive verarbeitet und eine Antwort gesendet wird, wird der Strom für etwa 20 Millisekunden abgeschaltet

  3. Tristar 0x70, 0x80 . HiFive

  4. , Tristar,


: , . , . ,



ESN Tristar I2C



Ein weiteres Feature von Tristar, über das ich sprechen möchte, ist ESN. Dies ist ein kleiner Blob, den Tristar in seinem EEPROM speichert (auf CBTL1610A2 und höher). Sie können über IDBUS mit dem Serial Number Reader-Kabel abgerufen werden (oder Kanzi, sie sind bis auf unterschiedliche USB-PIDs und leicht unterschiedliche Gehäuse grundsätzlich gleich). Wenn Sie



diesen Blob an ttrs.apple.com senden , erhalten Sie einfach die Seriennummer des Geräts ... Dieser Mechanismus wird von Mitarbeitern des Apple Store / Apple Premium Reseller verwendet, um SN von toten Geräten abzurufen (wenn Tristar noch aktiv ist):







Was passiert auf IDBUS, wenn ein ESN empfangen wird, @spbdimka dokumentiert :





Ausbildung



Das Verfahren für "Firmware» ESN erforderte Tristar- Training (Provisioning). Die Diagnose erfolgt geräteseitig über EzLink empfangsseitig in drei Schritten.



Sie können den Status mithilfe von Diags überprüfen:



tristar --prov_stat




... und auch ESN bekommen:



tristar --esn




Übrigens haben Diags im Allgemeinen eine Vielzahl von Tristar-Befehlen (verfügbar seit iOS 7):





Tristar I2C



Tristar ist auf dem I2C-Bus verfügbar (Adresse 0x34 zum Schreiben, 0x35 zum Lesen). So interagieren Diag- und Kerneltreiber damit.



Über Register ist nicht viel öffentlich bekannt. Viele Informationen über die Registerkarte selbst können aus dem durchgesickerten iBoot-Quellcode abgerufen werden (nur für THS7383 - scheint abwärtskompatibel mit CBTL1608 zu sein - und CBTL1610), aber nicht viel darüber, was dort geschrieben werden muss, um interessante Ergebnisse zu erzielen.



Eine weitere Wissensquelle ist das Tristar-Modul aus Diags (das während der Ausführung einfach über SWD abgerufen werden kann). Zum Beispiel konnte ich die Bereitstellungs- und ESN-Lesealgorithmen umkehren. Dann habe ich dies als Ergänzung zu meiner Last für iBoot namens Lina implementiert :







Ich habe auch versucht, den ESN-Schreibalgorithmus zu ändern, bin aber gescheitert - der Mechanismus ist mir zu kompliziert. Code-Schnipsel von Lina finden Sie hier .



Elektrische Eigenschaften des Tristar



Der Tristar selbst wird von einer 1,8-V-Versorgung gespeist. Die Leitungen für IDBUS sind laut meinem Oszilloskop 3,0 V-tolerant:







Ohne eine Pegelverschiebungsschaltung ist es daher besser, nicht zu versuchen, mit IDBUS über 5 V-tolerante Geräte wie einige Arduino-Modelle zu kommunizieren ...



All Articles