Ini adalah artikel kecil saya yang menjelaskan (hampir) semua yang saya ketahui tentang antarmuka Apple Lightning dan teknologi terkait: Tristar, Hydra, HiFive, SDQ, IDBUS, dll. Tetapi pertama-tama, sedikit peringatan ...



Baca artikel ini dengan risiko Anda sendiri! Informasi ini didasarkan pada banyak bahan internal Apple internal (kebocoran data, skema, kode sumber) yang saya baca secara diagonal. Dan, tentu saja, berdasarkan penelitian saya sendiri. Saya harus memperingatkan Anda bahwa saya belum pernah melakukan penelitian seperti itu sebelumnya. Oleh karena itu, artikel ini mungkin menggunakan istilah yang salah atau hanya aneh dan sebagian atau seluruhnya salah!



Sebelum kita menyelam lebih dalam, mari kita pahami persyaratannya:

Apa itu Petir?

Lightning adalah antarmuka digital yang digunakan di sebagian besar perangkat Apple iOS sejak akhir 2012. Itu menggantikan konektor 30-pin lama.



Gambar di atas adalah soket konektor, dan gambar di bawah ini adalah pinout:







Harap dicatat bahwa pada konektor, pin di kedua sisi konektor tidak terhubung dalam urutan yang sama. Dengan demikian, perangkat host harus menentukan orientasi kabel sebelum melakukan apa pun.



Meskipun ini tidak selalu terjadi. Banyak aksesoris Lightning yang saya jumpai memiliki pinout cermin di konektor.

Apa itu Tristar dan Hydra?

Tristar adalah sirkuit terintegrasi yang terpasang pada setiap perangkat dengan konektor Lightning. Ini pada dasarnya adalah multiplexer:







Antara lain, tujuan utamanya adalah untuk terhubung ke konektor Lightning male segera setelah dicolokkan - untuk menentukan orientasi, ID Aksesori dan rute antarmuka internal yang benar seperti USB, UART dan SWD.



Hydra adalah varian baru dari Tristar, digunakan sejak iPhone 8 / X. Mungkin perubahan yang paling signifikan adalah dukungan untuk pengisian daya nirkabel, tetapi ini masih harus diverifikasi:







Saya mengetahui lima varian utama Tristar / Hydra:

• TI THS7383  - Tristar Generasi Pertama di iPad mini 1 dan iPad 4
  
  
• NXP CBTL1608A1  - Tristar generasi pertama di iPhone 5 dan iPod touch 5
  
  
• NXP CBTL1609A1  - Tristar generasi pertama yang misterius di iPod nano 7 - source
  
  
• NXP CBTL1610Ax  - TriStar generasi kedua, digunakan sejak iPhone 5C / 5S dan tampaknya dalam segala hal lain yang tidak mendukung pengisian daya nirkabel. Beberapa generasi ada (x adalah jumlah generasi)
  
  
• NXP CBTL1612Ax  - Hydra digunakan dengan iPhone 8 / X dan tampaknya segala sesuatu yang mendukung pengisian daya nirkabel. Beberapa generasi ada (x adalah jumlah generasi)

Mulai sekarang, saya hanya akan menggunakan istilah TriStar, tetapi perlu diingat bahwa itu juga singkatan dari Hydra karena mereka sangat mirip di sebagian besar aspek yang akan dibahas dalam teks ini.

Apa itu HiFive?

HiFive adalah anak dari Lightning, yaitu konektor plug. Ini juga berisi gerbang logika - chip ini dikenal sebagai SN2025 / BQ2025.

Apa itu SDQ dan IDBUS?

Kedua istilah ini sering dianggap sinonim. Untuk kenyamanan, saya hanya akan menggunakan istilah IDBUS, karena sepertinya lebih tepat bagi saya (dan inilah teknologi yang disebut dalam spesifikasi THS7383).



Jadi, IDBUS adalah protokol digital yang digunakan untuk komunikasi antara Tristar dan HiFive. Sangat mirip dengan protokol Onewire .

Sekarang kita bisa mulai

Mari kita dengarkan komunikasi Tristar dan HiFive. Dapatkan penganalisis logika, riser petir dengan jack dan konektor pria, aksesori (kabel Lightning-to-USB biasa berfungsi dengan baik), dan, tentu saja, perangkat dengan port Lightning.



Pertama, sambungkan saluran penganalisa logika ke kedua garis ID riser (pin 4 dan 8) dan hubungkan papan ke perangkat, tetapi jangan menghubungkan aksesori lagi:







Segera setelah itu, mulailah pengambilan sampel (frekuensi dari 2 MHz atau lebih tinggi akan dilakukan). Anda akan melihat sesuatu seperti ini:







Seperti yang Anda lihat, Tristar melakukan polling pada setiap baris ID secara bergantian, satu demi satu. Tetapi karena kami tidak mencolokkan aksesori apa pun, survei jelas gagal. Pada titik tertentu, perangkat akan bosan dengan aliran kegagalan yang tak berkesudahan ini dan menghentikannya. Sementara itu, mari kita lihat apa yang sebenarnya terjadi selama jajak pendapat:







Pertama, kita melihat interval panjang (sekitar 1,1 milidetik), ketika levelnya tinggi, tetapi tidak ada yang terjadi:







Rupanya, kali ini digunakan untuk mengisi kapasitor HiFive internal - energi dari itu kemudian akan digunakan untuk menyalakan chip logika internal.



Jauh lebih menarik adalah apa yang terjadi selanjutnya:







Jelas, ini adalah aliran dari beberapa data. Tetapi bagaimana menafsirkannya? Bagaimana cara mendekripsi? Mari kita benar-benar membaginya menjadi bagian signifikan minimal - apa yang saya sebut kata-kata :







Faktanya, sebuah kata adalah kombinasi dari jatuh-naik-turun:

• Tahap konten - interval yang menentukan arti kata
  
  
• Fase pemulihan - interval yang tampaknya diperlukan untuk memproses fase konten di sisi penerima dan / atau untuk mempersiapkan kata berikutnya pada fase pengiriman

Berikut adalah tabel kata-kata terkenal dengan jaraknya untuk kedua tahap yang kita bahas di atas (semua unit dalam mikrodetik):



* STOP digunakan ketika ini adalah bit terakhir dalam byte.



Menggunakan tabel di atas kita sekarang dapat membangun decoder protokol sederhana:







Seperti yang Anda lihat, tuan rumah mengirimkan BREAK pertama - ketika Tristar ingin mengirim permintaan baru, tuan rumah selalu mulai dengan kata itu. Kemudian muncul tahap transfer data. Harap dicatat bahwa bit terakhir (ke-8) dalam byte memiliki fase pemulihan yang lebih lama. Ketika fase transfer data berakhir, tuan rumah mengirim BREAK lain. Anak kemudian harus mengirim respons (setelah penundaan setidaknya 2,5 mikrodetik - lihat tabel). Tristar akan menunggu sekitar 2.2ms untuk tanggapan. Jika tidak ada respons yang diberikan dalam jangka waktu ini, Tristar akan mencoba menginterogasi jalur ID lain.



Sekarang mari kita lihat tahap data menggunakan contoh di atas - 0x74 0x00 0x02 0x1f:

• 0x74 - jenis permintaan / tanggapan. Selalu merata untuk permintaan dan aneh untuk respons (tipe permintaan +1)
  
  
• 0x00 0x02 - data faktual. Mungkin kosong
  
  
• 0x1f - ini adalah CRC8 dari byte tipe permintaan dan semua data (polinomial - 0x31, nilai awal - 0xff)

Mari sambungkan beberapa aksesori ke rig kami dan lihat apa yang terjadi. Saya akan menggunakan kabel Lightning-to-USB asli Apple:







Dan inilah yang muncul di IDBUS setelah permintaan







0x74 : HiFive menjawab! Dan jika Anda menggulir lebih jauh, Anda akan melihat banyak pasangan permintaan / respons lainnya:







Beberapa permintaan tidak memerlukan respons:

Menafsirkan Permintaan dan Tanggapan IDBUS

Permintaan IDBUS yang paling penting adalah 0x74, digunakan untuk dua tujuan: untuk memberitahu HiFive untuk menyalakan tegangan dan arus penuh (jika didukung oleh aksesori), untuk menanyakannya tentang konfigurasi pin yang didukung oleh kabel, dan beberapa metadata lainnya.



Tidak banyak yang diketahui tentang bagaimana data respons 0x75 dikodekan. Tetapi beberapa bit tersedia dalam spesifikasi Tristar yang lama:



Data respons pertama byte 0x75



Konfigurasi ACCx ketika ID ditemukan di ID0



Konfigurasi ACCx ketika ID ditemukan di ID1



Konfigurasi Dx ketika ID ditemukan di ID0



Konfigurasi Dx ketika ID ditemukan di ID1



Dengan menggunakan tabel ini, mari kita uraikan ID kabel kita ( 10 0C 00 00 00 00), dengan mempertimbangkan fakta bahwa garis ID ditemukan pada pin ID0:



Byte pertama dari respons kabel 0x75



Jadi ACCx adalah 00, ini berarti bahwa pin ID0 hanya terikat ke IDBUS, dan Dx = 01 berarti bahwa pin DP1 / DN1 dikonfigurasi sebagai USB0_DP / USB0_DN. Persis seperti yang kami harapkan dari kabel USB standar.



Sekarang mari kita sela sesuatu yang lebih menarik:





Berikut ini adalah daftar lengkap (?) Permintaan IDBUS dari @spbdimka :







Kiat # 1 : Anda dapat dengan mudah mendapatkan properti aksesori termasuk ID-nya menggunakan accctl:





Ini adalah utilitas internal Apple yang dilengkapi dengan rakitan NonUI / InternalUI. Tetapi Anda dapat dengan mudah menjalankannya di perangkat apa pun setelah jailbreak.



Kiat # 2 : Anda dapat dengan mudah mendapatkan konfigurasi pin kabel menggunakan diags:

tristar -p

Harap dicatat bahwa perintah ini hanya tersedia di iOS 7+.



Tip # 3 : Anda dapat dengan mudah melacak 0x74 / 0x75 permintaan / tanggapan yang dihasilkan oleh probe SWD dengan mengatur debugenv var ke 3:

astrisctl setenv debug 3

Kemudian pada COM virtual dari kabel, Anda akan melihat sesuatu seperti ini:

HOSTID

Di salah satu tabel di atas, Anda dapat melihat penyebutan HOSTID tertentu. Ini adalah nilai 16-bit yang diteruskan dalam permintaan 0x74. Sepertinya itu juga mempengaruhi jawaban HiFive. Setidaknya jika Anda mengaturnya ke nilai yang tidak valid (ya, itu mungkin dengan diags), HiFive berhenti bekerja dengannya:





Namun, firmware KongSWD / KanziSWD memiliki variabel lingkungan disableIdCheck yang dapat Anda konfigurasikan untuk mengabaikan HOSTID yang tidak valid.

Catatan Penting: Kong dan Kanzi tidak memiliki HiFive sebagai chip khusus yang tidak dapat diprogram. Aksesori ini menirunya dengan mikrokontroler dan / atau FPGA, sehingga mudah untuk memperbarui / memprogram ulang.

BANGUN

Dalam tabel ID aksesori di atas, Anda dapat melihat bahwa Kong dan Kanzi mengirim respons berbeda tergantung pada apakah Astris berjalan atau tidak, yang merupakan perangkat lunak internal Apple untuk debugging dengan probe SWD (atau probe). Jika Anda menguraikan jawaban ini menggunakan tabel di atas, Anda akan menemukan bahwa ketika Astris gagal untuk memulai, probe akan bertindak persis seperti DCSD - USB pada garis D1 dan debug UART pada garis D2. Tetapi ketika perangkat lunak debug sedang berjalan, garis-garis ACCID beralih ke SWD.



Tetapi bagaimana jika kita ingin meluncurkan Astris setelah probe sudah terhubung ke perangkat? Apa yang akan dilakukan kabel? Bagaimana ini akan beralih antara saluran ACC ke SWD? Di sinilah WAKE berperan! HiFive (atau perangkat yang mengemulasikannya) dapat memulaiWAKE  - dan proses enumerasi IDBUS akan dimulai lagi: Tristar akan mengirim permintaan 0x74, Kong / Kanzi akan merespons dengan ID baru, Tristar akan mengonfirmasinya dan mengirim saluran ACC ke ekstensi SWD (tentu saja SoC harus mendukung ini pada level fisik).

Jabat tangan kekuasaan

Hal terakhir yang akan saya lihat adalah jabat tangan kekuasaan. Ini adalah algoritma permintaan / respons IDBUS yang digunakan oleh driver kernel Tristar sebelum mengizinkan pengisian daya aksesori.



Ketika kabel Lightning hanya terletak di suatu tempat, terhubung ke pengisi daya / komputer, tetapi tidak terhubung ke perangkat, HiFive membatasi arus pada PWR ke nilai yang sangat kecil (sekitar 10-15 mA menurut pengukuran saya). Untuk mengaktifkan arus penuh, permintaan 0x74 harus dikeluarkan oleh Tristar dan diproses oleh HiFive. Untuk SecureROM / iBoot, ini sudah cukup, tetapi langkah-langkah tambahan harus diambil saat memuat kernel:

1. TriStar mengeluarkan dua permintaan 0x70
   
   
2. Segera setelah permintaan kedua diproses oleh HiFive dan respons dikirim, ia mematikan arus saat ini selama sekitar 20 milidetik
   
   
3. Tristar 0x70, 0x80 . HiFive
   
   
4. , Tristar,

: , . , . ,

ESN Tristar I2C

Fitur lain dari Tristar yang ingin saya bicarakan adalah ESN. Ini adalah gumpalan kecil yang disimpan Tristar di EEPROM-nya (pada CBTL1610A2 dan yang lebih baru). Ini dapat diperoleh melalui IDBUS menggunakan kabel Serial Number Reader (atau Kanzi, pada dasarnya sama kecuali untuk USB-PID yang berbeda dan lampiran yang sedikit berbeda)



Sederhananya, dengan mengirim gumpalan ini ke ttrs.apple.com , Anda bisa mendapatkan nomor seri perangkat ... Mekanisme ini digunakan oleh karyawan Apple Store / Apple Premium Reseller untuk mengambil SN dari perangkat mati (jika Tristar masih hidup):







Apa yang terjadi pada IDBUS ketika ESN diterima, @spbdimka mendokumentasikan :

Latihan

Prosedur untuk "Firmware» ESN meminta pelatihan Tristar (penyediaan). Itu terjadi dengan diagnostik di sisi perangkat, melalui EzLink di sisi penerima dalam tiga langkah.



Anda dapat memeriksa status menggunakan diags:

tristar --prov_stat

... dan dapatkan ESN:

tristar --esn

Ngomong-ngomong, diags umumnya memiliki serangkaian perintah Tristar (tersedia sejak iOS 7):

Tristar I2C

Tristar tersedia di bus I2C (alamat 0x34 untuk menulis, 0x35 untuk membaca). Inilah cara diag dan driver kernel berinteraksi dengannya. Tidak banyak yang diketahui publik



tentang pendaftar . Banyak informasi tentang peta register itu sendiri dapat diperoleh dari kode sumber iBoot yang bocor (hanya untuk THS7383 - tampaknya kompatibel dengan CBTL1608 - dan CBTL1610), tetapi tidak banyak tentang apa yang perlu ditulis di sana untuk mencapai hasil yang menarik. Sumber pengetahuan lain adalah modul Tristar dari diags (mudah diambil melalui SWD saat sedang berjalan). Sebagai contoh, saya dapat membalikkan ketentuan dan membaca algoritma ESN. Lalu saya menerapkan ini sebagai tambahan untuk beban saya untuk iBoot yang disebut Lina :











Saya juga mencoba mengubah algoritma penulisan ESN tetapi gagal - mekanismenya terlalu rumit untuk saya. Namun, cuplikan kode dari Lina tersedia di sini .

Karakteristik kelistrikan Tristar

Tristar sendiri ditenagai oleh pasokan 1.8V. Garis-garis untuk IDBUS 3.0V toleran, menurut osiloskop saya:







Jadi tanpa sirkuit level-shifting, lebih baik tidak mencoba untuk berinteraksi dengan IDBUS menggunakan perangkat toleran 5V seperti beberapa model Arduino. ...