Güncel sonuç: R211 Pi 5 üzerinde pasif Wi-Fi taramasını tamamladı. Bluetooth Classic Inquiry, aktif/pasif BLE taraması, SSP, canlı UI ve Wi-Fi/BLE birlikte çalışma fiziksel olarak ilerledi. BT-B18 değişken satır yerleşimi gerçek DSI fotoğrafıyla PASS. BT-B19 ad kaynağını gerçek HCI kökeniyle taşıdı; BT-B20 aktif çalışma zamanı penceresinde gerçek Scan Response adı ve eşzamanlı R211 Wi-Fi PASS aldı. 21 Eylül 2026'da BT-B21–B29 host/imaj zinciri tamamlandı: ADV ve Scan Response ayrı kanıt, bounded Remote Name kuyruğu, AES-CTR+HMAC cache modeli, Core ah/IRK, strict ATT/GAP/DIS/SDP ve yalnız resmî Fast/Swift Pair biçimleri, ardından ad kaynağı/kimlik/model satırlarının ayrılması. Bu, fiziksel PASS değildir: B21 UART DUAL_PAYLOAD kabulü fiziksel olarak alındı; güvenilir cihaz sırrı+atomik backend, gerçek LE SMP/GATT ve Classic SDP taşıması, pozitif vendor reklamı ve DSI matrisi hâlâ eksik. Model, RSSI/OUI veya Apple Nearby Info'dan uydurulmayacak; B30 gerçek cihaz matrisinde blocked. Aşağıda R1–R211 Wi-Fi ve B00–B30 Bluetooth kanıt/plan zinciri yer alır.
Pasif Wi-Fi taraması çalıştı; bağlanma kanıtı değildir.
FWSTAGE OK=1 · NVRAM OK=1 · FWREADY_MS=55 · CLM_ACK=2676 · WIFIPROTO READY=1 · escan ScanAccepted · WIFISCAN_RESULT GEN=2/5/6 STATUS=Complete COUNT=16 TRUNCATED=1
UART üzerinde fiziksel PASS; ham R211 UART dosyası henüz mühürlü arşiv değil. TRUNCATED=1, taramanın başarısızlığı değil, 16 kayıtlık UI listesinin dolmasıdır. R211 imajı TFTP ile açıldı; Pi'deki USB bellek yeniden yazılmadı.
İmaj SHA-256: 4fa0cc4883e736be7e2133184e51b539ade5699d9ba88ee42671e853dcde3b90 · firmware/rpi5-wifi-scan-r211-profile.txt
BT-SCAN-2026-09 · BT-B22
Hedef: B18 tabanını koruyarak Android/BlueZ düzeyine yaklaşan kanıta dayalı aygıt adlandırması: ad kaynağı telemetrisi, çalışma zamanı aktif Scan Response, Classic Remote Name kuyruğu, kalıcı kullanıcı adı/bond önbelleği, IRK kimlik çözümü, GATT GAP/DIS ve Classic SDP Device ID
Tahmin: 22–35 iş günü · 168–272 mühendislik saati · B19–B30 için 28–54 tek-değişkenli imaj · 45–90 kontrollü açılış ve en az 18 cihaz-senaryo koşusu.
Kabul: Gerçek Classic/BLE kimliği ve tarama; iki uçta aynı SSP sayısı; BlueZ Paired=yes; ACL kopunca eşleşme korunurken RustOS satırının Bağlı Değil'e dönmesi; ölçülen tüm aygıtların dört satırda kesilmeden doğru satır eşlemesiyle kaydırılması; aynı görünen satırların ölçülen ve açıkça geçici ID ile ayrılması; açılış taraması boş olsa bile sonraki gerçek BLE sonucunun listeye aktarılması; R211 Wi-Fi taramasında regresyon olmaması.
Kapsam dışı: A2DP/HFP/HID/RFCOMM/dosya aktarımı, belgesiz üretici verisinden model tahmini ve Apple Nearby Info'dan iPhone nesli uydurma bu adlandırma kampanyasının kapsamında değildir.
Dürüst durum, 21 Eylül 2026: BT-B08–B20 fiziksel zinciri korunuyor; BT-B12 BlueZ üzerinde Paired=yes ve Connected=yes ile fiziksel geçti. Masaüstü bağı koptuğunda yanlış canlı durum gösteren yol B13'te düzeltildi; fiziksel kopma/yeniden bağlantı makbuzu henüz PASS değildir ve sonraki imajlarda korunuyor. B14 listeyi dört satırla sınırlamıyor; B15'teki geçici ID model, seri numarası veya kalıcı takip kimliği değildir; B16 boş liste hatasını kapattı. Gerçek ad yayınlanmadığında adsız aygıta model veya sıra numarası uydurulmaz. Nearby Info kesin iPhone nesli yayınlamadığı için arayüz model yokluğunu açıkça söylüyor; “Apple aygıtı 2” gibi uydurma model/sıra adı yok. En son B20 yedi BLE aygıtı, Scan Response kaynaklı bir ad ve eşzamanlı R211 Wi-Fi PASS verdi. B21–B29 host/imaj uygulaması hazır: ADV+Scan Response kanıtı paket sırasından bağımsız; Classic Remote Name 1 s/5 s deadline ve 512 bayt poll bütçesiyle ana döngüyü bloklamıyor; alias/bond/live adı şifreli-authenticated cache modelinde ayrılıyor, RPA yalnız gerçek IRK ile birleşiyor, GATT/DIS/SDP parser'ları ve belgeli Fast/Swift Pair biçimleri strict, UI ad kaynağı/kimlik kararı/model evidence'ını ayrı satırlarda gösteriyor. Ancak bunların hiçbiri otomatik fiziksel PASS değildir. B21 gerçek UART'ta atomik BTM21 ... BOTH=1 OK=1 makbuzuyla kapandı (uzun BTMERGE_RESULT satırı yoğun CDC'de parçalanabildiği için kabul atomik makbuza dayanıyor); B23 için güvenilir cihaz sırrı ve atomik reboot backend'i, B24–B27 için gerçek L2CAP/SMP/GATT/SDP taşımaları, B28 için pozitif vendor reklamı, B29/B30 için gerçek DSI ve çoklu cihaz matrisi eksik. Eşleşmemiş rastgele adresler ad/RSSI/üretici benzerliğiyle birleştirilmiyor.
BT-A1: BT_ON uygulanıyor, UARTA 115200 8N1, HCI Reset dört bayt gönderiliyor; TX=4, RXLEN=0, RXTO=1, ANSWERED=0.
Raspberry Pi OS R75: hci0 UP/RUNNING; brcm/BCM4345C0.raspberrypi,5-model-b.hcd yüklendi.
İmaj SHA-256 6f3a85aa399d31ffc61e91647904f2b130b1868942ef3cd26f950343acc0817b; AFE ile MCR=0x23, TX=4, RXTO=0, EVENT=1 ve Reset status=0. 360 saniyelik kayıtta FWREADY 55 ms, protokol ready ve art arda gerçek BSS nesilleri korundu.
İmaj SHA-256 968665a071294dee93567216f65a4a83f1cfdd25018624a4cc746c5389d23cfd; 63.806 bayt HCD tam tüketildi, 323/323 kayıt ve 62.837 payload baytı status=0 ile onaylandı, timeout olmadı. Aynı fiziksel boot R211 Wi-Fi Complete ve gerçek BSS satırları üretti.
İmaj SHA-256 bc03d8ff3f0b222f1db4960eb17e5c24fc407845625dca9f024ec3ec4c3bef95; controller-first 0xfc18 ACK=1/status=0, host divisor 52→2/readback=2, 3 Mbit/s Reset ACK=1. HCI/LMP 5.0, Cypress 305, subversion 0x6119 ve BCM4345C0 verbose kimliği COMPLETE=1.
İmaj SHA-256 2388fe867a7dd55d5faaf2b928ee5c727275fd541e0d5626d56691f978828404; kalıcı H4 motoru fiziksel 100/100 tamamlanma ve 100/100 kimlik eşleşmesi, sıfır timeout/overflow/drop üretti. Aynı boot Wi-Fi sonucu COUNT=7, TRUNCATED=0, STALE=0 verdi.
İmaj SHA-256 83bf67618ac94ca192a659abd697aaa4709ca078003942f0e7202f94662783be; HCD/3 Mbit/s/BTH4 100/100 yeniden geçti. Classic çağrısı sırasında 15 saniyelik PM watchdog beslenecek kontrol akışına dönemedi ve BTCLASSIC sonuç satırından önce donanım reseti oluştu. Bu koşu Classic PASS değildir; ham UART iki parça ve reset ofsetiyle korundu.
İmaj SHA-256 ebd03783f27feb3b761a8ccf91eb62205522e085caafbd3fcebbd05bf6e56134; watchdog servisli B06b Inquiry Mode/Inquiry/Complete status 0, DEVICES=1, NAMED=1, timeout=0 ve COMPLETE=1 verdi. Gerçek cihaz adı DESKTOP-A21IH62 ve class 6c010c, Kali public controller 94:E6:F7:AA:1D:64 ile bağımsız doğrulandı. Ham UART SHA-256 1aaafacadfb990d4eb3e513a10da5765eeaf71b462de14b0f6a1fec36fe47224; R211 Wi-Fi aynı açılışta korundu.
İmaj SHA-256 8915187ec1781e5dcdd1a2bc68c3337021fa70788ea133b659da7c538b87b07c; pasif LE tarama dört status-zero komut, 99 reklam olayı, 9 tekil cihaz, gerçek adres/tür/RSSI/AD, malformed=0, truncation=0 ve COMPLETE=1 üretti. NAMED=0 çevresel pasif reklam sonucudur. Ham UART SHA-256 6c0223deb70c4716cb5c623ff63e6db341eb5f35014000eb81cc3e11bce0f369; aynı boot Classic geçti ve 136 Wi-Fi sonuç marker'ı korundu.
Aktif görsel doğrulama: imaj SHA-256 16399d241094c90eb174a185ff19e9ac3ded7d9de653770ed51dc8758e285829. Liste ayrıntısı `ID XX:XX:XX / Nearby Info -47 dBm` biçiminde gerçek adres son ekini gösterir. İki aynı `iPhone` host testinde farklı ID aldı. Fiziksel netboot 11 Bluetooth kimliği, BT-B09 COMPLETE=1 ve tekrarlanan R211 WIFI_OK üretti. Kanıt: evidence/rpi5/radio/attempt-bt-b15-session-id-uart-capture; çekirdek UART SHA-256 59f5786e60654cea3b1b7881f369bfd9c96148bfd73413866c127a174b56a516. ID dönebilir ve kalıcı kimlik değildir; DSI metin kabulü bekleniyor.
Fiziksel PASS: imaj SHA-256 4dd6573d12a799fe997343cb78f192598a25eba17150a634f0a93f55ad1c017d, profil SHA-256 65e8c82328ae28cba654dc369fe8d4502bc302b3b5c6c0b5c51e3e7b8848fe53. Bootloader `aselsanos-rpi5-bt-scan-b16.img` dosyasını TFTP'den aldı ve 1190 firmware sektörü yeniden yüklendi. Açılışta boş kalabilen model, çalışma zamanı BLE sonucu ile BTUI MODEL_DEVICES=7 değerine geçti; sonraki yenileme BT_DEVICES=6/BT_COMPLETE=1 verdi. Boş yenileme son iyi listeyi koruyor, paired/Classic kayıtları tutuluyor ve pairing olayı taramadan öncelikli. Aynı koşuda R211 Wi-Fi 12–16 ağ üretmeye devam etti.
Fiziksel PASS: imaj SHA-256 2f640e11f824626842f1ef199b7c177ac58a6fc0ddf85ef10594b90633522917, profil SHA-256 381b687efb6889fe3a34f7a767c526087f075b2a1c9097804cd019c36cea934d. Bootloader `aselsanos-rpi5-bt-scan-b17.img` dosyasını TFTP'den aldı; 1190 sektör OK=1 tamamlandı. Ham Advertising Data Apple 0x004C üretici alanını, Continuity 0x10 Nearby Info ve 0x12 Find My türlerini taşıdı. Arayüz ID, şirket ve paket türünü gösteriyor; Nearby Info'da bulunmayan kesin iPhone modelini tahmin etmiyor. Gerçek Proximity Pairing model kimliği varsa bilinen ad, bilinmiyorsa hex kimlik korunuyor. B16 canlı yenileme ve R211 Wi-Fi aynı bootta geçti.
Fiziksel ve görsel PASS: imaj SHA-256 14a7d9fff357f914bf44c7290bc6b39333b6c2108635df0360e235be1d7fac71, profil SHA-256 b966d992807feec81fee136d070749959ef07ac05c330075c1f867f99de048e5. Bootloader `aselsanos-rpi5-bt-scan-b18.img` dosyasını TFTP'den aldı. 1190 sektör staging, başlangıçta 13 gerçek Bluetooth aygıtı, canlı `BTRF A=1 G=2 D=9 B=13 M=10 OK=1 P=1` ve `WIFI_OK G=2 N=13 OK=1` geçti. İki/üç satırlı geometri, doğru dokunma ve eski piksel izi ana makine testlerinde geçti. DSI fotoğrafı SHA-256 707ae05018821239a3cb76ea7ea7e7fdd1af3e0f8322834be7a54ad96343473d, iki ve üç satırlı gerçek kayıtların çakışmadığını fiziksel olarak doğruladı.
Fiziksel PASS: imaj SHA-256 0eeab18d68de232949449a9efabaa2be613bf32b40b31eba34fc7f415e5eca8a, profil SHA-256 0d587625b9c7cbd410211d4508d40ea0c0e37511e33ec821932281641f841bb6. Sıkı B08 makbuzu D=14/C=1/L=13, 14 benzersiz gerçek adres, dört görünür UI satırı, framebuffer CRC 0x8346a26544f57c23 ve aynı kayıtta sekiz Wi-Fi Complete verdi. Kanıt evidence/rpi5/radio/attempt-bt-b08-ui-model-auto-boot1-20260919T183622Z; ham UART SHA-256 17d25ff4b92119c9b25a583828908b66569a49b55277714c7c0a907c39688033. Aktif Scan Response ile yayınlanan gerçek JBL Tune 520BT-LE ve Classic Remote Name ile gelen DESKTOP-A21IH62 aynen gösterildi. Ad yayınlamayan cihaza model veya sıra numarası uydurulmuyor; üretici/tür fallback'i ile ayrıntıda 'Ad ve model yayınlanmıyor' yazılıyor.
Fiziksel 3/3 PASS: imaj SHA-256 d168bf47408478190716b3ec1b9453d858ee52ad0a1466b3585b17c9ee345d78, profil SHA-256 bfc821e0a5fde07e8de67f9337bee62ced500d27ea35ac10e2e46059d6011e59. Üç boot sırasıyla Wi-Fi 9/10/13 ağ ve 438/430/428 poll sürdürürken BLE 13/13/12 rapor ile 6/6/5 gerçek cihaz üretti; timeout, malformed, unexpected ve bütçe taşması her koşuda sıfırdı. Yoğun kuyrukta kaybolan ilk scan-disable ACK için aynı idempotent komut bir kez tekrarlandı (DR=1) ve status-zero ACK alındı. Kanıtlar: attempt-bt-b09-wifi-ble-coexistence-auto-boot1/2/3-20260919T185237Z/T185808Z/T190359Z; UART SHA-256 a38e350619da3f93dd35fbcbe497757ac115673d68c7867eb9347c20900e3d3c, 1edeebc4167dea9c0c7f0377dc2db9d77b380ab5014b80c378c85479072b20b9 ve 289c3e3a0c48f574505aa7dbdaf6540de543cf50275719779c39d649e5498666.
İmaj SHA-256 8e0d4d47c4098abb7effe344ad9d17447270b7512eda2fc5539f1c6e95119e28; gerçek SSP sayısı 518167 iki uçta görüldü, fakat status 0x08 nedeniyle ilişkilendirme tamamlanmadı.
Fiziksel PASS: imaj SHA-256 015453b793f85c197d56140d7f0142861d27f66528d8bedd6cce91f0698c2ab3; gerçek sayı 693174, BlueZ Paired=yes/Connected=yes, Class=0x000104 ve Icon=computer. Link Key yalnız RAM'dedir; SDP/UUID profili yoktur.
Aktif fiziksel doğrulama: imaj SHA-256 820f85990a6bef3c0502fef58f67cff8a7d76ef2ce7139e5d58c9c227856b73e. Disconnection Complete sonrası paired=true/connected=false ve aynı-açılış yeniden bağlantı yolu kodlandı; fiziksel BTLINK makbuzu bekleniyor.
B15'e taşındı: imaj SHA-256 a8e39e65dae7cbc54b153c32a292a8ea2c0cec56fe62f451bc79ed5c3fc29f37. Dört satırlık belge sınırı kaldırıldı; en çok 16 gerçek kayıt RSSI sırasıyla uzayan belgede çiziliyor. Fiziksel boot 11 kayıt ve TRUNCATED=0 üretti; kullanıcı DSI fotoğrafı dördüncü satır ötesini doğruladı. Ofsetli son-satır dokunması ana makinede geçti, fiziksel dokunma makbuzu açık kaldı.
HCD: 63.806 bayt · 323 kayıt · payload 62.837 bayt · SHA-256 51c45e77ddad91a19e96dc8fb75295b2087c279940df2634b23baf71b6dea42c
Resmî sıra: Linux hci_bcm.c · Raspberry Pi 5 DTS · Bluetooth SIG Company Identifiers · Apple CoreBluetooth Manufacturer Data · PoPETs Apple Continuity ölçümü
| Kapı | Durum | Planlanan tek sonuç | Geçiş ölçütü | Canlı kayıt |
|---|---|---|---|---|
| BT-B00Temel durum ve araç zinciri | Geçti | R211 Wi-Fi bazını, UART/TFTP erişimini, Linux denetleyici kimliğini ve HCD dosyasını sabitle. | İmaj, firmware ve UART kimlikleri SHA-256 ile kayda alınmış; otomatik reset yolu sınanmış olmalı. | Geçti: ttyACM1, eth1 10.43.0.1, dnsmasq/TFTP, imaj SHA-256 ve UART R/PM-watchdog yeniden başlatması aynı BT-B01 koşusunda fiziksel olarak doğrulandı. |
| BT-B01Linux–AselsanOS UART ilk farkı | Geçti | Pin mux, BT_ON sırası, UART saat/divisor, akış kontrolü ve ilk H4 baytlarını Linux ile karşılaştır. | İlk farklı işlem ve zaman damgası tek, yeniden üretilebilir bir değişkene indirgenmiş olmalı. | Geçti, fakat HCI henüz geçmedi: R194 W5=0x15555655 kaydı pin24..27 için [1,1,1,1] pull-down gösterdi. BT-B01 resmi D0 planı [0,2,0,2]'yi VERIFIED=4/4 ve UNPLANNED=0 ile uyguladı; HCI yine ANSWERED=0 kaldı. |
| BT-B02ROM-speed HCI yanıtı | Geçti | BT-B01 pull tabanı üzerinde Linux 8250/BCM7271 yolundaki otomatik RTS/CTS'yi tek değişken olarak aç; 115200 8N1 hattında HCI Reset Command Complete al. | 0x04 0x0e olayının opcode=0x0c03 ve status=0 olması ham UART'ta görülmeli. | Geçti: fiziksel imaj MCR'yi 0x00→0x23 yaptı; TX=4, RXTO=0, EVENT=1 ve tam H4 Reset Command Complete (04 0e 04 01 03 0c 00) çözüldü. Wi-Fi FWREADY 55 ms kaldı, protokol hazır oldu ve tekrarlanan gerçek BSS taramaları sürdü. |
| BT-B03BCM4345C0 patchram yükleme | Geçti | Pinli HCD'yi doğrula, 323 kaydı sıra/status kontrolüyle gönder ve başarısız kaydı raporla. | 63.806 bayt HCD tam tüketilmiş, her vendor komutu status=0 ile tamamlanmış olmalı. | Geçti: fiziksel BTHCD makbuzu SHAPE=1, BYTES=63806/63806, RECORDS=323/323/323, PAYLOAD_SENT=62837, START_ACK=1, LAUNCH=1/1, TXTO=0, RXTO=0 ve COMPLETE=1 verdi. Aynı açılışta R211 Wi-Fi gerçek BSS kayıtları ve Complete sonucu üretmeye devam etti. |
| BT-B043 Mbit/s ve post-patch kimliği | Geçti | Broadcom baud komutu ile denetleyici ve host hızını kontrollü geçir; Reset ve sürüm oku. | BCM43455/Cypress 305, HCI 5.0 ve 3 Mbit/s sonrası iki başarılı HCI komutu görülmeli. | Geçti: fiziksel BTBAUD makbuzu 0xfc18 payload=0000c0c62d00 için ACK=1/status=0, divisor 52→2/readback=2 ve 3 Mbit/s Reset ACK=1 verdi. BTIDENT HCI/LMP 5.0, Cypress manufacturer=305, subversion=0x6119 ve BCM4345C0 verbose eşleşmesini COMPLETE=1 ile doğruladı. |
| BT-B05Dayanıklı H4 işlem motoru | Geçti | Command/Event ACL ayrımı, opcode eşleme, timeout, taşma ve beklenmeyen olay kuyruğu ekle. | Parçalı ve birleşik olay birim testleriyle ardışık 100 HCI komutu kayıpsız tamamlanmalı. | Geçti: parçalı/birleşik Event+ACL, 300 bayt taşma-drain, yanlış opcode/kuyruk ve EIR/ad çözümleme dahil 7 host testi geçti. Fiziksel BTH4 100/100 Command Complete ve 100/100 kimlik eşleşmesi, sıfır timeout/overflow/drop verdi; aynı boot Wi-Fi taramasını yedi gerçek kayıtla tamamladı. |
| BT-B06Classic Inquiry | Geçti | Inquiry başlat, Inquiry Result/RSSI/Complete olaylarını gerçek cihaz modeline aktar. | Yakındaki en az bir Classic cihazın gerçek BD_ADDR, RSSI ve adı listelenmeli. | Geçti: B06b Mode 2 ve Inquiry status 0, Inquiry Complete status 0, bir gerçek sonuç ve bir Remote Name cevabıyla COMPLETE=1 verdi. DESKTOP-A21IH62 adı ile 6c010c cihaz sınıfı bağımsız Kali denetleyici kimliğiyle eşleşti; R211 Wi-Fi aynı boot içinde gerçek BSS sonuçlarını sürdürdü. Uzun UART cihaz satırındaki karakter karışması nedeniyle temiz adres/RSSI sunumu BT-B08/BT-B10 kabulünde ayrıca mühürlenecek. |
| BT-B07BLE passive scan | Geçti | LE event mask, passive scan parameters/enable ve advertising report çözümleme ekle. | Yakındaki en az bir BLE yayınında gerçek adres, adres türü, RSSI ve ad/AD özeti görülmeli. | Geçti: status-zero event mask/parameters/enable/disable ve timeout olmadan 99 Advertising Report, 9 tekil gerçek BLE adresi, adres türü, RSSI ve AD özeti üretildi; malformed/truncation 0, COMPLETE=1. Ortamdaki pasif reklamlarda ad alanı yoktu (NAMED=0); aktif scan request kapsam dışı tutuldu. Aynı boot B06 Classic ve 136 R211 Wi-Fi sonuç marker'ını korudu. |
| BT-B08Çekirdek–UI veri modeli | Geçti | Classic/BLE kayıtlarını tekilleştir, yaşlandır, sinyal sırasına koy ve Bluetooth sayfasına bağla. | UI satırları yalnız gerçek tarama kaydından oluşmalı; yerel demo/hard-code cihaz kalmamalı. Aynı fiziksel bootta Bluetooth sayfasının tam framebuffer bileşimi, model nesli/satır sayısı ve sıfır olmayan frame CRC makbuzuyla kanıtlanmalı. | Geçti: 0eeab18d… imajının sıkı fiziksel koşusunda BTM G=1 D=14 C=1 L=13 CC=1 LC=1 OK=1 oluştu; 14 benzersiz gerçek adres, dört görünür UI satırı, framebuffer CRC 0x8346a26544f57c23 ve sekiz Wi-Fi Complete makbuzu aynı capture içinde kabul edildi. Gerçek ad döndüğünde DESKTOP-A21IH62 ve aktif Scan Response koşusunda JBL Tune 520BT-LE aynen gösterildi. Ad dönmeyen cihazlara model/sıra numarası uydurulmuyor; yalnız marka adı (Apple, Samsung, Google, Sony vb.) ve 'Ad ve model yayınlanmıyor' ayrıntısı kullanılıyor. R199 görüntü adı düzeltmesi: 20 markalık kısa ad eşlemesi doğrulandı — DSI ekran görüntüsü IMG_0058.jpeg'de ad yayınlamayan cihazlar 'Apple' kısa adıyla, gerçek adlı cihazlar ise DESKTOP-A21IH62 ve Galaxy Watch Ultra (DV1A) olarak görünüyor; eski 'Apple aygıtı', 'Samsung aygıtı' benzeri genel etiketler kaldırıldı. Apple Continuity type field ile cihaz sınıfı tespiti: | Type | Cihaz | Güvenilirlik | | 0x07 | AirPods / Beats | Yüksek | | 0x0B | Apple Watch | Yüksek | | 0x0E | iPhone | Yüksek (Instant Hotspot) | | 0x09 | AirPlay (Apple TV / HomePod) | Orta | | 0x05 | Apple (AirDrop) | iPhone/iPad/Mac ayrımı yok | | 0x0C | Apple (Handoff) | iPhone/iPad/Mac ayrımı yok | | 0x08 | Apple (Siri) | Sub-field ile ayrım | | 0x10 | Apple (Nearby) | Sub-field ile ayrım | | 0x12 | Apple (Find My) | Şifreli, model ayrımı yok | |
| BT-B09Wi-Fi/Bluetooth birlikte çalışma | Geçti | R211 Wi-Fi taraması açıkken Classic ve BLE taramasını ayrı ve birlikte çalıştır. | Aynı R211 nesli Wi-Fi Complete ve gerçek BSS üretirken BLE rapor/cihaz üretmeli; HCI timeout, malformed/unexpected olay ve UART bütçe doygunluğu sıfır olmalı. | Geçti, üç bağımsız bootun üçü de sıkı kabul edildi. d168bf47… imajında sonuçlar sırasıyla: Wi-Fi 9 / 10 / 13 ağ, aynı BLE penceresinde 438 / 430 / 428 Wi-Fi poll; 13 / 13 / 12 reklam raporu ve 6 / 6 / 5 gerçek BLE cihazı. Her bootta BT_TIMEOUTS=0, BT_MALFORMED=0, BT_UNEXPECTED=0, BT_BUDGET_EXHAUSTIONS=0 ve COMPLETE=1. Yoğun reklam kuyruğunda ilk nonblocking scan-disable ACK görünmediğinde aynı idempotent disable bir kez tekrarlandı (DR=1) ve status-zero ACK ile kapandı. |
| BT-B10Tekrar, mühür ve yayın | Geçti | Üç bağımsız tam önyükleme, altı tarama, imaj/UART SHA-256 ve sitede nihai uygunluk raporu. | Tüm kabul maddeleri kanıt yollarıyla geçmiş ve sapmalar kapatılmış olmalı. | Geçti: B08 strict PASS ve B09 3/3 bağımsız tam netboot PASS olarak mühürlendi; her B09 bootunda başlangıç B08 taraması ile eşzamanlı B09 taraması bulunduğu için toplam altı Bluetooth taraması ölçüldü. UART kanıt SHA-256 değerleri a38e3506…d3c, 1edeebc4…0b9 ve 289c3e3a…666. Uzaktan fiziksel güç kesme yapılmadı; tekrarlar UART R ile bootloader'a dönüp imajı TFTP'den ve 1190 firmware sektörünü sıfırdan yükledi. Bu sapma açıkça kaydedildi. |
| BT-B11Gerçek SSP sayısal karşılaştırma | Geçmedi | Ölçülmüş Classic satıra dokununca gerçek ACL bağlantısı, kimlik doğrulama ve denetleyici kaynaklı altı haneli sayısal karşılaştırmayı başlat. | İki uç aynı sayıyı göstermeli; onay sonrası Simple Pairing, Link Key ve Authentication olayları status=0 ile tamamlanmalı. | Koşuldu, geçmedi: DESKTOP-A21IH62 için gerçek User Confirmation Request ve iki uçta 518167 görüldü; panel onayı HCI'ya iletildi. Ancak Simple Pairing Complete, Link Key Notification ve Authentication Complete gelmedi; oturum STATUS=0x08 ile kapandı ve masaüstü aygıtı ilişkilendirmedi. Sonraki adımın nedeni, peer'in tören boyunca keşfedilebilir/bağlanabilir kalmasını ve asenkron SSP olaylarının kaybolmamasını sağlamaktı. |
| BT-B12BlueZ ile güvenli ilişkilendirme | Geçti | Create Connection öncesi AselsanOS adını, Computer/Desktop sınıfını, authentication ve Inquiry+Page Scan'i etkinleştir; asenkron HCI olaylarını koru ve denetleyici Link Key'ini RAM'de tut. | Aynı gerçek sayı iki uçta onaylanmalı; BlueZ Paired=yes ve Connected=yes göstermeli; RustOS aygıtı yalnız Authentication Complete sonrasında Aygıtlarım'a taşımalı. | Fiziksel PASS: sayı 693174 iki uçta eşleşti. Blueman AselsanOS için Address=43:45:C0:00:1F:AC, Class=0x000104, Icon=computer, Paired=yes ve Connected=yes ölçtü. Trusted=no BlueZ'nin yerel politikasıdır; UUID listesi boştur çünkü SDP profili uydurulmadı. İmaj SHA-256 015453b793f85c197d56140d7f0142861d27f66528d8bedd6cce91f0698c2ab3. Bağ sonradan masaüstünde koptuğunda RustOS satırının Bağlı kalması B13'e geçiş nedenidir. |
| BT-B13Canlı ACL bağlantı durumu | Sonraki imaja taşındı | Eşleşme tamamlandıktan sonra H4 olay tüketimini sürdür; Disconnection Complete eşleşmeyi koruyup yalnız connected=false yapsın, aynı-açılış kimlikli yeniden bağlantı connected=true yapsın. | Kopmada ASELSAN/BTLINK GATE=BT-B13 CONNECTED=0 PAIRED=1 UI_UPDATED=1 görülmeli; satır Aygıtlarım'da Bağlı Değil olmalı ve aynı-açılış yeniden bağlantıda Bağlı'ya dönmeli. | B14'e taşındı: 820f85990a6bef3c0502fef58f67cff8a7d76ef2ce7139e5d58c9c227856b73e imajı 2026-09-20'de Ethernet/TFTP ile açıldı; staging OK, Wi-Fi Complete ve Classic/BLE tarama korundu. 17/17 H4, 66/66 UI/model ve 93/93 kaynak kapısı geçti. Fiziksel yeniden eşleşme, kopma ve aynı-açılış yeniden bağlantı makbuzu henüz alınmadığı için PASS yazılmadı; aynı davranış B14 imajında korunuyor. |
| BT-B14Tüm ölçülen aygıtlar ve kaydırılabilir liste | Sonraki imaja taşındı | Dört satırlık belge sınırını kaldır; denetleyici modelinde tutulan tüm gerçek eşleşmemiş aygıtları RSSI sırasıyla sayfaya ekle. Sabit üst alan altında piksel tabanlı ataletli kaydırma ve kaydırma ofsetini hesaba katan doğru satır dokunması kullan. | En az sekiz ölçülen aygıtla ilk dört satırın ötesine kayılmalı; son satıra dokununca aynı ölçülen kimlik seçilmeli. DSI'da liste aşağı doğru uzamalı, uydurma satır oluşmamalı ve R211 Wi-Fi ile BT-B13 bağlantı davranışı gerilememeli. | B15'e taşındı: 8 ölçülen aygıtlı ana makine senaryosu sekizinci satıra kadar kaydı ve doğru aygıtı seçti. a8e39e65dae7cbc54b153c32a292a8ea2c0cec56fe62f451bc79ed5c3fc29f37 imajı fiziksel Pi'de DEVICES=11, TRUNCATED=0 ile 11 gerçek kaydı tuttu; kullanıcı DSI fotoğrafı dördüncü satırın ötesine uzayan gerçek listeyi gösterdi. Son satır dokunmasının aynı ölçülen kimliği seçtiği fiziksel olarak ayrıca ölçülmedi; davranış B15 imajında korunuyor. |
| BT-B15Aynı adlı aygıtlar için ölçülen oturum kimliği | Sonraki imaja taşındı | Gerçek ad/model yayınlamayan ve aynı üretici/tür adıyla görünen kayıtların ayrıntısına, ölçülen denetleyici adresinin son üç oktetini `ID XX:XX:XX` biçiminde ekle. | İki aynı `iPhone` veya `Apple` satırı farklı ölçülen adreslere sahipse DSI'da farklı ID göstermeli; ID'nin dönebilen oturum etiketi olduğu, seri numarası/model/kalıcı kimlik olmadığı açık kalmalı. Tarama, B14 liste davranışı ve R211 Wi-Fi gerilememeli. | B16'ya taşındı: kod ve fiziksel boot çalıştı; 16399d241094c90eb174a185ff19e9ac3ded7d9de653770ed51dc8758e285829 imajı Ethernet/TFTP'den açıldı, Bluetooth N=11/OK=1 ve R211 WIFI_OK üretildi. UART `BTUI_ID` sözleşmesi `ADDR_SUFFIX`, `OCTETS=3`, `ROTATING=1`, `PERSISTENT=0` olarak çalıştı. DSI'da gerçek `ID XX:XX:XX` metni görülmeden B15 görsel PASS yapılmadı; kimlik davranışı B16 imajında korunuyor. |
| BT-B16Çalışma zamanı taramasını canlı listeye aktar | Geçti | Açılış Classic/BLE snapshot'ı boş kalsa bile B09 birlikte-çalışma taramasının başarılı BLE sonucunu HomePager modeline yayımla; 15 saniyelik sessiz aralıktan sonra taramayı yeniden kur. | Gerçek D>0 çalışma zamanı makbuzu MODEL_DEVICES>0 üretmeli; boş/başarısız yenileme son iyi listeyi silmemeli; eşleşme sahibi öncelikli kalmalı ve aynı bootta R211 WIFI_OK sürmeli. | Fiziksel PASS: 4dd6573d12a799fe997343cb78f192598a25eba17150a634f0a93f55ad1c017d imajı Ethernet/TFTP'den açıldı. Açılış taramasının sıfır sonuçlu olabildiği aynı bootta çalışma zamanı `BTCOEX_RESULT` D=7/COMPLETE=1, sonraki yenileme `BTREFRESH_RESULT` BT_DEVICES=6/BT_COMPLETE=1 ve `BTUI` STATUS=Complete/MODEL_DEVICES=7 üretti. Wi-Fi nesil 7–13 arasında çalışmayı sürdürdü ve 12–16 gerçek ağ raporladı. Başarılı BLE sonuçları artık listeye yayınlanıyor; yenileme tek seferle sınırlı değil. |
| BT-B17Apple reklam kanıtı ve dürüst model sınırı | Geçti | Apple Manufacturer Specific Data içindeki little-endian Company Identifier 0x004C'yi, Continuity türünü ve varsa gerçekten yayınlanan model kimliğini çöz; Nearby Info paketinden kesin iPhone modeli tahmin etme. | Fiziksel ham reklamda ff 4c 00 görülmeli; UI `Apple 0x004C / Nearby Info` ile `Model: yayınlanmıyor` sınırını göstermeli. Yalnız Proximity Pairing gibi gerçek model kimliği taşıyan pakette eşleşen model adı/hex kimliği gösterilmeli; B16 canlı yenileme ve R211 Wi-Fi gerilememeli. | Fiziksel PASS: 2f640e11f824626842f1ef199b7c177ac58a6fc0ddf85ef10594b90633522917 imajı Ethernet/TFTP'den açıldı ve `BTAPPLE GATE=BT-B17 COMPANY=0x004C MODEL_POLICY=ADVERTISED_ONLY NEARBY_INFO_MODEL=ABSENT SESSION_ID=ROTATING` sözleşmesini yayınladı. Gerçek BLE kaydında 11 cihaz ve birden çok `ff4c00...` Apple reklamı görüldü; Nearby Info (0x10), Find My (0x12) ve Galaxy Watch adı ayrıştırıldı. Canlı yenileme `BTRF ... OK=1`, Wi-Fi `WIFI_OK ... OK=1` verdi. UI host kabulü 69/69 geçti; Nearby Info'dan iPhone nesli uydurulmuyor. |
| BT-B18Değişken satır yüksekliği ve çakışmasız liste | Geçti | B17'nin isteğe bağlı üçüncü bilgi satırını gerçek font ölçülerine göre yerleştir; çizim, ayraç, dokunma, görünürlük ve kaydırma sonunu tek satır geometrisinden üret. | Karışık iki/üç satırlı listede metinler çakışmamalı, dokunulan aygıt ekrandaki aygıtla aynı olmalı, son aygıt erişilebilir kalmalı ve yenilemede eski üçüncü satır izi kalmamalı. Fiziksel DSI fotoğrafı görsel kabul için zorunludur. | Fiziksel ve görsel PASS: eski 76 px satırda üçüncü metin y+90'da başlıyordu. B18 font ölçülerinden 90 px iki satır ve 118 px üç satır üretiyor. 71/71 UI ve 93/93 radyo-kaynak testi geçti. 14a7d9fff357f914bf44c7290bc6b39333b6c2108635df0360e235be1d7fac71 imajı Ethernet/TFTP'den açıldı; `BTROW GATE=BT-B18`, `BTRF ... OK=1` ve `WIFI_OK G=2 N=13 OK=1` görüldü. 707ae05018821239a3cb76ea7ea7e7fdd1af3e0f8322834be7a54ad96343473d karmalı gerçek DSI fotoğrafında iki satırlı DESKTOP-A21IH62 ile üç satırlı Apple/iPhone kayıtları aynı görünümde çakışmadan çizildi. |
| BT-B19Aygıt adı kaynağı telemetrisi | Geçti | Her adın Classic EIR, Classic Remote Name, BLE Advertisement veya BLE Scan Response kaynağını kısa/tam ayrımıyla HCI'dan UI modeline taşı; tarama davranışını değiştirme. | Host testleri bütün kaynak sınıflarını doğrulamalı; fiziksel UART'ta `BTNAMEPROV GATE=BT-B19` ve her adlı aygıtta `NAME_SOURCE=` görülmeli; B18 görünümü ve R211 Wi-Fi korunmalı. | Fiziksel PASS: `e0877f0244786d97b802b870353451bd2362d6e19c77b07ee749e4115857fa8f` imajı Ethernet/TFTP'den açıldı. Firmware staging 1190/1190 sektör, RETRIES=0 ve OK=1; NVRAM OK=1. `BTNAMEPROV GATE=BT-B19 DEVICES=14 PHYSICAL=1` görüldü. DESKTOP-A21IH62 adı `CLASSIC_REMOTE_NAME`, Galaxy Watch Ultra adı `BLE_SCAN_RSP_COMPLETE` kaynağından geldi. R211 regresyonu yok: ilk tarama `WIFI_OK G=2 N=13 OK=1`, canlı tekrarlar G=4/N=11, G=5/N=15 ve G=8/N=11 ile geçti; UI/PRESENT ve BTCOEX canlı kaldı. |
| BT-B20Çalışma zamanı aktif BLE ad penceresi | Geçti | Şu an pasif olan B09/B16 çalışma zamanı taramasında, kısa ve bounded aktif pencereyle Scan Request gönder; eşleşme ve Wi-Fi H4/SDIO sahipliğini koru. | B19'a göre `BLE_SCAN_RSP_*` kaynaklı ad sayısı artmalı; timeout/malformed/unexpected sıfır, Wi-Fi taraması canlı ve önceki iyi liste korunmuş olmalı. | Fiziksel PASS. `40a2f172e8869370a17195bea741b7f0f9aa88c9d2a06ec4828a997149284b37` karmalı imaj Ethernet/TFTP'den 4.715.792 bayt olarak açıldı. Çalışma zamanı taraması aktif moda geçti ve `BTA20 G=5 D=7 N=1 SR=1 T=0 M=0 U=0 X=0 OK=1 P=1` verdi: yedi BLE aygıtı, Scan Response kaynaklı bir gerçek ad, sıfır timeout/bozuk/beklenmeyen çerçeve ve sıfır bütçe taşması. Aynı bootta R211 Wi-Fi `WIFI_OK G=3 N=16 OK=1` ile canlı kaldı. Bağlantı/eşleşme/GATT eklenmedi; seçili fiziksel makbuz `evidence/rpi5/radio/attempt-bt-b20-runtime-active-scan-uart-receipt/` altında kayıtlıdır. |
| BT-B21ADV + Scan Response sağlam birleştirme | Geçti | Aynı adres/tür için reklam üretici verisini kaybetmeden Scan Response adını birleştir; eksik/kısa/tam ad önceliğini deterministik yap. | Paket sırası ters, yinelenmiş veya parçalı olduğunda üretici verisi, en iyi ad ve kaynak etiketi kaybolmamalı; 16 kayıt sınırı taşmamalı. | Fiziksel PASS. ADV ve Scan Response iki ayrı 31 baytlık tamponda tutuluyor; connectable bilgisi yalnız ADV event type'tan geliyor ve ad önceliği tam/kaynak/uzunluk sırasıyla deterministik kalıyor. `c6b4bec6e606de4af1e3c863d748880f6d68d03f2b2db190bc228bef789bc2d1` karmalı imaj Ethernet/TFTP'den açıldı ve iki gerçek pencerede `BTM21 D=5 SR=4 BOTH=1 RO=0 C=4 M=0 T=0 OK=1 P=1` ile `BTM21 D=6 SR=3 BOTH=1 RO=0 C=3 M=0 T=0 OK=1 P=1` verdi: aynı kimlikte hem reklam hem dolu Scan Response yükü ölçüldü, bozuk rapor ve taşma sıfır kaldı. Aynı bootta R211 Wi-Fi 84 tamamlanmış tarama ile canlı kaldı (`WIFI_OK G=85 N=13 OK=1`). İkinci boot ölçülmüş negatif kontrol olarak saklandı: reset makbuzu `WIFIAUTORESET RESET REASON=UART_R BYTE=0x52` yakalandı, 13 pencere `BOTH=0 OK=0` verdi çünkü menzilde dolu Scan Response yayan aygıt yoktu; kapı kendini terfi ettirmedi. Aynı gün B22 imajının açılışlarında ölçüm tekrarlandı: bir bootta 14 pencerenin 14'ü `OK=1` verdi ve `BOTH` 3'e kadar çıktı, yani birleştirme tek bir şanslı pencereye bağlı değil. Ham UART arşivleri, doğrulayıcı JSON'u ve sınırlar `evidence/rpi5/radio/attempt-bt-b21-adv-scan-merge-uart-receipt/` altında mühürlü. Sınır: tek atışlık `BTMERGE GATE=BT-B21` sözleşme satırı yoğun CDC'de parçalandı, bu yüzden imaj kimliği atomik `BTM21` makbuzuna ve yayımlanan TFTP SHA-256'sına dayanıyor; açılış güç kablosu kesilerek değil hands-free PM watchdog `R` yoluyla yapıldı. |
| BT-B22Bloklamayan Classic Remote Name kuyruğu | Yürütülüyor | EIR adı olmayan Classic aygıtları tek tek ve süre sınırlı Remote Name kuyruğuna al; ana döngüyü ve watchdog'u durdurma. | DESKTOP/TV gibi Classic aygıt adları canlı yenilemede çözülmeli; bir aygıtın timeout'u sonraki aygıtı, BLE'yi veya Wi-Fi'yi engellememeli. | Sıradaki fiziksel kapı; host uygulaması ve B22 imajı hazır. En çok 16 ölçülmüş Classic hedef tek tek kuyruğa alınıyor. Komut durumu için 1 saniye, ad için 5 saniye sınırı var; her ana döngü poll'u en çok 512 UART baytı tüketiyor ve watchdog'u besliyor. Timeout/reject sonraki hedefe ilerliyor; BLE taraması aynı anda başlayamıyor, pairing isteği kuyruğu HCI Remote Name Cancel ile boşaltıp önceliği alıyor. Çözülen ad yalnız mevcut Classic satıra `CLASSIC_REMOTE_NAME` kaynağıyla uygulanıyor. 30/30 H4 ve 74/74 UI testi geçti; `image-rpi5-bt-scan-b22` başarıyla üretildi. Fiziksel kabul için `verify-rpi5-bt-gate-uart.py --gate b22` artık `BTREMOTE_START`, `REQUESTED==TARGETS`, sıfır malformed/bütçe taşması ve çözülen ad ya da timeout-sonrası ilerleme arıyor. 21 Eylül'de `d74b3e812a6327f036b82ab62ec524f4421dafb8d96ac95ec2b34036f86842b2` karmalı B22 imajı TFTP'den üç kez açıldı: `BTREMOTE GATE=BT-B22` sözleşmesi hatta görüldü, Classic Inquiry menzildeki tek keşfedilebilir Classic aygıtı buldu ve adı zaten açılış yolunda `CLASSIC_REMOTE_NAME` ile çözüldü. Bu yüzden çalışma zamanı kuyruğunun hedefi kalmadı ve tasarım gereği hiç `BTRN22` makbuzu basılmadı; kapı kendini terfi ettirmedi. PASS için en az bir gerçek adsız Classic hedef (ör. ikinci keşfedilebilir Classic aygıt veya açılışta adı çözülemeyen bir aygıt) gerekiyor. |
| BT-B23Kalıcı kullanıcı adı, bond adı ve güvenli önbellek | Engelli | Kullanıcı alias'ını, doğrulanmış bonded adı ve son canlı adı ayrı güven düzeyleriyle sakla; yeniden açılışta adres/ad/tarih/kaynak bütünlüğünü doğrula. | HUAWEI FreeClip 2 ve ZR-WP3C03 gibi eşleşmiş aygıtlar reklam adı yayınlamasa da yeniden açılışta doğru adla görünmeli; bozuk kayıt fail-closed atılmalı. | Host biçimi ve RAM entegrasyonu hazır; fiziksel kalıcılık güvenlik önkoşulunda engelli. Alias → bonded cache → canlı ad önceliği, Classic bond sonrası RAM kimliği ve 16 kayıtlık ASBTID01 biçimi uygulandı. Kayıt 4096 bayt, AES-128-CTR ile şifreli ve tüm header+ciphertext HMAC-SHA256 ile doğrulanıyor; anahtarlar 32 bayt kök sırdan ayrı türetiliyor. Sıfır/eksik sır, sıfır nonce, tahrif, yanlış anahtar, bozuk padding, yinelenen kimlik, geçersiz UTF-8 ve sıfır IRK/Link Key fail-closed. NIST AES ve cache round-trip/tahrif testleri geçti; B23 imajı üretildi. Fakat Pi imajında güvenilir cihaz sırrı ve atomik kalıcı backend yok: `PERSIST_BACKEND=UNAVAILABLE WRITE=0`. Bu iki önkoşul ve gerçek reboot restore kampanyası olmadan PASS verilmeyecek. |
| BT-B24LE SMP, IRK ve dönen adres kimliği | Engelli | BLE bonding anahtarlarını ve IRK'yı güvenli sakla; Resolvable Private Address'ı bond kimliğine çöz ve eski oturum satırını birleştir. | Adres döndüren bağlı aygıt yeniden göründüğünde çift satır üretmemeli; eşleşmemiş rastgele adresler kesinlikle birleştirilmemeli. | Host kripto/kimlik çözümü ve B24 imajı hazır; gerçek LE bond taşıması olmadığı için fiziksel IRK ediniminde engelli. AES-128 `ah`, HCI byte sıralı RPA çözümü ve yalnız şifreli SMP Identity Information 0x08 + Identity Address Information 0x09 assembler'ı uygulandı. Bluetooth Core Appendix D.7 vektörü, yanlış IRK/non-RPA, PDU sıra değişimi, uzunluk/adres türü, sıfır IRK ve çelişkili tekrar testleri geçti. UI iki dönen adresi yalnız aynı non-zero identity_id kanıtından sonra birleştiriyor; RSSI/ad/üretici benzerliği birleşme nedeni değil. Mevcut imaj `SMP_TRANSPORT=ABSENT` beyan ediyor; minimal LE ACL/L2CAP/SMP ve gerçek IRK ölçülmeden PASS değildir. |
| BT-B25Bağlanabilir aygıtlar için minimal L2CAP / ATT / GATT istemcisi | Engelli | Yalnız reklam olayı bağlanabilir olduğunu kanıtlıyorsa ve kullanıcı eşleşmeyi onayladıysa servis keşfi ile GAP Device Name 0x2A00 oku; ATT MTU, Authorization/Authentication hatası ve timeout sınırlarını uygula. Bağlantısız Find My/Nearby Info yayınlarına CONNECT_REQ gönderme. | GATT adını gerçekten ve yetkili biçimde sunan aygıt doğrulanmış bağlı ad olarak güncellenmeli; non-connectable olay, alan yokluğu veya izin reddi ölçülü sonuç üretmeli, önceki kanıt korunmalı ve ad uydurulmamalı. | Host ATT/GATT çekirdeği ve B25 imajı hazır; LE ACL/L2CAP taşımasında engelli. `GattAdmission` yalnız ölçülmüş connectable olay + açık kullanıcı onayı + authenticated link üçlüsünü kabul ediyor. MTU Exchange, Read By Type ve Read istekleri ile Error/MTU/Read cevapları bounded çözülüyor; Insufficient Authentication ve Insufficient Authorization ayrı kalıyor. Non-connectable Find My/Nearby Info bağlantı isteğine terfi etmiyor. `LE_ACL_L2CAP_TRANSPORT=ABSENT CONNECT_REQ=0`; gerçek LE bağlantısı ve ATT makbuzu olmadan PASS değildir. |
| BT-B26Device Information Service model kanıtı | Engelli | Yetkili ve bağlanmış GATT oturumunda DIS içindeki Model Number, Manufacturer Name ve PnP ID alanlarını yalnız aygıt gerçekten sunuyorsa oku; model ile görünen adı ayrı tut. | Model satırı karakteristik UUID ve gerçek değer kanıtıyla oluşmalı; opsiyonel alan yoksa `yayınlanmıyor` sınırı korunmalı; seri/system ID izinsiz gösterilmemeli. | Host kanıt modeli ve B26 imajı hazır; B25 taşımasının arkasında engelli. GAP Device Name 0x2A00, DIS Model Number 0x2A24, Manufacturer Name 0x2A29 ve PnP ID 0x2A50 ayrı alanlarda tutuluyor. Metin bounded geçerli UTF-8 olmalı; PnP ID tam 7 bayt ve vendor-source 1/2 olmalı. Seri numarası ve System ID özellikle toplanmıyor (`SERIAL=FORBIDDEN SYSTEM_ID=FORBIDDEN`). Gerçek yetkili GATT oturumundan alan ölçülmeden model/ad iddiası yok. |
| BT-B27Classic SDP Device ID | Engelli | Classic ACL üstünde minimal SDP istemcisiyle Device ID vendor/product/version özniteliklerini oku ve belgeli ürün tablosuna bağla. | Smart TV/PC gibi hedefte gerçek SDP kaydı ölçülmeli; kayıt yoksa Class of Device üstünden kesin model çıkarılmamalı. | Strict SDP parser ve B27 imajı hazır; Classic L2CAP/SDP taşımasında engelli. SDP data-element uzunluk/türleri ve tam ServiceSearchAttributeResponse PDU'su çözülüyor; Device ID 0x0200–0x0205 alanlarında eksik, duplicate, truncated, yanlış tür ve continuation/trailing veri fail-closed. Vendor/product/version yalnız ölçülen kimlik olarak kalıyor; Class of Device'tan model adı üretilmiyor. `CLASSIC_L2CAP_SDP_TRANSPORT=ABSENT`; gerçek TV/PC SDP kaydı olmadan PASS değil. |
| BT-B28Belgeli Fast Pair ve Swift Pair adları | Sonraki imaja taşındı | Google Fast Pair 0xFE2C model kimliği ve Microsoft Swift Pair Display Name alanını yalnız resmî biçim ve uzunluk doğrulamasıyla çöz. | Pozitif ve bozuk-paket testleri geçmeli; belgesiz Apple/Samsung üretici baytlarından model tahmini yapılmamalı. | Host parser, canlı BLE snapshot entegrasyonu ve B28 imajı hazır; B21 fiziksel kabulinin arkasına taşındı. Google Fast Pair yalnız UUID 0xFE2C Service Data'nın tam üç bayt Model ID biçimini kabul ediyor; ID ancak açık belgeli tablo ile ürün adına dönüşebilir, aksi halde UI `Fast Pair ID: 0xXXXXXX` gösterir. Microsoft Swift Pair yalnız Company 0x0006 / Beacon 0x03 / sub-scenario 0x00 ve bounded geçerli UTF-8 Display Name biçimini kabul ediyor; ad kaynağı `SWIFT_PAIR`. Bozuk uzunluk/UUID/company/beacon/UTF-8 reddediliyor. Belgesiz Apple/Samsung üretici baytlarından model çıkarılmıyor. Gerçek pozitif Fast/Swift reklamı ve DSI/UART kanıtı olmadan PASS değil. |
| BT-B29Ad önceliği, tekilleştirme ve kanıt sunumu | Sonraki imaja taşındı | Alias → bonded cache → canlı tam ad → belgeli ürün adı → kısa ad → üretici/sınıf fallback sırasını uygula; model ve ad kanıtını ayrı göster. | Aynı adlı iPhone'lar yanlış birleştirilmemeli; aynı bonded aygıt adres döndürünce çiftlenmemeli; ayrıntı sayfası ad/model kaynağını dürüstçe göstermeli. | Host/UI uygulaması ve B29 imajı hazır; fiziksel önkoşulların arkasına taşındı. Tek öncelik zinciri `kullanıcı alias > bonded cache > yetkili GATT Device Name > tam canlı ad > belgeli vendor ad > kısa canlı ad > üretici/sınıf fallback` olarak kodlandı. Non-zero identity_id olmadan `Kimlik: bond` gösterilmiyor; RPA collapse yalnız IRK çözümünden sonra. B29 görünümü ad kaynağını (`Scan Response tam`, `Classic Remote Name`, `Swift Pair Display Name`, alias/bond vb.) ayrı satırda, Fast Pair/Apple model kanıtını ayrı satırda çiziyor; üç/dört satırlı geometri aynı paint/hit/scroll hesabını kullanıyor. Host testleri session-vs-bond kanıtını ve ad/model satır ayrımını doğruluyor. Gerçek DSI, same-name çoklu cihaz ve gerçek IRK rotation makbuzu olmadan PASS değildir. |
| BT-B30Fiziksel cihaz matrisi ve sürüm kabulü | Engelli | PC, saat, kulaklık, TV ve çoklu iPhone ile eşleşmemiş/eşleşen/reboot/menzil-dışı/adres-dönüşü senaryolarını; aynı anda R211 Wi-Fi'yi tekrar ölç. | Her görünen adın kaynağı, kimlik kararı ve kalıcılığı kanıtlanmalı; üç bağımsız boot, sıfır radyo regresyonu ve DSI görsel/dokunma kabulü tamamlanmalı. | B30 release-candidate imajı ve fail-closed matris marker'ı hazır; fiziksel donanım/cihaz kampanyasında engelli. İmaj `HOST_READY=1 PHYSICAL_ACCEPTED=0 BOOTS_REQUIRED=3` yayımlıyor. B21 DUAL_PAYLOAD UART kabulü, B22 adsız Classic/timeout sırası, B23 güvenli sır+atomik reboot restore, B24 gerçek IRK/RPA, B25/B26 gerçek GATT, B27 gerçek SDP, B28 pozitif Fast/Swift reklamı ve B29 DSI satır/kimlik kanıtı henüz yok. PASS yalnız PC, saat, kulaklık, TV ve çoklu iPhone matrisi üç bağımsız cold bootta; unpaired/paired/reboot/range/RPA senaryoları, eşzamanlı R211 Wi-Fi ve mühürlü UART/DSI kanıtıyla tamamlandığında verilebilir. |
Hedef: Android/BlueZ benzeri zengin ad listesini, tahmin değil ölçülmüş kaynağa dayandırmak. B19 gerçek UART'ta 14 aygıt ve ad kaynağı telemetrisiyle geçti; B20 çalışma zamanı aktif pencerede Scan Response kaynaklı bir ad ve sıfır hata sayacıyla fiziksel PASS aldı. B21 ADV+Scan Response birleştirmesi gerçek UART'ta BOTH=1 ile fiziksel PASS aldı. R211 Wi-Fi korundu; sıradaki fiziksel kapı B22.
B19–B23 · 6–9 iş günü / 44–70 saat: görünür ad kapsamını ve reboot sonrası adı belirgin biçimde iyileştirir.
B24–B26 · 8–13 iş günü / 68–106 saat: dönen adres kimliği ile bağlı aygıt GAP/DIS kanıtını ekler.
B27–B28 · 5–8 iş günü / 36–60 saat: Classic Device ID ve belgeli Fast/Swift Pair ürün bilgisini ekler.
B29–B30 · 3–5 iş günü / 20–36 saat: öncelik, tekilleştirme, fiziksel matris ve sürüm kabulünü kapatır.
Toplam: 22–35 iş günü / 168–272 mühendislik saati. Çevresel cihazların reklam/servis davranışı revizyon sayısını etkiler.
Aynı ad, yakın RSSI, aynı OUI veya aynı üretici kimliği tek başına iki kaydı birleştirme yetkisi vermez. Model bilgisi görünen addan ayrı kanıtlanır.
| Fiziksel hedef | Çözülecek yollar | Kabul |
|---|---|---|
| DESKTOP-A21IH62 | Classic EIR / Remote Name / SDP | Canlı ad, PC sınıfı, kopma ve yeniden görünme |
| Galaxy Watch Ultra (DV1A) | BLE Advertisement + Scan Response + RPA | Ad korunur; dönen adres yanlış çiftlenmez |
| HUAWEI FreeClip 2 | Scan Response / bond cache / Fast Pair | Reboot sonrası doğrulanmış ad; varsa belgeli model ID |
| ZR-WP3C03 | Eşleşme ve kalıcı ad | Reklam sessizken bile bağlı kayıt adı korunur |
| Smart TV | Classic/dual-mode / Remote Name / SDP Device ID | Ad ve model kanıtı ayrı; CoD'dan model uydurulmaz |
| Birden çok iPhone | Apple Nearby Info / Find My / connectable bayrağı / GAP 0x2A00 yalnız onaylı eşleşme / Personal Hotspot A/B | Non-connectable yayına bağlantı zorlanmaz; aynı görünen adlar karışmaz; iPhone nesli tahmin edilmez |
Plan: Önce mevcut yeteneği dürüstçe ayır, sonra fiziksel altyapıyı ve firmware girdisini doğrula.
Gerçekleşen: UI yerel-only; gerçek scan yok. ttyACM1, eth1/TFTP ve 63.806 bayt HCD doğrulandı; Pi R211 Wi-Fi scan üretmeye devam ediyor.
Sapma: Yok. Otomatik reset henüz PASS değil ve varmış gibi raporlanmadı.
Plan: Linux–AselsanOS ilk UART farkını tek değişkene indir; R211 Wi-Fi tabanını koruyarak fiziksel imaj çalıştır.
Gerçekleşen: R194 ham W5 kaydından dört yanlış pull-down çözüldü. BT-B01 yalnız UART pad bias planını [0,2,0,2] yaptı; TFTP imajı ve UART R reset yolu doğrulandı. HCI cevap vermedi, Wi-Fi GEN=2 Complete kaldı.
Sapma: Takvim sapması yok. Pull düzeltmesi gerekliydi fakat tek başına yeterli değildi; sonuç PASS gibi sunulmadı ve BT-B02'ye yalnız sonraki resmi fark olan AFE taşındı.
Plan: ROM-speed HCI yanıtı için tek yeni davranış olarak BCM7271 otomatik RTS/CTS'yi aç.
Gerçekleşen: MCR AFE 0x23 fiziksel olarak okundu. Sıkı çözücü opcode 0x0c03/status 0 Command Complete olayını kabul etti; EVENT=1 ve RXTO=0. R211 Wi-Fi FWREADY 55 ms ve gerçek BSS taramaları korundu.
Sapma: Takvim sapması yok. Çok çekirdekli UART çıktısı karakter seviyesinde karıştığı için sonuç tek bir kozmetik satıra değil, sıkı decoder durumuna ve ham kayıt SHA-256'sına bağlandı.
Plan: ROM HCI geçtikten sonra pinli BCM4345C0 HCD'yi Linux sırasıyla ve her opcode/status cevabını eşleyerek yükle.
Gerçekleşen: Fail-closed HCD parser ve senkron H4 komut motoru kodlandı. İlk derleme, davranış hatası değil eski bir kaynak testinin yeni yardımcı fonksiyonu yanlış kapsamda taraması nedeniyle durdu; test bring_up gövdesine daraltıldı. 92/92 test ve AArch64 build geçti; fiziksel koşu başladı.
Sapma: Bir test-düzeltme çevrimi eklendi; donanım planı, tek değişken ve kapı sırası değişmedi.
Plan: HCD'nin 323 kaydını Linux sırasıyla, her Command Complete opcode/status cevabını doğrulayarak yükle; R211 Wi-Fi'yi aynı açılışta yeniden kabul et.
Gerçekleşen: BTHCD SHAPE=1, SHA sabit, BYTES=63806/63806, RECORDS=323/323/323, PAYLOAD_SENT=62837, START_ACK=1, LAUNCH=1/1, FAILED_REC=65535, TXTO=0, RXTO=0 ve COMPLETE=1. Wi-Fi gerçek BSS ve Complete üretmeye devam etti.
Sapma: Donanım veya kapı sırası sapması yok. Çok çekirdekli UART satırları karıştığı için değerlendirme alan bazlı makbuzlara ve mühürlü ham kayda dayanıyor.
Plan: Patchram geçtikten sonra Raspberry Pi 5'in resmi 3 Mbit/s hızına, önce controller sonra host sırasıyla geç; post-patch Reset ve sürüm kimliğini oku.
Gerçekleşen: Raspberry Pi DTS max-speed=3000000 ve Linux hci_bcm 0xfc18 sırası doğrulandı. B04 tek-değişkenli imajı hazırlanıyor; henüz fiziksel PASS yok.
Sapma: Yok.
Plan: Denetleyiciyi 0xfc18 ile önce 3 Mbit/s'ye geçir, yalnız ACK'den sonra host divisorünü değiştir ve yeni hızda Reset ile iki bağımsız kimlik sorgusu yap.
Gerçekleşen: BTBAUD ACK=1/status=0, divisor 52→2/readback=2 ve Reset ACK=1 verdi. BTIDENT HCI_VER=0x09, LMP_VER=0x09, MFR=305, SUBVER=0x6119, verbose match ve COMPLETE=1 üretti. İmaj bc03d8ff…bef95 olarak TFTP'den açıldı.
Sapma: Kapı sırası ve controller-first geçiş değişmedi. UART çok çekirdekli çıktısı yine karakter seviyesinde karıştı; karar sıkı opcode/status/kimlik eşlemesine bağlandı.
Plan: 3 Mbit/s kimliği geçtikten sonra genel H4 işlem motorunu ve 100-komut stres kabulünü ekle.
Gerçekleşen: BT-B04 fiziksel kabulünün hemen ardından B05 kaynak ve simülasyon çalışması başlatıldı; henüz fiziksel PASS yok.
Sapma: Yok.
Plan: Paket türü/uzunluğu koruyan kalıcı H4 motorunu host akış testlerinden geçir ve 3 Mbit/s hatta 100 ardışık kimlik komutuyla fiziksel olarak zorla.
Gerçekleşen: 7/7 host akış testi geçti. BTH4 100 tamamlanma ve 100 kimlik eşleşmesi, TXTO=0, RXTO=0, overflow/drop=0 üretti; aynı boot R211 Wi-Fi COUNT=7, TRUNCATED=0, STALE=0 tamamlandı.
Sapma: Kapı veya davranış sapması yok. Otomatik UART wrapper SIGUSR1 sonrasında ebeveyni 138 ile kapattığı için yetim kalan aynı capture süreci terminalden sonra doğal olarak bitti; reset öncesi prefix makbuzdaki kesin offset ile kesildi ve bu araç davranışı kanıt notuna yazıldı.
Plan: H4 motoru fiziksel geçtikten sonra Classic Inquiry/RSSI/EIR ve gerekirse Remote Name çözümlemesini ekle.
Gerçekleşen: Linux hci.h komut/olay yapılarıyla parser ve fiziksel profil hazırlandı; henüz Classic cihaz PASS'i yok.
Sapma: Yok.
Plan: Mode 2 ve 10,24 saniyelik GIAC Inquiry'yi çalıştır; sonuç/RSSI/EIR olaylarını ve gerekirse Remote Name cevaplarını tek makbuzda kapat.
Gerçekleşen: 83bf6761… imajı TFTP'den açıldı; HCD, 3 Mbit/s kimlik ve BTH4 100/100 yeniden geçti. Sonraki senkron bekleyiş 15 saniyelik PM watchdog besleme yoluna dönemedi; bootloader donanım resetini kaydetti ve BTCLASSIC sonuç satırı oluşmadı.
Sapma: Plan sırası değişmedi. İlk fiziksel koşu yeni bir yürütme sınırı buldu: radyo sonucu değil otomasyon watchdog'u taramayı kesti. B06b'nin tek farkı HCI sessizken 500 ms'de bir watchdog servis çağrısıdır; Inquiry komutu, parser ve Wi-Fi tabanı aynıdır. UART reset sarmalayıcısının 138 çıkışı nedeniyle açılış iki salt-okunur parçada mühürlendi.
Plan: B06a'nın Inquiry/parser/R211 tabanını değiştirmeden uzun HCI bekleyişinde watchdog'u en geç 500 ms arayla servis et; gerçek Classic adres/RSSI/ad ve aynı-boot Wi-Fi kabulünü ölç.
Gerçekleşen: ebd03783… imajı TFTP'den açıldı. Inquiry mode ve Inquiry status 0, Inquiry Complete status 0, DEVICES=1, NAMED=1, timeout=0, COMPLETE=1 oluştu. Ad DESKTOP-A21IH62 ve class 6c010c bağımsız Kali denetleyicisiyle eşleşti; R211 Wi-Fi gerçek BSS nesilleri üretmeye devam etti.
Sapma: Radyo veya kapı sırası sapması yok. Çok çekirdekli console uzun cihaz satırında karakterleri iç içe geçirdiği için tam adres ve sayısal RSSI metni okunaklı kalmadı; sıkı iç makbuz RSSI varlığını doğruladı, ad/class bağımsız kontrolle eşleşti. Temiz adres/RSSI sunumu BT-B08/BT-B10'a açık kabul maddesi olarak taşındı; bu sınırlama gizlenmedi.
Plan: Classic kapısı geçtikten sonra LE event mask, pasif scan parameters/enable ve Advertising Report parserını tek yeni davranış olarak ekle.
Gerçekleşen: Linux hci.h yapı ve opcode'ları sabitlendi; B07 host testleri ve fiziksel imaj hazırlanıyor. Classic B06 ile R211 Wi-Fi özellikleri tabanda kalıyor; henüz BLE cihaz PASS'i yok.
Sapma: Yok.
Plan: LE event mask, pasif scan parameters/enable, 10 saniyelik Advertising Report toplama ve scan-disable kapanışını gerçek donanımda; B06 Classic ve R211 Wi-Fi ile aynı boot içinde kabul et.
Gerçekleşen: 8915187e… imajı TFTP'den açıldı. Dört LE komutu status 0 ve timeout 0 verdi; 99 rapor, 9 tekil gerçek cihaz, adres türleri/RSSI/AD verileri, malformed=0, truncation=0 ve COMPLETE=1 oluştu. Aynı boot B06 Classic'i ve 136 Wi-Fi sonuç marker'ını korudu.
Sapma: Takvim veya komut kapsamı sapması yok. Çevredeki pasif reklamlarda Local Name AD alanı bulunmadı (NAMED=0); aktif scan request eklenmedi çünkü B07 sözleşmesi pasifti. UI adsız cihaz etiketi BT-B08'e taşındı. Çok çekirdekli UART interleaving'i sürdüğü için atomik sunum BT-B08/BT-B10 kabulinde açık kaldı.
Plan: Fiziksel Classic/BLE kayıtlarını ortak modele aktar; tekilleştir, yaşlandır, RSSI sırasına koy ve demo satırlarını gerçek snapshot ile değiştir.
Gerçekleşen: B06 ve B07 fiziksel kapıları kapandı; ortak model/UI kaynak incelemesi başladı. Henüz demo satırları kaldırılmadı ve UI PASS iddiası yok.
Sapma: Yok.
Plan: Fiziksel Classic/BLE kayıtlarını ortak modele aktar; aynı adresi birleştir, 60 saniyede yaşlandır, güçlüden zayıfa sırala ve yerel demo cihazları Bluetooth sayfasından kaldır.
Gerçekleşen: 16 kayıt sınırı ve en-zayıfı düşürme kuralı olan gerçek HCI snapshot'ı eklendi. Classic/BLE kaynakları, ad/adres/tür/class/AD/RSSI ve generation alanları UI'ya kopyalanıyor; sayfa en çok dört gerçek satır çiziyor ve eşleştirme/bağlantı durumu uydurmuyor. 62/62 UI, 93/93 radyo-kaynak, 12/12 ekran ve 17/17 SD testi geçti.
Sapma: Fiziksel kabul henüz yapılmadığı için kapı geçirilmedi. Görsel sayfa dört satır gösteriyor; model 16 kaydı koruyor. Kaydırma ve ayrıntı etkileşimi B09/B10 kabulinde ayrıca ölçülecek.
Plan: B08 imajını Ethernet/TFTP ile aç, BTMODEL ve gerçek Bluetooth UI makbuzlarını al; aynı bootta R211 Wi-Fi regresyonunu doğrula.
Gerçekleşen: İlk ea0a1015…160f adayı TFTP'den yüklendi, fakat çok çekirdekli satırları atomik yapan global spin kilidi cache/coherency kurulmadan ilk Rust logunda etkinleşti. UART yalnız BOOT0'a ulaştı; BTMODEL/UI makbuzu oluşmadı. Kök neden kapatıldı: diagnostic kilidi erken bootta devre dışı, yalnız Bluetooth bring-up öncesinde güvenli SMP aşamasında etkin. İlk düzeltilmiş bbd5de50…f098 aday fiziksel açılmadan geçersiz kaldı; makine kabul profiliyle yeniden üretilen 885fa3b3…d8f1 imajı 2026-09-19T11:35:46Z'de TFTP'ye yayımlandı ve sonraki BTUI kabul sertleştirmesiyle yerini d15757f6…af70 adayına bıraktı.
Sapma: Plan sırası ve radyo davranışı değişmedi; ölçüm altyapısı erken-boot sapması yarattı ve aynı kapı içinde düzeltildi. Duran kernel UART R resetini işlemedi. Debug Probe donanım reset arayüzü Kali'de root yazma izni gerektiriyor ve erişilebilir güç rölesi yok. Bu nedenle düzeltilmiş aday hazır olsa da yeni fiziksel açılış olmadan PASS yazılmadı; ilk koşu ve boş reset denemesi ayrı SHA-256 kanıtlarıyla mühürlendi.
Plan: B08 fiziksel geçtikten sonra R211 Wi-Fi ve ikinci pasif BLE taramasını aynı zaman penceresinde, kayıp ve liveness sayaçlarıyla çalıştır.
Gerçekleşen: B08'i atlamadan B09 kodu önceden hazırlandı: BLE H4 alımı ana döngüde 1024 baytla sınırlı, Wi-Fi poll sayısı ve tüm kayıp göstergeleri makbuzda. 62/62 UI, 93/93 radyo, 12/12 ekran, 17/17 SD testi ve AArch64 build geçti; ilk b23e7f70…559d imajı yerelde mühürlendi, BTUI kabul sertleştirmesi sonrasında 1b198f8c…e1a6 olarak yeniden üretildi. TFTP config ve PUBLISHED yalnız B08 d15757f6…af70'i seçiyor.
Sapma: Uygulama hazırlığı takvimden öne çekildi, fakat kapı sırası genişletilmedi: B09 yayımlanmadı ve fiziksel PASS iddia edilmedi. B08'in duran ilk imajı UART R komutuna yanıt vermedi. Debug Probe USB düğümü geçici ve hedefi daraltılmış izinle salt-okunur sorgulandı; SWD ACK=0x07/DPIDR=0 nedeniyle bağlı bir reset hedefi kanıtlanamadı ve reset komutu gönderilmedi.
Plan: Fiziksel kapıları yalnız aynı UART kaydındaki açık, makinece denetlenebilir ölçütlerle kapat; eski boot kuyruğu, eksik alan veya kaynak/build başarısını fiziksel PASS yerine kullanma.
Gerçekleşen: Fail-closed UART değerlendiricisi ve dört olumlu/olumsuz host testi eklendi. B08 için fiziksel ve sentetik olmayan benzersiz model satırları, Classic/BLE gözlemleri ve aynı kayıtta R211 COUNT>0 zorunlu; B09 için ek olarak gerçek eşzamanlı Wi-Fi poll'u, BLE raporu/cihazı ve sıfır timeout, malformed, unexpected ve bütçe taşması zorunlu. İlk başarısız B08 kaydı araç tarafından FAIL olarak sınıflandırıldı.
Sapma: Kapı sırası ve imaj seçimi değişmedi. 60 saniyelik tazelik kodu ayrıca denetlendi: Bluetooth ekranı bu eşikte satırları silmiyor; son doğrulanmış snapshot yeni ölçüm gelene kadar korunuyor. Böylece uzun Wi-Fi staging süresi B08 satırlarını görünmez yapmıyor.
Plan: B08 bütün-boot UART kaydını al; sıkı kabul geçerse B09'u atomik yayımla, ardından üç bağımsız B09 bootunu aynı değerlendiriciyle ölç. Reset veya BOOT0 yoksa zaman aşımında fail-closed dur.
Gerçekleşen: run-rpi5-bt-b08-b09.py eklendi; imaj/profil/TFTP kimliklerini doğruluyor, UART'ı tek descriptor ile arm ediyor, aynı descriptor üzerinden R yazıyor, yeni BOOT0 ve fiziksel kapı makbuzunu zorunlu tutuyor. Gerçek 11:49 UTC koşusunda reset yazma makbuzu OFFSET=0 geldi; 20 saniyede BOOT0 ve UART baytı gelmedi. Süreç exit 75/BLOCKED ile kapandı, kanıtı ve SHA-256'ları mühürledi; promotions=[] kaldı ve TFTP bt-b08 885fa3b3…d8f1 seçimini korudu.
Sapma: Radyo planı veya kapı sırası sapmadı. Donmuş ilk B08 çekirdeği UART reset dinleyicisine ulaşmadığı, Debug Probe USB reset düğümü root yazma izni istediği ve erişilebilir güç rölesi olmadığı için yazılımdan yeni fiziksel boot üretilemedi. Otomasyon eski/boş kaydı PASS saymadı; B09'u yayımlamadı ve kullanıcı müdahalesi varmış gibi raporlamadı.
Plan: Çekirdekten UI'ya başarının yalnız model belleğine kadar değil, gerçek Bluetooth sayfasının fiziksel framebuffer bileşimine kadar kanıtlanmasını sağla.
Gerçekleşen: Ölçülmüş cihaz varsa Bluetooth sayfasını kabul amacıyla otomatik açan yol eklendi. Tam compose sonrasında BTMODEL ile aynı generation/model sayısı, min(model,4) görünür satır, sıfır olmayan frame CRC, AUTO_OPEN=1, PHYSICAL=1 ve SYNTHETIC=0 taşıyan BTUI makbuzu üretiliyor. Değerlendirici B08 ve B09 için bu makbuzu zorunlu kılıyor; eksik-BTUI olumsuz testiyle birlikte 5/5 değerlendirici, 62/62 UI ve 93/93 radyo testi geçti.
Sapma: Kapı sırası değişmedi. Önceki B08 adayları fiziksel UI compose'u kanıtlamadığı için geriye dönük PASS sayılmadı; imaj ve profil yeni sözleşmeyle yeniden üretildi.
Plan: UART R yanıt vermediğinde yalnız kanıtlanmış, hedefi daraltılmış ve güvenli bir donanım reset yolu varsa kullan.
Gerçekleşen: Debug Probe 2.0.0 ve SWD yeteneği salt-okunur CMSIS-DAP sorgusuyla doğrulandı. SWD DP IDCODE sorgusu ACK=0x07 ve DPIDR=0x00000000 döndürdü; bağlı hedef/reset hattı kanıtlanmadı. RESET_SENT=0 bırakıldı, USB düğümünün eski izni geri yüklendi ve geçici yardımcı ortam kaldırıldı. Kanıt: evidence/rpi5/radio/attempt-bt-b08-cmsis-dap-reset-path-20260919/cmsis-dap-target.txt; SHA-256 865a0ccce121ac09091b462b0697f1453c2ac7081e4f128bd29c4454db278569.
Sapma: Fiziksel reset hedefi kanıtlanmadığı için reset göndermeme kararı alındı. Bu, kampanya kapısını ilerletmedi ve donanımı belirsiz bir SWD komutuyla riske atmadı.
Plan: Salt-okunur sorgu hedef bulamazsa yalnız standart ve cevaplı DAP_ResetTarget komutunu dene; doğrudan SWJ pin/GPIO sürme ve belirsiz nRESET darbesi uygulama.
Gerçekleşen: DAP_ResetTarget komutu ANSWERED=1 ve STATUS=0x00 ile cevaplandı, fakat cihaz-özel reset dizisi EXECUTED=0 ve RESET_SENT=0 kaldı. Önceden açılan 115200 raw UART penceresi 25 saniyede 0 bayt verdi; BOOT0 görülmedi. Raspberry Pi resmî pin tanımı DEBUG kablosunda yalnız SWCLK/GND/SWDIO, UART kablosunda TX/GND/RX bulunduğunu ve ayrı nRESET olmadığını doğruluyor. Kanıt: evidence/rpi5/radio/attempt-bt-b08-cmsis-dap-reset-target-20260919/cmsis-dap-reset-target.txt; SHA-256 fa3632c8eb3aeb260936b304d2224de127d3280d8f8acb0885db6d2ad8f699ee.
Sapma: Yok. Araç reset uygulanmadığını açıkça bildirdi; bu cevap fiziksel reset veya PASS gibi yorumlanmadı. USB izinleri geri yüklendi, geçici container ve binary kaldırıldı.
Plan: BTUI sözleşmeli B08'i yayımla; fiziksel PASS olursa B09'u yayımla ve üç boot ölç, aksi halde fail-closed dur.
Gerçekleşen: B08 d15757f69b98a834ee9bb191462a376957a7e6585a38db75d68ecfa1eaf4af70 ve profil ada4b171b0f8c8ef459263cdf0a61bf1f2fbe42cf4d2c6bb6734566fb3d48b1a TFTP'ye atomik yayımlandı. B09 1b198f8c8d7df3f49df53f07cbcfcb3feea07cbead2dd018d836adc87582e1a6 yerelde tutuldu. 12:09:29Z koşusu B08 kimliğini doğrulayıp R yazdı; 20 saniyede yeni BOOT0 gelmeyince exit 75/RESET_UNAVAILABLE ile durdu, promotions=[] kaldı. Kanıt: evidence/rpi5/radio/attempt-bt-b08-ui-model-auto-boot1-20260919T120929Z; RUN SHA-256 1bc2881fb1bf6a483bc09c358f038477ef5d16de1a45d305276c981feea2fe28, capture SHA-256 e67d310b467e9a2e64585e416afbf08d056c7dd9402a1dd64374d75b27773a4b.
Sapma: Yok: otomasyon yeni boot görmeden B08'i geçirmedi, B09'u yayımlamadı ve üç-boot aşamasına atlamadı. Kalan tek dış koşul çalışan bir fiziksel reset/power-cycle hattıdır.
Plan: Gerçek Classic/BLE kayıtlarını ortak modele ve fiziksel framebuffer'a bağla; aynı bootta R211 Wi-Fi'yi koru, sentetik cihaz ve uydurma model adı gösterme.
Gerçekleşen: 0eeab18d… imajı strict kabulden geçti: 14 benzersiz adres, Classic=1, LE=13, dört görünür satır, CRC=0x8346a26544f57c23 ve sekiz Wi-Fi Complete aynı kayıtta bulundu. Ayrı aktif-scan kaydı gerçek JBL Tune 520BT-LE adını, Classic kayıt DESKTOP-A21IH62 adını verdi. Adsız cihazlar numaralandırılmıyor ve modele dönüştürülmüyor.
Sapma: B07 pasif taramada ad yayınlanmadığı için B08'e aktif Scan Request eklendi. Bu yalnız Scan Response adını toplar; bağlantı veya eşleştirme başlatmaz. Ad zenginleştirmesi başarısız olsa bile başarılı Inquiry tamamlanması korunarak BLE aşamasının atlanması önlendi.
Plan: Wi-Fi poll sürerken BLE reklamlarını topla ve scan-disable kapanışını status-zero ACK ile bitir.
Gerçekleşen: İlk koşu 13 BLE raporu ve yüzlerce Wi-Fi poll üretti; fakat yoğun H4 kuyruğunda ilk nonblocking scan-disable ACK görünmediği için BT_COMPLETE=0 kaldı ve koşu FAIL sayıldı. Güvenilir kısa UART makbuzları eklendi; yalnız aynı idempotent disable komutunun bir kez tekrarlanmasına izin verildi.
Sapma: Öngörülen tek komut yerine en çok bir idempotent tekrar gerekti; DR alanıyla açıkça ölçüldü ve kabul sınırı DR≤1 olarak sabitlendi. İlk başarısız kayıt geriye dönük PASS yapılmadı.
Plan: B08 geçtikten sonra üç bağımsız tam bootta eşzamanlı Wi-Fi/BLE kabulünü tekrarla; altı Bluetooth taramasını ve bütün kimlikleri mühürle.
Gerçekleşen: d168bf47… imajı üç bootun üçünde geçti. Wi-Fi ağ/poll değerleri 9/438, 10/430 ve 13/428; BLE rapor/cihaz değerleri 13/6, 13/6 ve 12/5 oldu. T/M/U/X sayaçları sıfır, DR=1 ve COMPLETE=1 kaldı. Her boot başlangıç B08 taraması ile B09 eşzamanlı taramasını içerdi; toplam altı tarama ölçüldü ve üç UART SHA-256 kaydedildi.
Sapma: Üç tekrar fiziksel güç kablosunu kesen cold-boot değil, UART R ile bootloader'a dönülen bağımsız tam ağ önyüklemeleridir. Her birinde TFTP imajı ve 1190 firmware sektörü sıfırdan yüklendi; bu sınır fiziksel power-cycle gibi sunulmadı.
Plan: Gerçek Classic satırdan ACL/SSP başlat; denetleyicinin ürettiği sayıyı iki uçta karşılaştır ve tam kimlik doğrulamayı bekle.
Gerçekleşen: DESKTOP-A21IH62 ile 518167 iki uçta görüldü ve yerel onay HCI'ya iletildi. Simple Pairing/Link Key/Authentication olayları gelmedi; status 0x08 ile bitti.
Sapma: Başarısız tören PASS sayılmadı. Ölçülen eksik, keşfedilebilirlik/bağlanabilirlik ve asenkron olay saklama olarak B12'nin tek kapsamına dönüştürüldü.
Plan: Yerel ad/sınıf/authentication/scan yapılandırmasını SSP öncesi uygula, olayları kaybetme ve Link Key'i aynı açılış için RAM'de tut.
Gerçekleşen: 693174 iki uçta onaylandı. Blueman Address=43:45:C0:00:1F:AC, Name=AselsanOS, Class=0x000104, Paired=yes ve Connected=yes gösterdi; RustOS satırı Aygıtlarım'a geçti.
Sapma: Trusted=no uzaktaki RustOS'un hatası değil BlueZ yerel politikasıdır. UUID boşluğu saklanmadı; gerçek SDP profili uygulanmadığı için hizmet uydurulmadı. UART capture terminal sonuçtan önce kapanmış olsa da panel onayları ve BlueZ durumu fiziksel kanıt olarak ayrı tutuldu.
Plan: B12 bağından sonra HCI olaylarını okumayı sürdür; bağlantı kopmasını eşleşme kaybından ayır ve aynı-açılış yeniden bağlantıyı izle.
Gerçekleşen: Kök neden bulundu: Complete durumunda pairing motoru poll edilmiyordu. Disconnection Complete modeli, ayrı paired/connected UI alanları, BTLINK makbuzu ve yeniden bağlantı yolu eklendi. 820f8599…56b73e imajı TFTP'den açıldı; fiziksel kopma makbuzu bekleniyor.
Sapma: Kapı PASS yapılmadı. Yeniden başlatmada RAM anahtarı kaybolduğu için B13 doğrulaması bir kez yeniden eşleşme gerektiriyor; kalıcı anahtar deposu hâlâ açıkça kapsam dışı.
Plan: Bluetooth sayfasındaki dört satırlık belge sınırını kaldır; modeldeki bütün gerçek aygıtları aşağı doğru uzat ve kaydırılmış satır dokunmasını ölçülen kimlikle eşleştir.
Gerçekleşen: Belge en çok 16 ölçülen kimliğe genişletildi; ilk görünüm dört satır olarak kaldı. Aynı AselMotor ekseniyle piksel tabanlı ataletli kaydırma, sabit navigasyon/kırpma ve ofsetli hit-test eklendi. Sekiz aygıtlı host testi son satıra kayıp doğru sekizinci kimliği seçti. B14 imajı Ethernet/TFTP ile Pi'de açıldı; fiziksel model 11 gerçek aygıtı TRUNCATED=0 ile tuttu ve R211 Wi-Fi taraması korundu. Kullanıcı DSI fotoğrafında dördüncü satırın ötesine uzayan listeyi doğruladı.
Sapma: Sentetik aygıt eklenmedi ve 16 kayıtlık ölçülen model sınırı büyütülmedi. İlk dört görünür satırı raporlayan tarihsel BT-B08 makbuzu belge sınırı değil görünüm makbuzu olarak korundu. Fiziksel fotoğraf uzun belgeyi kanıtladı; belirli son satırın dokunma-kimlik eşleşmesi yalnız host testinde kaldığı için tam B14 PASS yazılmadı ve B15'e taşındı.
Plan: Apple/iPhone gibi aynı görünen gerçek BLE kayıtlarını uydurma sıra/model adı vermeden, ölçülmüş ve açıkça geçici bir belirteçle ayır.
Gerçekleşen: Satır ayrıntısına denetleyici adresinin son üç okteti `ID XX:XX:XX` olarak eklendi. Host kabulünde iki `iPhone` satırı `ID 2D:E1:57` ve `ID 83:AA:71` olarak ayrıldı. 16399d24…5829 imajı Ethernet/TFTP'den fiziksel olarak açıldı; staging 1190/1190, Bluetooth N=11/OK=1, BT-B09 COMPLETE=1 ve R211 WIFI_OK ölçüldü.
Sapma: Model veya seri numarası uydurulmadı. BLE private/random adres dönebildiği için etiket kalıcı kimlik olarak sunulmadı (`ROTATING=1`, `PERSISTENT=0`). Çok çekirdekli UART B15 makbuzunu karakter düzeyinde başka satırla birleştirdi; bu nedenle görsel ID kabulü DSI gözlemi gelene kadar PASS yapılmadı.
Plan: B09'un zaten bulduğu gerçek çalışma zamanı BLE sonucunu, açılıştaki boş snapshot yerine canlı Settings modeline yayınla; taramayı eşleşme olaylarıyla çakışmadan tekrar kur.
Gerçekleşen: Kök neden, başarılı B09 sonucunun yalnız UART kanıtında kalıp HomePager'a hiç verilmemesiydi. `publish_ble_refresh` başarılı sonucu modele aktarıyor; stale BLE-only satırları yeniliyor, paired ve Classic-only kimlikleri koruyor, boş/başarısız sonucu yayınlamıyor. 15 saniyelik yeniden kurma yalnız Wi-Fi taraması kabul edildiğinde ve pairing H4 sahibi değilken çalışıyor. 4dd6573d… imajı netboot edildi; gerçek BLE sonucu 6–7 cihaz, BTUI MODEL_DEVICES=7 ve eşzamanlı Wi-Fi 12–16 ağ verdi.
Sapma: Fiziksel DSI fotoğrafı alınmadı; liste belleğine ve gerçek framebuffer yoluna yayın `BTUI STATUS=Complete/MODEL_DEVICES=7` makbuzuyla doğrulandı. Çok çekirdekli UART bazı uzun satırları karakter seviyesinde birleştirdiği için karar tek bir okunaklı uzun satıra değil, BTCOEX/BTREFRESH/BTUI ve Wi-Fi alanlarının birlikte görülmesine bağlandı.
Plan: Apple 0x004C Manufacturer Data'yı ham BLE reklamından çöz; yayınlanan paket türünü ve varsa model kimliğini göster, fakat Nearby Info'dan kesin iPhone modeli üretme.
Gerçekleşen: UI çözümleyicisi Company ID, Continuity type/length, AD flags ve Proximity Pairing model kimliğini tek kanıt nesnesinde topluyor. Fiziksel B17 bootunda `ff4c00` taşıyan gerçek reklamlar, Nearby Info/Find My ayrımı, 11 BLE aygıtı, B16 canlı yayın ve R211 Wi-Fi birlikte görüldü. Nearby Info satırı `Model: yayınlanmıyor`; gerçek model kimliği taşıyan Proximity Pairing satırı bilinen ad veya hex kimlik kullanıyor.
Sapma: Kesin iPhone nesli için aktif GATT sorgusu eklenmedi; bu kapı pasif reklama ve mahremiyet-korumalı sınıra sadık kaldı. Yeni B17 metninin DSI fotoğrafı alınmadı; çizim biçimi 69/69 UI host testiyle, fiziksel girdi ise ham Advertising Data ve UART kapı makbuzuyla doğrulandı.
Plan: B17'deki üçüncü bilgi satırının sonraki aygıt adına taşmasını, radyo yollarını değiştirmeden ortak ve ölçülü satır geometrisiyle düzelt.
Gerçekleşen: Kök ölçü bulundu: sabit satır 76 px, üçüncü satır başlangıcı y+90 idi. Body/Caption line-height değerlerinden 90/118 px değişken satırlar üretildi; çizim, ayraç, hit-test, ilk görünüm ve maksimum kaydırma aynı sınırları kullanıyor. Karışık satır ve stale-pixel testleriyle UI toplamı 71/71'e çıktı. B18 fiziksel bootunda 13 Bluetooth aygıtı, canlı BTRF OK=1 ve R211 Wi-Fi N=13/OK=1 korundu.
Sapma: Yeni iPhone model çözümleyicisi eklenmedi ve Nearby Info sınırı değiştirilmedi. 4032x3024 gerçek DSI fotoğrafı, karışık iki/üç satırlı kayıtların çakışmadığını doğruladı (SHA-256 707ae05018821239a3cb76ea7ea7e7fdd1af3e0f8322834be7a54ad96343473d). Alt kenardaki kısmi Samsung satırı kaydırma görünümünün doğal kırpmasıdır; fiziksel son-satır dokunma makbuzu ayrı açık sınır olarak kalır.
Plan: Adlandırma davranışını değiştirmeden her gerçek adın EIR, Remote Name, Advertisement veya Scan Response kökenini kısa/tam ayrımıyla ölç.
Gerçekleşen: Sürücüde `HciNameSource`, UI snapshot'ında `BluetoothNameSource` eklendi; merge yalnız seçilen adla birlikte kaynağı da değiştiriyor. UART cihaz satırları `NAME_SOURCE`, toplu makbuz `BTNAMEPROV` taşıyor. 17/17 H4, 71/71 UI ve 93/93 kaynak testi geçti. 4.719.888 baytlık `e0877f0244786d97b802b870353451bd2362d6e19c77b07ee749e4115857fa8f` imajı etkin Ethernet/TFTP kökünden fiziksel olarak açıldı. Staging 1190/1190 ve RETRIES=0/OK=1; Bluetooth 14 aygıtla tamamlandı. Classic Remote Name ve BLE Scan Response Complete kaynakları gerçek aygıtlarda ölçüldü. Wi-Fi G=2/N=13, G=4/N=11, G=5/N=15 ve G=8/N=11 taramalarında OK=1 kaldı.
Sapma: İlk imaj denemesinde eksik B19 profil girdisi fail-closed biçimde derlemeyi durdurdu; B18 tabanını ve B19 tek değişken sınırını açıklayan profil eklenerek giderildi. TFTP kökündeki genel radyo imajının karması farklıydı fakat `config.txt`in seçtiği kapı dosyası kaynak B19 imajıyla birebir aynı SHA-256 değerindeydi. Tarama tipi, süre, bağlantı, eşleşme, liste görünümü ve Wi-Fi yolu değiştirilmedi.
Plan: B19 tabanındaki pasif çalışma zamanı BLE penceresini, süre ve byte bütçesini değiştirmeden aktif yap; Scan Response ad kazanımını ve Wi-Fi birlikte çalışmasını fiziksel UART'ta ölç.
Gerçekleşen: 110/110 odaklı kaynak/HCI testi ve tam imaj kapıları geçti. `40a2f172e8869370a17195bea741b7f0f9aa88c9d2a06ec4828a997149284b37` imajı Ethernet/TFTP'den fiziksel Pi 5'e açıldı. `BTA20 G=5 D=7 N=1 SR=1 T=0 M=0 U=0 X=0 OK=1 P=1` ile çalışma zamanı aktif pencerede yedi aygıt ve Scan Response kaynaklı bir ad ölçüldü. Eşzamanlı R211 Wi-Fi `WIFI_OK G=3 N=16 OK=1` verdi.
Sapma: Bağlantı, eşleşme ve GATT özellikle eklenmedi. İlk UART oturumu etkileşimli yakalandığı için eksiksiz byte-akış arşivi iddia edilmiyor; tam kabul alanlarını taşıyan kısa B20 makbuzu, TFTP imaj kimliği ve eşzamanlı Wi-Fi makbuzu seçili kanıt olarak mühürlendi.
Plan: ADV üretici/servis kanıtını Scan Response adıyla, paket sırası ve yinelemeden bağımsız birleştir; connectable kanıtını kaybetme.
Gerçekleşen: Sürücü ve UI modelinde ADV ile Scan Response ayrı 31 baytlık tamponlara ayrıldı. Scan Response event type artık ADV connectability bilgisini ezemiyor. Ad önceliği complete/source/length/byte sırasıyla deterministik; geçersiz UTF-8, kontrol karakterleri, rezerv event/adres türleri ve bozuk AD yapıları fail-closed. Ters sıra, çelişkili tam ad, yinelenen/seyrek paket, manufacturer korunumu, non-connectable beacon, 16 kayıt sınırı ve UI aktarımı 28 H4 + 73 UI testinde geçti.
Sapma: Henüz B21 imajından gerçek `BTMERGE_RESULT` ve eşzamanlı Wi-Fi makbuzu alınmadı. Bu nedenle kapı PASS'e yükseltilmedi; DUAL_PAYLOAD>0 ve hata sayaçları sıfır fiziksel olarak görülene kadar active kalıyor.
Plan: Boot Inquiry'de adsız kalan Classic hedefleri ana döngüyü durdurmadan, bir timeout'un sonraki hedefi engellemediği bir kuyruğa al.
Gerçekleşen: Bir isteklik H4 durum makinesi eklendi: Command Status ve Remote Name Complete bounded poll ile tüketiliyor; 1 s/5 s deadline ve 512 bayt poll bütçesi var. Timeout, command reject, peer reject, yanlış adres ve geçersiz UTF-8 ayrı sonuçlar. Pairing HCI Cancel ile öncelik alıyor; BLE coexistence ile aynı anda UART sahibi olunmuyor. Çözüm yalnız mevcut Classic UI satırına uygulanıyor. 30 H4 ve 74 UI testi ile B22 imaj kapısı geçti.
Sapma: Fiziksel adsız Classic hedef ve timeout-sonrası ikinci hedef henüz ölçülmedi. Bu yüzden B22 `carried`, PASS değil.
Plan: Alias, bonded ad ve canlı adı ayrı güven düzeylerinde, bozuk kaydı fail-closed reddeden yeniden açılış biçiminde tut.
Gerçekleşen: Alias/Bonded/Live önceliği, Classic bond sonrası RAM kimliği ve 4096 baytlık ASBTID01 biçimi uygulandı. AES-128-CTR ciphertext ile HMAC-SHA256 doğrulaması ayrı türetilmiş anahtarlar kullanıyor. NIST AES, round-trip, plaintext sızıntısı, tahrif, yanlış anahtar ve canonical kayıt testleri geçti; B23 imajı derlendi.
Sapma: Cihazda güvenilir kök sır ve atomik kalıcı backend yok. Bu nedenle üretim yazması bilinçli olarak kapalı; RAM sonucu veya format testi reboot kalıcılığı sayılmıyor.
Plan: Yalnız bond IRK'sıyla Resolvable Private Address'ı kalıcı kimliğe çöz; eşleşmemiş rastgele adresi birleştirme.
Gerçekleşen: Bluetooth ah/AES-128, HCI-order RPA çözümü, şifreli SMP 0x08/0x09 assembler'ı ve identity_id tabanlı UI collapse uygulandı. Core Appendix D.7, NIST AES, yanlış IRK/non-RPA, PDU sıra/uzunluk/conflict ve UI rotating-address testleri geçti; B24 imajı derlendi.
Sapma: LE ACL/L2CAP/SMP taşıması yok; imaj bunu `SMP_TRANSPORT=ABSENT` diye yayımlıyor. Gerçek IRK edinimi ve iki fiziksel RPA ölçülmeden PASS değil.
Plan: Yalnız connectable ve kullanıcı-onaylı authenticated linkte GAP/DIS oku; authn/authz/alan-yok/timeout ayrımını koru.
Gerçekleşen: Admission üç koşulu birlikte zorunlu kılıyor. ATT MTU, Read By Type, Read ve Error PDU'ları bounded; Authentication/Authorization ayrı. GAP 0x2A00 ile DIS 0x2A24/0x2A29/0x2A50 ayrı evidence alanları, seri/System ID yasak. B25/B26 imaj marker'ları ve host pozitif/bozuk testleri geçti.
Sapma: CONNECT_REQ ve fiziksel ATT gönderilmedi; `LE_ACL_L2CAP_TRANSPORT=ABSENT CONNECT_REQ=0` sınırı korunuyor.
Plan: Classic ACL üzerinde Device ID özniteliklerini strict SDP ile ölç; CoD'dan model uydurma.
Gerçekleşen: SDP data-element ve ServiceSearchAttributeResponse parser'ı 0x0200–0x0205 alanlarını çözüyor; duplicate/missing/truncated/type/continuation hataları fail-closed. B27 imajı derlendi.
Sapma: Gerçek SDP isteği yok; vendor/product/version host fixture'ı fiziksel model kanıtı sayılmıyor.
Plan: Fast Pair model ID ve Swift Pair Display Name'i yalnız resmî biçim/uzunlukla çöz.
Gerçekleşen: 0xFE2C tam üç bayt Model ID ve Microsoft 0x0006/0x03/0x00 UTF-8 Display Name parser'ları canlı ADV+Scan Response modeline bağlandı. Fast Pair ID belgeli tablo olmadan adlandırılmıyor; Swift Pair gerçek kaynak etiketi taşıyor. B28 imajı derlendi.
Sapma: Çevrede pozitif Fast/Swift reklamı fiziksel olarak yakalanmadı; bu yüzden PASS değil.
Plan: Tek ad önceliği uygula; name source, identity decision ve model evidence'ı birbirinden ayır.
Gerçekleşen: Alias/Bond/GATT/live/vendor/short fallback zinciri tek precedence modeline bağlandı. UI ad kaynağını ve session-vs-bond kararını ayrı satırda; Apple/Fast Pair model kanıtını başka satırda gösteriyor. Explicit B29 layout testi üç/dört satırın paint/scroll geometrisini doğruluyor; imaj marker'ı eklendi.
Sapma: Gerçek DSI fotoğrafı, çoklu aynı adlı aygıt ve fiziksel IRK rotation yok; dolayısıyla PASS değil.
Plan: PC, saat, kulaklık, TV ve çoklu iPhone'u üç bağımsız boot ve R211 birlikte çalışmasıyla kabul et.
Gerçekleşen: Release imajı cihaz/senaryo/boot/UART/DSI sözleşmesini fail-closed yayımlıyor: `HOST_READY=1 PHYSICAL_ACCEPTED=0 BOOTS_REQUIRED=3`. Önceki host parser/kimlik/UI kapıları adayda birlikte derleniyor.
Sapma: Donanım koşusu yapılmadı; release marker'ı hiçbir fiziksel sonucu veya PASS'i kendi kendine üretmiyor.
Plan: B21 imajını TFTP'den açıp gerçek bir kimlikte DUAL_PAYLOAD>0 ölç; malformed/truncated/bütçe sıfır ve R211 Wi-Fi canlı kalsın.
Gerçekleşen: İki hands-free boot koşuldu. Boot A iki pencerede `BTM21 ... BOTH=1 ... OK=1 P=1` verdi; aynı bootta 84 tamamlanmış Wi-Fi taraması ve `BTHCD BYTES=63806/63806` görüldü. Boot B, `WIFIAUTORESET RESET REASON=UART_R BYTE=0x52` reset makbuzundan itibaren kaydedildi; 13 pencerede hata sayaçları sıfır kaldı fakat menzilde dolu Scan Response yayan aygıt yoktu, bu yüzden `BOTH=0 OK=0`. Ham UART arşivleri (1.680.404 ve 759.308 bayt) ve `--gate b21` doğrulayıcı JSON'ları mühürlendi.
Sapma: Tek atışlık `BTMERGE GATE=BT-B21` sözleşme satırı yoğun debug-probe CDC'sinde parçalandı; doğrulayıcı bunu `contract_marker=shredded/absent` olarak kaydediyor ve kabulü yalnız atomik `BTM21` makbuzuna dayandırıyor. Açılışlar güç kablosu kesilerek değil PM watchdog `R` yoluyla yapıldı; boot A yakalaması çekirdek fazının birkaç saniye içinde başladığı için o dosyada bootloader transfer satırı yok.
Plan: B22 imajını açıp adsız Classic hedefte bloklamayan Remote Name kuyruğunu ölç.
Gerçekleşen: İmaj üç kez TFTP'den açıldı; `BTREMOTE GATE=BT-B22` sözleşmesi hatta görüldü ve B21 birleştirmesi aynı imajda 14/14 pencerede `OK=1` (BOTH 3'e kadar) verdi. Classic Inquiry yalnız bir keşfedilebilir Classic aygıt buldu (`DEVICES=1 NAMED=1`, `NAME_SOURCE=CLASSIC_REMOTE_NAME`); adı açılış yolunda çözüldüğü için kuyruğun hedefi olmadı.
Sapma: Kuyruk hiç çalışmadığı için `BTRN22` makbuzu yok; eksik olan kod değil, menzilde adsız kalan gerçek bir Classic hedef. Kabul ölçütü gevşetilmedi.
Raspberry Pi OS da Linux'tur; ilk sütundaki "Linux" bağımsız Ubuntu 24.04.3 koşusudur. Her hücre yalnız ilgili koşuda ölçülen iddiayı taşır; "ölçülmedi" başarısızlık demek değildir.
| Kapı | Linux / Ubuntu R136 | Raspberry Pi OS R75/R80 | AselsanOS R211 | Doğru okuma ve kanıt |
|---|---|---|---|---|
| Koşunun kapsamı | Ubuntu 24.04.3 / ayrı Linux çekirdeği; R136 oturum içi SDIO izi. Yeniden sonda başarısız, ilk preinit çerçevesi ölçülmedi. | R75 soğuk açılış ve R80 SDIO izi; Linux 6.18.34+rpt-rpi-2712, brcmfmac. | R211 TFTP ile açılan bare-metal imaj; aynı BCM43455 ailesi, USB belleğe yeniden yazma yok. | Bunlar eşzamanlı A/B koşuları değildir; sadece her koşunun gerçekten ölçtüğü kapı karşılaştırılır.evidence/rpi5/radio/linux-r136-first-frame-ubuntu/README.md · attempt-r75-linux-control/RUN.txt · firmware/rpi5-wifi-scan-r211-profile.txt |
| Çip / firmware | Oturum içi brcmfmac SDIO yazmaları yakalandı; ilk firmware yüklemesinin tamamı bu izde ölçülmedi. | R75: F1 imzası 0x15264345, BCM4345/6 firmware preinit satırı ve wlan0 var. | R211: 1190 sektör firmware doğrulandı, NVRAM OK=1, FWREADY_MS=55. | Firmware'in TCM'e yazılması tek başına tarama kanıtı değildir; R211 ayrıca kontrol yanıtı ve escan sonucu gösterir.attempt-r75-linux-control/dmesg-radio-filtered.txt · firmware/rpi5-wifi-scan-r211-profile.txt |
| SDPCM kontrol biçimi | R136 oturum içi 235 F2 yazmasının 235'i glom/doff=20; ilk preinit dizisi bu pakette yakalanmadı. | R136 v3 reprobe izinde glom/doff=20 oturum çerçeveleri; R80 transaction izi mevcut. | R194 glomsuz/doff=12 ilk MAC GET'e iki yanıt aldı; R210/R211 aynı ilk yol üzerinde üç eşleşen kontrol yanıtına çıktı. | Oturum içi glom düzeni ile pazarlık öncesi ilk kontrol çerçevesi farklı fazlardır; 'Linux hep glomsuz' veya 'hep glom' denemez.linux-r136-first-frame-ubuntu/README.md · linux-r136-first-frame-v3/README.md · attempt-r194-plain-control-uart-capture/uart10.raw |
| CLM ve tarama | Bu R136 izi CLM ACK veya tamamlanan escan kanıtı değildir. | R75'te wlan0 doğrulandı; mühürlü kontrol, SSID listesi veya escan tamamlanması iddia etmez. | R211'de altı CLM yanıtı, CLM_ACK=2676; escan kabul edildi; GEN=2/5/6 Complete, 16 saklanan BSS. | Tarama PASS'ı yalnız AselsanOS R211 UART gözlemi için ileri sürülür; 16 kayıt sınırı TRUNCATED=1 üretir.attempt-r75-linux-control/iw-dev.txt · firmware/rpi5-wifi-scan-r211-profile.txt |
| Bluetooth ve ağa bağlanma | Bu Ubuntu izi Bluetooth veya association/ping kabul testi değildir. | R75: hci0 UP/RUNNING ve başarılı HCI olayları; WLAN soft-blocked, association/ping kanıtı yok. | R211 yalnız pasif Wi-Fi taraması kanıtı. Bluetooth R211'de yeniden doğrulanmadı; WPA/bağlanma uygulanmadı. | Wi-Fi tarama, Wi-Fi bağlantısı ve Bluetooth keşfi üç ayrı kabul kapısıdır.attempt-r75-linux-control/hciconfig.txt · attempt-r75-linux-control/rfkill.txt · firmware/rpi5-wifi-scan-r211-profile.txt |
| MAC kimliği / kanıt gücü | Ubuntu R136 izinde MAC eşitliği A/B kapısı olarak sınanmadı. | R75 wlan0 adresi 98:fe:54:0e:c9:e9; mühürlü RUN/EVIDENCE_SHA256SUMS var. | R211 yanıtı b8:27:eb:74:f2:6c; mevcut BRCMNVR.TXT içinde aynı sabit macaddr satırı var. R211 raw UART henüz mühürlü değil. | Fark, kartlar farklıydı sonucunu kanıtlamaz; AselsanOS'un sabit NVRAM MAC'ini board-kimliğine bağlamadığını gösterir. Bu taramayı geçersiz kılmaz ama bağlantı öncesi düzeltilmelidir.attempt-r75-linux-control/iw-dev.txt · firmware/wifi/BRCMNVR.TXT · firmware/rpi5-wifi-scan-r211-profile.txt |
Her satır, sonraki denemeyi doğuran ölçümü anlatan bir karar köprüsüdür; aralıktaki her revizyonun ayrı fiziksel PASS aldığı iddiası değildir. R1–R157 cihaz kartları ve R95 sonrası ayrıntılı merdiven aşağıda kalır. Varışsız, iptal ve sonradan düzeltilmiş yorumlar ayrıca işaretlendi.
Önce veri yolunun neden sessiz olduğu ayrıldı: WL_ON, GPIO canlılık denetimi ve C0/D0 ped haritası birbirinden bağımsız sınandı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R1 → R2 | DTB'deki WL_ON (GPIO 28) sürüldü; yanlış IODIR canlılık reddi düzeltildi. | R1 CMD5 OCR=0 ve DAT/CMD düşük; R2'de WL_ON ASSERTED=1, DAT hatları yükseldi fakat OCR=0 kaldı. | Güç hattı artık ölçülürken radyo sessizdi; pedlerin gerçekten SDIO'ya bağlı olup olmadığı R3'te okundu. | mühürlüattempt-r1-backplane-gate-uart-capture · attempt-r2-wl-on-power-uart-capture |
| R2 → R3 | Yazmadan pinmux envanteri alındı. | SDIO CLK/CMD pedlerinin GPIO seçicisinde kaldığı görüldü; DTB sd2 istiyordu. | Donanım bağlanmamışken protokol denemesi anlamlı değildi; R4'te sınırlı pinmux yazma kapısı açıldı. | mühürlüattempt-r3-pinmux-inventory-uart-capture |
| R3 → R14 | R4–R13'te yazma sırası, genişlik, overlay ve sınır hipotezleri sınandı; R14 silikon stepping'ini yeniden sordu. | C0 tablosuyla 8/10 ped tutuldu; R13 reddin bit 16 sınırında olduğunu düzeltti. R14 kartın D0 olduğunu ölçtü; bazı ara koşular geçersiz/varışsızdı. | Yazma ısrarı yerine yanlış ped haritası bırakıldı; R15 D0 planını uyguladı. | karma / tarihselattempt-r4-pinmux-write-uart-capture · attempt-r14-d0-stepping-probe-uart-capture; R9/R11 gibi ara sonuçlar geçerli PASS değil |
| R14 → R15 | C0 yerine D0 pin planı uygulandı ve on ped geri okundu. | VERIFIED=10/10; backplane CHIPID=0x15264345 (BCM43455) yanıtladı. | Elektriksel erişim kapandı; sonraki soru CMD53'ün güvenilir veri taşıyıp taşımadığıydı (R16). | mühürlüattempt-r15-d0-pinplan-uart-capture |
Çip kimliğini okumakla firmware'i RAM'e yazmak farklı kapılardı; CMD53 okuma geçse de TCM blok yazması ayrı başarısız kaldı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R16 → R30 | R17–R29'da sıra, pencere, adres bayrağı, reset, saat ve pull-up adayları ayrıldı; R30 host'u 4-bit'e aldı. | CMD52 çipi görürken CMD53 0x00804253 okuyordu; host 4-bit eşleşince MATCH52=1 ve 4 baytlık okuma düzeldi. | Genişlik uyuşmazlığı giderildi ama ardışık CRC kaldı; R31 kart yerleşmesini bekledi. | mühürlüattempt-r16-cmd53-gate1-uart-capture · attempt-r30-host-4bit-bus-uart-capture |
| R30 → R31 | CMD5/CMD7 kart yerleşmesi ve ardışık CMD53 kapısı düzeltildi. | Altı CMD53 aktarımının altısı temiz; GATE1=1, CHIPID yine eşleşti. | Okuma yolu kanıtlanınca yazma ve CR4/EROM keşfi R32–R37'de ayrıldı. | mühürlüattempt-r31-settle-card-uart-capture |
| R32 → R37 | Kirli giriş, 32 KB pencere hizası ve EROM tarama sırası düzeltildi. | R32 geçersizdi; R37 temiz sırada 7 çekirdek ve CR4 wrapbase=0x18102000 buldu. | Gerçek CR4 konumu bilindi; R38–R41 TCM okuma/yazma yolunu ayrı denedi. | karma / tarihselattempt-r37-erom-reorder-selftest-uart-capture; R32 varışsız |
| R38 → R41 | CR4 HALT hipotezi ile TCM'de CMD53 ve CMD52 yolları karşılaştırıldı. | CR4 zaten halt idi; CMD53 blok TCM'de 0x0060 ile düşerken CMD52 TCM'i okuyup yazdı ve geri doğruladı. | Blok yazma beklenmedi; cmd52 üzerinden toplu/verified staging R42'de kuruldu. | mühürlüattempt-r40-tcm-read-probe-uart-capture · attempt-r41-cmd52-write-isolated-uart-capture |
| R41 → R43 | CMD52 ile 1024 kelimelik dizi ve FAT'tan BRCMFW.BIN okuması doğrulandı. | 1024/1024 kelime geri okundu; firmware dosyası doğru boyut ve ilk içerikle bulundu. | Mekanizma çalışınca R44–R58 gerçek tam indirme, hız ve NVRAM kapısına geçti. | mühürlüattempt-r42-cmd52-bulk-write-uart-capture · attempt-r43-firmware-read-uart-capture |
Sessiz ve yavaş ilerlemeyi kilitlenmeden ayırmak, R5 gürültüsünü veri bütünlüğüyle karıştırmamak bu aşamanın ana dersiydi.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R44 → R47 | Sektör ilerlemesi eklendi, saat /16'ya alındı ve başarı R5 yerine geri okuma/verify ile tanımlandı. | R44 terminale varmadı; R45 8/8 sektör doğruladı. R46 hızlandı ama R5 gürültüsü yanlış OK=0 üretti; R47 verify ile OK=1 gördü. | Küçük parça doğruydu; R48 tam firmware indirmesini sınadı. | karma / tarihselattempt-r45-firmware-stage-progress-uart-capture · attempt-r47-stage-verify-retry-uart-capture |
| R48 → R54 | Pencere retry, saat-süpürme ve issue() bekleme bütçesi ayrı ayrı ölçüldü. | R48 128 sektörde durdu; R49 ~8,08 s/sektör; R53 yavaş saat yararsız; R54 bekleme sınırıyla /16 hızı 4976→109 ms/sektör (~45×). | İndirme süresi makul olunca R55'te tam doğrulama koşuldu. | mühürlüattempt-r48-firmware-full-download-uart-capture · attempt-r53-clock-sweep-measured-uart-capture · attempt-r54-staging-poll-bound-uart-capture |
| R54 → R55 | 1191 sektörlük BRCMFW.BIN'in tamamı TCM'e indirildi. | FWSTAGE OK=1, WORDS_V=152448, RETRIES=0; yaklaşık 2–3 dakika. | Firmware varlığı artık yeterli değildi; R56–R58 NVRAM ve gürültülü boot dayanıklılığını sınadı. | mühürlüattempt-r55-full-download-fast-uart-capture |
| R56 → R58 | Retry sayısını artırmak yerine completion/R5'ten bağımsız DATA-tabanlı doğrulama kullanıldı. | R56/R57 firmware abort nedeniyle NVRAM'e ulaşamadı; R58 iki boot'ta firmware ve NVRAM OK=1, TOKEN_OK=1, FW_INTACT=1 verdi. | Yükleme kapandı; sıradaki bağımsız kapı CR4'ün yürütme/tanık yoluydu. | mühürlüattempt-r56-nvram-load-uart-capture · attempt-r57-nvram-load-robust-uart-capture · attempt-r58-nvram-data-verify-uart-capture |
Firmware'in yüklenmesi CR4 yürütmesini kanıtlamadı. İlk tanık yorumlarının bir kısmı R97'de düzeltildi; Linux kontrolü donanım olasılığını ayrı ölçtü.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R59 → R74 | CPUHALT/FGC, PMU, ALP/HT, reset vektörü, D11-disable ve always-on tanık varyantları sınandı. | R72/R74'te MBOX=0 ve INTSTAT=0; o sırada host-görünür yürütme kanıtı yoktu. R97 daha sonra bazı TCM/hat tanık yorumlarını geçersiz kıldı. | Yeni register tahminleri yerine aynı kartta Linux/brcmfmac soğuk-açılış kontrolü R75'e geçildi. | mühürlü, yorum düzeltildiattempt-r59c-cr4-start-uart-capture · attempt-r72-execution-witness-uart-capture · attempt-r74-d11-disable-uart-capture |
| R74 → R75 | AselsanOS yerine aynı fiziksel Pi 5'te Raspberry Pi OS/brcmfmac kontrolü çalıştırıldı. | Aynı F1/CHIPID ailesi görüldü; firmware preinit tamamlandı, wlan0 ve hci0 oluştu. Bu SSID taraması/association kanıtı değildi. | Çipin çalışabilirliği gösterilince host-init sırası R76–R80'de Linux'a karşı ölçüldü. | mühürlüattempt-r75-linux-control/RUN.txt · dmesg-radio-filtered.txt |
| R75 → R80 | R76–R79'da INTSTATUS, KSO, clock ve CARDCTRL adımları denendi; R80 Linux SDIO işlem izini topladı. | Yazılar bazen latch etti ama yürütme gelmedi; R80 gerçek brcmfmac işlem sırasını sağladı. | Sonraki PMU/rstvec/transport adayları artık tahmine değil ölçülen Linux sırasına bağlandı. | mühürlüattempt-r80-linux-sdio-trace · attempt-r76-*–attempt-r79-* cihaz kartları |
| R81 → R93 | Attach sırası, PMU RES_RELOAD, CMD53 4B ve rstvec/wrapper taşıması A/B ayrıldı. | Bazı boot'lar FWSTAGE'a varmadı; R83/R87 firmware+NVRAM'i doğruladı ama MBOX=0, R93 bayraklı okuma çalışırken yazma atomikliği açılmadı. | Kör taşıma varyantları yerine CR4 TCM boyutu ve tanık geçerliliği R95–R97'de ölçüldü. | mühürlü, yorum düzeltildiattempt-r83-attach-kso-cardctrl-only-uart-capture · attempt-r93-wrapper-4byte-flag-uart-capture |
Ölçümün kendisi doğrulandıktan sonra ilk BCDC isteğinin baytları, SDHCI DATA arızaları ve ikinci F2 yazmasının sınırı ayrıştırıldı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R95 → R97 | Sabit TCM boyutu çipten ölçüldü; staging saat/poll bütçesi geri alındı; canlı nöbetçi aynı pencerede okundu. | RAMSIZE=0x000c8000; R97 nöbetçi 100/100, MBOX/INTSTAT=0 canlı hatta. Eski TCM tanıklarının bir kısmı güvenilir değildi. | Tanık doğrulandı; R98 sonrası saat/HT ve kontrol protokolü ölçüldü. | mühürlü, yorum düzeltildiEXECUTION_LADDER R95–R97 · mühürlü cihaz kartları |
| R98 → R105 | HT isteği, SDHCI clock genişliği, D11 yazması ve BCDC GET_VAR uzunluğu ayrıldı. | Host/D11 yolu ilerledi; R105 FRAMELEN=48 XFER=48 BCDCLEN=20 SENT=1 fakat REPLIED=0. | Doğru TX'e rağmen yanıt yoktu; R106–R116 RX zarfı ve INTSTATUS okuma sahipliğini ölçtü. | mühürlüEXECUTION_LADDER R98–R105 · R105 cihaz makbuzu |
| R106 → R116 | Ham RX header, D11 retry, F1 INTSTATUS CRC ve tek host-only SDHCI DATA reseti ölçüldü. | İki 12B header-only zarf kontrol yanıtı değildi; R116'da 100.000 poll'un açamadığı host DATA durumu tek resetle 10 µs'de açıldı, READY yine yok. | Host kilidi bir belirtiydi; R117–R126 arızanın sürekliliği, IRQ ve wake adaylarını ayırdı. | mühürlüattempt-r113-d11-crc-retry-uart-capture · EXECUTION_LADDER R116 |
| R117 → R126 | F1 okuma varyansı ve CMD53 sayımı alındı; F2 watermark, CCCR INT_ENABLE ve WAKEUPCTRL denendi. | R123'te CMD53W_INCOMPLETE=0/15 iken ilk ioctl cevapsızdı; R124 değişkenine varmadı, R125/R126 yazıları latch etti ama yanıt gelmedi. | Tek register açıklaması çıkmayınca R127–R135 bounded deneme matrisiyle ikinci F2 yazması ayrıldı. | karma / tarihselEXECUTION_LADDER R117–R126; R122/R124 varışsız makbuzları ayrıca etiketli |
| R127 → R136 | Hazırlık matrisi, IO_ABORT, F2 yaşam döngüsü, block-size, DATA reset ve byte-count elendi; R136 Linux'ta ölçülen glom biçimini denedi. | İkinci F2 yazması R135'e kadar 0x0020 ile düşüyordu; R136'da kabul edildi ve birden çok denemeye geçildi, fakat REPLIED=0 kaldı. | Taşıma açılınca sıradaki soru firmware'in protokole ne zaman hazır olduğuydu (R137). | mühürlüEXECUTION_LADDER R127–R136 · linux-r136-first-frame-v3/README.md · linux-r136-first-frame-ubuntu/README.md |
Cevapsız çerçevenin nedeni hazır bayrağı, firmware iç durum ve F2 kabul kuralı olarak üç ayrı hatta ölçüldü.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R137 → R140 | Mailbox tanığı, her okumada ACK/sürüm ve sonra Linux'taki post-CR4 host-ready yazma konumu karşılaştırıldı. | R137/R138 protokol fazında FWREADY görmedi; R140 yazmayı CR4 bırakılışına taşıyınca dongle ~30 ms'de FWREADY verdi. | Bayrak geçiciydi; R141–R145 ACK, kesme ve F2 okuma yoluna geçti. | mühürlüEXECUTION_LADDER R137–R140 |
| R140 → R148 | Mailbox ACK/INTSTATUS, DAT1/IRQ ve dongle shared-area/konsolu okundu. | R141 SETTLED=1; R146 firmware canlı ve shared/console adresi geçerli; R148 konsolda 'device disabled' ve 'tx submit failed' görüldü. | Firmware gerçekten çalışıyordu; R149–R152 D11 saat şikâyetiyle gönderim zamanını ayırdı. | mühürlüEXECUTION_LADDER R141–R148 |
| R148 → R152 | FORCE_HT denendi, D11 reset bırakıldı, host/dongle zaman damgaları hizalandı. | R150'de 'No clock' kayboldu ama yanıt gelmedi; R152'de Disable olayını bizim çerçevemizin tetiklediği ölçüldü. | Saat tek neden değildi; R153–R157 çerçeve seq ve glom pazarlığı sırasına baktı. | mühürlüEXECUTION_LADDER R149–R152 |
| R153 → R157 | Seq hipotezi elendi; Linux'un glom pazarlığını ilk kontrol çerçevelerinden ayıran sırası kuruldu. | R156'da ilk çerçevemiz glomluyken Linux'un başlangıç fazı glomsuzdu; R157'de preinit SENT=0, bu boot glom sırasını sınamadı. | R158–R161 önce F2 yazmasının gerçekten tamamlanıp tamamlanmadığını ayırdı. | karma / tarihselEXECUTION_LADDER R153–R157; R157 varışsız |
| R158 → R161 | F2 drain ve 64B yazma birimi elendi; tamamlanmış saf DATA_CRC yazmasının bounded kabul kuralı preinit ve kontrole uygulandı. | R160'da preinit SENT=3/3; R161'de denemeler 3/11'e çıktı, fakat firmware yine REPLIED=0 ve bazı boot'larda 'device disabled' dedi. | F2 yazma kapısı aşılınca kimlik, F2 toggle ve okuma/credit tarafı R162–R170'e taşındı. | mühürlüEXECUTION_LADDER R158–R161 |
Kredi açlığı ve bazı saat açıklamaları elendi; netboot, SD kartı çıkarıp aynı radyo noktasına tekrar ulaşmak için kullanıldı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R162 → R164 | Benzersiz dcmd kimlikleri ve F2 zaten READY iken kapat/aç yapmama; sonra TFTP payload yolu. | R162 9/11 denemeye çıktı ama yanıt yok; R163'te konsol Disable 6→0. R164 firmware/NVRAM/CLM'yi ağdan doğrulayıp aynı cevapsız noktaya vardı. | SD/USB değişiminden bağımsız tekrar mümkün oldu; R165–R170 F1 okuma ve kredi tanığını ölçtü. | mühürlüEXECUTION_LADDER R162–R164 |
| R165 → R170 | INTSTATUS okuma latch'i ve bounded DATA reset bütçesi sınandı; kredi örnekleme anı her trial sınırına taşındı. | Latch aralıklıydı: R168'de 11/11 tamamlandı. R170 kredi mevcutken de REPLIED=0 gördü. | Kredi kıtlığı kapanınca FWREADY'nin görülme fazı R171–R173'te ayrıldı. | karma / tarihselEXECUTION_LADDER R165–R170; varışsız boot'lar ayrı |
| R171 → R177 | FWREADY bariyeri, erken F2 enable, sürüm tekrarı, ölçülen Linux preinit ve post-CR4 saat A/B denendi. | R171 kapısı +25 ms FWREADY pulse'ını kaçırdı; R172'de erken F2, pulse'ı erken pencerede kalıcı tuttu ama protokol fazında FWREADY yine yoktu. R175 dört preinit TX eşleşti, REPLIED=0; R177 kredi/saat açıklamasını daralttı. | Başlangıç girdileri benzerken RX gerçekten var mı sorusu R179/R180'e kaldı. | mühürlüattempt-r171-fwready-gate-final-2-uart-capture · EXECUTION_LADDER R172–R177 |
| R178 → R179 | R178 imajı flash edilmedi; R179 aynı Pi'de Raspberry Pi OS kontrolünü tekrarladı. | Linux aynı firmware/NVRAM/CLM ile cevap aldı; firmware iç 'No clock/Invalid antennas' mesajları tek başına cevap yokluğunu açıklamadı. Linux fwcon dökümü alınamadı. | AselsanOS host tarafındaki F2 okuma yolunu R180'de doğrudan yokladı. | karma / tarihselevidence/rpi5/radio/linux-r179-control · EXECUTION_LADDER R178 (gereksiz, koşulmadı) |
| R179 → R180 | Kontrol gönderimi sonrası INTSTATUS servisi ve F2 okuması eklendi. | İlk kez FRAME_IND=1 ve 64B F2 okuması görüldü; DATA_CRC=0x0020 nedeniyle geçerli kontrol cevabı ayrıştırılamadı. | Okuma ile önceki yazmanın bus durumunu ayırmak için R181 planlandı; o kanıt daha sonra geçersiz sayıldı. | mühürlüattempt-r180-f2-post-send-uart-capture |
Bu numaralar başarı basamağı değil. R181/R185/R190/R191 aynı eksik yakalamaya bağlanmış; R189 hiç üretilmemiştir. Geri çekilmiş hipotezler sonraki karara dayanak yapılmaz.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R181 → R188 | DAT_INHIBIT, SDIO saat, F2 başlık ve paylaşım işaretçisi adayları gözden geçirildi. | R181 yakalaması mühürsüz/varışsız; R185'in 12B olayı sonradan boş EVENT zarfı olarak doğru çözüldü; R182–R188'in çoğu davranış adımına varmadı. | 'Bus contention elendi' veya 'ilk kez RX' gibi iddialar geri çekildi; yorumlanabilir temiz baz gerekti. | varışsız / iptalEXECUTION_LADDER R181–R188; R192 mühürlü UART'taki karşılaştırma |
| R189 → R192 | R189 block-mode adayı iptal edildi; R190 ayrı koşu değildi; R191 donanım/uart yorumu düzeltildi. | R189 imajı üretilmedi. R190/R191 aynı mühürsüz R181 kaydına dayanıyordu; PSTATE=0x01ff0000 hatları düşük değil yüksek gösterir. | R192 USB baz koşusu bağımsız mühürlenerek yeni karşılaştırma zemini kuruldu. | varışsız / iptalEXECUTION_LADDER R189–R191 · attempt-r192-usb-baseline-uart-capture |
Temiz baz, pull-up düzeltmesi ve pazarlık öncesi düz SDPCM çerçevesi karşılaştırıldı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R192 → R193 | D0 SDIO CLK pull kapalı, CMD/DAT0–3 pull-up; pad geri okuması. | CMD52 hata 93.061/611.629 → 0/611.629; CRC/end-bit sıfır; ilk kontrol SENT=1, REPLIED=0. | Hat temizlenince kalan ölçülü fark çerçeve düzeniydi; glomsuz ilk istek R194'te sınandı. | mühürlüattempt-r192-usb-baseline-uart-capture · attempt-r193-sdio-pulls-uart-capture |
| R193 → R194 | İlk kontrol çerçevesi glom 56B/doff20 yerine düz 48B/doff12. | MAC ve sürüm için iki gerçek WIFIRX yanıtı; üçüncü 43B SET yanıtı görüldü ama parser eşleştirmedi; tarama yok. | RX yolu canlıydı; SET yanıtı yön denetimi ve sonraki kontrol dizisi ayrıştırıldı. | mühürlüattempt-r194-plain-control-uart-capture/uart10.raw |
Bu grubun raw/profil boşlukları var; sohbet UART tablosu mühürlü kök neden gibi okunmamalı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R194 → R195–R197 | SET yanıtı ayrıştırması/feature bağımlılığı ve host DATA reset tanısı; R197 yalnız yazılım makbuzları ekledi. | R197'de FWREADY görüldü ama PREINIT SENT=0; INTSTATUS clear CMD52 0x0010 verse de firmware hazır olabildi. R195/R196 notlarında FWREADY yorumu tutarsız. | FWREADY ile preinit'i ayrı kapılar olarak tutup INTSTATUS clear zamanlamasını A/B sınadık; bu grup tek-değişken nedensel kanıt değildir. | sohbet özetifirmware/rpi5-wifi-scan-r196-profile.txt · r197-profile.txt · oturum UART özeti |
| R197 → R198 / R199a–c | INTSTATUS clear için CMD53 retry, atlama, çift CMD52 ve 1 ms gecikme varyantları. | Sohbet tablosunda R197 FWREADY≈60 s, diğer varyantlarda 83–92 s içinde FWREADY yok; preinit başlamadı. | Bu varyantlar kapıyı açmadı; R200, R197 clear yoluna döndü ve sonraki pre-session F2 blokunu ayırdı. | sohbet özetioturum UART karşılaştırması; ilgili R199 raw arşivi bulunamadı |
TX ilerlemesi ile RX yanıtının parser'a gerçekten ulaşması ayrı ölçüldü; birden fazla A/B varyantı uygulandı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R197 → R200 | Transport öncesi beş tanı F2 okuması, host DAT reset ve 19 ms bekleme kaldırıldı. | FWREADY sonrası 12B header-only olay taşımaya ulaştı; takip eden gereksiz F2 okuması 0x0020 ile düştü. | Eski receive_pending latch'i test etmek için R201 header-only frame sonrası latch'i temizledi. | UART/profilfirmware/rpi5-wifi-scan-r200-profile.txt · r201-profile.txt |
| R200 → R201 | Tam header-only çerçeveden sonra receive_pending temizlendi. | İlk 48B preinit F2 yazması kabul; ikinci 64B yazma DATA_TIMEOUT=0x0010. | Tam 64B aktarımın SDIO kipini byte-mode yaparak R202'de denendi. | UART/profilfirmware/rpi5-wifi-scan-r201-profile.txt · r202-profile.txt |
| R201 → R202 | 64B F2 yazmalarında block-mode yerine byte-mode. | Dört preinit çerçevesi ve ilk kontrol çıktı; 0x0020/0x0060 veri hataları ve firmware'de discarded SDPCM frame kaldı. | Hız kaynaklı mı diye yalnız runtime saati R203'te 50→25 MHz indirildi. | UART/profilfirmware/rpi5-wifi-scan-r202-profile.txt · r203-profile.txt |
| R202 → R203 | Runtime SDIO saat bölücüsü 0x02→0x04 (50→25 MHz). | İki koşu ikinci 64B preinit yazmasında DATA_TIMEOUT verdi; iyileşme yok. | R202'nin 50 MHz çizgisine dönüp sıradan kontrolün glom düzeni R204'te ayrıldı. | UART/profilfirmware/rpi5-wifi-scan-r203-profile.txt · r204-profile.txt |
| R202 → R204 | Preinit 4/4 korunup sıradan 104B revinfo yerine 96B düz kontrol. | 96B istek ve FRAME_IND görüldü; dört INTSTATUS CMD53 hatası ardından F2 RX CRC; yanıt ayrıştırılamadı. | Okuma yolunu yalıtmak için R205 yalnız INTSTATUS'u denetimli CMD52×4 okudu. | UART/profilfirmware/rpi5-wifi-scan-r204-profile.txt · r205-profile.txt |
| R204 → R205 | SDIO core INTSTATUS: CMD53 yerine dört denetimli CMD52. | İki boot'ta host-idle reset gerekmeksizin okundu; ilk 96B kontrol yazması DATA_TIMEOUT, SENT=0. | R194'ün yanıt veren daha kısa bootstrap yolunu R206'da A/B denedik; bu preinit'in yanlışlığını tek başına kanıtlamaz. | UART/profilfirmware/rpi5-wifi-scan-r205-profile.txt · r206-profile.txt |
| R205 → R206 | Preinit ve revinfo-first birlikte devre dışı; ilk istek R194 gibi düz MAC GET. | FWREADY_MS=55; ilk kontrolden önce F1 Write32 0x18004040 DATA_CRC=0x0020, SENT=0. | R194'teki D0 pull-up'ın bu profilden eksik olduğu görüldü; R207'de geri eklendi. | UART/profilfirmware/rpi5-wifi-scan-r206-profile.txt · r207-profile.txt |
| R206 → R207 | D0 SDIO pull-up'lar geri eklendi (6/6 geri okuma). | Hat temiz, yedi düz MAC GET gönderildi; 11 trial sonunda REPLIED=0. | R194'te yanıt getiren tek CMD53 INTSTATUS yoluna R208'de dönüldü. | UART/profilfirmware/rpi5-wifi-scan-r207-profile.txt · r208-profile.txt |
| R207 → R208 | INTSTATUS CMD52×4 kaldırılıp atomik CMD53 geri alındı. | Yedi MAC GET yine REPLIED=0; FIFO_READS=1, ZERO_MARKERS=1; CMD53W hatası yok. | R194'ün pre-session F2 tanı blokunu R209'da geri alıp ilk çerçevenin orada tüketilip tüketilmediğini test ettik. | UART/profilfirmware/rpi5-wifi-scan-r208-profile.txt · r209-profile.txt |
| R208 → R209 | Legacy pre-session F2 tanı bloku geri geldi (beş okuma + reset + 19 ms; birleşik değişken). | WIFIDBG R194 ile aynı; yine yedi MAC GET ve REPLIED=0, FIFO_READS=1. | Koda bakınca send_control içindeki post-send tanı okumasının F2 baytlarını parser'a vermeden attığı görüldü; R210'da yalnız o feature çıkarıldı. | UART/profilfirmware/rpi5-wifi-scan-r209-profile.txt · r210-profile.txt · kernel/src/driver/brcmf_sdio.rs |
Post-send F2 tanısı çıkarılınca üç kontrol yanıtı geldi; CLM aktarımı 512B FIFO sınırına indirildiğinde escan tamamlandı.
| Geçiş | Değişken / A-B kapsamı | Ölçülen veya ölçülemeyen | Sonraki adımın gerekçesi | Kanıt düzeyi |
|---|---|---|---|---|
| R209 → R210 | rpi5-wifi-f2-post-send kaldırıldı; yanıttan sonra ham F2 okuması artık çerçeveyi tüketmiyor. | SENT=3 REPLIED=3: MAC, sürüm ve bus:txglom SET yanıtlandı. Sonraki CLM 1400B veri → 1448B çerçeve F2'nin 512B planlama sınırında InvalidArgument. | Yanıt yolu doğrulandı; CLM aktarımı ACK-gated 448B dilimlere R211'de indirildi. | UART/profilfirmware/rpi5-wifi-scan-r210-profile.txt · r211-profile.txt · kernel/src/driver/rpi5_sdio_wifi.rs |
| R210 → R211 | CLM_CHUNK_LEN 1400→448; düz 28B başlık + 20B envelope + 448B = 496B F2. | Altı CLM yanıtı, CLM_ACK=2676, READY=1; escan kabul, BSS görüldü; GEN=2/5/6 Complete, COUNT=16 TRUNCATED=1. | Tarama kapandı. Sonraki işler tarama başarısı değil: 16 kayıt sınırı, sabit MAC, bağımsız Bluetooth ve association kabulü. | UART/profilfirmware/rpi5-wifi-scan-r211-profile.txt · kernel/src/driver/brcmf_scan.rs |
Kanıt düzeyi: R194 son mühürlü tarihsel radyo koşusudur; firmware+NVRAM birlikte 146 mühürlü koşuda doğrulandı. R211 ise bu oturumda Pi 5 UART'ında görülen başarılı taramadır ve ham UART akışı henüz mühürlü arşiv değildir. R193 ve önceki koşuların başarısızlık açıklamaları yalnız kendi tarihlerine aittir; güncel tarama sonucunu geçersiz kılmaz.
R1'den başlayan güç ve SDIO adımları, R75/R179 Linux kontrolleri, R192→R193 pull-up düzeltmesi, R194 düz kontrol yanıtı, R210'da post-send tanı okumasının çıkarılması ve R211'de 448 baytlık CLM aktarımı yukarıdaki dönem tablolarında açıklanır. Sıradaki plan: R212 (planlı, tarama sonrası): R211 ham UART tekrarını mühürle; 16 kayıt sınırını ve sabit NVRAM MAC kimliğini ayrı ayrı doğrula. Bu adım mevcut R211 escan PASS'ını geri almaz; WPA/association ve Bluetooth ayrı kapılardır. Wi-Fi bağlanma ve Bluetooth hâlâ ayrı kabul testleri gerektirir.
Her basamak tek bir soru sorar ve o soruyu cevaplamak için gereken en az şeyi yapar. "Reddediyor" sütunu, o basamağın bilerek yapMADIĞI şeydir — kapsamın nerede bittiğini iddia değil, kod belirler. R1–R93 makbuzları tarihsel anlık durumları anlatır; R211'in güncel tarama sonucu üstteki kutu ve karşılaştırma tablolarındadır.
| Dosya | Bayt | Kaynaktaki adı | sha256 |
|---|---|---|---|
| BRCMFW.BIN | 609.309 | cypress/cyfmac43455-sdio-standard.bin | d608f866582519c0a28d86db43040f4f1b98dd1d153e72e9752586546b4a36c3 |
| BRCMNVR.TXT | 2.074 | brcm/brcmfmac43455-sdio.txt | ca709be81a78bdb6932936374f39943acbd7af07fae6151011127599a3ce9e3d |
| BRCMCLM.BLB | 2.676 | cypress/cyfmac43455-sdio.clm_blob | 9823842cae9fb9a5dd1e5fb31f595516ec7deee341354bef30bb3026eee29cc1 |
| LICENSE.txt | 21.253 | Cypress + Broadcom yeniden dağıtım metinleri | 19b26b80dcd61423f1c722d4f86e25e657ee429ada149e40062806ad8364f6bf |
Kaynak: RPi-Distro/firmware-nonfree, dal trixie
CHIPID=0x15264345 (BCM43455) ölçüldü. R194 son mühürlü tarihsel koşudur; R211 ağdan açılan imajın UART gözleminde FWSTAGE OK=1, NVRAM OK=1, FWREADY_MS=55, CLM_ACK=2676, READY=1 ve üç tamamlanan escan vardır. R75 Raspberry Pi OS kontrolü wlan0 ve hci0 oluşumunu gösterir; R75 bir SSID taraması veya association kanıtı değildir. R211 ham UART akışı ayrıca mühürlenmelidir.
R136, Linux'un aynı kartta ölçülen host→card çerçeve biçimini (SDPCM glom eklentisi, BCDC dcmd 20. baytta) uyguladı. Fiziksel koşuda R127'den beri ilk kez yeniden kurulan ikinci F2 yazması kabul edildi: TRIAL=1 FRAMELEN=56 XFER=56 SENT=2 REPLIED=0 ERR=ControlTimeout — WriteFifo/0x0020 hatası yok; süpürme TRIAL=2'ye ve TRIALS_RUN=2'ye ilerledi. Yani tel biçimi duvarı aşıldı ve kalan sınır firmware'in çerçeveyi işlememesi. Ölçülen Linux çerçeveleriyle kalan farklar seq (bizde 255, Linux'ta küçük/artan), dcmd türü-id (GET id=1 vs SET id=4+) ve preinit sırasıdır. Bu tanı PASS'tir; Wi-Fi PASS değildir.
Kanıtlanan
Kanıtlanmayan sınır
Tekrar edilmeyecekler
Aynı fiziksel RPi5 üzerinde, tam PSU sök-tak sonrası Linux/brcmfmac'in BCM43455'i çalıştırıp çalıştırmadığını görmek; R75 bunu pozitif cevapladı. Sıradaki iş Linux ile AselsanOS arasındaki ilk anlamlı host-init farkını bulmaktır.
Ön koşullar
Kanıt toplama komutları
R75_COLD_BOOT_CONFIRMED=1 scripts/collect-rpi5-r75-linux-control.sh evidence/rpi5/radio/attempt-r75-linux-control # Betik sonunda EVIDENCE_SHA256SUMS'i kendisi üretir; ikinci kez shasum * çalıştırmayın.
Kabul: ALINDI: Linux Wi‑Fi arayüzü oluştu, firmware preinit tamamlandı; Bluetooth HCI hci0 cevap verdi. WLAN soft-blocked olduğu için association/ping ölçülmedi.
Red: GERÇEKLEŞMEDİ (bu dal açılmadı): Linux da firmware load / wlan init aşamasında kalsaydı kart/silikon/blob hipotezi öne çıkacak ve R76 hiç açılmayacaktı. R75 pozitif çıktığı için bu dal kapandı.
| R75 sonucu | Anlamı | Sonra |
|---|---|---|
| Linux Wi‑Fi çalışır | R75 sonucu budur: silikon, board saatleri ve blob ailesi Linux altında çalışıyor; sorun AselsanOS host-init farkında. | Linux–AselsanOS trace diff yapılacak; yalnız ilk anlamlı fark tek değişken olarak uygulanacak. |
| Linux Wi‑Fi de çalışmaz | Kart/silikon/güç/saat/firmware paketi sorunu güçlü adaydır. | Onboard BCM43455 terk edilir veya kart değiştirilir; R76 açılmaz. |
| Linux Wi‑Fi çalışır, BT çalışmaz | Wi‑Fi CR4 yolu ayrışır; Bluetooth ayrı UART/patchram/init problemi olabilir. | Wi‑Fi diff'i ayrı yürütülür, BT ayrı hata raporuna alınır. |
| Linux BT çalışır, AselsanOS BT susar | R75 sonucu AYNI ZAMANDA budur: Linux hci0'ı kurdu, AselsanOS ise 83 mühürlü koşuda TX=4 / ANSWERED=0 aldı. R75 dmesg'i çipi BCM4345C0 diye tanıdı ve brcm/BCM4345C0.raspberrypi,5-model-b.hcd yamasını yükledi; bu dosya AselsanOS'ta yok. | BT için ayrı HCI trace diff hazırlanır; ilk aday patchram (.hcd) yokluğudur — Wi-Fi CR4 yolundan bağımsız yürütülür. |
| Linux Wi‑Fi çalışmaz, BT çalışır | Ortak çip ölümü değil; WLAN path veya firmware/PMU özel problemi öne çıkar. | Onboard Wi‑Fi ürün yolundan kapalı kalır; BT bağımsız değerlendirilir. |
LTE / UART-AT
Telefon ürünü için en hızlı WAN kanıtı: UART sahipliği, AT komut motoru, SIM/operator registration, PDP context ve veri yolu.
Ethernet / RP1 GEM
AselsanOS'un kendi ağ yığını için temiz yol: RP1 BAR keşfi, GEM MMIO, MDIO/PHY, DMA ring, ilk frame, ARP ve ICMP ping.
Onboard BCM43455 Wi‑Fi
Ürün bloklayıcısı değil, araştırma hattı. İki koşul da gerçekleşti: R75 Linux kontrolü pozitif çıktı ve ilk anlamlı host-init farkı daraltıldı — bu yüzden hat R76–R93 ile AÇIK yürüdü. Ürün ağı yine de P0/P1 üzerinden kurulur; bu hattın PASS'i ürün planına girmez.
| Sıra | Olasılık | Kanıt | İşlem |
|---|---|---|---|
| 1 | SDIO core intstatus clear before rstvec | R76 fiziksel koşusunda SDIO_INT_B=0x00020000 → clear landed → SDIO_INT_A=0x00000000; CR4 hâlâ çalışmadı. | Tek başına elendi; kaynakta Linux-parity cleanup olarak kalır. |
| 2 | KSO / SBSDIO_FUNC1_SLEEPCSR wake discipline | R77 ölçtü: KSO_B=0x03, KSO_W=1, KSO_A=0x03, KSO_SET=1, KSO_DEVON=1; CR4 yine çalışmadı. | Tek başına elendi; kaynakta Linux-parity cleanup olarak kalır. |
| 3 | CHIPCLKCSR / DEVICE_CTL clock-available yolu | R78 ölçtü: CLK_REQ=0x28, CLK_HOLD=0x21; CR4 yine çalışmadı ve WRITE_OK=0 oldu. | Bu yerleşimde elendi; R79'da R77 clock baseline'a dönülür. |
| 4 | Function-0 Broadcom CARDCTRL_WLANRESET | R79 ölçtü: CARD_B=0x01, CARD_W=1, CARD_A=0x03, CARD_WLANRST=1; CR4 yine çalışmadı. | Tek başına elendi; kaynakta Linux-parity cleanup olarak kalır. |
| 5 | NVRAM generated-byte equality ve opsiyonel MAC ekleme | Host-side mirror R74 ile aynı metrikleri verdi: VARSZ=1748, TOKEN=0xfe4b01b4, ADDR=0x23792c; .txt zaten macaddr içeriyor. | Düşük öncelik; sonraki fiziksel CR4-start adayı değil. |
| 6 | F2 enable / hostintmask / watermark / MESBUSYCTRL | Linux bunları firmware başladıktan sonra yapar; R74 firmware-ready/MBOX aşamasına ulaşmadı. | Post-MBOX aşaması; R76 start adayı değil. |
| 7 | Bluetooth patchram / baud transition | Linux HCI Broadcom patch dosyası sonrası çalışıyor; AselsanOS yalnız ROM-speed Reset gönderiyor. | Ayrı BT diff; Wi‑Fi CR4-start değişkeni değil. |
R76–R79 tek-register/tek-semantik adayları elendiği için sonraki bounded iş yeni AselsanOS register denemesi değil, Linux'un gerçek brcmfmac/mmc/sdio işlem sırasını boot-time trace buffer'ından yakalamaktır.
Kartı arm etme komutu
scripts/arm-rpi5-r80-linux-trace-card.sh /Volumes/bootfs
docs/radio/R80-linux-transaction-trace.md
scripts/collect-rpi5-r80-linux-sdio-trace.sh
Boot trace argümanları
Beklenen kanıt
Kapsam dışı: Wi‑Fi association/ping değil, AselsanOS koşusu değil, modül reload veya servis restart değil; yalnız Linux trace/dmesg/firmware kimliği toplama.
docs/radio/R81-linux-order-combined.md
Bu imajda yok: R78 0x28→0x21 at CR4-start; halt_cr4 before TCM; F2/hostintmask/watermark (post-MBOX).
docs/radio/R82-alp-hold-through-ramrw.md
Bu imajda yok: R81 HTCLK 0x08 before ramrw; R78 0x28→0x21 at CR4-start; halt_cr4 before TCM; F2/hostintmask/watermark (post-MBOX).
docs/radio/R83-attach-kso-cardctrl-only.md
Bu imajda yok: Pre-ramrw PMU RES_RELOAD; Pre-ramrw D11 disable; R81 HTCLK 0x08; halt_cr4 before TCM.
docs/radio/R84-attach-pmu-reload.md
Bu imajda yok: Pre-ramrw D11 disable (R81/R82 hang çifti); R81 HTCLK 0x08; halt_cr4 before TCM; F2/hostintmask/watermark (post-MBOX).
docs/radio/R85-post-nvram-pmu-reload.md
Bu imajda yok: Pre-ramrw PMU RES_RELOAD (R84, S=0 takılması); Pre-ramrw D11 disable; R81 HTCLK 0x08; halt_cr4 before TCM.
docs/radio/R86-pmu-write-path.md
Bu imajda yok: R84/R85 4× CMD52 PMU yazması; Pre-ramrw PMU (R84); R81 HTCLK 0x08; halt_cr4 before TCM.
docs/radio/R87-drop-pmu-reload.md
Bu imajda yok: ASELSAN/PMUREL / RES_RELOAD yazması; R81 HTCLK 0x08; halt_cr4 before TCM.
docs/radio/R88-set-active-vs-cr4-start.md
Bu imajda yok: RES_RELOAD yazması; R81 HTCLK 0x08; halt_cr4 before TCM; Yeni rstvec adresi yok; rambase'e ikinci rstvec yazması yok; terminal IOCTL 0x00 (R51); F2/hostintmask (post-MBOX).
docs/radio/R89-rstvec-cmd52-restore.md
Bu imajda yok: Linux ramrw/CMD53 rstvec yazması; RES_RELOAD yazması; R81 HTCLK 0x08; halt_cr4 before TCM; terminal IOCTL 0x00 (R51).
docs/radio/R90-rambase-rstvec-second-write.md
Bu imajda yok: rstvec adresini 0'dan rambase'e taşımak; Linux ramrw/CMD53 rstvec; RES_RELOAD yazması; R81 HTCLK 0x08; halt_cr4 before TCM; terminal IOCTL 0x00 (R51).
docs/radio/R91-drop-rambase-rstvec.md
Bu imajda yok: R90 rambase rstvec yazması; RES_RELOAD yazması; R81 HTCLK 0x08; halt_cr4 before TCM; terminal IOCTL 0x00 (R51); CMD53 rstvec / ramrw.
docs/radio/R92-copyable-linux-cr4-start-closed.md
Bu imajda yok: Yeni FGC/rstvec/D11/saat/PMU/rambase varyantı; terminal IOCTL 0x00 (R51); R81 HTCLK 0x08; halt_cr4 before TCM; CMD53 rstvec / ramrw; RES_RELOAD yazması.
Sıra geçerlilik, geri alınabilirlik ve mümkün olduğunda tek değişkenli A/B denemeleriyle belirlendi. R194 sonrası her kart, bulunan sonucu ve sonraki denemeye geçiş nedenini gösterir. R195–R199 sohbet özetleriyle R200–R211 mühürsüz profil/UART kayıtları, mühürlü koşudan ayrı etiketlenir; birleşik değişiklikler de açıkça belirtilir.
Değişiklik / kapsam: TCM_RAMSIZE sabit tahmin yerine ARMCR4 CAP + banka taramasıyla ölçülür; NVRAM ve yürütme tanığı ölçülen tepeden türer.
Neden bu sırada: Yerleşim hatası, ölçüm körlüğünü de içeriyordu: aynı sabit hem NVRAM'in yazıldığı yeri hem de yürütmeye bakılan yeri 160 KiB kaydırıyordu.
CR4RAM CAP=0x00000b44 BANKS=8 RAMSIZE=0x000c8000 MEASURED=1 · NVRAM ADDR=0x0025f92c · MBOX=0 EXECUTED=0
Kapattığı: C01 ve C03 KAPANDI (kusur gerçekti ama neden değildi). C02 kalıcı kazanç: ramsize artık ölçülüyor.
Risk: Düşük — tek yazma BANKIDX indeks kaydına; Linux aynı yazmayı aynı adrese yapıyor.
Değişiklik / kapsam: Komut-tamamlandı yoklama sınırı 2.000 → 50.000, SDIO saati /16 → /256 (tanımlama değerleri). Yalnızca cr4_start'tan hemen önce.
Neden bu sırada: GEÇERLİLİK ÖN KOŞULU. Firmware staging'i hızlandırmak için daraltılan bütçe hiç geri alınmıyordu: R59–R95 arasındaki BÜTÜN CR4-start sonuçları bu daraltılmış bütçe altında ölçüldü. Bir yazmanın 'indi' sayılıp aslında zaman aşımına uğraması mümkün; WRITE_OK=1 ve MBOX=0 okumalarının ikisi de şüpheli. Bu düzelmeden sonraki hiçbir adayın sonucu güvenilir okunamaz.
CR4PRE POLLS=50000 CLKDIV=0x80 · CR4START POLLS= HOST_BLK= HOST_CLK= HOST_TMO= HOST_CTL1= HOST_CTL2= PMU_TC= CHIPID2= MBOX2=
Kapattığı: C12 KAPANDI (geri alma çalıştı, sonuç değişmedi). Ama C15 ayırt edicisi ateşledi: CHIPID2=0x00000000 — tanık okumaları güvenilmez. Bu, C33'ü doğurdu ve merdiveni yeniden sıraladı.
Risk: Çok düşük — yalnızca host tarafı yapılandırması geri alınır ve üç okuma eklenir. Çipe yeni bir yazma yok.
Değişiklik / kapsam: TCM (shared word) okuması tanık döngüsünden ÖNCE değil SONRA yapılır. Serbest eklenen salt-okunur enstrümantasyon: her turda MBOX ile AYNI 32 KB pencereden bir nöbetçi bayt (ChipCommon ofset 0, beklenen 0x45) durum kontrollü okunur.
Neden bu sırada: GEÇERLİLİK ÖN KOŞULU — ikinci kez. R96 ölçtü ki cr4_start'tan sonra SD hattı ölü ve bu R70'ten beri böyle. Ölçü aleti doğrulanmadan merdivene basamak eklemek yeni bir belirsiz datum üretir. C04 bu yüzden bir sıra geriye alındı: sonucu da aynı güvenilmez pencereden okunacaktı.
FENCE=0xdeadbeef SENT_N= SENT_OK= SENT_LAST_OK_MS= SENT_BAD_MS= F0_REV= F0_OK= WIN_OK_END= WIN_W= WIN_R= SHARED_AFTER=1
Kapattığı: C33'ün ölçüm sırası düzeltildi: nöbetçi 100/100, MBOX=0 ve INTSTAT=0 canlı hatta ölçüldü. Host-görünür sinyal yokluğu, hiç komut yürütülmediği anlamına gelmez. R70–R96 tanıkları geçersiz; PMU sayacı ilerlediği için C13'ün 'LPO ölü' yorumu da düştü. TCM sonrası hat sorunu C34'te açık.
Risk: Çok düşük — davranış değiştiren tek şey bir okumanın SIRASI. Yeni yazma yok; nöbetçi ekstra komut maliyeti olmadan issue()'nun zaten döndürdüğü durumu saklıyor.
Değişiklik / kapsam: Reset dizisi bittikten hemen sonra CHIPCLKCSR ← 0x00, ardından ← 0x10 (HT_AVAIL_REQ); 60 ms HT yoklaması.
Neden bu sırada: R95/R97'de CLK_CSR=0x49 ve release sonrası HT isteği yoktu. Linux release'ten sonra 0x00 → 0x10 yazıp HT bekliyor. Önceki FORCE_ALP yorumu düzeltildi: Linux'un erken 0x21 yazması bu biti içerir, indirme tutamağı ise 0x08'dir.
HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_CLR=0x40 HT_CSR_REQ=0x50 HT_CSR_FIN=0x50 HT_REQ_MS=60 HT_REQ_AVAIL=0 · SENT_N=100 SENT_OK=100 WIN_OK_END=1 FENCE=0xdeadbeef
Kapattığı: C04 kapandı: istek latch etti, HT gelmedi. PMU kaynak ailesi öne çıktı; C09 henüz elenmedi.
Risk: Düşük — yazılan tek kayıt, fonksiyonun zaten iki kez yazdığı CHIPCLKCSR. Yeni adres, yeni çekirdek, yeni reset varyantı yok. HT_AVAIL bir BAŞARI ORACLE'I OLARAK KULLANILMIYOR: yürütme kararı hâlâ MBOX/INTSTAT tanığından geliyor ve bir kaynak testi HT bloğunun yürütme bayraklarına dokunmadığını pinliyor (bu koruma bir dönem yanlış pozitif üretmişti).
Değişiklik / kapsam: Release sonrası HT temizlemesinden önce ve 60 ms yoklamadan sonra CTL, STAT, RES_ST, RES_PEND, MINRES ve MAXRES salt-okunur alınır. Pencere ve CHIPID kontrolleriyle her kaydın okuma geçerliliği taşınır.
Neden bu sırada: R98: ALP hazır, HT isteği latch etti, PMU sayacı ilerledi; HT gelmedi. Karşılaştırma, isteğin PMU kaynak durumunda gözlenebilir değişim üretip üretmediğini ayırır. PMU'ya yeni yazma yok; RES_RELOAD ayrı koşudur.
PMUHT PHASE=PRE/POST WIN_OK= READ_OK= VALID= CHIP_B= CHIP_A= CTL= STAT= RES_ST= RES_PEND= MINRES= MAXRES=; R98 HT makbuzu ve R97 nöbetçisi korunur
Kapattığı: C09'u tek başına kapatmaz. VALID=1 ve READ_OK=0x3f ile iki görüntünün eşit olduğu görüldü; ara geçişler ve PMU yazma yolu hâlâ sınanmadı.
Risk: Düşük — PMU kayıtları yalnız okundu. Ek okumalar release ile HT isteği arasına gecikme ekler; görüntüler atomik değildir.
Değişiklik / kapsam: set_sdio_clock() CLOCK_CONTROL erişimleri u32 yerine u16 olur; clock bölücü ve CR4 dizisi değişmez.
Neden bu sırada: R99 ve önceki koşular HOST_TMO=0x00 gösterdi. 0x2c'ye 32-bit yazım bitişik TIMEOUT_CONTROL alanını sıfırlıyordu; R100 yalnız erişim genişliğini değiştirerek bu yan etkiyi ayırır.
HOST_TMO=0x0e HOST_CLK=0x8007 HOST_CTL1=0x02 POLLS=50000 · HT_REQ_AVAIL=0
Kapattığı: Clock/timeout kusuru fiziksel olarak doğrulandı ve ayrıldı. C09 PMU kaynak ailesi kapanmadı; HT yine gelmedi.
Risk: Düşük — yalnız host SDHCI register erişim genişliği değişti; firmware, reset ve PMU yazmaları aynı kaldı.
Değişiklik / kapsam: R100 timeout düzeltmesi korunarak tek D11 CMD53 yazmasının issue/complete/busy makbuzu alınır; sonraki reset yolu değiştirilmez.
Neden bu sırada: R100 timeout'u korudu ama R101 ilk D11 yazmasında DAT inhibit nedeniyle issue edilmeden durdu. Bu sonuç, sonraki adayların cihazda gerçekten yazma yapıp yapmadığını ayıran transport kapısını görünür kılar.
CR4CTRL PHASE=D11 ABORTED=1 ISSUED=0 COMPLETE=0 BUSY=1 PSTATE=0x017f0206
Kapattığı: C05'in wrapper yazma taşıması bu koşuda uygulanmış sayılmaz; ilk yazma issue edilmedi. C05 açık kalır.
Risk: Düşük-orta — yeni yazma varyantı yok; sonuç host DAT inhibit durumuna duyarlı.
Değişiklik / kapsam: Birleşik adayda DATA reseti, 18-op wrapper, HT isteği ve scan runtime aynı cold boot içinde gözlenir.
Neden bu sırada: R101'deki DAT inhibit'i ayırmak için host DATA reseti eklendi; R102, HT erişilebilir olduktan sonra ilk FullMAC yazmasının gerçek sonucunu ölçtü.
CR4HOSTDATA READY=1 · CR4CTRL COMPLETE=1 · HT_REQ_AVAIL=1 · WIFISCAN_RESULT STATUS=INIT_ERROR
Kapattığı: C10/C07/C08 kapanmadı. Host kurtarma ve HT kapıları geçti; gerçek FullMAC kontrol cevabı gelmeden firmware-ready veya Wi-Fi PASS denemez.
Risk: Orta — birden fazla geçiş aynı koşuda; sonuç sonraki R103 transaction-owned ölçümüyle daraltıldı.
Değişiklik / kapsam: Tamamlanmış CMD53'ün kendi completion/R5/error/byte-count sonucu kullanılır; sonraki settle CMD52 cevabı geriye dönük hata kanıtı sayılmaz.
Neden bu sırada: R102'de iç CMD53 temiz olmasına rağmen sonraki dummy CMD52'nin RESP0 değeri önceki yazmaya mal edildi. R103 bu response ownership sınırını ayırır.
HT_REQ_AVAIL=1 · WIFIPROTO STARTED=1 READY=0 · WIFISCAN_RESULT Session(Wire(Truncated))
Kapattığı: R102'nin outer-rejection açıklaması daraldı; R103 parser'ın hangi RX zarfında durduğunu basmadığı için C07/C08 açık kaldı.
Risk: Düşük — transport sonucu sahipliği düzeltildi; yeni FIFO/control retry eklenmedi.
Değişiklik / kapsam: Doğrulanmış empty Event/Data çerçevesi sequence/credit akışını koruyarak tüketilir; kontrol cevabı için ayrı RX ve hata makbuzu basılır.
Neden bu sırada: R103'te Truncated hata yolunda RX içeriği yoktu. R104 boş zarfı güvenle ayırıp parser'ın kontrol cevabına kadar ilerleyip ilerlemediğini ölçer.
WIFIRX LEN=12 DOFF=12 EMPTY=1 SEQ=0/1 · WIFIFAIL FRAMES_RECEIVED=2 HEADER_ONLY=2 CONTROLS_REPLIED=0
Kapattığı: Boş Event/Data tanısı doğrulandı; C07/C08 kapanmadı çünkü READY=1 veya kontrol cevabı yok.
Risk: Orta — parser hata sınırı değişti; raw, README ve kaynak yamaları web kanıt paketi olarak mühürlendi.
Değişiklik / kapsam: İlk kontrol çerçevesinde veri uzunluğu max(isim, kapasite) yerine isim + kapasite olarak hesaplanır.
Neden bu sırada: R104 iki boş Event/Data zarfı ve ControlTimeout gösterdi. R105, kontrol header'ının beklenen 48 bayt olup olmadığını fiziksel olarak ayırır; BCDC aritmetiği RX cevabından bağımsız sınanır.
WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 SEQ=255 TXWIN=21 SENT=1 REPLIED=0
Kapattığı: BCDC uzunluk hipotezi kapandı: doğru istek gönderildi. C07/C08 ve kontrol cevabı/RX transport sınırı açık; C16 DDR50 en son ve ayrı tutuluyor.
Risk: Düşük — yalnız BCDC request buffer uzunluğu; yeni register/reset/clock varyantı yok.
Değişiklik / kapsam: R105'in değişmez BCDC isteği korunur; RX çerçevesinin ham başlık/payload, sequence/credit ve control-reply durumu basılır. R106'da görülen core+INTSTATUS Read32 hatası ayrı sahiplik adımı olarak kaydedilir.
Neden bu sırada: İki header-only RX frame fiziksel olarak görüldü, fakat kontrol cevabı gelmeden host Read32(INTSTATUS) SDIO Transfer/R5 hatasıyla durdu. Bu koşu RX parser'ı veya BCDC aritmetiğini değiştirmeden gerçek hata sınırını mühürler.
WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 · WIFIRX_RAW HEADER_HEX/PAYLOAD_LEN · WIFICTRLSTATE SENT=1 REPLIED=0 · Read32 INTSTATUS Transfer/R5
Kapattığı: C07/C08 kapanmadı; RX görünürlüğü doğrulandı ancak READY=1 veya doğrulanmış FullMAC control reply/IOReady makbuzu yok.
Risk: Düşük — R106 tanısını kaynakta değişmez tutar; yeni Wi-Fi retry, BCDC aritmetiği veya association davranışı eklenmez.
Değişiklik / kapsam: R106'nın BCDC 48/20 isteği ve RX parser'ı korunarak R107 imajı gerçek Pi 5 üzerinde çalıştırılır; açılış akışı, RX başlıkları ve terminal hata mühürlenir.
Neden bu sırada: R106'nın hedeflediği Read32 makbuzu için ilk gerçek fiziksel koşu yapıldı. Kart + güç + boot artık ayrı kanıt; ancak capture güç geçişinden sonra bağlandığı için bu kayıt Read32 issue/complete/R5/error sahipliğini geriye dönük iddia etmez.
FWSTAGE OK=1 · NVRAM OK=1 · CR4HOSTDATA READY=1 · WIFIRX SEQ=0/1 · WIFICTRLSTATE SENT=1 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ControlTimeout
Kapattığı: Fiziksel açılış kanıtı kapandı; C06/C07/C08 ve INTSTATUS Read32 issue/complete/R5/error sınırı açık kaldı. Bu basamak Wi-Fi PASS değildir.
Risk: Düşük — kart ve imaj değişmedi; yeni register/reset/clock veya BCDC/RX davranışı eklenmedi.
Değişiklik / kapsam: Kart Pi'de takılı bırakılır; UART capture güç döngüsünden önce arm edilir. BCDC 48/20, RX parser ve R107 imajı korunur; yalnız Read32 issue/complete/bytes-read/R5/error makbuzu tam boot sınırında toplanır.
Neden bu sırada: R107 fiziksel açılışı ve ControlTimeout sınırını doğruladı, fakat capture güç geçişinden sonra bağlandı. Ön-arm edilmiş tek bir güç döngüsü, kartı tekrar tekrar söküp takmadan açılış ile Read32 hedefini aynı kayda alır.
WIFIREAD OP=Read32 FUNCTION=1 ADDRESS=0x18004020 · ISSUED=1 COMMAND_COMPLETE=0 BUFFER_READY=0 TRANSFER_COMPLETE=0 BYTES_READ=0 R5_FLAGS=0x10 ERROR_STATUS=0x0020
Kapattığı: Read32 sınırı artık ölçüldü: ilk F1 aktarımı data-CRC/transfer hatasıyla düştü. C06/C07/C08 ve gerçek control reply/IOReady açık kaldı; bu basamak Wi-Fi PASS değildir.
Risk: Düşük — tek host read tanısı; BCDC, RX parser, clock/reset ve association davranışı değişmez.
Değişiklik / kapsam: R108'in değişmez BCDC/RX akışı korunarak F1 Read32 CMD53 status, R5, error, present-state ve reset sonrası durumu birlikte mühürlenir.
Neden bu sırada: R108 ilk F1 Read32'de ERROR_STATUS=0x0020 ve komut tamamlanmadan düşen bir aktarım gösterdi. Bu veri-CRC/end-bit sınırı, control-response sahipliğini firmware veya BCDC uzunluğu ile karıştırmadan daraltılmalıdır.
WIFIREAD OP=Read32 · STATUS=0x00608001 · R5_FLAGS=0x10 · ERROR_STATUS=0x0060 · COMMAND_COMPLETE=0 · TRANSFER_COMPLETE=0 · BUS_WAS_BUSY=0
Kapattığı: F1 Read32 aktarımının data-CRC/end-bit hata dalı görüldü; ancak control response/IOReady ve CR4 yürütme hâlâ kanıtlanmadı.
Risk: Düşük — yalnız mevcut Read32 tanısının tam makbuzu; firmware, BCDC aritmetiği ve association değişmez.
Değişiklik / kapsam: F1 Read32 fallback'ine geçmeden önce ölçülen D11 başlangıç yazmasının issue/complete/busy/R5/error sonucu mühürlenir.
Neden bu sırada: R109'un F1 data-CRC/end-bit sonucu, R110'da D11 başlangıç yazması aynı transport kapısında ayrıştırılmadan yorumlanamaz.
CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=1 ISSUED=1 CMD=1 BUF=1 XFER=1 BYTES=4 R5=0x10 ERR=0x0010
Kapattığı: R110'da D11 başlangıç yazması ayrı bir transport hatası olarak görüldü; R109 fallback'i bu koşuda çalışmadı. D11 transport varyansı R113'te bounded retry ile sınırlandı.
Risk: Düşük-orta — yalnız ölçülmüş D11 yazma hatasına tek bounded retry eklenir; Wi-Fi başarı sonucu çıkarılmaz.
Değişiklik / kapsam: R110'un ölçülmüş D11 transport dalına bounded retry uygulanır; FIFO/RX ve ilk BCDC isteği korunur.
Neden bu sırada: D11 temiz geçtiğinde ilk fiziksel SDPCM kontrol sınırına dönmek gerekir; retry'nin kendisi başarı sayılmaz ve yalnız ölçülmüş timeout/CRC koşulunda çalışır.
CR4CTRL COMPLETE=1 ERR=0x0000 D11_RETRY_ATTEMPTED=0 · WIFIRX SEQ=0/1 EMPTY=1 TXWIN=21 · WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 · REPLIED=0
Kapattığı: D11/SDPCM başlangıç yolu geçti; ilk control reply/READY=1 yok. Retry dalı bu koşuda tetiklenmedi.
Risk: Orta — bounded retry güvenlik kapısıyla sınırlı; ikinci fiziksel transport varyansı hâlâ ölçülmelidir.
Değişiklik / kapsam: İlk initialization/scan/control isteğinden önce bekleyen F2 RX FIFO frame'leri tüketilir; BCDC 48/20 isteği ve RX parser değişmez.
Neden bu sırada: R111'de iki header-only frame ve cevapsız BCDC isteği görüldü. Linux sıralamasına yaklaştırılan drain bariyeri, bekleyen RX frame ile yeni TX control isteğinin sahipliğini ayırır.
FWSTAGE OK=1 · NVRAM OK=1 · CR4HOSTDATA READY=1 · D11_RESET=1 D11_IOCTL=0x00000007 · CR4CTRL PHASE=CR4 OPS=17 ADDR=0x18102408 ABORTED=1 R5=0x10 ERR=0x0020
Kapattığı: R112 SDPCM FIFO drain davranışını ölçemedi; D11 geçtikten sonraki CR4 activation yazısı data-CRC ile düştü. Bu koşu CR4 transport varyansını görünür kıldı, FIFO hipotezini kapatmadı.
Risk: Düşük — yalnız bekleyen RX frame tüketim sırası; hata dalı başarı gibi yorumlanmaz.
Değişiklik / kapsam: R112'nin FIFO sırası korunur; ilk D11 yazısı data-timeout/CRC hata koşulunda en çok bir kez yeniden denenir ve ilk control-response bekleyişi mühürlenir.
Neden bu sırada: R110'un D11 DATA_TIMEOUT sonucu bounded retry gerektiriyordu; DATA_CRC aynı veri-taşıma sınıfı olarak fail-closed biçimde kapsandı. R112 raw hatası CR4 activation'da olduğundan bu retry onun exact işlemini kapsamaz. R113 temiz dalda retry'yi tetiklemeden sonraki ilk control sınırını yeniden ölçtü.
CR4HOSTDATA READY=1 · CR4CTRL COMPLETE=1 R5=0x10 ERR=0x0000 D11_RETRY_ATTEMPTED=0 · CR4START STARTED=0 OK=0 · WIFIRX SEQ=0/1 · WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 · WIFICTRLWAIT CAPTURED=1 · REPLIED=0
Kapattığı: D11 temiz geçişi ve iki header-only RX doğrulandı; CR4 yürütme, ilk control reply, READY=1 ve Wi-Fi PASS açık kaldı. Sıradaki dar kapı R114'tür.
Risk: Düşük-orta — retry yalnızca ölçülmüş ERR_DATA_TIMEOUT/ERR_DATA_CRC için bir kez; R113'te branch tetiklenmedi.
Değişiklik / kapsam: R113 davranışı, firmware/NVRAM, D11, FIFO sırası, RX parser ve BCDC 48/20 isteği sabit; yalnız timeout-sonrası salt-okunur TX/interrupt/FIFO/host makbuzları eklenir.
Neden bu sırada: R113 doğru uzunluklu ilk isteği gönderdi, iki header-only frame aldı, INTSTATUS=Some(0) ve REPLIED=0 ile ControlTimeout'a düştü. Yeni firmware veya BCDC uzunluğu değişikliği bu sınırı karıştırır.
IMAGE_SHA=d82ce641084d… · WIFICTRLTX_RAW REQUEST_ID=1 LOGGED=48 · WIFIREAD_FALLBACK ERR=0x0060 RESULT=PASS VALUE=0 · SBADDR_LOW Write8 INHIBIT issued=false PSTATE=0x01ff0206 · WIFICTRLWAIT CAPTURED=0
Kapattığı: Exact ilk TX doğrulandı; ancak koşu timeout snapshot'ından önce fallback-sonrası DAT_INHIBIT dalında durdu. Control-response interrupt/FIFO sahipliği açık kaldı.
Risk: Düşük — R114 yalnız tanı ekledi; ölçülen kırılma timeout-sonrası tanı okumalarından önce oluştu.
Değişiklik / kapsam: Sayaçlar request gönderiminde sıfırlanır; pending-control I/O hatasında terminal host/F1 snapshot alınır; CMD52 fallback yalnız bounded passive post-check host idle ise başarı sayılır.
Neden bu sırada: R114, CMD53 0x0060 fallback'inin VALUE=0 döndürmesine rağmen PRESENT_STATE=0x01ff0206 durumunu temizlemediğini ve sonraki SBADDR_LOW erişiminin issue edilmeden Inhibit ile durduğunu fiziksel olarak ölçtü.
IMAGE_SHA=7f7ca549198b… · WIFIREAD_FALLBACK ERR=0x0020 RESULT=PASS VALUE=0 HOST_IDLE=0 PSTATE_B=0x01ff0206 PSTATE_A=0x017f0206 POLLS=100000 DAT0=1 · WIFICTRLWAIT CAPTURED=1 PENDING_BEFORE=1 AGE_MS=994 · request-local CORE_OR/FIFO/CTRL=0
Kapattığı: Fallback false-success kusuru kapandı ve host data engine'in kendiliğinden idle olmadığı ölçüldü. IENx/FIFO sahipliği hâlâ okunamadı; sıradaki dar kapı R116'dır.
Risk: Düşük-orta — yeni register yazması yok; bounded passive bekleme ve fail-closed başarı koşulu eklenir.
Değişiklik / kapsam: Yalnız discovered SDIO-core INTSTATUS saf DATA_CRC=0x0020 + valid fallback + 100.000 poll HOST_IDLE=0 dalında bus ömründe bir host-only SOFTWARE_RESET_DAT uygulanır; CMD52×4 checked eşleşen readback ve idle doğrulanmadan sonuç kabul edilmez.
Neden bu sırada: R115, DAT0 yüksek ve CMD hattı boşken host veri motorunun 0x0206 durumunda takılı kaldığını ölçtü. Aynı boot'ta pre-CR4 host-only DATA reset aynı deseni iki poll'da 0x0000'a temizledi; runtime kullanımı yine ayrı fiziksel hipotezdi.
IMAGE_SHA=39e7de9d9256… · WIFIREAD_RECOVERY USED_BEFORE=0 ELIGIBLE=1 APPLIED=1 CLEARED=1 RESET_FIRST=0x04 RESET_POLLS=2 ELAPSED_US=10 PSTATE_B=0x017f0206 PSTATE_A=0x017f0000 HOST_IDLE=1 CONFIG_SAME=1 RECOVERY_OK=1 POST_READ_OK=1 POST_MATCH=1 POST_HOST_IDLE=1 ACCEPTED=1 · ikinci olay USED_BEFORE=1 ELIGIBLE=0 · terminal ERR=0x0060 · PENDING_POLLS=121 AGE_MS=2183
Kapattığı: Tıkanan tarafın host SDHCI veri motoru olduğu ölçüldü: 100.000 pasif kontrolün açamadığı yolu tek reset 10 µs'de açtı, konfigürasyon değişmedi ve bir kez kullanım disiplini tuttu. Wi-Fi hazır olmadı; arıza aynı registerda 0x0020'den 0x0060'a taşındı, sıradaki dar kapı R117'dir.
Risk: Orta — yalnız host SDHCI data hattına tek reset; kart/core/WLAN reseti ve CMD53 retry yok.
Değişiklik / kapsam: R116 kararı hesaplandıktan sonra, bus ömründe bir kez, aynı pencerede üç salt-okuma probu: ChipCommon chipid'de CMD52×4, bayraklı 4 baytlık byte-mode CMD53 ve tek-blok 64 baytlık CMD53. Her prob yalnız host idle iken denendi; yazma, reset, pencere değişimi ve CMD53 tekrarı yok.
Neden bu sırada: R116, firmware'in konuştuğunu ve host veri motorunun reset ile açıldığını ölçtü; buna rağmen 0x18004020 CMD53 okuması kırıldı. Geriye ayrılabilir üç değişken kalmıştı: veriyolu durumu, adres, transfer modu.
IMAGE_SHA=e4e1583dcc9c… · WIFIREAD_MATRIX CMD52_OK=1 BYTE_OK=1 BLOCK_OK=1 hepsi V=0x15264345 M=1 ERR=0x0000 · TAIL_IDLE=1 TAIL_POLLS=0 TAIL_PSTATE=0x01ff0000 · VERDICT=ADDRESS_SPECIFIC · WIFICTRLWAIT READ_FAILURES=0 CLOCK=0xd2 SLEEP=0x03 IO_READY=0x06 F2_ENABLED=0x06 MAILBOX=0x00040002 INTSTATUS=0 · terminal ControlTimeout AGE_MS=2500
Kapattığı: Veriyolu durumu ve transfer modu elendi: kırılma adrese özgü. Taşıma sona kadar ayakta kaldı, hiçbir tanı okuması düşmedi ve arıza sınıfı BusError'dan ControlTimeout'a döndü — sorun artık host taşıması değil, dongle'ın cevap üretmemesi. Açık kalan soru: 136 kez yoklanan INTSTATUS=0 değeri 4-baytlık erişim bayrağı olmadan okunuyor.
Risk: Düşük — yazma, reset veya pencere değişimi yok; problar yalnız host idle iken çalıştı ve hattı tamamen boş bıraktı.
Değişiklik / kapsam: Aynı R117 kapısı içinde, bus ömründe bir kez, host idle iken: SDIO çekirdeği INTSTATUS (+0x20) ve pozitif kontrol tohostmailboxdata (+0x4c), her iki backplane erişim yoluyla dört denetlenmiş CMD52 baytıyla okunur. Veri hattı, yazma ve CMD53 yok.
Neden bu sırada: R117'de sürücünün 136 kez yokladığı INTSTATUS=0 değeri bayraksız yoldan okunuyordu; kırılan CMD53 ise bayraklı okuyor. Doğrulanmamış bir yoldan okunan sıfır 'firmware sessiz' sonucunu taşıyamaz.
IMAGE_SHA=db5809cb08ac… · ilk hata 0x0060 (0x0020 değil) · WIFIREAD_RECOVERY ELIGIBLE=0 · WIFIREAD_MATRIX CMD52_SKIP=1 tüm problar A=0 · WIFICORE_ACCESS INT_SKIP=1 INT_PLAIN=None MBOX_PLAIN=None VERDICT=INCOMPLETE · TAIL_IDLE=0 TAIL_POLLS=100000 TAIL_PSTATE=0x017f0206
Kapattığı: Hiçbir şey kapatmadı; soru açık kaldı. Kapattığı tek şey bir yanılgı riskiydi: takılı host ölçülmedi, zorlanmadı. Ölçtüğü yeni olgu, ilk hata sınıfının koşudan koşuya değiştiği — dolayısıyla ölçüm, kapı saf 0x0020'ye daraldığı sürece hangi dala düşüldüğüne bağlı bir yazı-tura.
Risk: Düşük — komut hattı dışında hiçbir şeye dokunulmadı; problar zaten hiç çalışmadı.
Değişiklik / kapsam: Tek yüklem: bus ömründe bir kez uygulanan host-only SDHCI DATA reset artık DATA_CRC'li her veri hatası (0x0020 veya 0x0060) için uygun; başka hiçbir koşul değişmez.
Neden bu sırada: R118'de ilk hata 0x0060 geldiği için dar kapı reddetti, host idle olmadı ve hiçbir prob çalışamadı. İki bit veri fazının nasıl kırıldığını söyler, host-only reset'in doğru cevap olup olmadığını değil.
IMAGE_SHA=c2818abf67d0… · bu boot'ta HİÇ veri hatası olmadı, kapı sınanmadı · READ_FAILURES=0 PENDING_POLLS=144 AGE_MS=2500 PRESENT_STATE=0x01ff0000 · terminal ControlTimeout
Kapattığı: Kapıyı sınamadı ama daha önemlisini ölçtü: taşıma arızası aralıklı, yani belirti; kök neden değil. Beş koşuda ilk hata 0x0020 / 0x0020 / 0x0020 / 0x0060 / yok. 0x18004020 her zaman okunamaz değil.
Risk: Düşük — yeni bir eylem eklemedi; zaten iki kez ölçülmüş tek reset'in kapsamını genişletti.
Değişiklik / kapsam: R119'dan tek fark rpi5-bt-isolate feature'ı: BT_ON'u süren ve UARTA'ya yazan bring_up atlanır. Salt-okunur BT envanteri ve Wi-Fi yolu aynen kalır.
Neden bu sırada: BCM43455'te BT ve WLAN aynı kalıpta PMU/saat paylaşır ve R117 kaydında BT_ON, SDPCM başlamadan hemen önce yükseliyordu (BTHCI 288, WIFIPROTO 311).
IMAGE_SHA=2f220c4bbcdf… · BTHCI SKIPPED=1 BT_ON_DRIVEN=0 UARTA_WRITES=0 · PINMUX BT_ON=0 WRITES=0 · WIFIPWR BT_ON_TOUCHED=0 · sonuç R119 ile birebir: READ_FAILURES=0 PENDING_POLLS=144 AGE_MS=2500 INTSTATUS=IEN=INT_PENDING=0 2 çerçeve/0 cevap terminal ControlTimeout
Kapattığı: Bluetooth bring-up'ı eler. BT hiç açılmamışken arıza alan alan aynı; Linux'ta bu çip için bildirilen miniuart-bt çözümü bizimkinden başka bir arızaya bakıyor. Geriye kalan adaylar: çerçeve hatalı biçimlendiği için reddediliyor, yanlış yere yazılıyor, ya da firmware ioctl'den önce yapılmayan bir adım bekliyor.
Risk: Düşük — saf çıkarma; hiçbir yeni yazma eklenmedi. Bu imaj Bluetooth iddiası taşımaz.
Değişiklik / kapsam: R120 tabanı + R119 BT bring-up'ı geri; tek fark function 1 SBSDIO_WATERMARK (0x10008) 0x60 yerine 0x08. R121'in diğer üç farkı bu revizyonda yok.
Neden bu sırada: R121, Linux'un ilk 48 baytlık kontrol çerçevesinden hemen önce bu kayda 0x08 yazdığını ölçtü; sürücü 0x60 yazıyordu. 0x60 yazım hatası değil, daha yeni brcmfmac sabiti — ama bu Pi ve bu firmware izde 0x08 kullanmış.
IMAGE_SHA=8fd85b5a7e38… · CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT WIN_OK=0 WIN_W=0x18100000 WIN_R=0x18181800 ISSUED=0 · CR4START RSTVEC_OK=0 · WIFISCAN_RESULT STATUS=UNAVAILABLE CORE_READY=0 · watermark yazılmadı
Kapattığı: Değişkeni sınamadı. Kapattığı şey bir yanılgı: bu boot'un ControlTimeout olmadığı, üçüncü imzanın CMD52 pencere uyuşmazlığı olduğu. F2 watermark hakkında ne lehte ne aleyhte kanıt.
Risk: Düşük — tek bayt, CR4 start sonrası; bu boot o noktaya gelmedi.
Değişiklik / kapsam: R122 üzerine sıfır davranış. CMD52/CMD53 gövdeleri inner'a taşındı; sarmalayıcılar yalnız sayar ve inner sonucu aynen döndürür. F2 watermark 0x08 duruyor.
Neden bu sırada: R118, R119 ve R122 kendi değişkenlerini hiç icra edemedi; her koşu tek veri noktası ve kırılma yeri kayıyor. Üç imza (CMD53 CRC, cevapsız BCDC, CMD52 pencere uyuşmazlığı) oran olmadan ayırt edilemez.
IMAGE_SHA=8ab16337d0e0… · WIFIBUSCENSUS STAGE=ERROR CMD52_OPS=612077 CMD52_FAIL=83469 CMD53R_OPS=164 CMD53R_INCOMPLETE=2 CMD53W_OPS=15 CMD53W_INCOMPLETE=0 ERR_CRC_ONLY=1 ERR_CRC_ENDBIT=1 WINDOW_MISMATCH=0 · WIFIPROTO STARTED=1 · XFER=48 REPLIED=0 · ControlTimeout AGE_MS=2500
Kapattığı: Aralıklı CMD53 yazma bozulmasını cevapsız ioctl'ün tek nedeni olmaktan çıkarır: yazmalar 0/15 incomplete, pencere 0, çerçeve XFER=48, bekleme READ_FAILURES=0. F2 watermark 0x08 bu boot'ta icra edildi ve cevap üretmedi. Arama protokole döner.
Risk: Yok — yazma, retry, reset veya fail-closed gevşetme yok; atomik artırım.
Değişiklik / kapsam: R123 tabanı + R122 watermark 0x08 durur. Tek davranış: fonksiyon 0 CCCR INT_ENABLE (0x04) Linux izindeki gibi önce 0x03 sonra 0x07 (IENM|IEN1|IEN2). WAKEUPCTRL ve CCCR 0x000f0 bu revizyonda yok. CMD52 sayımı STAGE/OTHER kırılımı ekler; cmd52_inner değişmez.
Neden bu sırada: R121 bu yazmayı ölçtü; R115–R123 IEN=Some(0) okuyor. R123 sayımı veriyolu yazma yolunu temiz saydı, INTSTATUS=0'ı her iki erişimle doğruladı ve watermark'ı eledi. Kalan ölçülmüş farkların ilki, firmware'in kesme kaldırmamasını doğrudan ilgilendiren kayıttır.
IMAGE_SHA=644ed7aad9ea… · CR4CTRL PHASE=D11 ABORTED=1 ERR=0x0020 WIN_OK=1 ISSUED=1 XFER=0 ADDR=0x18101800 · WIFIEN yok · WIFIBUSCENSUS STAGE=UNAVAILABLE CMD52_STAGE_FAIL=78837 CMD52_OTHER_FAIL=0/457 CMD53R_INCOMPLETE=2/9 · UNAVAILABLE CORE_READY=0
Kapattığı: Değişkeni sınamadı. Kapattığı şey census kırılımı: 78.837 CMD52 fail'in tamamı STAGE, OTHER 0/457. INT_ENABLE hakkında ne lehte ne aleyhte kanıt.
Risk: Düşük-orta — Linux'un yazdığı CCCR kesme maskesi; bu boot o noktaya gelmedi.
Değişiklik / kapsam: R124 ile aynı bayt. Tek fark yeni güç döngüsü: D11 CRC bu boot'ta olmadı, Function2Ready'ye ulaşıldı, 0x03 sonra 0x07 yazıldı.
Neden bu sırada: R124 değişkeni hiç icra edemedi. Aynı imaj, aynı tek değişken, protokol yoluna kadar.
IMAGE_SHA=644ed7aad9ea… · WIFIEN W1=Some(3) W2=Some(7) READBACK=Some(7) IEN_TIMEOUT=Some(7) · IEN=Some(7) INT_PENDING=Some(0) · XFER=48 REPLIED=0 · ControlTimeout AGE_MS=2500 · CMD52_OTHER_FAIL=0/535
Kapattığı: CCCR INT_ENABLE=0 cevapsız ioctl'ün nedeni değil. Kapı Linux gibi açıldı, latch etti, firmware yine cevap vermedi. R121'de WAKEUPCTRL=0x02 ve CCCR 0x000f0=0x06 kaldı.
Risk: Yok — R124 ile aynı imaj.
Değişiklik / kapsam: R125 tabanı (watermark 0x08, INT_ENABLE 0x03→0x07 durur). Tek davranış eklemesi: fonksiyon 1 SBSDIO_FUNC1_WAKEUPCTRL (0x1001e) = 0x02 (HT-wait), Linux'un yazdığı noktada — watermark ile CCCR INT_ENABLE çiftinin arasında. Kaydın yazmadan önceki ve sonraki okuması gözlemdir. CCCR 0x000f0 bu revizyonda yok.
Neden bu sırada: R121 bu yazmayı ölçtü; biz hiç yazmıyorduk. R123 watermark'ı, R125 INT_ENABLE'ı cihazda icra edip elemişti. Kalan iki hazırlık farkından, firmware'in kesme kaldırmasını doğrudan ilgilendiren olan buydu.
IMAGE_SHA=0e4fb7ae33ad… · WIFIWAKEUP BEFORE=Some(0) WROTE=Some(2) READBACK=Some(2) EXPECT_R80_WROTE=0x02 · WIFIEN W1=Some(3) W2=Some(7) READBACK=Some(7) · CR4CTRL PHASE=COMPLETE ABORTED=0 WIN_OK=1 · CR4START RSTVEC_OK=1 ALIAS_OK=1 HT_REQ_AVAIL=1 HT_CSR_FIN=0xd0 · WIFIPROTO STARTED=1 READY=0 · iki header-only RX SEQ=0/1 TXWIN=21 · XFER=48 SENT=1 REPLIED=0 · IEN=Some(7) INT_PENDING=Some(0) CORE_OR=0x00000000 FRAME_IND_SEEN=0 · ControlTimeout AGE_MS=2500 PENDING_POLLS=144 · CMD52_OTHER_FAIL=0/531 CMD53W_INCOMPLETE=0/15
iki paket: attempt-r126-wakeupctrl-uart-capture (tam boot, D11'de düştü, değişken icra edilmedi) ve attempt-r126-wakeupctrl-uart-capture-repeat-01 (reflash YOK, yeni güç döngüsü, değişkeni icra etti; yakalama güçten sonra kurulduğu için BAŞI EKSİK — README'de beyan edildi)
Kapattığı: fn1 WAKEUPCTRL=0x02 cevapsız ioctl'ün nedeni DEĞİL. Kartın güç-açılış değeri Some(0) ölçüldü — yani 0x02 gerçek bir değişiklikti, boş yazma değil; yazıldı, latch etti, firmware yine cevap vermedi. Bu, R121'in dört ölçülmüş hazırlık farkından ÜÇÜNCÜSÜNÜN cihazda elenmesidir (watermark R123, INT_ENABLE R125, WAKEUPCTRL burada). GERİYE BİR TANE KALDI: fn0 CCCR 0x000f0 = 0x06. Kombinasyon ihtimalini kapatmaz: dördü hiç aynı anda doğru olmadı ve Linux'ta olmayan iki fazlalığımız hiç kaldırılmadı.
Risk: Düşük — Linux'un yazdığı tek bayt; yeni core/WLAN reseti yok.
Değişiklik / kapsam: R126 tabanı davranış olarak değişmez. Tek yapısal ekleme: transport'a opt-in süpürme yeteneği. Deneme 0 hiçbir şey uygulamaz — R126'nın tek-değişkenli koşusunun ta kendisi. Sonra on bir hazırlık profili, her biri aynı 48/20 isteğini kendi BCDC request id'siyle gönderir. 'Yazmayı kaldırmak' atlamakla değil tersini yazmakla yapılır; güç-açılış baytları boot bloğundan önce örneklenir.
Neden bu sırada: R121'in dört farkı hiç aynı anda doğru olmadı ve CCCR 0x000f0 hiç kodlanmamıştı. Neden tek kayıt değil de kombinasyonsa, tek-değişkenli yöntem onu yapısal olarak bulamaz.
IMAGE_SHA=882c67867b88… · İLK BOOT: D11'de düştü, WIFITRIALPLAN bile basılmadı, hiçbir deneme koşmadı — ama CMD52_FAIL=0/611999 (kayıttaki en temiz CMD52 boot'u) iken CMD53W_INCOMPLETE=2/2 · TEKRAR BOOT: WIFITRIALPLAN ARMED=1 TOTAL=11 · TRIAL=0 BASE_R126 XFER=48 REPLIED=0 POLLS=144 AGE_MS=2500 ControlTimeout (R126 tabanı birebir) · TRIAL=1 LINUX_EXACT APPLIED=1 POWERON_MISSING=0 — WM 0x08, WC 0x02, DEVCTL 0x10→0x00, MESBUSY 0xd0→0x00, CARDCAP 0x00→0x06, IEN 0x07, hepsi geri okumayla doğrulandı · sonra WriteFifo fn=2 error_status=0x20 (saf veri CRC) · CMD53W_OPS=16 INCOMPLETE=1 · STOP TRIALS_RUN=1/11 REPLIED=0
iki paket: attempt-r127-prereq-sweep-uart-capture (tam boot, D11'de düştü) ve attempt-r127-prereq-sweep-uart-capture-repeat-01 (tam boot, motor koştu, iki deneme)
Kapattığı: Hiçbir şeyi elemez — ama üç şeyi kurar. (1) Süpürme motoru cihazda çalışıyor: arm oldu, denemeler koştu, makbuzlar basıldı, tek sonlandırma işareti ile yakalama temiz kapandı. (2) Deneme 0, R126 tabanını üçüncü kez birebir doğruladı. (3) ZİNCİRDE İLK KEZ tam Linux hazırlık eşitliği karta uygulandı ve geri okumayla doğrulandı — CCCR 0x000f0=0x06 dahil, ki hiçbir koşuda karta ulaşmamıştı. LINUX_EXACT ELENMEDİ: çerçevesi hiç iletilemedi, sorusu sorulmadı.
Risk: Gerçekleşen risk sıralamaydı. En riskli deneme ikinci sıradaydı; veri CRC'si aldı ve Io kalıcı terminal olduğu için sonraki dokuz denemeyi öldürdü. ADAY (n=1): DEVICE_CTL bit 4'ü (kaynağımızın F2WM_ENAB dediği bit) temizleyen tek deneme oydu ve o boot'taki on altı CMD53 yazmasından düşen tek yazma hemen ardından geldi. Doğruysa o 'fazlalık' bizim transport'umuz için fazlalık değil. Bitin upstream adı bu pakette doğrulanmadı ve DEVICE_CTL hiç tek başına temizlenmedi.
Değişiklik / kapsam: Süpürme motoru R127 ile aynı. Üç fark: matris artan riske göre sıralandı (CARDCAP_06 birinci ve tek başına, BASE_CONTROL riskli aileden önce, LINUX_EXACT sonuncu), durma sebebi ayrıştırıldı, deneme 0 kendi kayıt kaydını taşır.
Neden bu sırada: R127'de en riskli profil ikinci sıradaydı, veri CRC'si aldı, ve Io kalıcı terminal olduğu için dokuz deneme sorusunu soramadı. Ayrıca kirlenme kontrolü en sonda olduğu için hiç ölçülemedi.
IMAGE_SHA=19d1caafb30d… · D11 GEÇTİ (yeni flash olmasına rağmen) · TRIAL=0 BASE_R126 XFER=48 REPLIED=0 POLLS=134 ControlTimeout · TRIAL=1 CARDCAP_06 APPLIED=1 — DEVICE_CTL 0x10→0x10 KORUNDU (geri okumayla), MESBUSY 0xd0→0xd0, tek değişiklik CARDCAP 0x00→0x06 · yine WriteFifo fn=2 addr=0x8000 hatası · CMD53W_OPS=16 INCOMPLETE=1 · STOP=NOT_REARMABLE TRIALS_RUN=1/11 · deneme 0 güç-açılış durumunu kaydetti: WM=0x20 WC=0x00 DEVCTL=0x00 MESBUSY=0x00 CARDCAP=0x00 IEN=0x00
attempt-r128-prereq-sweep-ordered-uart-capture (tam boot; ayrıca reflash deseni 0/4'ten 1/5'e indi)
Kapattığı: R127'nin ürettiği adayı ÇÜRÜTÜR. R127'de düşen deneme DEVICE_CTL bit 4'ü temizliyordu; R128'de düşen deneme o biti KORUDU (geri okumayla doğrulandı) ve aynı işlemde aynı hatayı aldı. İki boot, adayın adını verdiği bitte farklılaşan iki profil, birebir aynı sonuç. DEVICE_CTL sebep değil. Ayrıca kartın gerçek güç-açılış watermark'ı 0x20 ölçüldü — ne bizim 0x60'ımız ne Linux'un 0x08'i.
Risk: Geriye tek ortak nokta kaldı ve daha keskin: her iki düşen yazma da CEVAPSIZ KALAN bir çerçeveden SONRAKİ ilk çerçeveydi; iki boot'ta da 16 CMD53 yazmasından düşen tek yazma oydu. İki okuma var: (a) yeniden kurmamız eksik — Linux'un DPC'sinin çerçeveler arası yaptığı hiçbir şeyi yapmıyoruz, her mühürlü koşuda FIFO_READS=0; (b) kart bir çerçeveyi yoksaydıktan sonra F2 yazması kabul etmiyor. Paket ikisi arasında seçim yapmıyor. Süpürme bu çözülmeden deneme 1'i geçemez.
Değişiklik / kapsam: R128 imajı, matrisi ve profilleri aynen durur. Tek ekleme: her yeniden kurmadan ÖNCE bir kurtarma adımı — maskeli core INTSTATUS okunur ve sıfır değilse geri yazılır; fonksiyon-2 FIFO'sundan FRAME_IND beklemeden TEK sınırlı first-64 okuması yapılır; host veri motoru durumu örneklenir. Boşaltma profilden ÖNCE koşar, böylece kuyrukta bekleyen bir çerçeve denemenin göndermek üzere olduğu isteğe cevap sanılamaz.
Neden bu sırada: R128 tek ortak noktayı bıraktı: düşen yazma her seferinde cevapsız kalan bir çerçeveden sonraki ilk çerçeve. Her mühürlü koşuda kart FRAME_IND kaldırmadı ve biz F2'den hiç okumadık (FIFO_READS=0) — yani 'yeniden kurmamız eksik' okuması hiç sınanmadı.
IMAGE_SHA=aedd2f1c1450… · tam boot · TRIAL=0 BASE_R126 XFER=48 REPLIED=0 POLLS=137 ControlTimeout · WIFIRECOVER ATTEMPTED=1 INTSTATUS=Some(0) CLEARED=0 FIFO_OK=1 FIFO_FAILED=0 LENGTH=Some(0) LEN_COMPLEMENT_OK=0 PSTATE=Some(33488896)=0x01ff0000 · TRIAL=1 CARDCAP_06 APPLIED=1 · ikinci WriteFifo fn=2 addr=0x8000 aynı veri CRC'siyle düştü · CMD53R=168, CMD53W=16/INCOMPLETE=1, CMD52_OTHER_FAIL=0/531 · STOP=NOT_REARMABLE
attempt-r129-inter-trial-recovery-uart-capture (tam boot) · build/rpi5-wifi-scan-r129/aselsanos-rpi5-radio.img · sha256 aedd2f1c1450fabb34a0bbec0bff1ee3a6c71bf6d2f8e286152e33df49734c4a
Kapattığı: R129'un sınadığı biçimiyle 'yeniden kurma eksik' okumasını ve 'kart, toplamadığımız bir cevabı F2 FIFO'da tutuyor' okumasını çürütür. Kurtarma başarılıydı, FIFO boştu, kesme yoktu ve host idle'dı. Üç boot'un ortak ifadesi daha dar: cevapsız bir çerçeveden sonra function 2 okumayı kabul ediyor, yazmayı reddediyor.
Risk: Gözlenen risk aynı kaldı: ikinci F2 yazması transport'u terminal yaptı ve süpürme trial 1'de durdu. Recovery'nin kendisi hatasız tamamlandı; yeni bir arıza üretmedi.
Değişiklik / kapsam: R129 matrisi ve kurtarması aynen durur. Tek davranış eklemesi: CARDCAP_06 profilinin son CMD52'sinden sonra, yeniden kurulan ikinci F2 yazmasından hemen önce function 0 CCCR IO_ABORT (0x06) kaydına function 2 seçimi (0x02) yazılır. Function-2 kapat/aç ve block-size re-assert yoktur.
Neden bu sırada: R129, düşüş anında function-2 okumasının çalıştığını ve FIFO'nun boş, core INTSTATUS'ın sıfır, host veri motorunun idle olduğunu ölçtü. Geriye kartın F2 yazma tarafındaki durum kaldı; IO_ABORT SDIO'nun bu durumu sonlandırmak için tanımladığı ve hiçbir koşuda issue edilmemiş mekanizmadır.
IMAGE_SHA=670818f2326d… · tam boot · TRIAL=0 BASE_R126 XFER=48 REPLIED=0 POLLS=132 ControlTimeout · WIFIRECOVER INTSTATUS=Some(0) FIFO_OK=1 LENGTH=Some(0) PSTATE=Some(33488896)=0x01ff0000 · WIFIF2ABORT ATTEMPTED=1 OK=1 FAILED=0 · TRIAL=1 CARDCAP_06 APPLIED=1 · hemen sonraki WriteFifo fn=2 addr=0x8000 error_status=0x0020 veri CRC'siyle düştü · CMD53R_OPS=165 INCOMPLETE=2 · CMD53W_OPS=16 INCOMPLETE=1 · CMD52_OTHER_OPS=535 FAIL=0 · STOP=NOT_REARMABLE
attempt-r130-f2-io-abort-uart-capture (tam boot) · build/rpi5-wifi-scan-r130/aselsanos-rpi5-radio.img · sha256 670818f2326d84f7f50a1571bf466823abeb8cdd7badf0fb89ae81741e93bfdc
Kapattığı: IO_ABORT tek başına elendi. Kart function-2 abort yazmasını kabul etti ve sürücü OK=1 makbuzunu verdi; buna rağmen hemen sonraki ikinci F2 yazması aynı işlemde, aynı veri CRC sınıfıyla düştü. Bu sonuç abort komutunun hiç gönderilmediği ya da başarısız olduğu okumasına açık kapı bırakmaz.
Risk: Gözlenen risk gerçekleşmedi: IO_ABORT başarılı oldu ve kurtarma okumaları çalıştı. Transport yalnız hemen sonraki ikinci F2 yazmasında terminal oldu; süpürme trial 1'de durdu.
Değişiklik / kapsam: R130 matrisi, kurtarması ve CARDCAP_06 profili aynen durur. Tek mekanizma: ikinci yazmadan önce CCCR IO_ENABLE (0x02) okunur; F2 enable biti temizlenirken F1 korunur, IO_READY (0x03) üzerinde F2'nin düştüğü sınırlı beklemeyle doğrulanır; F2 yeniden açılır ve hazır biti yükselene kadar sınırlı beklenir. Block-size yeniden yazılmaz.
Neden bu sırada: R130, function-2 IO_ABORT'un başarıyla issue edilmesinin kartın ikinci F2 yazmasını kabul ettirmediğini gösterdi. Abort'tan daha güçlü fakat hâlâ dar bir sonraki kart-tarafı mekanizması, fonksiyonun enable/ready yaşam döngüsünü gerçekten kapatıp yeniden kurmaktır.
IMAGE_SHA=877a1b96ba3d… · tam boot · TRIAL=0 XFER=48 REPLIED=0 POLLS=144 ControlTimeout · WIFIRECOVER INTSTATUS=Some(0) FIFO_OK=1 LENGTH=Some(0) PSTATE=0x01ff0000 · WIFIF2REENABLE BEFORE_ENABLE=Some(6) DISABLE_OK=1 READY_CLEAR=1 CLEAR_POLLS=1 ENABLE_OK=1 READY_SET=1 SET_POLLS=1 FAILED=0 BLOCK_SIZE_REWRITE=0 · hemen sonraki ikinci WriteFifo fn=2 addr=0x8000 error_status=0x0020 ile düştü · HOST_INT=1 CORE_OR=0x00000080 · CMD52_OTHER_FAIL=0/531 · STOP=NOT_REARMABLE
attempt-r131-f2-reenable-uart-capture (tam boot) · build/rpi5-wifi-scan-r131/aselsanos-rpi5-radio.img · sha256 877a1b96ba3df93034c31d93991986605c6447d38dfdd3076f39ecf0954f892f
Kapattığı: F2 enable/ready yaşam döngüsü gerçekten tamamlandı; yalnızca register yazılmış sayılmadı. Yeni kesmeyi servis etmeden yapılan bu tam kapat/aç ikinci yazmayı kurtarmadı. Ancak R130'da CORE_OR=0 olan aynı sınır R131'de 0x80 oldu; pre-lifecycle INTSTATUS=0 olduğundan bu yeni fark ayrıca sınanmalıdır.
Risk: Yaşam döngüsünün kendisi hatasız tamamlandı. Transport yine yalnız ikinci F2 yazmasında terminal oldu. Yeni HOST_INT, sonucu block-size'a atlamadan önce yakın bir post-lifecycle ack kapısına yönlendirir.
Değişiklik / kapsam: R131'in kurtarması, CARDCAP_06 profili ve doğrulanan F2 kapat/aç zinciri aynen kalır. Tek ekleme: READY_SET=1 sonrasında core INTSTATUS okunur; maskeli HOST_INT 0x80 varsa aynı registera write-one-to-clear yazılır ve geri okuma alınır. Sonra ikinci F2 yazması yapılır. Block-size registerlarına dokunulmaz.
Neden bu sırada: R131 öncesinde recovery INTSTATUS=0 iken tam yaşam döngüsünden sonraki trial 1'de HOST_INT=1 / CORE_OR=0x80 görüldü; R130'un aynı sınırında ikisi de sıfırdı. Bu, R131'in ürettiği tek yeni ayırt edici kart durumudur.
IMAGE_SHA=3fddd839a9e9… · tam boot · TRIAL=0 XFER=48 REPLIED=0 POLLS=132 ControlTimeout · WIFIRECOVER INTSTATUS=Some(0) FIFO_OK=1 LENGTH=Some(0) PSTATE=0x01ff0000 · WIFIF2REENABLE DISABLE_OK=1 READY_CLEAR=1 ENABLE_OK=1 READY_SET=1 FAILED=0 · WIFIF2POSTIRQ BEFORE=Some(128) MASKED=Some(128) ACK_ATTEMPTED=1 ACK_OK=1 AFTER=Some(0) FAILED=0 · hemen sonraki ikinci WriteFifo fn=2 addr=0x8000 error_status=0x0020 ile düştü · HOST_INT=0 CORE_OR=0x00000000 · CMD52_OTHER_FAIL=0/535 · STOP=NOT_REARMABLE
attempt-r132-post-lifecycle-host-int-uart-capture (tam boot) · build/rpi5-wifi-scan-r132/aselsanos-rpi5-radio.img · sha256 3fddd839a9e9f31830d62f17da1f1f3907fa6b6990c9c6c4911a656075ab2582
Kapattığı: Post-lifecycle HOST_INT açıklamasını kapatır: 0x80 READY_SET sonrasında gerçekten vardı, ack tamamlandı, readback sıfırdı ve trial 1 boyunca core status sıfır kaldı; buna rağmen aynı yazma aynı veri CRC'siyle düştü. R131'deki 0x80'in yalnız sonuç sonrası gürültü olmadığı da zaman olarak daraldı.
Risk: Ack hedeflenen durumu değiştirdi ve başka bir terminal hata üretmedi. Transport yalnız hemen sonraki ikinci F2 yazmasında terminal oldu; block-size ayrı değişken olarak kaldı.
Değişiklik / kapsam: R132'nin kurtarması, F2 yaşam döngüsü ve post-lifecycle HOST_INT temizliği aynen kalır. Tek ekleme: ikinci yazmadan hemen önce function 0 F2 block-size low/high registerlarına 0x210=0x00 ve 0x211=0x02 yazılır, ikisi geri okunur. IO_ABORT yoktur ve başka profile/lifecycle değişikliği yapılmaz.
Neden bu sırada: F2 block-size başlangıçta 512 olarak programlandı, fakat cevapsız çerçeve ve tam function lifecycle sonrasında hiç yeniden doğrulanmadı. IO_ABORT, kapat/aç ve onun ürettiği kesmenin ack'i ayrı ayrı elendi; sıradaki önceden ayrılmış kart-tarafı durum bu iki bayttır.
İlk iki tam boot değişkene erişmeden kapandı: ilki trial 0 Read32 error_status=0x0060, ikincisi CR4CTRL PHASE=D11 ABORTED=1 / D11_RETRY_PRIMARY_ERR=0x0010. Üçüncü tam boot karar verdi: IMAGE_SHA=c58ee8c1fa30… · FWSTAGE/NVRAM OK=1 · TRIAL=0 XFER=48 SENT=1 REPLIED=0 POLLS=144 ControlTimeout · WIFIRECOVER FIFO_OK=1 LENGTH=Some(0) PSTATE=0x01ff0000 · F2REENABLE FAILED=0 · F2POSTIRQ BEFORE=Some(128) ACK_OK=1 AFTER=Some(0) FAILED=0 · WIFIF2BLKSZ ATTEMPTED=1 BEFORE_LOW=Some(0) BEFORE_HIGH=Some(2) WRITE_LOW_OK=1 WRITE_HIGH_OK=1 READBACK_LOW=Some(0) READBACK_HIGH=Some(2) MATCH_512=1 FAILED=0 · bitişik ikinci WriteFifo fn=2 addr=0x8000 R5=0x10 ERROR_STATUS=0x0020 BUS_WAS_BUSY=0 PSTATE=0x01ff0000 · trial 1 HOST_INT=0 CORE_OR=0x00000000
attempt-r133-f2-block-size-repeat-2-uart-capture (tam boot) · build/rpi5-wifi-scan-r133/aselsanos-rpi5-radio.img · sha256 c58ee8c1fa30a776e1b67a4253353e6df1609cd8e020dd4d4cf58201c7509c37 · raw sha256 a2a9776becfedda57d3be7c81b554bbec0387b09b9253e16f8560b2a00af083b
Kapattığı: F2 block-size kaybını ve bayat programlamayı kapatır: değer reassert öncesinde zaten 512'ydi, iki yazma ve iki readback tamamlandı; buna rağmen aynı ikinci yazma aynı veri CRC'siyle düştü.
Risk: Mekanizma eksiksiz tamamlandı ve kart-tarafı block-size durumu doğrulandı. Tek terminal işlem hemen sonraki ikinci F2 yazmasıdır; sonuç Wi-Fi PASS değildir.
Değişiklik / kapsam: R133'ün recovery, F2 yaşam döngüsü, HOST_INT ack ve block-size readback zinciri aynen korunur. Tek ekleme: MATCH_512=1 sonrasında ve ikinci F2 yazmasından hemen önce host tarafında bir SDHCI DATA reset uygulanır; resetin temizlendiği ve host konfigürasyonunun değişmediği doğrulanır. Reset, rearm sonunda değil send_control'ün write_fifo sınırındadır — reset ile ikinci yazma arasına hiçbir SDIO işlemi girmez. Kart reseti, IO_ABORT, ek F2 yaşam döngüsü veya profil değişikliği yoktur.
Neden bu sırada: R133 kart tarafındaki FIFO, interrupt, F2 enable/ready ve block-size durumlarını tek tek sağlıklı doğruladığı hâlde ikinci yazma veri CRC'siyle düştü. R116 host-only DATA resetin uygulanıp doğrulanabilen somut bir primitive olduğunu gösterdi; fakat bu primitive ikinci F2 yazmasının tam önündeki sınırda hiç denenmedi. R24'ün meşgul-hatta-reset GERİLEMESİ ile R116'nın arıza-sonrası kurtarması arasında kalan bu üçüncü yerleşim ayrı bir fiziksel hipotezdi.
İlk koşu değişkene ulaşmadan kapandı (varışsızlık): WIFIHOSTDATA_PLAN ARMED=1 basıldı fakat trial 0 sonrası F1 Read32 INTSTATUS 0x18004020 ikinci kez 0x0020 ile düştü, ikinci reset bus-ömründe-bir-kez kuralıyla reddedildi (USED_BEFORE=1 ELIGIBLE=0), NOT_REARMABLE. Tekrar koşu karar verdi: IMAGE_SHA=b3910252804b… · FWSTAGE/NVRAM OK=1 · TRIAL=0 POLLS=134 ControlTimeout · WIFIRECOVER FIFO_OK=1 · F2REENABLE FAILED=0 · F2POSTIRQ ACK_OK=1 AFTER=Some(0) · F2BLKSZ MATCH_512=1 · WIFIHOSTDATA ATTEMPTED=1 MEASURED=1 APPLIED=1 CLEARED=1 READY=1 CONFIG_SAME=1 POLLS=2 ELAPSED_US=10 PSTATE_B=0x017f0000 PSTATE_A=0x017f0000 RESET_FIRST=0x04 CARD_COMMANDS=0 · UART'ta WIFIHOSTDATA ile bitişik ikinci WriteFifo fn=2 addr=0x8000 R5=0x10 ERROR_STATUS=0x0020 · trial 1 HOST_INT=0 CORE_OR=0 · STOP=NOT_REARMABLE TRIALS_RUN=1/11
attempt-r134-host-data-reset-at-send-boundary-uart-capture (varışsızlık) · attempt-r134-host-data-reset-at-send-boundary-uart-capture-repeat (karar) · build/rpi5-wifi-scan-r134/aselsanos-rpi5-radio.img · sha256 b3910252804ba69fb8ed40c90f52abf4c886d9849c77ac64961f5efd059f1cf0 · repeat raw sha256 c409d7fcd52b9202c7e2bc5fdef2a3230f2874d5e708582e04edd2403767500e
Kapattığı: Send sınırındaki temiz host DATA reset elendi: reset uygulandı, temizlendi, konfigürasyon korundu ve reset ile ikinci yazma arasına hiçbir SDIO işlemi girmedi; buna rağmen aynı ikinci yazma aynı 0x0020 data CRC'siyle düştü. R24 (meşgul hatta), R116 (arıza sonrası kurtarma) ve R134 (send sınırı) birlikte, host SDHCI DATA reset eyleminin — hangi yerleşimde olursa olsun — ikinci yazmanın 0x0020'sinin nedeni olmadığını mühürler.
Risk: Reset öncesi host inhibit yoktu (PSTATE_B=0x017f0000) ve CARD_COMMANDS=0; aksiyonun kendisi yeni bir arıza üretmedi. İlk koşunun varışsızlığı ayrıca kaydedildi; karar yalnız tekrar koşusunun makbuzundan alındı. Sonuç Wi-Fi PASS değildir.
Değişiklik / kapsam: R134'ün elenen send-sınırı reset'i zincirden çıkarıldı (R25 emsali); R129–R133 zinciri aynen korundu. Tek değişken: yeniden kurulan ikinci F2 yazmasının transfer byte sayısı 48 → 64 oldu (16 bayt sıfır dolgu), byte-mode aynı kaldı. İlk yazma (trial 0 bootstrap) değişmedi. Yeni kayıt yazması yok, kart komutu yok.
Neden bu sırada: Masabaşı kararı (docs/radio/R135-second-write-shape-desk.md): R80 izinde Linux fn=2 adres=0x8000'e HİÇ 48 bayt yazmıyor; kısa-çerçeve yazma birimi 64 bayttır (1456 adet). Bizim düşen ikinci yazmamız 48 bayt byte-mode gidiyordu — kip aynı, byte sayısı farklı; eleme zincirinde kalan tek trace-görünür şekil farkı buydu.
IMAGE_SHA=db93f033197a844046dda915ac79e1d23690e48a9cab867be0e77ec94999aa2d · WIFIF2WRITE64_PLAN ARMED=1 UNIT=64 PAD_ZERO=1 FIRST_WRITE_UNCHANGED=1 CARD_COMMANDS=0 HOST_RESET=0 · üçüncü boot: TRIAL=0 FRAMELEN=48 XFER=48 ControlTimeout → WIFIRECOVER ATTEMPTED=1 FIFO_OK=1 LENGTH=Some(0) → F2REENABLE FAILED=0 → F2POSTIRQ ACK_OK=1 AFTER=Some(0) → F2BLKSZ MATCH_512=1 FAILED=0 → WIFIREAD OP=WriteFifo BYTES_READ=64 ERROR_STATUS=0x0020 · WIFIHOSTDATA 0 adet · STOP=NOT_REARMABLE TRIALS_RUN=1/11
üç paket: attempt-r135-f2-write64-uart-capture (varışsızlık 0x0060), attempt-r135-f2-write64-uart-capture-repeat-01 (varışsızlık 0x0020), attempt-r135-f2-write64-uart-capture-repeat-02 (ELENDİ — BYTES_READ=64 ERROR_STATUS=0x0020)
Kapattığı: 64 baytlık ikinci yazma da aynı 0x0020 ile düştü: transfer byte-count şekli (48 ve 64'ün ikisi) elendi. İlk iki boot mühürlü varışsızlık paketidir (F1 Read32 0x0060 / 0x0020, WIFIF2BLKSZ ATTEMPTED=0). Sıradaki aday re-arm→yazma zamanlamasıdır (R26 emsali) — R136.
Risk: Düşük gerçekleşti: dolgu baytları SDPCM için anlamsızdı ve bootstrap yolu korundu. Kaynakta veya trace'te görülmeyen kayıt yazması yok.
Değişiklik / kapsam: Kodlayıcı, Linux'un aynı kartta ölçülen host→card çerçeve biçimine taşındı: HW(4) + 8 baytlık glom eklentisi + SW(8, dat_offset=20) + BCDC dcmd(20..36) + veri; toplam uzunluk 8-bayta hizalı. R134'ün elenen send-sınırı reset'i ve R135'in elenen 64-bayt deneyi imajdan çıkarıldı; flags kodlaması (id<<16 | ifidx<<12 | SET) değişmedi.
Neden bu sırada: R136 Linux yakalaması (linux-r136-first-frame-v3) Linux'un ilk kontrol çerçevelerini ölçtü ve bizim çerçevemizin 8 bayt kısa olduğunu, dcmd'ın 12. yerine 20. baytta olması gerektiğini gösterdi; brcmfmac v6.18 kaynağı (hdpack/tx_ctrlframe) bunu doğruladı.
IMAGE_SHA=940ff0ae798cca612f4481bf5b8b22c81c0ac5753b33d764ab5a11ce5c8fa246 · Linux ölçümü iki bağımsız çekirdekte doğrulandı (RPi OS 97 ve Ubuntu 235 yazma çerçevesi, hepsi glom; glomsuz 0) · WIFICTRLTX_RAW HEX=3800c7ff3400000100000000ff00001400000000060100001400000000000100… · TRIAL=0 FRAMELEN=56 XFER=56 ControlTimeout · WIFIF2BLKSZ MATCH_512=1 · TRIAL=1 SENT=2 FRAMELEN=56 XFER=56 REPLIED=0 ControlTimeout (WriteFifo hatası YOK) · TRIAL=2 SENT=3 · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=2/11 REPLIED=0
attempt-r136-glom-control-frame-uart-capture (tek boot, WHOLE BOOT, 45.849 bayt)
Kapattığı: Tel biçimi sınırını KAPATIR: yeniden kurulan ikinci F2 yazması ilk kez kabul edildi ve süpürme birden fazla denemeye ilerledi. Cevap getirmedi: firmware çerçeveyi işlemiyor (REPLIED=0, FRAME_IND=0, HOST_INT=0). Sıradaki aday R137: seq (255 vs Linux'un artan değeri), dcmd türü/id ve Linux'un preinit sırası — önce masabaşı notu.
Risk: Gerçekleşen: yok — kart yeni biçimi kabul etti, hata sınıfı değişmedi. Kapsam dışı: R116/R119 kurtarma-yolu reset'i ve kart komutları değişmedi.
Değişiklik / kapsam: R136 zinciri ve glom biçimi aynen durur. Tek ekleme salt-okunur bir tanık: protokol fazında her sekizinci poll'da tohostmailboxdata (SDIO çekirdeği + 0x4c) örneklenir, değişen her değer Linux'un yaptığı gibi ACK'lenir ve sürüm/DEVREADY/FWREADY bitleri makbuza yazılır. Çerçeve baytı, kayıt yazması, reset veya komut değişmez.
Neden bu sırada: R136 dongle'ın mailbox'ında DEVREADY'yi görüp FWREADY'yi görmemişti; FWREADY 'protokol aktivitesi için hazır' bitidir ve kalkmadan kontrol isteklerinin cevaplanması beklenmez. Çerçeve içeriği denemeleri bu soru cevaplanmadan yanlış katmana bakar.
IMAGE_SHA=68cad3b57b5c34bbe4a306d0314904e9241bcf9672111eb11901d88dc821ad76 · WIFIMBOXWATCH SAMPLES=87 CHANGES=0 DEVREADY_SEEN=0 FWREADY_SEEN=0 VERSION=0 LAST=0x00040002 · TRIAL=0..3 FRAMELEN=56 XFER=56 BCDCLEN=20 SENT=1..4 REPLIED=0 · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=4/11 REPLIED=0
attempt-r137-mailbox-handshake-uart-capture (tek boot, WHOLE BOOT, 74.047 bayt)
Kapattığı: Taşıma sorusunu KAPATIR: glom biçimi dört çerçeve boyunca kararlı, makbuz alanları doğru. Cevapsızlığı çerçeve içeriğinden çıkarır: dongle protokol hazır bayrağını hiç kaldırmıyor. Sıradaki aday R138: hostmail ACK'inin ve sürüm yazmasının zamanlaması.
Risk: Gerçekleşen: yok — salt-okunur örnekleme + kodda zaten var olan ACK yazması. Kapsam dışı: yeni kayıt yazması, reset, kart komutu yok.
Değişiklik / kapsam: Tel biçimi, R133 zinciri ve bootstrap çerçevesi donuk. Tek davranış değişikliği iki mevcut yazmanın ZAMANLAMASI: her mailbox okumasında koşulsuz SMB_INT_ACK (0x40 ← 2) ve okunan değerde DEVREADY/FWREADY varsa protokol sürümünün yeniden yazımı (0x48 ← 4<<16). Tanık bayrakları artık her örnekte değerlendirilir.
Neden bu sırada: Linux `brcmf_sdio_hostmail` her okumada ACK yazar ve hazır bayrağında sürümü yeniden yazar; R137'de ACK yalnız değişimde, sürüm yalnız F2-hazır yolunda bir kez gidiyordu ve dongle sessizdi.
IMAGE_SHA=e125208d4eb9d73bd0d7a71985766ce0fa172be9f4a2b975523bc80e57536b39 · WIFIHOSTMAIL_PLAN ARMED=1 ACK_EVERY_READ=1 VERSION_REWRITE_ON_READY=1 · WIFIMBOXWATCH SAMPLES=32 CHANGES=0 DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION=4 ACKS=32 VERSION_WRITES=32 LAST=0x00040002 · TRIAL=0/1 FRAMELEN=56 XFER=56 BCDCLEN=20 SENT=1/2 REPLIED=0 · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=1/11
üç paket: attempt-r138-hostmail-complete-uart-capture (D11 varışsızlığı), attempt-r138-hostmail-complete-uart-capture-repeat-01 (değişken icra, erken kapanış), attempt-r138-hostmail-complete-uart-capture-repeat-02 (karar)
Kapattığı: Host el sıkışması adayını KAPATIR: 32 örnekte her okuma ACK'lendi ve sürüm yeniden yazıldı, dongle yine FWREADY kaldırmadı ve iki çerçeveye cevap vermedi. Duvar host el sıkışmasında değil. Sıradaki aday R139: CR4 yürütme + host SDHCI hatalarının ayrıştırılması.
Risk: Gerçekleşen: yok — iki yazma da kodda mevcuttu, yalnız zamanlaması değişti. Kapsam dışı: yeni kayıt, reset, kart komutu ve çerçeve baytı değişmedi.
Değişiklik / kapsam: Tel biçimi, R133 zinciri, R138 hostmail tamamlama ve tüm register değerleri donuk. Tek değişken: reset vektörünün backplane adres 0'a Linux'un yaptığı gibi **4-baytlı bayraklı CMD53** ile yazılması (brcmf_sdio_buscore_activate → ramrw); inmediyse doğrulanmış CMD52 yazması sınırlı geri dönüş olarak kullanılır.
Neden bu sırada: R139 Linux ölçümü CR4 başlatma değerlerinin birebir aynı olduğunu gösterdi; kritik yolda kalan tek yapısal fark bu yazmanın taşımasıydı ve R88'in 0x0060 veri CRC'si R94'ün CMD53 disiplin düzeltmesinden önceydi.
IMAGE_SHA=a7d06727d947bdaa1aad452a83eb9ea21bff8156e35378ee4b65e9b8ed438eaa · WIFIRSTVEC_PLAN ARMED=1 MODE=CMD53_4B_FLAGGED FALLBACK=CMD52 · CR4START RSTVEC_OK=1 RSTVEC_C53=1 RSTVEC_B=4 RSTVEC_ERR=0x0000 RSTVEC_CMD52_FALLBACK=0 HT_REQ_AVAIL=1 MBOX=0 INTSTAT=0 SHARED_RAW=0 EXECUTED=0 STARTED=0 · WIFIMBOXWATCH SAMPLES=18 ACKS=18 VERSION_WRITES=17 FWREADY_SEEN=0 · WIFITRIALEND TRIALS_RUN=1/11 REPLIED=0
attempt-r139-rstvec-cmd53-uart-capture (tek boot, WHOLE BOOT, 55.546 bayt)
Kapattığı: Kritik yoldaki taşıma sorusunu KAPATIR: Linux'un rstvec taşıması bizde de hatasız iniyor ve CMD52 geri dönüşü gerekmiyor. CR4 yürütme sorusunu getirmez: tanıklar sıfır. Sıradaki aday R140: firmware staging taşıması ya da F1 yazma güvenilirliği.
Risk: Düşük gerçekleşti: aynı adrese aynı değer yazıldı, yalnız taşıma Linux'a çevrildi; CMD52 geri dönüşü hazır bekledi ve kullanılmadı.
Değişiklik / kapsam: Tek değişken: "host hazır" protokol sürümü yazmasının YERİ. Linux `brcmf_sdio_firmware_callback` (sdio.c:4261-4262) `SDPCM_PROT_VERSION << 16` değerini `tosbmailboxdata`ya (0x18004048) CR4 bırakıldıktan hemen sonra yazar; R139 tel izinde bırakma t=143.630543, yazma t=143.630617 (~74 µs), F2 enable ve hostintmask'ten ÖNCE. R136–R139 aynı yazmayı protokol fazındaki posta nöbetinde, bırakılıştan saniyeler sonra yapıyordu. Adres, değer, genişlik, çerçeve, saat ve reset donuk.
Neden bu sırada: R139 Linux ölçümü değerlerin ve rstvec taşımasının birebir aynı olduğunu gösterdi; kritik yolda kalan tek fark bu yazmanın zamanı/yeriydi.
IMAGE_SHA=12595cd216f02de34ba7c320360d6abd39aed982c91f41173d46530287cf7471 · WIFIHOSTREADY_PLAN ARMED=1 WHERE=AFTER_CR4_RELEASE VALUE=0x00040000 REGISTER=0x18004048 WATCH_VERSION_REPEAT=0 EARLY_WITNESS_MS=600 WRITES=0 · WIFIHOSTREADY ATTEMPTED=1 BEFORE=0x00000000 WRITE_OK=1 AFTER=0x00040000 AFTER_RELEASE_MS=5 · WIFIEARLYMBOX SAMPLES=7 CHANGES=1 FIRST=0x00000000 LAST=0x00040008 INT_OR=0x208000c0 FWREADY_MS=30 WINDOW_MS=600 WRITES=0 · WIFIMBOXWATCH_R140 VERSION_AT_START=1 WATCH_VERSION_WRITES=0 WATCH_ACKS=30 LAST=0x00040002 · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=1/11 REPLIED=0
attempt-r140-hostready-at-start-uart-capture (tek boot, WHOLE BOOT, 57.712 bayt)
Kapattığı: Zamanlama hipotezini DOĞRULAR: "host hazır" yazması Linux'un yerinde olunca dongle 30 ms'de FWREADY yazıp host kesmesini kaldırıyor. El sıkışmanın tamamlanmasını getirmez: pencere salt-okunurdu, posta ACK'siz kaldı ve dongle DEVREADY'ye geri düştü. Sıradaki adım R141: aynı pencerede Linux ISR'inin cevabı (tosbmailbox ← SMB_INT_ACK, intstatus write-1-to-clear).
Risk: Düşük gerçekleşti: aynı yazma yalnızca daha erken yapıldı; yeni kayıt, değer, çerçeve veya reset yok.
Değişiklik / kapsam: Tek değişken: R140'ın salt-okunur erken penceresinin KENDİ iki kaydı artık Linux ISR'inin yazdığı gibi yazılıyor — her posta okumasından sonra `tosbmailbox` (0x18004040) ← SMB_INT_ACK=2 (brcmf_sdio_hostmail) ve `intstatus` (0x18004020) ← okunan & 0x200000f0 write-1-to-clear (brcmf_sdio_intr_rstatus); el sıkışma oturunca pencere erken kapanır. Yeni kayıt, değer, çerçeve, saat ayarı veya reset yok.
Neden bu sırada: R140 dongle'ın FWREADY'sini (+30 ms) ve host kesmesini (0x208000c0) ölçtü ama pencere salt-okunur olduğu için el sıkışma onaylanmadı ve posta kutusu DEVREADY'ye düştü; Linux aynı pencerede postayı ACK'liyor ve intstatus'ı temizliyor (R139 tel izi: 0x18004040 ← 2, 0x18004020'ye ~70 write-1-to-clear).
IMAGE_SHA=044266fbe0a4b9b616feca094abab47352bef9c6606e1a69a9e9a090dac5d765 · WIFIMBOXANSWER_PLAN ARMED=1 WHERE=EARLY_WINDOW ACK_REGISTER=0x18004040 ACK_VALUE=0x0002 INTSTATUS_MASK=0x200000f0 WRITE_ONE_TO_CLEAR=1 EARLY_EXIT=1 WRITES=2 · WIFIEARLYMBOX SAMPLES=7 CHANGES=1 LAST=0x00040008 INT_OR=0x208000c2 FWREADY_MS=25 WRITES=2 · WIFIMBOXANSWER ATTEMPTED=1 ACKS=7 INT_WRITES=2 INT_MASKED=0x200000c0 SETTLED=1 FWREADY_ACKED_MS=25 · WIFIMBOXWATCH SAMPLES=13 FWREADY_SEEN=0 LAST=0x00040002 · WIFITRIALEND TRIALS_RUN=0/11 · WIFIFAIL HOST_CARD_INT=true SDHCI_INT_SIGNAL_ENABLE=0 READ_FAILURES=5 · WIFISCAN_RESULT STATUS=ERROR F1 Read32 0x18004020 error_status=0x0020
attempt-r141-mailbox-answer-uart-capture (tek boot, WHOLE BOOT, 52.965 bayt)
Kapattığı: Cevabın kendisini KAPATIR: posta ACK'i ve intstatus temizliği hatta çıkıyor ve el sıkışma oturuyor (SETTLED=1). El sıkışmanın kalıcılığını getirmez: dongle protokol fazında DEVREADY'ye düşüyor. Ayrıca veri hattı çakışmasını doğrudan gösterir: kart DAT1'i sürüyor (HOST_CARD_INT=true), biz bu kesmeyi servis etmiyoruz (SDHCI_INT_SIGNAL_ENABLE=0) ve 4 baytlık CMD53 okumaları CRC ile düşüyor.
Risk: Düşük gerçekleşti: pencerenin kendi iki kaydı yazıldı; yeni kayıt, değer, çerçeve veya reset yok.
Değişiklik / kapsam: Tek değişken: CCCR `INT_ENABLE` (F0 0x04) çiftinin master kesme biti. R124'ten beri Linux'un çifti yazılıyordu (0x03 → 0x07); bu imajda aynı iki yazma master biti temiz yapar (0x02 → 0x06). Kayıt, yazma şekli, fonksiyon bitleri (F1/F2), çerçeve, saat, reset ve komutlar donuk.
Neden bu sırada: R141 arıza makbuzu kartın DAT1'i sürdüğünü (HOST_CARD_INT=true) ve bu kesmenin servis edilmediğini (SDHCI_INT_SIGNAL_ENABLE=0) gösterdi; izin bu çiftten geliyordu.
IMAGE_SHA=6de90c05876cf2fd28fa01781c53e96cecb2fde5392407cb10a31c7cee4edc11 · WIFIINTEN_PLAN ARMED=1 REGISTER=0x04 W1=0x02 W2=0x06 MASTER_BIT=0 · WIFIEN W1=Some(2) W2=Some(6) READBACK=Some(6) · WIFIFRAMECOUNT HOST_CARD_INT=false,true,true READ_FAILURES=0,5 · WIFITRIALEND TRIALS_RUN=2/11 REPLIED=0 · WIFISCAN_RESULT F1 Read32 0x18004020 veri CRC
attempt-r142-int-enable-off-uart-capture (tek boot, WHOLE BOOT, 60.507 bayt)
Kapattığı: CCCR fonksiyon/master bitlerinin bu silikonda DAT1 hattını kapatmadığını KAPATIR. Koşu biraz ilerledi (TRIALS_RUN=2) ve tanığın dinamik olduğunu gösterdi. Sıradaki aday R143: SDIO çekirdeği host kesme maskesi.
Risk: Düşük gerçekleşti: aynı iki yazmanın tek biti değişti.
Değişiklik / kapsam: Tek değişken: SDIO çekirdeği host kesme maskesine yazılan değer (`0x18004024`): Linux'un `0x200000f0` değeri yerine `0x00000000`. Yoklamalı tasarım `intstatus`ı doğrudan okuduğu için hat gerekmez; maske yalnızca sürekli çekili DAT1 üretiyordu.
Neden bu sırada: R142 CCCR master bitini temizledi ve kart DAT1'i yine sürdü; bu sürücünün yazdığı tek diğer kesme etkinleştirmesi hostintmask'ti (R121 farkı).
IMAGE_SHA=79e05167ce0bf84fbc8d2fdaa2b207f1c08a9f6e6ecc31506be2b91127d2eb80 · WIFIHOSTINTMASK_PLAN ARMED=1 REGISTER=0x18004024 VALUE=0x00000000 LINUX_VALUE=0x200000f0 · WIFIFAIL hostintmask_written: Some(0) · WIFIFRAMECOUNT HOST_CARD_INT=true ×4 · WIFITRIALEND TRIALS_RUN=3/11 REPLIED=0 · WIFIMBOXWATCH SAMPLES=62 FWREADY_SEEN=0 LAST=0x00040002 · WIFIREAD_RECOVERY PRIMARY_ERR=0x0020 APPLIED=1 RECOVERY_OK=1 POST_VALUE=Some(0)
attempt-r143-hostintmask-off-uart-capture (tek boot, WHOLE BOOT, 66.321 bayt)
Kapattığı: İki kesme-etkinleştirme hipotezini (CCCR ve SDIO çekirdeği maskesi) KAPATIR; DAT1'in dongle posta donanımından sürüldüğünü ve tanığın dinamik olduğunu gösterir. Kalan tek ölçülü kusur aralıklı veri hattı CRC'si; kurtarma yolu çalışıyor ama yoklama döngüsüne bağlı değil — R144'ün tek değişkeni bu.
Risk: Düşük gerçekleşti: tek bir yazma değeri değişti (Linux'a benzeyen değer kaldırıldı, gerekçesi makbuzda).
Değişiklik / kapsam: Tek değişken: yoklamadaki `Read32 0x18004020` hatası artık turu düşürmüyor. Taşıma katmanının zaten yaptığı sınırlı kurtarmadan (SDHCI reset + tek okuma; WIFIREAD_RECOVERY RECOVERY_OK=1 POST_READ_OK=1 POST_VALUE=Some(0)) sonra okuma BİR KEZ yinelenir; ikinci hata yine fatal. Yeni kayıt, değer, çerçeve, saat ayarı veya reset yok; özellik kapalıyken R143 davranışı birebir korunur.
Neden bu sırada: R141/R142/R143 koşularının üçü de aynı yerde (F1 Read32 0x18004020 veri CRC'si) kapandı ve kurtarma yolunun hatayı temizleyebildiği makbuzla kanıtlıydı; eksik olan sonucu kullanmaktı.
IMAGE_SHA=81323546eef41f6eff9437e597e5307dad8e8c547988675ef7941486dc09a2f3 · WIFIPOLLRETRY_PLAN ARMED=1 REGISTER=0x18004020 MAX_RETRY=1 SECOND_FAILURE_FATAL=1 · WIFIPOLLRETRY RETRIES=0 RETRY_OK=0 RETRY_FAILED=0 · WIFIFAIL frame_ind_seen=1 host_int_seen=1 interrupt_status_or=192(0xc0) fifo_reads=0 · WIFITRIAL_RESULT TRIAL=0 FRAME_IND=1 HOST_INT=1 CORE_OR=0x000000c0 · WIFISCAN_RESULT ERROR=ReadFifo fn=2 addr=0x8000 transfer_complete=false bytes_read=64 error_status=0x20 timeout_transfer=true · WIFIMBOXANSWER SETTLED=1 FWREADY_ACKED_MS=25
attempt-r144-poll-retry-uart-capture-repeat-01 (2. boot; 1. boot non-arrival, 52.910 bayt)
Kapattığı: Yoklama hatasının ölçümü bloke etmesini KAPATIR: koşu artık F2 çerçeve yoluna ulaşıyor ve dongle'ın host kesmesi ilk kez görülüyor (0xc0). F2 okumasının kendisini kapatmaz: yeni duvar orada. Sıradaki adım R145 — aynı yeniden deneme kuralını F2 FIFO okumasına uygulamak.
Risk: Düşük gerçekleşti: yalnızca hata yolu değişti; başarılı okuma davranışı ve tüm değerler aynı kaldı.
Değişiklik / kapsam: Tek değişken: R144'ün tek-yeniden-deneme kuralı F2 FIFO okumalarına da uygulandı (64 baytlık başlık okuması ve gerekiyorsa devamı): taşıma katmanının sınırlı kurtarmasından sonra okuma BİR KEZ yinelenir, ikinci hata fatal kalır. Okuma geometrisi, çerçeve baytları, saat ve resetler donuk.
Neden bu sırada: R144 koşusu dongle'ın kesmesini ilk kez gördü ve F2 okumasında düştü (ReadFifo fn=2 addr=0x8000, bytes_read=64, error_status=0x20, timeout_transfer=true).
IMAGE_SHA=167cb2334c20a188c9af717f19c96f3e3b5d235ad049dc7e48f2375f8d163739 · WIFIFIFORETRY_PLAN ARMED=1 FUNCTION=2 ADDRESS=0x8000 MAX_RETRY=1 · boot1: WIFIPOLLRETRY RETRIES=1 RETRY_FAILED=1, WIFITRIALEND TRIALS_RUN=1 · boot2 (repeat-01): WIFIFIFORETRY RETRIES=0 FIFO_READS=0, WIFITRIALEND TRIALS_RUN=8/11 REPLIED=0, her denemede CORE_OR=0x00000000, WIFIMBOXWATCH SAMPLES=158 FWREADY_SEEN=0 LAST=0x00040002, WIFIRECOVER FIFO_OK=1 LENGTH=Some(0) ×9
attempt-r145-fifo-retry-uart-capture (1. boot) + -repeat-01 (2. boot, 100.443 bayt)
Kapattığı: F2 okuma yolunun koşuyu düşürmesini KAPATIR: taşıma 8 denemeyi taşıyor ve kurtarma okumaları bayrak takılmadığını doğruluyor. Dongle'ın susmasını kapatmaz: posta kutusu DEVREADY'de kalıyor ve kontrol çerçeveleri cevapsız. Sıradaki adım R146 — R140'ın ölçülmüş tetikleyicisini koşullu yinelemek.
Risk: Düşük gerçekleşti: yalnızca hata yolu; başarılı okuma davranışı ve tüm değerler aynı kaldı.
Değişiklik / kapsam: Tek değişiklik: SALT-OKUNUR tanık. Koşunun en sonunda dongle'ın yayınladığı SDPCM paylaşım alanı okunur (Linux `brcmf_sdio_readshared`: RAM tepesi-4'teki işaretçi, sonra yapının ilk 12 sözcüğü); ChipCommon chipid okuma öncesi/sonrası nöbetçi olarak örneklenir. Hiçbir şey yazılmaz.
Neden bu sırada: R145 taşımanın 8 denemeyi taşıdığını ama dongle'ın sustuğunu gösterdi; eksik bilgi dongle'ın kendi durumuydu. Linux bu bilgiyi tam olarak bu yapıdan okur.
IMAGE_SHA=6b7e0c2116e8c6568b9f30b54f4451c125b58ca066141ec09bac8f2da0314b4e · WIFISHARED SENT_B_OK=1 SENT_B=0x15264345 SENT_A_OK=1 SENT_A=0x15264345 · PTR_ADDR=0x0025fffc PTR=0x00201cc0 PTR_PLAUSIBLE=1 STRUCT_OK=1 · W0_FLAGS=0x00000001 W1_TRAP=0x0 W2=0x0 W3=0x0 W4=0x0 W5_CONSOLE=0x0025debc W6_MSGTRACE=0x0 W7=0xb677b91b W8=0x47424544 W9=0x1 W10=0xb677b91b W11=0x35342e37 WRITES=0 · WIFITRIALEND TRIALS_RUN=3/11 REPLIED=0 · WIFIMBOXWATCH SAMPLES=54 FWREADY_SEEN=0 LAST=0x00040002
attempt-r146-shared-witness-uart-capture (tek boot, WHOLE BOOT, 67.678 bayt)
Kapattığı: "Firmware yürüyor mu, çöktü mü?" sorusunu KAPATIR: firmware canlı, sağlıklı (ASSERT/TRAP/FAIL yok), paylaşım alanını ve konsol adresini yayınlamış, kimliği bizim blobumuzla aynı. Kontrol çerçevesinin cevapsızlığını kapatmaz; ama artık firmware'in kendi konsol metni elimizde — sıradaki adım R147: o konsolu okumak.
Risk: Yok denecek kadar düşük: WRITES=0; okuma koşunun sonuna konuldu ve nöbetçiyle doğrulandı (R97 kararma uyarısı).
Değişiklik / kapsam: Tek değişiklik: SALT-OKUNUR. R146'nın bulduğu konsol adresinden (W5_CONSOLE) 16 başlık sözcüğü, başlıktaki ilk hizalı RAM işaretçisinden 128 bayt (düzen varsayılmadan) ve konsol adresinin kendisinden 128 bayt okunur; ASCII olarak basılır. Yazma yok.
Neden bu sırada: R146 firmware'in sağlıklı olduğunu ve konsol adresini yayınladığını gösterdi; eksik bilgi firmware'in ne yazdığıydı.
IMAGE_SHA=9a51d4a3b407a8272bc2a03a73218bf0f6c3fab871d00a6c28c4300ab7e0b147 · WIFISHAREDCONSOLE CONSOLE_ADDR=0x0025debc HEADER_OK=1 BUF_PTR=0x0025dab4 BUF_OK=1 PRINTABLE=124 WRITES=0 · HEADER: 0x00000000 0x00000000 0x0025dab4 0x00000400 0x00000177 0x00000177 0x00000001 · TEXT: '1024..000000.061 wl0: wlc_channels_commit: no valid channel for "#n" nbands 2 bandlocked 0..000000.062 wl0: Broadcom BCM4345 80'
attempt-r147-console-witness-uart-capture-repeat-01 (2. boot; 1. boot non-arrival, 55.257 bayt)
Kapattığı: Konsolun okunabildiğini ve firmware log biçiminin/yapısının tutarlı olduğunu KAPATIR. Tam logu getirmez: 367 baytın yalnız ilk 128'i okundu. Sıradaki adım R148 — tam log.
Risk: Yok: salt-okunur; okuma koşunun sonunda ve nöbetçiyle (SENT_B_OK=0 not edildi).
Değişiklik / kapsam: Tek değişiklik: SALT-OKUNUR. Konsol başlığındaki ÖLÇÜLEN düzenle (W2 tampon, W3 boy, W4 indeks) TAM log tamponu okunur (≤1024 bayt) ve tüm yazdırılabilir metin basılır; nöbetçi konsol okumasından önce 8 kez yinelenir (R147 SENT_B_OK=0 kaydı). Yazma yok.
Neden bu sırada: R147 ilk 128 baytı okudu ve firmware'in wl0 satırlarını gösterdi; tamponda 367 bayt yazılıydı ve kalan satırlar çerçevelerimize dair olabilirdi.
IMAGE_SHA=f5c772b4892b8da5060463a62786f0a1bcad397b7ecb552c22f95e602a108e69 · WIFISHAREDCONSOLE_FULL SIZE=1024 IDX=527 READ=1024 PRINTABLE=991 SENT_RETRIES=0 WRITES=0 · LOG: '000002.919 sdpcmd_dpc: Enable' … '000006.022 sdpcmd_dpc: Disable' + 'sdpcmd_tx: device disabled' + 'sdpcmd_sendheader: tx submit failed!!' + 'sdpcmd_dpc: Enable' · 'wl0: wlc_stf_txcore_shmem_write: No clock' · 'wlc_channels_commit: no valid channel for "#n"' · 'BCM4345 … 7.45.265 (28bca26 CY)' · WIFITRIALEND TRIALS_RUN=1/11 REPLIED=0
attempt-r148-console-full-uart-capture (tek boot, WHOLE BOOT, 60.174 bayt)
Kapattığı: "Dongle neden cevap vermiyor?" sorusunu KAPATIR: firmware'in kendi logu, çerçevemizin cihaz devre dışıyken gönderildiğini ve düştüğünü yazıyor. Ayrıca iki iç eksikliği bildiriyor: PHY/TX çekirdeğine saat yok ve geçerli kanal yok. Sıradaki adım R149 — Linux'un FORCE_HT değeri (0xd2).
Risk: Yok: salt-okunur (WRITES=0), nöbetçi temiz.
Değişiklik / kapsam: Tek değişken: HT beklemesinden sonra `CHIPCLKCSR`'ye Linux'un CR4 bırakılışı sonrası yazdığı `saveclk | FORCE_HT` değeri (0xd0 → 0xd2). Kayıt, konum (HT isteğinden sonra, host-hazır yazmasından önce) ve diğer her şey donuk.
Neden bu sırada: R148'in tam konsol logu firmware'in 'wl0: wlc_stf_txcore_shmem_write: No clock' yazdığını ve SDPCM veri yolunun kapanıp çerçevemizin 'device disabled' durumunda düştüğünü gösterdi; Linux'un aynı noktada yazdığı değer R139 izinde 0xd2.
IMAGE_SHA=3e348bd06eaa86223c7df9470e531a45f1f803bb762c57b8d7705174cab46d27 · WIFIFORCEHT ATTEMPTED=1 BEFORE=0xd0 WROTE=0xd2 WRITE_OK=1 AFTER=0xd2 · CR4START HT_CSR_FIN=0xd2 · WIFISHAREDCONSOLE_FULL SIZE=1024 IDX=375 READ=1024 PRINTABLE=992 · LOG: '000002.951 sdpcmd_dpc: Enable' … 'wl0: wlc_stf_txcore_shmem_write: No clock' (AYNEN) · WIFITRIALEND TRIALS_RUN=0/11 REPLIED=0
attempt-r149-force-ht-uart-capture (tek boot, WHOLE BOOT, 55.407 bayt)
Kapattığı: FORCE_HT'in firmware'in iç saat şikâyetini gidermediğini KAPATIR (ama veri yolu bu boot'ta kapanmadı). Sıradaki adım R150: D11/PHY çekirdeğini reset'te tutmayı bırakmak — 'No clock' satırının en doğrudan açıklaması.
Risk: Düşük gerçekleşti: tek bit; Linux'un ölçülmüş değeri yazıldı.
Değişiklik / kapsam: Tek değişken: D11 (PHY/TX) çekirdeğinin reset'i, ioctl 0x07 yazıldıktan sonra kaldırılır (`BCMA_RESET_CTL ← 0`); reset aynı şekilde assert edilip doğrulanır. Linux'un R139 tel izinde D11 için hiç reset-ctl yazması yok.
Neden bu sırada: Firmware kendi logunda 'TX çekirdeği shmem'e yazamıyorum: saat yok' diyordu; reset'te tutulan çekirdeğin saati olmaz ve bu, firmware'in şikâyetiyle birebir örtüşen tek bizim-taraflı farktı.
IMAGE_SHA=7889fea1c1f8919182fcb96c0abbde04fdca7557ccfe10e391b65e8b406f541d · WIFID11RELEASE ATTEMPTED=1 RST_BEFORE=0x00000001 WROTE=0x00000000 RST_AFTER=0x00000000 RELEASED=1 · WIFISHAREDCONSOLE_FULLTEXT: 'No clock' satırı YOK · kalıp: 'sdpcmd_dpc: Disable' + 'sdpcmd_sendheader: tx submit failed!!' ×4 (6.082/9.048/12.014/14.979) · WIFITRIALEND TRIALS_RUN=4/11 REPLIED=0
attempt-r150-d11-release-uart-capture (tek boot, WHOLE BOOT, 76.580 bayt)
Kapattığı: Firmware'in çekirdek-saati eksikliğini KAPATIR: D11 reset'te tutulduğu için PHY/TX saati yokmuş, kaldırılınca 'No clock' kayboldu. Cevabı getirmez: veri yolu ~2,97 s'de bir kapanıyor ve çerçevemiz o pencerelerde gönderiliyor. Sıradaki adım R151 — iki zaman çizgisini hizalamak.
Risk: Orta-düşük gerçekleşti: D11 dizisine tek yazma eklendi, assert+doğrulama korundu ve sonuç ölçüldü.
Değişiklik / kapsam: Ölçüm revizyonu: CR4 bırakılışı kaydedilir ve kritik host olayları (deneme başlangıcı/sonucu, kurtarma, konsol okuması) o andan itibaren ms ile damgalanır. Davranış değişmez.
Neden bu sırada: Firmware logu kendi damgalarını taşıyor, host tarafı damgasızdı; Disable'ın tetikleyicisi ölçülemiyordu.
IMAGE_SHA=b9b2560f26c6e1208b99a0de2f24c687822a5a2074ac0ef59d266fc2de7d2b27 · WIFITIMELINE T0_MS=2018624513 (ham sayac) · bütün T_MS=0 · konsolda 'No clock' VAR, 'tx submit failed' 0 kez · WIFITRIALEND TRIALS_RUN=0? (REPLIED=0)
attempt-r151-host-timeline-uart-capture (tek boot, WHOLE BOOT, 55.720 bayt)
Kapattığı: Altyapının kurulduğunu gösterir, ölçümü KAPATMAZ: ms kaynağı frekansı ilk çağrıda bulamadığı için T0 ham sayac oldu ve hizalama okunamadı. Düzeltme R152.
Risk: Yok: yalnızca damga; davranış aynı.
Değişiklik / kapsam: Ölçüm revizyonu + düzeltme: `host_now_ms()` artık frekansı kendisi kaydettirir (`freq_cached()` makul değilse `timer::init()`), böylece T_MS alanları gerçek ms olur. Davranış, değerler, çerçeveler ve resetler aynı.
Neden bu sırada: R151'de ölçüm altyapısı kuruldu ama T0 ham sayac olduğu için bütün damgalar 0 çıktı; hizalama yapılamadı.
IMAGE_SHA=0d6349ce99ca3f35fb0ecbae3c774fb5aa7f0f88107cc07194e3e5ec42b4d7df · WIFITIMELINE T0_MS=196494 · TRIAL T_MS=5702/8686/11652/14619/17586 · RESULT T_MS=5752/8736/11703/14669/17636 · RECOVER T_MS=6101/9068/12035/15001/17968 · konsol: Disable+tx submit failed ×5 (firmware t=6.095/9.062/12.029/14.996/17.963 s) · fark SABİT ~326 ms · konsol okuması T_MS=35503 · WIFITRIALEND TRIALS_RUN=5/11 REPLIED=0
attempt-r152-timeline-fix-uart-capture (tek boot, WHOLE BOOT, 82.550 bayt)
Kapattığı: Veri yolunu neyin kapattığını KAPATIR: bizim kontrol çerçevemiz. Dongle çerçeveyi alıyor, sonra cihaz devre dışı kalıyor ve `sendheader` düşüyor. Cevaplanmayı getirmez: REPLIED=0. Sıradaki adım R153 — R136'da ölçülen tek çerçeve farkı: seq 0xFF vs Linux 0x02.
Risk: Yok: yalnızca ms kaynağı düzeltildi; davranış ve değerler aynı.
Değişiklik / kapsam: Tek değişken: oturumun başlangıç SDPCM `tx_sequence` değeri 255 → 0. İlk kontrol çerçevesi böylece seq=0 taşır; artış kuralı (0,1,2…) ve çerçevenin diğer bütün baytları, glom geometrisi, BCDC dcmd (20. bayt), kayıtlar, saatler ve resetler donuk.
Neden bu sırada: R152'nin hizalı zaman çizgisi dongle'ın bizim çerçevemizi alıp veri yolunu kapattığını gösterdi; R136 mühründe kalan tek ölçülü çerçeve farkı seq baytıydı (Linux 0x02, bizde 0xFF).
IMAGE_SHA=c8a51ce7203b897e56b92e3b7ee0ddd04926da7e188152fcbd2ef83c7ee80b74 · WIFISEQ_PLAN ARMED=1 FIRST_SEQ=0 PREVIOUS=0xFF LINUX_MEASURED=0x02 · TRIAL=0 SEQ=0 REPLIED=0 T_MS=5765 · TRIAL=1 SEQ=1 REPLIED=0 T_MS=7098 · konsol: Disable + tx submit failed!! (t=6.106 s) · WIFITRIALEND TRIALS_RUN=1/11 REPLIED=0
attempt-r153-seq-zero-uart-capture-repeat-01 (2. boot; 1. boot non-arrival, 71.834 bayt)
Kapattığı: Seq numaralandırmasının tetikleyici olmadığını KAPATIR (hipotez elendi). Cevabı getirmez. Kalan aday kredi/pencere sözleşmesidir (TXWIN=21 bizim varsayımımız; dongle'ın ilan ettiği pencere hiç görülmedi) — R154.
Risk: Düşük gerçekleşti: tek bayt; tel biçimi ve geometri aynı kaldı (kredi hesabı trial 0'da 22 → 21 oldu, kayda geçti).
Değişiklik / kapsam: Tek değişken: oturumun İLK kontrol çerçevesinin dcmd içeriği — bizim GET'imiz (cmd=262, id=1) yerine Linux'un mühürlü preinit çerçevesi: cmd=263, flags=0x00040002 (id=4, SET), len=20, veri `cur_etheraddr\0` + aynı kartta ölçülen 6 bayt MAC; reply kapasitesi 0. Tel biçimi (R136 glom, dat_offset=20, kuyruk dolgusu), seq=0, kayıtlar, saatler ve resetler donuk.
Neden bu sırada: R153 seq baytını eledi; geriye ilk çerçevenin içeriği kaldı. R152'nin hizalı zaman çizgisi veri yolunu kapatanın bizim çerçevemiz olduğunu göstermişti.
IMAGE_SHA=0d930016cab64c745088291621e130fccd82665f6ca9c4915eeff9b78df98024 · WIFIPREINIT USED=1 CMD=263 ID=4 SET=1 DATA_LEN=20 · WIFITRIAL_RESULT TRIAL=0 REQ_ID=4 CMD=263 FRAMELEN=56 XFER=56 BCDCLEN=20 SEQ=0 SENT=1 REPLIED=0 T_MS=5700 · konsolda 'Disable'/'tx submit failed!!' YOK · WIFISHAREDCONSOLE_FULL IDX=375 T_MS=21452
attempt-r154-preinit-first-uart-capture (1. boot, WHOLE BOOT, 56.000 bayt)
Kapattığı: İlk çerçevenin içeriğinin veri yolunu kapatma desenini durdurduğunu GÖSTERİR (ilk olumlu sinyal) ama cevabı getirmez; tek boot karar için yetmez. Sıradaki adım: aynı imajın 2. ve 3. boot'u.
Risk: Düşük gerçekleşti: yalnızca ilk çerçevenin dcmd içeriği değişti.
Değişiklik / kapsam: Ölçüm revizyonu (davranış değişmez): `WIFIREAD_RECOVERY` makbuzuna CR4 bırakılışından itibaren monoton ms damgası (`T_MS=`) eklendi; zaman çizgisi yardımcıları tüm imajlarda derlenir, sıfır noktası yalnız ilgili özellik açıkken işaretlenir. Yeni yazma, kayıt değeri, çerçeve veya reset yok.
Neden bu sırada: R152/R154 deseni bizim çerçevemizden ~326–328 ms sonra geliyor ama her boot'ta gelmiyor; SDHCI hat sıfırlaması içeren kurtarma olaylarının zamanı bilinmiyordu.
IMAGE_SHA=4f7b59a7b91eae4b7d4a14e75c91c23e3fc52c3e79f9985473c26463aa8a7abe · WIFIREAD_RECOVERY T_MS=1 APPLIED=1 (PRIMARY_ERR=0x0020) ve T_MS=0 APPLIED=0 (0x0060) · TRIAL T_MS=5740/8707/11674/14640/17326 · konsolda Disable YOK, tx submit failed 0, No clock YOK · WIFITRIALEND TRIALS_RUN=4/11 REPLIED=0
attempt-r155-recovery-timeline-uart-capture (1. boot, WHOLE BOOT, 78.172 bayt)
Kapattığı: Ölçüm altyapısını KURAR (kurtarma zamanı artık biliniyor) ve desen varyansını belgeler (R152 5, R153 1, R154-1 0, R154-2 1, R155 0). Soruyu kapatmaz: bu boot'ta Disable hiç olmadığı için hizalama yapılamadı. Sıradaki adım R156 — tekrar boot'lar.
Risk: Yok: yalnızca damga; davranış ve değerler aynı.
Değişiklik / kapsam: Yeni değişken yok (aynı R155 imajının 2. boot'u): kurtarma T_MS'leri firmware Disable damgasıyla hizalandı.
Neden bu sırada: R155'te desen görülmemişti; hizalamanın tamamlanması için desenin görüldüğü bir boot gerekiyordu.
IMAGE_SHA=4f7b59a7b91eae4b7d4a14e75c91c23e3fc52c3e79f9985473c26463aa8a7abe · WIFIREAD_RECOVERY T_MS=1 APPLIED=1 ve T_MS=0 APPLIED=0 · WIFITRIAL_RESULT TRIAL=0 T_MS=5907 REPLIED=0 · konsol: '000006.239 sdpcmd_dpc: Disable … tx submit failed!!' (No clock var) · WIFITRIALEND TRIALS_RUN=1/11 REPLIED=0 · Linux preinit sırası: GET ulp_sdioctrl (glomsuz) → SET bus:rxglom=1 (glomsuz) → SET cur_etheraddr (glomlu)
attempt-r155-recovery-timeline-uart-capture-repeat-01 (2. boot, WHOLE BOOT, 64.275 bayt)
Kapattığı: Tetikleyicinin çerçeve olduğunu KAPATIR (kurtarma yolu elendi) ve yeni bir yapısal fark ölçer: Linux glom'u ikinci çerçevede pazarlık ediyor, bizim ilk çerçevemiz ise glomlu. R157 ölçülen preinit sırasını uygular.
Risk: Yok: yeni değişken getirmedi, aynı imajın tekrar boot'u.
Değişiklik / kapsam: Tek değişken: oturumun ilk üç kontrol çerçevesi Linux'un ölçülmüş preinit sırası — (1) GET `ulp_sdioctrl` GLOMSUZ (data_offset=12, seq=0, cmd=262, id=2, len=29 + 15 bayt cevap yeri), (2) SET `bus:rxglom`=1 GLOMSUZ (seq=1, cmd=263, id=3, len=15), (3) SET `cur_etheraddr`=MAC GLOMLU (glom ext, data_offset=20, seq=2, cmd=263, id=4, len=20). Glom yalnız pazarlıktan sonra kullanılır. İlk R157 boot'unda çağrı yeri yanlıştı (istek dalının içinde) ve sıra hiç çıkmadı; çağrı artık taşıma hazır olur olmaz, yoklamanın öncesinde çalışıyor.
Neden bu sırada: R156 hizalaması deseni çerçevenin tetiklediğini gösterdi; mühürlü Linux listesi ilk iki çerçevenin glomsuz olduğunu ve glom'un ikinci çerçevede pazarlık edildiğini ölçüyor — bizim ilk çerçevemiz glomluydu.
İki boot: IMAGE sha256 fccf3ee52e94038d6f521cbf9880f8e3e91425f2c5b0bba9c9f6795f751b408d (1.) ve 3b3f3a5ae2fa736ccc79f0c03527a447653580cc1d37eaf44820d2e0e2519af0 (düzeltilmiş, 2.) · WIFIPREINITSEQ SENT=0 (her ikisi) · WIFIFAIL frames_received=1-2 frame_ind_seen=1 host_int_seen=1 interrupt_status_or=192 · WIFIFAIL_RX FRAME_LEN=12 HEX=0c00f3ff0001000c00150000 (seq=0, kanal=1, yüksüz — dongle'dan okunan İLK çerçeve) · ERR=WriteFifo F2 0x8000 T_MS=3271 · TRIALS_RUN=0/11
attempt-r157-glom-negotiation-uart-capture (74.652 bayt) · attempt-r157-glom-negotiation-uart-capture-repeat-01 (52.302 bayt)
Kapattığı: Pazarlık sırası çıkarsa (SENT=3) ve konsolda Disable/tx-submit-failed kaybolursa glom pazarlığı kapanır; sıra çıkar ama desen sürerse kalan aday kredi/pencere sözleşmesidir; koşu F2 yazma hatasıyla kapanırsa o hata bir sonraki tek değişken olur.
Risk: Düşük: üç çerçevenin biçimi ve içeriği mühürlü ölçümden bayt bazında sabitlendi; sonraki çerçeveler ve tüm değerler aynı.
Değişiklik / kapsam: Tek değişken: F2 yazması artık FIFO boşalana kadar erteleniyor — sıra `DRAIN_THEN_WRITE`, kapı `FIFO_IDLE`, kaynak R157'nin ikinci boot'undaki okuma (dongle'ın ilk çerçevesi) ve Linux'un `brcmf_sdio_bus_txdata` öncesi boşaltma sırası. Yeni yazma, kayıt değeri, çerçeve içeriği veya reset yok.
Neden bu sırada: R157'nin iki boot'u F2 yazma hatasının tekrarladığını gösterdi; ilk aday hatanın yazmadan hemen önce F2'de biriken dongle çerçevesinden kaynaklanmasıydı (okuma yapılmadan yazma denendiğinde FIFO meşgul olabilir).
IMAGE_SHA=0dc09cba370d4a28e06595a51cc061148cdfbcaca1fa18d458210e77f241efa4 · üç boot: WIFIDRAINFIRST_PLAN ARMED=1 ORDER=DRAIN_THEN_WRITE GATE=FIFO_IDLE (her üçünde) · 1. ve 2. boot RSTVEC_OK=0 (CR4 oturumu tamamlanmadı, yorumlanmadı) · 3. boot RSTVEC_OK=1 ALIAS_OK=1 RSTVEC_C53=1 RSTVEC_ERR=0x0000 · WIFITRIAL_RESULT TRIAL=0 SENT=0 REPLIED=0 FRAME_IND=1 HOST_INT=1 CORE_OR=0x000000c0 T_MS=3360 ERR=WriteFifo (F2 0x8000, present_state=0x01FF0000) · WIFIPREINITSEQ SENT=0 · WIFITRIALEND TRIALS_RUN=0/11
attempt-r158-drain-first-uart-capture (1. boot) · -repeat-01 (2. boot) · -repeat-02 (3. boot, 52.900 bayt)
Kapattığı: Hipotezi ELEDİ: boşaltma kapısı açıkken de ilk F2 yazması aynı hatayla düşüyor, yani hata F2'de bekleyen veriden gelmiyor. Koşu ayrıca hata anında denetleyicinin aktif-transfer durumunu ölçtü (present_state=0x01FF0000) ve bu R159'un adayını doğurdu.
Risk: Düşük: yalnızca yazmanın zamanlaması/kapısı değişti; çerçeve baytları ve tüm değerler aynı.
Değişiklik / kapsam: Tek değişken: glomsuz preinit çerçevelerinin F2 yazma birimi 4 baytlık hizadan Linux'un ölçtüğü 64 bayta çıkarıldı (`UNIT=64`, `PREVIOUS=ALIGN4`, kaynak R80/R136 izleri, `WRITES=3`). Çerçeve baytları, sıra, kimlikler ve tüm kayıt değerleri aynı.
Neden bu sırada: R158 boşaltmanın sorun olmadığını gösterdi; kalan geometri adayı yazma birimiydi — Linux aynı noktada 64 baytlık birimle yazıyor, biz 4 baytlık hizada kalıyorduk.
IMAGE_SHA=402bc5a783d474c49cbe567ef75f263d31329f3ddbb44edae9a98eaf3dcd8ec4 · WIFIF2UNIT_PLAN ARMED=1 UNIT=64 APPLIES=PREINIT_PLAIN_FRAMES PREVIOUS=ALIGN4 SOURCE=R80_R136_64B WRITES=3 · CR4START RSTVEC_OK=1 ALIAS_OK=1 RSTVEC_C53=1 RSTVEC_ERR=0x0000 IOCTL_TERM=0x00000001 (oturum kuruldu) · WIFIFIFORETRY FIFO_READS=3 RETRIES=0 · WIFITRIAL_RESULT TRIAL=0 SENT=0 REPLIED=0 FRAME_IND=1 HOST_INT=1 CORE_OR=0x000000c0 T_MS=3370 ERR=WriteFifo (F2 0x8000, present_state=0x01FF0000) · WIFIPREINITSEQ SENT=0 · WIFITRIALEND TRIALS_RUN=0/11
attempt-r159-f2-write-unit-uart-capture (1. boot, WHOLE BOOT, 52.947 bayt)
Kapattığı: Yazma birimi hipotezini ELEDİ: 64 baytlık birimle de ilk F2 yazması aynı hatayla ve aynı anda (T_MS≈3,37 s) düşüyor. Dört koşunun ortak paydası artık çerçeve değil, yazma anındaki denetleyici durumu: `present_state=0x01FF0000` write/read transfer active bitlerini gösteriyor. R160 bu durumu tek değişken yapar.
Risk: Düşük: yalnızca yazma birimi değişti; çerçeve içeriği, sıra ve değerler aynı.
Değişiklik / kapsam: Tek değişken: R159'un mühürlü `WIFIREAD` makbuzunun ölçtüğü sınıfın kabul kuralı — F2 yazması (a) `WriteFifo`, (b) `reason=Transfer`, (c) `ISSUED+COMMAND_COMPLETE+BUFFER_READY+TRANSFER_COMPLETE`, (d) istenen bayt sayısı tam, (e) hiç zaman aşımı ve meşgul bayrağı yok, (f) `error_status == ERR_DATA_CRC` (yalnız bit 5, başka bit yok), (g) `r5_flags & R5_ERROR_MASK == 0`, (h) pencere tam ise FATAL değil; sayılır, basılır ve devam edilir. Başka her yazma hatası fatal kaldı (`WRITE_FAULTS`). Çerçeve baytları, 64 baytlık birim, sıra, geometri ve tüm kayıtlar aynı.
Neden bu sırada: R159'un makbuzu yazmanın kart tarafından reddedilmediğini ölçtü: aktarım bitti, bayt sayısı tam, R5'te hata yok; tek şikâyet SDHCI veri CRC bayrağıydı ve `error_status == 0` kuralı bu yüzden dört koşudur sırayı birinci çerçevede öldürüyordu.
IMAGE_SHA=f0185b74794ae09164fc9ca6545ec5f8d808d522cd8be413505ec9f2dab2d599 · WIFIF2CRC_PLAN ARMED=1 RULE=CRC_ONLY_COMPLETED … SILENT_ACCEPT=0 · WIFIF2CRC ACCEPTED=1 ×3 (REQUESTED=64 BYTES=64 R5_FLAGS=0x10 R5_ERROR=0 ERR_STATUS=0x0020 TIMEOUTS=0 WINDOW_OK=1) · WIFIPREINITSEQ SENT=3 EXPECTED=3 CRC_ACCEPTED=3 WRITE_FAULTS=0 · konsolda Disable 0, tx submit failed 0; günlük `000003.092 sdpcmd_dpc: Enable` ile bitiyor · sonraki (56 baytlık kontrol) yazmada aynı sınıf: WIFIREAD BYTES_READ=56 ERROR_STATUS=0x0020 TRANSFER_COMPLETE=1, WIFITRIAL_RESULT T_MS=3475 CORE_OR=0x000000c0, WIFITRIALEND TRIALS_RUN=0/11 REPLIED=0
attempt-r160-f2-crc-accept-uart-capture (1. boot, WHOLE BOOT, 54.133 bayt)
Kapattığı: Hipotezi DOĞRULADI: preinit sırasını durduran şey kart değil, bizim tamlık kuralımızdı; sıra tamamen çıktı ve firmware veri yolunu artık kapatmıyor. Kalan duvar kuralın kapsamıdır — aynı sınıf sıradan kontrol çerçevesinin yazmasında (`send_control`) hâlâ fatal.
Risk: Düşük: yalnız kabul kararı değişti; hiçbir bayt, kayıt veya geometri değişmedi ve kabul sessiz değil (bayrak + sayaç + satır).
Değişiklik / kapsam: Tek değişken: R160'ta preinit sırası için doğrulanan kabul kuralının KAPSAMI — aynı saf kural (`crc_only_completed_write`) artık sıradan kontrol çerçevesinin F2 yazmasında da geçerli ve her kabul ayrı sayılıyor (`control_crc_accepted`). Kuralın kendisi, çerçeve baytları, 64 baytlık birim, sıra ve geometri aynı kaldı.
Neden bu sırada: R160 koşusu tam bu duvarda düşmüştü: aynı ölçülen sınıf 56 baytlık kontrol çerçevesi yazmasında geliyordu ve `send_control` onu hâlâ fatal sayıyordu.
IMAGE_SHA=5642a8bbea0fe105762a91d2ca8c018229078d0826e3b36869f67d59f64b72ce · 1. boot CR4 oturumunu tamamlamadı (RSTVEC_OK=0, yorumlanmadı) · 2. boot RSTVEC_OK=1 RSTVEC_C53=1 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=1 WRITE_FAULTS=0 · WIFIF2CRC ACCEPTED=1 ×4 (REQUESTED=64 ×3, REQUESTED=56 ×1; hepsi R5_ERROR=0 ERR_STATUS=0x0020 SILENT_ACCEPT=0) · WIFIPREINITSEQ SENT=3 CRC_ACCEPTED=3 · WIFITRIALEND TRIALS_RUN=3/11 REPLIED=0 · denemeler ControlTimeout (AGE_MS=2500) · konsol: `000003.118 Enable`, sonra her çerçevemizde `Disable` + `sdpcmd_tx: device disabled` + `sdpcmd_sendheader: tx submit failed!!` (6.303/9.287/12.267 s) · 4. denemede F1 Read32 0x18004020 düştü (PRESENT_STATE=0x01ff0206)
attempt-r161-f2-crc-scope-uart-capture (1. boot, YORUMLANMADI) · -repeat-01 (2. boot, WHOLE BOOT, 75.049 bayt)
Kapattığı: Kapsam hipotezini DOĞRULADI ve F2 yazma duvarını tamamen kapattı: taşıma 0/11'den 3/11'e ilerledi. Yeni duvar artık kart değil firmware sözleşmesi: dongle çerçevemizi alıyor ama SDPCM TX yolu `device disabled`. Ayrıca R160'ın "konsolda Disable yok" gözleminin boot varyansı olduğu bu boot'ta ölçüldü (Disable 3).
Risk: Düşük: kural aynı ve saf; yalnız kapsam genişledi, her kabul bayrağıyla basıldı ve sayıldı.
Değişiklik / kapsam: Tek değişken: preinit sırasından SONRA gelen kontrol çerçevelerinin KİMLİĞİ — dcmd id preinit'in kullandığı 2,3,4'ten sonra 5'ten devam eder ve her çerçevede artar (`CTRL_ID_FIRST_AFTER_PREINIT`); ayrıca R154'ün ilk-çerçeve geçersiz kılması, preinit sırası o çerçeveyi zaten gönderdiyse artık uygulanmaz (tekrar yok). Bayt biçimi, uzunluk, 64 baytlık birim, kabul kuralı ve kayıtlar aynı.
Neden bu sırada: R160/R161 makbuzları aynı üç isteğin iki kez gittiğini ölçüyordu (id 2,3,4 sonra 4,2,3,4 — hem tekrar hem azalan), mühürlü Linux çerçeve listesinde ise id her istekte artıyor (0x8f, 0x90, 0x91 …); dongle tam o tekrar çerçevelerde SDPCM TX'ini kapatıyordu.
IMAGE_SHA=ac24e6352d1f7a3cab592d9f3826cc55ef118c88a05f9501a5cbef025befc865 · WIFICTRLID_PLAN ARMED=1 RULE=MONOTONIC_UNIQUE FIRST_ID=5 PREINIT_IDS=2,3,4 REPEAT=0 · WIFICTRLID CONTINUED=10 · WIFITRIAL_RESULT REQ_ID=5,6,7,8,9,10,11,12,13,14 (hepsi CMD=262) SENT=1…10 REPLIED=0 T_MS=5976…32398 · WIFITRIALEND TRIALS_RUN=9/11 REPLIED=0 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=6 WRITE_FAULTS=0 · konsol: her denemede (≈2,98 s) `Disable` + `sdpcmd_tx: device disabled` + `sdpcmd_sendheader: tx submit failed!!` + `Enable` · masa: last_tx_evidence Linux'un mühürlü `SET cur_etheraddr` çerçevesiyle aynı yerleşim (HW 3800c7ff, glom 34000001/00000000, doff=20)
attempt-r162-ctrl-id-continuation-uart-capture (1. boot, WHOLE BOOT, 109.996 bayt)
Kapattığı: Kimlik hipotezini ELEDİ ama taşımayı ilerletti (3/11 → 9/11). Duvarın çerçeve kimliğinde/içeriğinde olmadığını, dongle'ın SDPCM TX kapısında olduğunu ölçtü; masa karşılaştırması çerçeve biçimini de eledi, geriye host'un kesme/posta-kutusu kablolaması kaldı.
Risk: Düşük: yalnız id alanı ve ilk-çerçeve geçersiz kılmasının koşulu değişti; hiçbir bayt düzeni, kayıt veya geometri değişmedi.
Değişiklik / kapsam: Tek değişken: yazma öncesi fonksiyon-2 yaşam döngüsü "önce SOR" olur — F2 zaten açık (`IO_ENABLE` biti) ve READY (`IO_READY` biti) ise dongle'ın SDIO cihazı kapatılmaz; R131 disable/ready-clear/enable/ready-set dizisi yalnız F2 gerçekten hazır değilse, değişmeden uygulanır. Çerçeve baytları, 64 baytlık birim, kimlik devamlılığı, kabul kuralı ve diğer tüm kayıtlar aynı.
Neden bu sırada: R162'nin mühürlü kaydı, her deneme öncesi yapılan toggle'ın dongle'ın `sdpcmd_dpc: Disable` + `sdpcmd_tx: device disabled` + `sdpcmd_sendheader: tx submit failed!!` üçlüsüyle milisaniye düzeyinde çakıştığını ölçtü (≈2,98 s periyot, tam bizim deneme kadansımız); toggle yapmayan preinit yazmalarında ise o üçlü hiç görünmüyordu.
IMAGE_SHA=afd84d4bd34a6bff2150445be13388274d2ef6d742291576bcb51a0241316fea · 2. boot NETBOOT KONTROLÜ: bootloader `Boot mode: NETWORK (02) order f1` dedi ve config.txt + DTB + **çekirdek (3.882.720 bayt)** + epoch blob’u + overlay’i Mac’ten TFTP ile çekti (`TFTP_GET` satırları, DHCP 10.42.0.1); SD kart hiç kullanılmadı. Aynı koşu netboot’un ortaya çıkardığı bağımlılığı da ölçtü: `FWREAD PART_LBA=0 VOL_OK=0` (SD boot’ta `PART_LBA=32768 VOL_OK=1`) — çekirdeğin SD okuması, kartın bootloader tarafından önceden başlatılmış olmasına sessizce bağımlıymış · WIFIF2READYFIRST_PLAN ARMED=1 RULE=VERIFY_THEN_TOGGLE · WIFIF2READYFIRST SKIPPED_THIS_TRIAL=1 ACTION=VERIFY_ONLY · WIFIF2REENABLE ATTEMPTED=1 BEFORE_ENABLE=Some(6) DISABLE_OK=0 READY_CLEAR=0 ENABLE_OK=0 READY_SET=0 (toggle hiç yapılmadı) · konsol: Disable=0 tx submit failed=0 (R162: 6 / 8) · WIFIPREINITSEQ SENT=3 CRC_ACCEPTED=3 WRITE_FAULTS=0 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=2 · WIFICTRLID CONTINUED=2 REPEAT=0 · WIFITRIAL_RESULT TRIAL=0 SENT=1 REPLIED=0 ControlTimeout; TRIAL=1'de F1 Read32 0x18004020 düştü (PRESENT_STATE=0x01ff0206) · WIFITRIALEND TRIALS_RUN=1/11 · WIFIAUTORESET ARMED=1 PETS=7 COMMANDS=0 RADIO_REGISTERS=0
attempt-r163-f2-ready-first-uart-capture (1. boot, WHOLE BOOT, 70.169 bayt)
Kapattığı: Toggle hipotezini dongle konsolunda DOĞRULADI (Disable 6→0): yazma yolu artık dongle'ın TX'ini kapatmıyor. Kalan duvar F1 okuma yoludur (INTSTATUS okuması kart meşgulken düşüyor) ve cevap hâlâ yok (`REPLIED=0`). Ayrıca hands-free otomasyonu (PM watchdog + sürekleme) ilk kez donanımda doğrulandı: ARMED=1, PETS=7, yanlış reset yok.
Risk: Düşük: yalnız toggle koşullu hale geldi; yaşam döngüsü silinmedi ve hazır değilse aynı. İmaj ayrıca radyo-dışı otomasyon bayrağı taşıyor (makbuzda RADIO_REGISTERS=0).
Değişiklik / kapsam: Altyapı (radyo değişkeni YOK): Wi-Fi payload'ı — BRCMFW.BIN, BRCMNVR.TXT, BRCMCLM.BLB — çekirdekle aynı yoldan, firmware'in `initramfs` mekanizmasıyla ağdan taşınır. Boot blob'u 32 baytlık epoch + `ASLNPAY1` konteyneridir (kayıt başına offset/uzunluk/CRC-32/SHA-256; evrensel duvar saati ABI'si değişmez). Çekirdek önce FAT yolunu dener, yalnız kullanılamıyorsa konteynerden okur; her kaydın CRC'si yeniden hesaplanır. Çerçeve, sıra, kabul kuralı ve radyo kayıtları değişmez.
Neden bu sırada: Ağ boot'unda bootloader SD karta hiç dokunmuyor: `FWREAD PART_LBA=0 VOL_OK=0 FOUND=0` ölçüldü ve firmware yüklenemediği için radyo zinciri hiç başlamadı. Soğuk-kart SD başlatması dört netboot koşusunda uçtan uca denendi (ray açık `RAIL_VCC=1 RAIL_3V3=1`, denetleyici sıfırlandı `PSTATE_A=0x1fff0000 INHIBIT_CLR=1`, saat kararlı, 74 darbe, güç döngülü tekrar `RETRIES=1`) ve kart yine CMD0'a cevap vermedi (`CMD0=0`); dört olay `evidence/rpi5/radio/boot-incidents/` altında mühürlendi. Bağımlılığı kovalamak yerine kaldırmak seçildi.
KOŞTU (netboot): `FWPAYLOAD PRESENT=1 ADDR=0x10000000 WINDOW=1048576 ENTRIES=3 VERSION=1 SOURCE=INITRAMFS` · `FWPAYLOAD FW SRC=INITRAMFS BYTES=609309 SECTORS=1190 FIRST_WORD=0xb83ef198 CRC32=0xb8b12ced SHA256=d608f866…36c3 VERIFIED=1` (SD yolundan okunanla birebir aynı imza) · `FWPAYLOAD NVRAM … VERIFIED=1` ve `CLM … VERIFIED=1` · `FWSTAGE SECTORS_DONE=1190 OK=1` · `NVRAM FOUND=1 VERIFIED=437 OK=1 FW_INTACT=1` · `CR4START RSTVEC_OK=1 RSTVEC_C53=1` · `WIFIPREINITSEQ SENT=3 CRC_ACCEPTED=3` · `WIFITRIALEND TRIALS_RUN=1/11 REPLIED=0` · `WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac))` · `WIFIAUTORESET ARMED=1`. Kart KULLANILMADI (bootloader `Boot mode: NETWORK (02)`). İmaj sha256 `d878ee04a6591eb37964d26fc49a95cdc377430eea787aeb75aeed5e1dfeae88` · `build/rpi5-wifi-scan-r164/aselsanos-rpi5-radio.img` · yayın: `PUBLISHED.txt` (kernel_sha256 aynı) · şimdiye kadarki dört netboot boot'u **varışsız** ve `evidence/rpi5/radio/boot-incidents/` altında mühürlü (hizalama panic'i, devralınan DAT inhibit, tam soğuk-başlatma tanılaması, DTB fault'u) · beklenen: `FWPAYLOAD PRESENT=1 ADDR=0x10000000 WINDOW=1048576 ENTRIES=3 SOURCE=INITRAMFS`, ardından `FWPAYLOAD FW SRC=INITRAMFS BYTES=609309 SHA256=d608f866…36c3 VERIFIED=1`, `FWPAYLOAD NVRAM SRC=INITRAMFS`, `FWPAYLOAD CLM SRC=INITRAMFS` ve `FWSTAGE … OK=1` + `NVRAM … OK=1`; sonra radyo zinciri SD boot'takiyle aynı makbuzları vermeli. SD boot'ta bu dal hiç çalışmaz.
attempt-r164-initramfs-payload-uart-capture (1. boot, NETBOOT, WHOLE BOOT)
Kapattığı: Payload ağdan yüklenip radyo zinciri başladı: firmware'in SHA-256'sı SD yolundan okunanla birebir aynı (`d608f866…36c3`), CR4 oturumu kuruldu ve süpürme SD boot ile aynı ilk-deneme davranışını verdi (`TRIALS_RUN=1`, `REPLIED=0`); ikinci deneme yeni bir adla kapandı: `Session(CommandDeadline(Mac))`. Eller serbest hat tamamlanır: çekirdek ve payload TFTP'den, reset PM watchdog/UART ile, kart hiç takılmasa bile. Başlamazsa konteyner/CRC makbuzu hangi kaydın düştüğünü adıyla söyler. R163'te ölçülen F1 okuma yolu değişkeni (INTSTATUS okuması kart meşgulken düşüyor) bu altyapı işi nedeniyle bir sonraki radyo basamağına, R165'e taşındı.
Risk: Düşük: FAT yolu önce denenir ve SD boot'ta davranış bit bit aynı kalır; konteyner yalnız FAT kullanılamadığında okunur. Taşınan beyan (SHA-256) CRC doğrulanmadan makbuza geçmez.
Değişiklik / kapsam: Tek değişken (radyo): F1 backplane Read32 ve F2 read_fifo yollarından ÖNCE sınırlı bir host-idle kapısı. Yüklem bu kartta R114/R115'te fiziksel olarak kanıtlanmış runtime_host_idle (CMD/DAT inhibit temiz VE DAT0 serbest); bekleme READ_GATE_MAX_POLLS=4096 ile sınırlı. Kapı yalnız BEKLER: hiçbir kayıt yazmaz, hiçbir komut göndermez. Kapsam okuma yollarının tamamıdır (tek ofset değil); yazma yolu, çerçeve baytları, 64 baytlık birim, geometri, kabul kuralı ve kimlik devamlılığı değişmez.
Neden bu sırada: R163 süpürmenin ikinci denemesini tam burada kapattı: WIFIREAD OP=Read32 FN=1 ADDR=0x18004020 REASON=Transfer PRESENT_STATE=0x01ff0206 (DAT_INHIBIT|DAT_LINE_ACTIVE) ve WIFITRIALEND TRIALS_RUN=1/11. Aynı koşuda pasif bekleme sınırının tamamı (POLLS=100000) harcandı ve HOST_IDLE=0 kaldı; latch'i açan şey 2 poll / 10 µs süren R116 host-only DATA reset'iydi. R164 netboot koşusu bu tabanı ölçmedi (WIFIREAD makbuzu 0, READ_FAILURES=0; iki deneme de kontrol cevabı zaman aşımı), bu yüzden R165'in hedefi R163'te ÖLÇÜLEN duvardı.
KOŞULDU ama değişken HİÇ SINANMADI (ATTEMPTED=0): iki boot da radyo zincirine varmadı. 1. boot mühürlü (evidence/rpi5/radio/attempt-r165-read-gate-uart-capture, VARİŞ YOK / YORUMLANMADI): CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=1 ADDR=0x18101408 WRITE=1 WIN_OK=0 · CR4START RSTVEC_OK=0 ALIAS_OK=0 RSTVEC_C53=0 RAM_W=0 · WIFISCAN_RESULT STATUS=UNAVAILABLE CORE_READY=0 CLM_LOADED=1 · konsol Disable=0, tx submit failed=0, REPLIED=1 satırı 0 · FWSTAGE SECTORS_DONE=1190 OK=1 ve NVRAM VERIFIED=437 OK=1 FW_INTACT=1 (mühürlü PASS 119 → 120). 2. boot (…-repeat-01, mühür bekliyor) aynı sınıfta: FWSTAGE SECTORS_DONE=1190 WORDS_V=152320 OK=1 · NVRAM WRITTEN=313 VERIFIED=437 OK=1 FW_INTACT=1 · CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=7 ADDR=0x18101800 WRITE=0 WIN_OK=1 · CR4START RSTVEC_OK=0 · WIFISCAN_RESULT STATUS=UNAVAILABLE CORE_READY=0. Varışsızlık değişkene bağlanamadı: kapı yalnız runtime WifiSdioBus okuma yollarında (read32 ve read_fifo) bekler; cr4_start serbest backplane yardımcılarını (cmd52, backplane_read32_cmd53, backplane_write32_cmd53) kullanır ve R164'ün aynı netboot yolu CR4CTRL PHASE=COMPLETE OPS=21 ile RSTVEC_OK=1 vermişti.
attempt-r165-read-gate-uart-capture (1. boot, MÜHÜRLÜ, VARİŞ YOK / YORUMLANMADI) · attempt-r165-read-gate-uart-capture-repeat-01 (2. boot, MÜHÜRLÜ, VARİŞ YOK / YORUMLANMADI, aynı sınıf; ham kayıt netboot DHCP/TFTP izini taşır) · imaj sha256 84cd5a0b878e87c8872ff17d305c970cfb80b51ea8f6915591d78841ade34a62
Kapattığı: Ölçülen: firmware/NVRAM yolu iki boot'ta da geçti ve imaj mühürlü PASS sayısını 119'dan 120'ye taşıdı; buna karşılık okuma kapısı hakkında TEK bir veri noktası üretilemedi (WIFIREADGATE satırı hiç basılmadı çünkü okuma yolu çalışmadı). Aynı kapı kodu R166 imajında overlay olarak devralındı; değişken orada da sınanmayacak, orada asıl değişken reset bütçesidir.
Risk: Ölçülen risk: bu imajın hiçbir boot'u okuma yoluna ulaşmadı. Kapı salt-okunur ve sınırlı olduğu için bir çıktı değişikliği üretemez; cr4_start yolunda bulunmadığı için de varışsızlığa bağlanamadı. Varışsızlık sınıfı daha önce mühürlenen netboot olaylarıyla aynı ailede ve tekrarla ayrıştırılacak.
Değişiklik / kapsam: Tek değişken (radyo): host-only SDHCI DATA reset'inin OCCURRENCE BUDGET'i — runtime bus ömrü boyunca 1 yerine 4 (READ_RESET_BUDGET). Diğer her R116/R119 koşulu aynen kalır: keşfedilen SDIO çekirdeğinin INTSTATUS adresi, DATA_CRC hata sınıfı (DATA_END_BIT'li ya da değil, başkası değil), geçerli CMD52x4 fallback değeri, tam 100.000 poll'lik pasif sınır, DAT0 serbest, CMD inhibit temiz, veri motoru hâlâ aktif; reset dizisi, sonrasındaki CMD52 doğrulaması ve diğer tüm hataların fatal davranışı değişmez. Yeni kayıt değeri, yeni komut, CMD53 yinelemesi yok; yazma yolu, çerçeve baytları, 64 baytlık birim, geometri, kabul kuralı ve kimlik devamlılığı aynı. R165'in okuma kapısı overlay olarak taşınır: yalnız PRESENT_STATE örnekler, hiçbir kayıt yazmaz ve komut öncesi inhibit beklemesi (aynı iki bit, 50.000 poll) onu domine ettiği için çıktıyı değiştiremez.
Neden bu sırada: R163'ün mühürlü trial 1'i duvarı adıyla veriyor: latch ilk olayda reset ile açıldı (USED_BEFORE=0 ELIGIBLE=1 APPLIED=1 CLEARED=1 RESET_POLLS=2 ELAPSED_US=10 RECOVERY_OK=1 POST_MATCH=1), latch AYNI trial içinde tekrar armlandı ve ikinci olayda bütçe yoktu (USED_BEFORE=1 ELIGIBLE=0 APPLIED=0 CLEARED=0) — sonuç WIFIREAD REASON=Transfer PRESENT_STATE=0x01ff0206 ve WIFITRIALEND TRIALS_RUN=1/11. Beklemek işe yaramıyor: aynı koşuda pasif sınırın tamamı (POLLS=100000) iki kez harcandı ve HOST_IDLE=0 kaldı. Yani duvar okuma yolu değil, resetin bus başına BİR olan politikasıydı; R165 bu ölçümü hiç tekrarlayamadı (varışsız).
KOŞULDU, DEĞİŞKEN SINANDI ve VARDI: 1. boot mühürlü VARİŞ VAR (yorumlanabilir) — evidence/rpi5/radio/attempt-r166-read-budget-4-uart-capture (boot yolu netboot, reset yolu manual). WIFIRESETBUDGET_PLAN ARMED=1 BUDGET=4 SUBJECT=SDIO_INTSTATUS ERROR_CLASS=DATA_CRC+DATA_END_BIT PREVIOUS=R116_ONE_PER_RUNTIME_BUS WRITES=0 SOURCE=attempt-r163-read-recovery · CR4START PHASE=COMPLETE ABORTED=0 RSTVEC=0xb83ef198 RSTVEC_OK=1 ALIAS_OK=1 RSTVEC_C53=1 RSTVEC_B=4 D11_RESET=1 D11_IOCTL=0x00000007 HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_FIN=0xd2 HT_REQ_MS=4 HT_REQ_AVAIL=1 WRITE_OK=1 · üç WIFIREAD_RECOVERY (OP=Read32 FN=1 ADDR=0x18004020): USED_BEFORE=0 REMAINING=4 PRIMARY_ERR=0x0060 T_MS=12888 · USED_BEFORE=1 REMAINING=3 PRIMARY_ERR=0x0020 T_MS=17961 · USED_BEFORE=2 REMAINING=2 PRIMARY_ERR=0x0020 T_MS=20121 — üçünde de ELIGIBLE=1 APPLIED=1 CLEARED=1 RESET_POLLS=2 ELAPSED_US=10 CONFIG_SAME=1 RECOVERY_OK=1 POST_READ_OK=1 POST_MATCH=1 POST_HOST_IDLE=1 ACCEPTED=1 · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=5 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)) · konsol Disable=0 tx submit failed=0 No clock=1. Ön-kayıtlı karar tablosunun ilk satırı gerçekleşti: TRIALS_RUN>1 (R163'te 1 idi) ve latch başına bir kurtarma → bütçe duvardı — ve tükenmedi (BUDGET=4, kullanılan 3) — süpürme artık sıradaki duvarla sınırlı; o duvarı makbuz adlandırıyor: oturum yeniden armlanamadı (STOP=NOT_REARMABLE) ve cevap gelmedi (REPLIED=0, CommandDeadline(Mac)). SD taşıması aynı gün ölçülerek elendi: bootloader kartı iki denemede de açamadı (Failed to open device: 'sdcard', cmd 81a0010 status 0) — kayıt boot-incidents/2026-09-14-r166-sd-not-detected; koşu netboot ile alındı ve R165 de netboot olduğu için tek değişken korundu.
build/rpi5-wifi-scan-r166/aselsanos-rpi5-radio.img sha256 89cd08281922114297df808f7d26238300aa6d5578c98e9408f3f1c1f6d8bc1d · PROFILE.txt sha256 fcd0a03e9a7f4cbfdcedcdcd8cd403e5308558cfa99c54b8db35886c7272df0e · attempt-r166-read-budget-4-uart-capture (1. boot, MÜHÜRLÜ, VARİŞ VAR / yorumlanabilir)
Kapattığı: Ölçülen: reset bütçesini 1'den 4'e çıkarmak duvarı kaldırdı — aynı okuma adresinde (0x18004020) latch üç kez üst üste kurtarıldı (USED_BEFORE 0→1→2) ve üç kurtarma da kabul edildi (ACCEPTED=1 POST_MATCH=1 RECOVERY_OK=1); süpürme R163'ün 1 trialından 5 triale ilerledi. Duvarın yeni yeri okuma latch'i değil: oturum yeniden armlanamıyor ve komut cevabı gelmiyor. R167'nin tek değişkeni bu ölçülen duvarı adlandıracak.
Risk: Ölçülen: koşu varışlı ve değişken sınandı; Wi-Fi PASS iddiası yok (REPLIED=0, WIFISCAN_RESULT STATUS=ERROR). Bütçe hâlâ SINIRLI (4) ve her olay adıyla makbuza giriyor; reset host-only ve yapılandırmayı koruyor (CONFIG_SAME=1, 2 poll / 10 µs). Açık kalan ölçüm: boot yolu netboot olduğu için SD taşıması bu koşuda sınanmadı (ayrı olay kaydı var) ve tek boot alındı — imaj başına 3 boot hakkının 2'si kullanılmadı.
Değişiklik / kapsam: Tek değişken (radyo): R127'nin State::Failed'dan TEK sınırlı çıkışının kabul ettiği hata sınıfı — ControlTimeout → ControlTimeout + CommandDeadline. Gerekçe ölçülmüştür: R166'nın mühürlü makbuzu bütçenin tükenmediğini (BUDGET=4, USED_BEFORE 0→1→2, üç kurtarma da ACCEPTED=1) ve süpürmenin 5 triale ilerlediğini gösterdi, ama koşu STOP=NOT_REARMABLE ile kapandı; oturum katmanının adım zaman aşımı (Error::CommandDeadline(Step)) transport poll'undan ÖNCE döndüğü için R127 uygunluğu hiç kurulmadı. Kredi kuralı, silahlı süpürme koşulu, profil sınırı, prereq_stop adları, reset bütçesi (4, R166'nın ölçülmüş tabanı), okuma kapısı, yazma yolu, çerçeve biçimi ve diğer tüm hata sınıflarının fatal davranışı aynen kalır. Kabul, feature kapılı bir sabitle (REARM_ADMITS_COMMAND_DEADLINE) beslenen runtime bir değerdir: böylece R127 varsayılanı aynı ağaçtan yeniden kurulabilir ve MockBus testleri hem kabul hem ret yolunu koşar.
Neden bu sırada: Ölçülen ilerleme sayaçlıdır: R163 TRIALS_RUN=1/11 (bütçe yok) → R166 TRIALS_RUN=5/11 (bütçe 4). Aynı okuma adresinde (0x18004020) üç kurtarma da kabul edildi. Süpürmeyi artık durduran şey reset politikası değil; bunu R166 profilinin ön-kayıtlı karar tablosu zaten öngörmüştü: 'TRIALS_RUN>1 → bütçe duvardı, süpürme artık sıradaki duvarla sınırlı'. Sıradaki duvarın adı makbuzda: oturum yeniden armlanamıyor ve cevap gelmiyor.
KOŞULDU, DEĞİŞKEN SINANDI ve VARDI: 1. boot mühürlü VARİŞ VAR (yorumlanabilir) — evidence/rpi5/radio/attempt-r167-rearm-deadline-uart-capture (boot yolu netboot, reset yolu manual). WIFIREARM_PLAN ARMED=1 ADMITTED=ControlTimeout+CommandDeadline PREVIOUS=R127_CONTROL_TIMEOUT_ONLY SUBJECT=SESSION_STEP_DEADLINE WRITES=0 SOURCE=attempt-r166-not-rearmable · altı WIFIREARM satırı: ERROR_CLASS=ControlTimeout ADMITTED=1 (×4) · ERROR_CLASS=CommandDeadline STEP=Mac ADMITTED=1 (R166'da tam bu satır STOP=NOT_REARMABLE idi) · ERROR_CLASS=Other ADMITTED=0 STOP=NOT_REARMABLE (fatal sınıf korunuyor) · dört WIFIREAD_RECOVERY (ADDR=0x18004020): USED_BEFORE=0/1/2/3 REMAINING=4/3/2/1 PRIMARY_ERR=0x0060/0x0020/0x0020/0x0020 T_MS=4104/7220/10554/16020; dördü de ELIGIBLE=1 APPLIED=1 CLEARED=1 RESET_POLLS=2 ELAPSED_US=10 CONFIG_SAME=1 RECOVERY_OK=1 POST_READ_OK=1 POST_MATCH=1 POST_HOST_IDLE=1 ACCEPTED=1 · beşinci olayda USED_BEFORE=4 REMAINING=0 ELIGIBLE=0 APPLIED=0 CLEARED=0 (bütçe tükendi) · WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=5 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(Transport(Io(BusError { op: Read32, address: 0x18004020, reason: Transfer, status: 0x207f01, present_state: 0x01ff0206, Cmd53Read { issued: true, command_complete: false, buffer_ready: false, bytes_read: 0, r5_flags: 16, error_status: 32 } }))) · CR4START PHASE=COMPLETE ABORTED=0 RSTVEC_OK=1 · konsol Disable=0 tx submit failed=0 No clock=1. Ölçülen sonuç: R166'nın öldüğü sınıf kabul edildi (adım zaman aşımı artık tek sınırlı çıkıştan geçebiliyor) ve aynı okuma adresinde dört reset üst üste harcandı; duvar bütçeye taşındı ve son hata artık bir adım zaman aşımı değil, taşıma hatasıdır. Koşu, netboot ön koşulunun link ile çakışması yüzünden radio-auto-run.sh yerine manuel orkestre edildi (arm → temizlik kanıtı → güç → onaylı mühür aracı); sapma boot-incidents/2026-09-14-netboot-precondition-link-conflict altında kayıtlıdır.build/rpi5-wifi-scan-r167/aselsanos-rpi5-radio.img sha256 d330628077abe249f5043703d3096fd578b99d83aa99e8602474d0eba34e6929 · PROFILE.txt sha256 305df4ba90a6104ab5557c9d4c4a7afb5185bc708ba9f9d75ed0b8db6ac823ff · attempt-r167-rearm-deadline-uart-capture (1. boot, MÜHÜRLÜ, VARİŞ VAR / yorumlanabilir)
Kapattığı: Ölçülen: kabul edilen sınıf genişletmesi hedefini tuttu — R166'nın STOP=NOT_REARMABLE ile kapandığı CommandDeadline olayı R167'de ADMITTED=1 ile geçti ve latch aynı adreste dört kez kurtarıldı (R166'da üç). Bütçe 4/4 tükendi; sıradaki duvar artık reset sayısı değil, latch'in her alışverişte yeniden armlanma nedenidir.
Risk: Ölçülen: koşu varışlı ve değişken sınandı; Wi-Fi PASS iddiası yok (REPLIED=0, STATUS=ERROR). Bütçe sınırlı kaldı (4) ve artık tükendiği makbuzda adıyla görünüyor (ELIGIBLE=0 APPLIED=0); fatal sınıflar (Other → ADMITTED=0) korundu. Açık kalan ölçüm: tek boot alındı — imaj başına 3 boot hakkının 2'si kullanılmadı.
Değişiklik / kapsam: Tek değişken (radyo): her okuma-latch olayında KART-SAHİPLİĞİ ve KREDİ durumunu ölçen SALT-OKUNUR tanık — kart tarafında CCCR IO_ABORT (0x06), F2 IO_ENABLE (0x02) ve F2 IO_READY (0x03) CMD52 okumaları; host tarafında kurtarmanın zaten aldığı sınırlı host-idle örneklemi (CMD inhibit, DAT0, PRESENT_STATE) ve taşımanın SDPCM kredisi (tx_window/tx_sequence). Hiçbir şey değişmez: yeni yazma yok, yeni komut dizisi yok, reset/retry/CMD53 yinelemesi yok; tanık R116/R119 kararı HESAPLANDIKTAN SONRA koşar (R117'nin okuma matrisi gibi) ve dönen değeri ya da yüzeye çıkan hatayı değiştiremez. Yazma yolu, çerçeve baytları, 64 baytlık birim, geometri, kabul kuralı ve kimlik devamlılığı aynı kalır. Gerekçe: R167'nin karar tablosu sıradaki değişkeni 'latch NEDEN yeniden armlanıyor (kart kredisi / bekleyen veri sahipliği)' diye adlandırdı ama hangisi olduğunu ÖLÇMEDİ; deponun sırası önce tanık sonra mekanizmadır (R114/R115 → R116, R117 → R119, R146 → kullanım).
Neden bu sırada: Ölçülen ilerleme sayaçlıdır: R163 TRIALS_RUN=1/11 (bütçe yok) → R166 TRIALS_RUN=5/11 (üç kurtarma kabul) → R167 TRIALS_RUN=5/11 ama dört kurtarma kabul ve bütçe tükendi. R167'nin hedefi olan CommandDeadline sınıfı kabul edildi; son hata artık bir adım zaman aşımı değil, taşıma hatasıdır (Session(Transport(Io(BusError { op: Read32, address: 0x18004020, reason: Transfer, Cmd53Read { issued: true, command_complete: false, bytes_read: 0, r5_flags: 16, error_status: 32 } }))).
KOŞULDU ve VARDI, ama DEĞİŞKENİ İCRA EDİLMEDİ: 1. boot mühürlü VARİŞ VAR (yorumlanabilir) — evidence/rpi5/radio/attempt-r168-read-owner-uart-capture (netboot/manual; link, güç verildiğinde geldi ve betik `link hazır: en7=10.42.0.1` bastı). Kimlik: ASELSAN/CLOCK … EPOCH=1789383047 (R168 TFTP yayınının epoch'u) ve yalnız bu derlemede bulunan ASELSAN/WIFIREADOWNER_PLAN ARMED=1 SUBJECT=CARD_OWNERSHIP REGISTERS=CCCR_02+CCCR_03+CCCR_05+CCCR_07 HOST=PSTATE+DAT0 WRITES=0 · CR4START PHASE=COMPLETE ABORTED=0 RSTVEC_OK=1 · WIFIREARM ERROR_CLASS=CommandDeadline STEP=Mac ADMITTED=1 ve ControlTimeout ADMITTED=1 (×N), hepsi STOP=RUNNING · **WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0** · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)) · konsol Disable=0 tx submit failed=0 No clock=1. Kritik ölçüm: kayıtta WIFIREAD_FALLBACK / WIFIREAD_RECOVERY / WIFIREAD_OWNER / fatal WIFIREAD satırı YOK — yalnız WIFIREADGATE ve WIFIREADOWNER_PLAN var. Yani okuma latch'i bu boot'ta hiç oluşmadı, bütçe 0/4 kaldı ve süpürme tasarlandığı gibi on bir profilin tamamını tüketti. Tanık latch olayına bağlı olduğu için sahiplik/kredi hakkında tek veri noktası üretmedi; merdiven kuralı gereği değişken SINANMADI sayılır (R126'nın 'değişken icra edilmedi' sınıfı) ve üç boot'un tamamı kullanıldı: boot 2 (…-repeat-01) VARİŞ YOK / YORUMLANMADI — CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=1 ADDR=0x18101408 WRITE=1, R165'in iki boot'uyla aynı imza — ve boot 3 (…-repeat-02) VARİŞ VAR: latch İLK KEZ oluştu ve tanık İLK KEZ veri üretti. Ölçülen tanık: ASELSAN/WIFIREAD_OWNER ATTEMPTED=1 ERROR_STATUS=0x0020 F2_ENABLE=0x06 F2_READY=0x06 INT_PENDING=0x00 BUS_IFACE=0x42 F2_IOE2=1 F2_IOR2=1 CMD_INHIBIT=0 DAT0_RELEASED=1 PSTATE_AFTER=0x01ff0000 HOST_IDLE_AFTER=1 RECOVERY_OK=1 USED_BEFORE=0 WRITES=0 — yani kart tarafı SAĞLIKLI: F2 hem etkin hem hazır, bekleyen kesme yok, komut inhibit temiz, DAT0 bırakılmış, host boşta. Karar tablosunun 2. dalı gerçekleşti: yeniden armlanmanın nedeni kart sahipliği DEĞİL. Ölçülmüş seri: R163 1/11 → R166 5/11 → R167 5/11 → R168 11/11 (boot 1 ve boot 3).
build/rpi5-wifi-scan-r168/aselsanos-rpi5-radio.img sha256 c4343fc6e9b65d74798e89564b789c7023b25e7582fa81de1243faaac0943aaa · PROFILE.txt sha256 dfb740133f032f5ce293d84fb6c1af1c21cd4ba77b86deaf9a5d058f875479ca · attempt-r168-read-owner-uart-capture (1. boot, MÜHÜRLÜ, VARİŞ VAR / yorumlanabilir; tanık icra edilmedi)
Kapattığı: Ölçülen: okuma latch'i deterministik bir duvar değil — R163 onu ilk trialda, R167 aynı adreste dört kez gördü, bu boot'ta hiç görülmedi. Latch oluşmadığı için bütçe hiç harcanmadı ve süpürme 11/11 ile kapandı; duvar reply yoluna taşındı (REPLIED=0, terminal Session(CommandDeadline(Mac))). R168'in tanığı, latch'i geri getirecek bir tekrarda veri üretecek.
Risk: Ölçülen: koşu varışlı ve imaj kimliği kanıttan doğrulandı; Wi-Fi PASS iddiası yok (REPLIED=0, STATUS=ERROR). Karıştırıcı uyarısı: R168 ile R167 arasındaki tek fark latch SONRASI çalışan opt-in tanıktır (latch öncesi yola girmez), ama tek bir boot'tan 'tanık latch'i engelledi' sonucu çıkarılamaz — kod yerleşimi/zamanlama etkisi dışlanamaz; bu yüzden yokluk boot'lar arası değişkenlik olarak yorumlandı ve tekrarla sınanmalıdır. Açık kalan ölçüm: 1 boot alındı, 2 hak duruyor.
Değişiklik / kapsam: Tek değişken (radyo): TAŞIMA KATMANI KREDİ TANIĞI — okuma latch'i/kurtarması anında SDPCM tx_window ve tx_sequence değerlerinin SALT-OKUNUR kaydı. Gerekçe ölçülmüştür: R168 boot 3'te latch ilk kez oluştu ve bus katmanı tanığı kartı SAĞLIKLI buldu (F2_IOE2=1 F2_IOR2=1 INT_PENDING=0x00 CMD_INHIBIT=0 DAT0_RELEASED=1 PSTATE_AFTER=0x01ff0000 HOST_IDLE_AFTER=1), yani yeniden armlanmanın nedeni kart sahipliği değil; kalan iki aday host veri motorunun bıraktığı durum ve kredi muhasebesidir. Kredi taşıma katmanında yaşadığı için bus katmanından görünmez; R169 onu aynı kurtarma anında salt-okunur kaydeder ve hiçbir şeyi değiştirmez (yeni yazma, reset, retry ya da CMD53 yinelemesi yok). Duvar hâlâ reply yolu: üç boot'un ikisi varışlıydı ve ikisinde de süpürme 11/11 tükendi, REPLIED=0 kaldı; üçüncü boot D11 transport abort'uyla varışsız kaldı. Basamak KOŞULDU: imaj kimliği kanıttan doğrulandı, tanık kuruldu, ama latch oluşmadığı için değişken icra edilmedi ve ölçüm tetikleyiciyi adlandırdı (R170).
Neden bu sırada: Ölçülen seri: R163 TRIALS_RUN=1/11 → R166 5/11 → R167 5/11 → R168 11/11 → R169 11/11 (iki varışlı boot). R168'de okuma latch'i hiç oluşmadı ve bütçe harcanmadı; süpürmeyi durduran şey artık profil sayısı (EXHAUSTED) ve cevapsızlıktır. R169'un iki varışlı boot'unda da aynı tablo ölçüldü (CR4 PHASE=COMPLETE, süpürme 11/11, REPLIED=0); üçüncü boot D11 transport abort'uyla varışsız kaldı ve yorumlanmadı. Yani okuma-hattı ve bütçe duvarları bu boot'larda yoktu; kalan duvar reply yoludur. Latch altı boot'ta bir kez görüldüğü için kredi sorusu ölçülemedi; bu yüzden sıradaki tek değişken örnekleme ANIDIR (R170).
KOŞULDU ve VARDI, ama DEĞİŞKENİ İCRA EDİLMEDİ: 1. boot mühürlü VARİŞ VAR (yorumlanabilir) — evidence/rpi5/radio/attempt-r169-credit-witness-uart-capture (netboot/manual; yakalama 1 baytta temiz arm edildi, hat sessizleşince gözcü kendiliğinden arm etti ve güç verilince betik link hazır: en7=10.42.0.1 bastı). Kimlik: ASELSAN/WIFIREADCREDIT_PLAN ARMED=1 SUBJECT=SDPCM_CREDIT FIELD=tx_window+tx_sequence SOURCE=TRANSPORT_CENSUS PREVIOUS=R168_WITNESS_CARD_HEALTHY WRITES=0 ve yayın epoch'u · CR4START PHASE=COMPLETE ABORTED=0 · WIFIREARM ERROR_CLASS=CommandDeadline (×2) ve ControlTimeout (×10), hepsi ADMITTED=1 · WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)). Kritik: kayıtta WIFIREAD_RECOVERY / WIFIREAD_OWNER / WIFIREAD_CREDIT satırı YOK — okuma latch'i bu boot'ta da oluşmadı, bütçe 0/4 kaldı, kredi tanığı veri üretmedi. Latch görülme sıklığı dört boot'ta bir: R167 4 kez, R168 boot 1 0, R168 boot 3 1, R169 boot 1 0. Yan not: ilk netboot denemesi TFTP'de erken sonlandı (Early terminate, kernel transferi yarıda kaldı → BOOT ERROR code 7); bootloader yeniden denedi ve ikinci denemede çekirdek yüklendi — kayıt her iki denemeyi de taşır. Boot 2 (…-repeat-01) de mühürlü ve yine latchsiz: CR4CTRL PHASE=COMPLETE ABORTED=0 REASON=NONE OPS=21 (bu boot'un CR4 zinciri eksiksiz), CR4START RSTVEC_OK=1, WIFITRIALEND TRIALS_RUN=11/11 REPLIED=0, terminal Session(CommandDeadline(Mac)) ve yine WIFIREAD_RECOVERY / WIFIREAD_OWNER / WIFIREAD_CREDIT satırı YOK. Boot 3 (…-repeat-02) VARİŞ YOK / YORUMLANMADI: CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=4 ADDR=0x18101800 WRITE=0 — R165 ve R168 boot 2'nin D11 sınıfı, radyo zincirine hiç girilmedi ve latch yine oluşmadı. Üç boot hakkı da kullanıldı; kredi tanığı ÜÇÜNDE DE icra edilmedi ve ölçüm bu yüzden tetikleyiciyi adlandırdı: R170 örneklemeyi tur sınırına taşır (imaj hazır).
build/rpi5-wifi-scan-r169/aselsanos-rpi5-radio.img sha256 bc8292b446c06e72718a8ece3ed21682f433f40333e82084eb71eb98b6ece5d6 · PROFILE.txt sha256 a095ae5ec21b056f2d490432dbc002cce2ed4b941a74e876a3e4adce5bcf761a · attempt-r169-credit-witness-uart-capture (boot 1 ve boot 2 MÜHÜRLÜ, ikisi de VARİŞ VAR / yorumlanabilir; kredi tanığı iki boot'ta da icra edilmedi)
Kapattığı: Ölçülen: kredi tanığı kuruldu ve imaj kimliği kanıttan doğrulandı, ama latch oluşmadığı için kredi hakkında tek veri noktası yok; süpürme 11/11 tükendi ve duvar reply yolunda kaldı (REPLIED=0). Latch'in seyrekliği (beş boot'ta bir: R167 4 kez, R168 boot 1 0, R168 boot 3 1, R169 boot 1 0, R169 boot 2 0) tek boot'luk ölçümlerin neden çoğu kez tanığı icra edemediğini açıklıyor.
Risk: Ölçülen: koşu varışlı, imaj kimliği kanıttan doğrulandı; Wi-Fi PASS iddiası yok (REPLIED=0, STATUS=ERROR). Karıştırıcı not: TFTP'deki geçici erken-sonlanma aynı boot içinde bootloader'ın yeniden denemesiyle aşıldı ve çekirdek yüklendi; koşu geçerlidir. Açık kalan ölçüm: tanık üç boot'ta da icra edilmedi (latch altı boot'ta bir); R170 tetikleyiciyi değiştirir, ölçümü değil.
Değişiklik / kapsam: Tek değişken (radyo): ÖRNEKLEME ANI. R169 imajı SDPCM tx_window + tx_sequence değerlerini yalnız okuma latch'i/kurtarması anında salt-okunur kaydediyordu; R170 aynı yayınlanmış atomikleri, aynı salt-okumayı ve aynı WRITES=0 sözleşmesini korur, yalnız kaydı latch anından HER TUR SINIRINA taşır (boot başına 11 örnek). Gerekçe ölçülmüştür: latch altı boot'ta bir kez görüldü (R167 4 · R168 boot 1 0 · R168 boot 3 1 · R169 1/2/3 hepsi 0), yani latch'e bağlı bir tanık bu hat üzerinde imaj başına üç boot'luk bütçeyle güvenilir biçimde icra edilemiyordu; kredi ise tanım gereği her turda okunabilir. Değişen tek şey zamanlama, ölçülen büyüklük değil: WINDOW/SEQUENCE/CREDIT ve PUBLISHED sayacı aynıdır. Latch tetikli WIFIREAD_CREDIT tanığı, sahiplik overlay'i (WIFIREAD_OWNER), bütçe (4), kabul edilen sınıf ve okuma latch'i aynen armed kalır.
Neden bu sırada: Ölçülen seri: R163 TRIALS_RUN=1/11 → R166 5/11 → R167 5/11 → R168 11/11 → R169 11/11 → R170 11/11. R170 örneklemeyi latch anından tur sınırına taşıdı ve ölçüm ilk kez kredi hakkında konuştu: on iki örnekte WINDOW=Some(21) sabit kaldı, SEQUENCE 4→10 ilerledi, CREDIT 17→11 düştü ve PUBLISHED 6→12 arttı — yani dongle pencere veriyor, host çerçeveleri gönderiyor ve kredi tükeniyor. Buna karşılık on bir turun on birinde REPLIED=0, FRAME_IND=0, HOST_INT=0, CORE_OR=0x00000000 ve FIFO_READS=0 okundu: dongle kabul edilen çerçeveye tek bir işaret vermiyor. Ön-kayıtlı karar tablosunun ikinci dalı gerçekleşti (CREDIT>0, REPLIED=0): duvar kredide değil, cevabı üreten tarafta. Üçüncü dal (pencere turlar boyunca değişiyor) gerçekleşmedi: pencere sabitti, değişen yalnız host'un kendi dizisiydi.
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ: 2. boot mühürlü VARİŞ VAR (yorumlanabilir) — evidence/rpi5/radio/attempt-r170-credit-sample-uart-capture-repeat-01 (boot yolu netboot, reset yolu manual; yakalama ilk bootloader satırından başlıyor ve güç kesilince betik sessizliği görüp yakalamayı tazeleyip arm etti). Kimlik: ASELSAN/WIFIREADCREDITSAMPLE_PLAN ARMED=1 SUBJECT=SDPCM_CREDIT FIELD=tx_window+tx_sequence AT=TRIAL_BOUNDARY SOURCE=TRANSPORT_CENSUS PREVIOUS=R169_LATCH_TRIGGER_UNEXERCISABLE WRITES=0 · FWSTAGE SECTORS_DONE=1190 WORDS_V=152320 OK=1 · NVRAM FOUND=1 TOKEN_OK=1 WORDS=437 VERIFIED=437 OK=1 FW_INTACT=1 (firmware 130. kez doğrulandı) · CR4CTRL PHASE=COMPLETE ABORTED=0 REASON=NONE OPS=21. ÖLÇÜLEN: on iki ASELSAN/WIFIREADCREDIT_SAMPLE satırı, hepsinde WINDOW=Some(21) ve WRITES=0; SEQUENCE 4,5,5,6,6,7,7,8,8,9,9,10; CREDIT 17,16,16,15,15,14,14,13,13,12,12,11; PUBLISHED 6,7,7,8,8,9,9,10,10,11,11,12. Her turda ASELSAN/WIFITRIAL_RESULT … SENT=1 REPLIED=0 CTRL_SEEN=0 FRAME_IND=0 HOST_INT=0 CORE_OR=0x00000000 ve ASELSAN/WIFIIRQWAIT … FRAME_IND_SEEN=0 HOST_INT_SEEN=0 FIFO_READS=0 ZERO_MARKERS=0. Tur matrisi on bir satır (watermark 8/96, yazma sayısı 0/2, DAT kontrol maskesi set/clear, mailbox Set(208)/PowerOn, card control Observe/Set(6), IEN None/Some(3), son satır LINUX_EXACT) ve hiçbiri işaret üretmedi. Sonuç: WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 ve tek terminal sınıfı WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)). Dongle'ın kendi konsolu t=3.252 sn'de sdpcmd_dpc: Enable satırında duruyor; mailbox DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION=4 ACKS=126.
build/rpi5-wifi-scan-r170/aselsanos-rpi5-radio.img sha256 f1e1826a46470de9757ee8a290596670cf72c0d5805a6caecd628dcada9b923c · PROFILE.txt sha256 757cd766ca21c6fa0c5da09b6c32aa017d11bf8004cadb5dacf965df4452c263 · attempt-r170-credit-sample-uart-capture-repeat-01 (boot 2 MÜHÜRLÜ, VARİŞ VAR / yorumlanabilir; boot 1 gözetlenmeden geçti, ölçüm üretmedi)
Kapattığı: Kredi sorusu KAPANDI: süpürme kredi açlığı çekmiyor. Duvar iki adaydan birine indi ve R171 hangisi olduğunu ölçer: firmware çerçeveyi görüp tepki veriyorsa duvar onun işleyişinde, hiç görmüyorsa duvar yazmanın kendisinde. C06/C07/C08 bu ölçümle kapanmadı; ikisi de artık tek bir soruya bağlı.
Risk: Ölçülen taban: süpürme iki varışlı boot'ta 11/11 tükendi ve on iki kredi örneği WRITES=0 ile alındı; imaj riski düşük çıktı. Varışsız boot sınıfı (D11) yorumlanmaz; bu imajın üç boot hakkından biri gözetlenmeden geçti, ölçüm ikincisinde geldi.
Değişiklik / kapsam: Tek değişken: ilk kontrol çerçevesinden önce dongle'ın tohostmailboxdata (0x1800404c) üzerindeki FWREADY bitini sınırlı süre beklemek. Yeni CMD52/CMD53 yazması, çerçeve, retry, reset veya TCM/shared-area okuması yok; FWREADY gelmezse kontrol çerçevesi gönderilmeden ProtocolTimeout ile kapanır.
Neden bu sırada: R170 kredinin pozitif olduğunu ve cevapsızlığın kredi açlığı olmadığını gösterdi. R171'in read-only kapısı iki mühürlü boot'ta EXHAUSTED=1 ile kapandı ve posta kutusu 0x00040002 (yalnız DEVREADY) okundu. Ancak aynı boot'un erken penceresi FWREADY'yi +25 ms'de görmüş ve host onu onaylamıştı: kapı, pulse geri döndükten SONRA, protokol fazında kurulduğu için kendi kaçırdığı bir olayın yokluğunu ölçtü. R171 bir 'dongle hazır olmuyor' kanıtı değil, bir faz hatası kanıtıdır.
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ: aynı R171 imajının boot 1 ve boot 2 koşuları mühürlü — evidence/rpi5/radio/attempt-r171-fwready-gate-final-2-uart-capture ve ...-repeat-01. Kimlik: image_sha256=69c753195066a586a58e800ce76e41351207a8b0f27d5c8a014224aaf1f61116 · ASELSAN/WIFIFWREADY_GATE_PLAN ARMED=1 SUBJECT=CONTROL_FRAME_PREPAREDNESS REGISTER=0x1800404c MAX_WAIT_MS=600 WRITES=0 · her iki boot'ta ASELSAN/WIFIFWREADY_GATE ATTEMPTED=1 FWREADY_SEEN=0 POLLS=27 LAST=0x00040002 EXHAUSTED=1 WRITES=0 · WIFITRIALEND TRIALS_RUN=0/11 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(Transport/ProtocolTimeout). AYNI boot'un erken penceresi: WIFIEARLYMBOX SAMPLES=7 CHANGES=1 FIRST=0x00000000 LAST=0x00040008 INT_OR=0x208000c2 DEVREADY_MS=4294967295 FWREADY_MS=25 WRITES=2 ve WIFIMBOXANSWER ATTEMPTED=1 ACKS=7 INT_WRITES=2 INT_MASKED=0x200000c0 SETTLED=1 FWREADY_ACKED_MS=25. CR4START boot 1/2'de RSTVEC_OK=1 ve PHASE=COMPLETE; firmware staging ve NVRAM doğrulamaları geçti.
Kapattığı: R171'in karar tablosunun üçüncü dalı ('FWREADY 600 ms içinde hiç gelmedi') yazıldığı gibi gerçekleşmedi: FWREADY geliyordu ve kapı onu göremedi. Soru 'dongle neden hazır olmuyor' değil, 'hazır sinyali neden kalıcı olmuyor' olarak yeniden yazıldı; bu, R141'in karar tablosundaki 'dongle tek kesme onayından fazlasını istiyor (F2 önce etkinleşmeli)' satırıdır. C06/C07/C08 frame hipotezleri açık kalır. Bu kayıt Wi-Fi PASS değildir.
Risk: Düşük — kapı yalnız okuma ve sınırlı beklemedir; iki koşuda WRITES=0, TRIALS_RUN=0 ve frame gönderilmedi. UART reconnect yarışındaki Resource busy denemesi yakalama altyapısı düzeltmesiyle kanıtlandı; ham pre-reset kayıtlar ve retry logları ayrı tutuldu.
Değişiklik / kapsam: Tek değişken: F2 (CCCR IO_ENABLE, F0 0x02) etkinleştirmesinin YERİ. F2, erken posta penceresinin İÇİNDE — host-ready yazmasından hemen sonra, Linux'un ölçülen `sdio_enable_func` konumunda — açılır; bugüne kadar firmware/NVRAM staging'inden sonra, saniyeler sonra açılıyordu. Frame baytı, SDPCM seq, kredi kuralı, reset, retry, watermark, WAKEUPCTRL, CCCR INT_ENABLE çifti ve hostintmask politikası değişmedi. R171'in protokol fazındaki bariyeri bu imaja taşınmadı: kendi makbuzu onun yalnız geri dönmüş posta kutusunu görebildiğini kanıtlamıştı.
Neden bu sırada: R171 aynı boot'ta FWREADY_MS=25 ile FWREADY_SEEN=0'ı birlikte yazdı: dongle hazır sinyalini veriyor, host onaylıyor (SETTLED=1), ama sinyal kalıcı olmuyor ve posta kutusu 0x00040002'ye dönüyordu. Linux aynı kartta F2'yi pulse'tan hemen sonra açıyor (R139 izi: CR4 bırakılışı +74 ms) ve preinit'i tamamlıyor (R75). R172 bu tek farkı ölçtü.
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ — aynı imajın iki boot'u mühürlü. Kimlik: image_sha256=4f81a934c560480f10d7a891941f168815615c4a9eb7aea887b1dbf96587665c · her iki boot'ta ASELSAN/WIFIEARLYF2 ATTEMPTED=1 WRITE_OK=1 BEFORE=0x02 AFTER=0x02 READY=1 MS=36 SOURCE=sdio_enable_func · ASELSAN/WIFIFWREADY_PERSIST LATCHED=1 EARLY_FWREADY_MS=25 F2_MS=36 PROTOCOL_MAILBOX=0x00040008 PROTOCOL_FWREADY_SEEN=1 REVERTED=0 WRITES=0. Boot 1 (attempt-r172-f2-at-start-uart-capture) taşımada düştü: WIFIPREINITSEQ SENT=0/3 WRITE_FAULTS=1, terminal Session(Transport(Io(BusError { op: WriteFifo, transfer_complete=false, bytes_read=64, r5_flags=0x10, error_status=0x0020, timeout_transfer=true }))), TRIALS_RUN=0/11. Boot 2 (…-repeat-01) R170 tabanını birebir tekrarladı ve ÖLÇÜMÜ TAMAMLADI: WIFIPREINITSEQ SENT=3/3 CRC_ACCEPTED=3 WRITE_FAULTS=0 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=1 WRITE_FAULTS=0 · WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11/11 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)). Karşılaştırma: R170 boot 2 de 11/11 trial ve REPLIED=0 ölçmüştü; R172'nin farkı, aynı boot'ta posta kutusunun FWREADY'de yakalanmasıdır.build/rpi5-wifi-scan-r172/aselsanos-rpi5-radio.img sha256 4f81a934c560480f10d7a891941f168815615c4a9eb7aea887b1dbf96587665c · PROFILE.txt sha256 3006c72ae029d70905bbcadabfa0c77c17303007882ecec9dfeba33c19c8635a · attempt-r172-f2-at-start-uart-capture (boot 1: transport düşüşü, TRIALS_RUN=0) ve attempt-r172-f2-at-start-uart-capture-repeat-01 (boot 2: MÜHÜRLÜ, VARİŞ VAR / yorumlanabilir, TRIALS_RUN=11/11 REPLIED=0)
Kapattığı: R141'in karar tablosundaki 'dongle tek kesme onayından fazlasını istiyor (F2 önce etkinleşmeli)' satırı doğrulandı: F2 +36 ms'de açılınca FWREADY pulse'ı geri dönmedi (REVERTED=0) ve erken pencere R170/R171'de olduğu gibi DEVREADY'ye düşmedi. Buna karşılık aynı boot'un protokol fazı posta nöbeti 124 örnekte 0x00040002 (yalnız DEVREADY) ve VERSION_WRITES=0 okudu: F2 zamanlaması el şıkışmayı KURUYOR ama hazır bayrağını protokol fazı boyunca KORUMUYOR. Sıralama hipotezi kapandı; açık kalan duvar kontrol cevabıdır (C06/C07/C08). Bu kayıt Wi-Fi PASS değildir.
Risk: Düşük — tek yazma F2 enable biti; TCM/shared okuma eklenmedi, reset/retry/frame değişmedi. İmaj üç boot hakkının ikisini kullandı; boot 1'in varışsız transport düşüşü sınıflandırıldı ve yorumlanmadı.
Değişiklik / kapsam: Tek değişken: posta nöbetinin (protokol fazı) hazır bayrağını KORUMASI. R172'de erken pencere FWREADY'yi yakaladı ve F2 +36 ms'de açıldı (REVERTED=0), ama aynı boot'un protokol fazı WIFIMBOXWATCH SAMPLES=124 CHANGES=0 DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION_WRITES=0 LAST=0x00040002 okudu: her posta okuması SMB_INT_ACK ile cevaplanıyor, sürüm yeniden yazılmıyor ve posta kutusu DEVREADY'ye düşüyor. R173, R140'ın ertelediği sürüm yazmasını yeniden silahlandırır: hazır biti (DEVREADY veya FWREADY) hâlâ görünürken aynı yazma (aynı kayıt 0x18004048, aynı değer 0x00040000, aynı 4 baytlık CMD53) yapılır; bit çoktan dönmüşse yazma YAPILMAZ ve makbuz bunu söyler. Frame baytı, SDPCM seq, kredi, reset ve retry değişmez.
Neden bu sırada: R172 sıralama hipotezini kapattı: F2 doğru anda açıldı, FWREADY pulse'ı geri dönmedi, süpürme R170 tabanını birebir tekrarladı (WIFIPREINITSEQ SENT=3/3 WRITE_FAULTS=0, WIFIF2CRCSCOPE ACCEPTED_CONTROL=1, TRIALS_RUN=11/11) ve cevap yine gelmedi (REPLIED=0, CommandDeadline(Mac)). Geriye kalan ölçülü fark, hazır bayrağının protokol fazında görünmemesidir; Linux aynı yerde posta okumasını cevaplarken sürüm yazmasını da yineler (brcmf_sdio_hostmail + brcmf_sdio_firmware_callback sırası).
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ — boot 1 mühürlü: evidence/rpi5/radio/attempt-r173-fwready-preserve-uart-capture. Kimlik: image_sha256=70284d1ff6855a3bc32ae8419fd12abf6e6795a780a1b19169cb377b0987ed8c · ASELSAN/WIFIFWREADYPRESERVE ATTEMPTED=1 WRITES=113 FWREADY_BEFORE=0 DEVREADY_BEFORE=1 LAST_SEEN=0x00040002 REVERTED_AT_SAMPLE=0 SAMPLES=113 VERSION_WRITES=113 REGISTER=0x18004048 VALUE=0x00040000 · ASELSAN/WIFIMBOXWATCH SAMPLES=113 CHANGES=0 DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION=4 ACKS=113 VERSION_WRITES=113 LAST=0x00040002 · WIFIPREINITSEQ SENT=3/3 CRC_ACCEPTED=3 WRITE_FAULTS=0 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=7 WRITE_FAULTS=0 · WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11/11 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(Mac)). Aynı koşunun konsol halkası (WIFISHAREDCONSOLE_FULL SIZE=1024 IDX=375 PRINTABLE=992 WRITES=0 T_MS=27762) firmware'in KENDİ ağzından son sözü veriyor: `000003.300 sdpcmd_dpc: Enable` ve sonrasında 27,7 saniye boyunca TEK BİR yeni satır yok — R148'de çerçevemiz reddedildiğinde yazılan `sdpcmd_tx: device disabled` / `sdpcmd_sendheader: tx submit failed!!` satırları bu koşuda HİÇ görünmüyor.
build/rpi5-wifi-scan-r173/aselsanos-rpi5-radio.img sha256 70284d1ff6855a3bc32ae8419fd12abf6e6795a780a1b19169cb377b0987ed8c · PROFILE.txt sha256 9fd39e7b0762cc308fbb6ec5d9d0a92975d5c43d553c62c79896652d12ff6f97 · attempt-r173-fwready-preserve-uart-capture (boot 1 MÜHÜRLÜ, VARİS VAR / yorumlanabilir, TRIALS_RUN=11/11 REPLIED=0)
Kapattığı: Hipotez ELENDİ: sürüm yazması nöbet boyunca 113 kez yinelendi (Linux'un konumu ve değeriyle) ve posta kutusu tek örnekte bile FWREADY'ye dönmedi (FWREADY_BEFORE=0, LAST=0x00040002); süpürme R170 tabanını yineledi (TRIALS_RUN=11/11 REPLIED=0, CommandDeadline(Mac)). Hazırlık sinyali ve el sıkışma hattı artık kapalı bir konudur; açık kalan tek duvar frame yoludur (C06/C07/C08). Konsol halkası, firmware'in çerçevelerimiz için HİÇBİR hata yazmadığını gösterdi — R148'de yazmıştı; bu, çerçevenin ya işlendiğini ama cevapsız kaldığını ya da firmware'in veri yoluna hiç ulaşmadığını söyler ve sıradaki değişken bu iki şıkkı ayırmalıdır. Bu kayıt Wi-Fi PASS değildir.
Risk: Düşük — tek yazma zaten ölçülmüş sürüm yazmasıdır; TCM/shared okuma eklenmedi, frame/seq/kredi/reset/retry değişmedi. Konsol okuması koşunun EN SONUNDA tek kez yapıldı (bilinen TCM-karartması riski önceki ölçümleri susturamaz). Boot 1 ölçümü tamamladı; iki boot hakkı kaldı.
Değişiklik / kapsam: Tek değişken: süpürme bittikten SONRA dongle'ın kendi paylaşılan alanını BİR KEZ okumak — yapı işaretçisi, ilk sözcük (sürüm/bayraklar) ve konsol adresi sözcüğü. Aynı koşuda her tarama imajının zaten taşıdığı run-sonu konsol dökümü AYNI yapıyı okur (BUF_PTR ve BUF_IDX yayınlar), böylece iki okuma karşılaştırılabilir: firmware kontrol çerçevelerimiz beklerken kendi konsoluna yazmaya devam ettiyse yazma indeksi iki okuma arasında ilerler. Salt-okunur; kayıt yazılmaz, frame yolu ve F2/erken pencere ayarları R173'teki gibi donar.
Neden bu sırada: R173 hazırlık hattını kapattı ve iki olguyu yan yana koydu: host on bir kontrol çerçevesi yazdı ve F2CRC yedisini kabul etti (ACCEPTED_CONTROL=7, WRITE_FAULTS=0), buna karşılık dongle koşu boyunca YALNIZCA iki çerçeve gönderdi (SEQ=0 ve SEQ=1, ikisi de CHANNEL=1 EMPTY=1 TXWIN=21) ve her trial CTRL_SEEN=0 CTRL_UNMATCHED=0 FRAME_IND=0 HOST_INT=0 okudu; konsol halkası 3,300 sn'deki sdpcmd_dpc: Enable satırından sonra 27,7 saniye boyunca tek satır yazmadı. Bu, ya çerçevenin firmware'in veri yoluna hiç ulaşmadığını ya da ulaşıp cevaplanmadığını söyler; iki şık farklı kapı gerektirir.
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ — boot 3 mühürlü: evidence/rpi5/radio/attempt-r174-fw-probe-at-end-uart-capture-repeat-02 (VARİS VAR / yorumlanabilir). Kimlik: image_sha256=655e338c6bdbe2c50d1793c4680e5b122f2eeca22304c00212af54a6baa7a08c · ASELSAN/WIFIFWPROBE_AT_END ATTEMPTED=1 WHERE=AFTER_SWEEP PTR=0x00201cc0 PTR_OK=1 FLAGS=0x00000001 CONSOLE_ADDR=0x0025debc STRUCT_READ_OK=1 SENT_BEFORE_OK=1 SENT_AFTER_OK=1 WRITES=0 · ASELSAN/WIFISHAREDCONSOLE SENT_B_OK=0 SENT_A_OK=1 CONSOLE_ADDR=0x0025debc HEADER_OK=1 BUF_PTR=0x0025dab4 BUF_OK=1 PRINTABLE=124 WRITES=0 · ASELSAN/WIFISHAREDCONSOLE_FULL SIZE=1024 IDX=375 READ=1024 PRINTABLE=992 SENT_RETRIES=0 WRITES=0 T_MS=31960 · ASELSAN/WIFIPREINITSEQ SENT=3 EXPECTED=3 CRC_ACCEPTED=3 WRITE_FAULTS=0 · ASELSAN/WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=1 WRITE_FAULTS=0 · ASELSAN/WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=5 TRIALS_PLANNED=11 REPLIED=0 · ASELSAN/WIFISCAN_RESULT STATUS=ERROR ERROR=Session(Transport(Io(BusError { op: Read32, function: 1, address: 402669600, reason: Transfer, status: 2129921, response: 4096, present_state: 33489414, ... }))). Karşılaştırma (R173 run-sonu): BUF_PTR=0x0025dab4 ve IDX=375 AYNI; bayrak sözcüğü 0x00000001 (ASSERT 0x0200 / TRAP 0x0400 bitleri YOK). Boot 1 ve repeat-01 varışsız sınıfta kaldı ve yorumlanmadı.build/rpi5-wifi-scan-r174/aselsanos-rpi5-radio.img sha256 655e338c6bdbe2c50d1793c4680e5b122f2eeca22304c00212af54a6baa7a08c · PROFILE.txt sha256 4adc4712f9bba278cab92a4b63b6831f65646cc9ad9948175510912efc88eddf · attempt-r174-fw-probe-at-end-uart-capture-repeat-02 (boot 3 MÜHÜRLÜ, VARİS VAR / yorumlanabilir, TRIALS_RUN=5/11 REPLIED=0)
Kapattığı: R173'ün 'çerçeve ulaşıyor mu, işlenmiyor mu' sorusu salt-okunur tek ölçümle ayrıldı: konsol yazma indeksi R173'ün run-sonu değeriyle AYNI kaldı (IDX=375), bayrak sözcüğü trap/assert taşımadı ve WIFIFWPROBE_AT_END WRITES=0 okudu — dongle protokol fazında HİÇ yazmadı, yani çerçeve canlı bir veri yoluna ulaşmadı. Karar tablosunun ikinci dalı gerçekleşti ve sıradaki kapı host tarafına döndü: ilk kontrol çerçevesinin tam baytları Linux'un aynı kartta ölçülmüş ilk kontrol çerçevesiyle karşılaştırılır (R121 geometriyi eşitlemiş, içeriği ölçmemişti). Bu kayıt Wi-Fi PASS değildir.
Risk: Düşük — sıfır yazma; paylaşılan alan okuması süpürmeden SONRA tek kez yapıldı ve nöbetçi (ChipCommon chipid) probu iki yandan kuşattı (SENT_BEFORE_OK=1, SENT_AFTER_OK=1). İmaj üç boot hakkını kullandı; boot 3 ölçümü tamamladı ve mühürlendi.
Değişiklik / kapsam: Tek değişken: preinit sırasının İÇERİĞİ, Linux'un aynı kartta ölçülen sırasıyla birebir. Ölçüm mühürlü izden mekanik çıkarılır (scripts/extract-linux-preinit-frames.py; çıpa = izdeki en büyük yazma-arası boşluk). Dört çerçeve: (1) SET bus:txglomalign=8, GLOMSUZ, seq=255, cmd=263 id=1, len=20; (2) GET ulp_sdioctrl, GLOMSUZ, seq=0, cmd=262 id=2, len=29 (13 bayt ad + 16 bayt yanıt alanı); (3) SET bus:rxglom=1, GLOMSUZ, seq=1, cmd=263 id=3, len=15; (4) SET cur_etheraddr=MAC, GLOM, seq=2, cmd=263 id=4, len=20. Taşıma birimi ölçülen ALIGN8(frame_len) olur (48/64/48/56) ve SDPCM sayacı ölçülen ardıldan (3) devam eder. Ayrıca R173'ün elenen hazır-bayrağı onayı en çok 3 kez yinelenip bırakılır (FWREADY_PRESERVE_MAX_WRITES=3).
Neden bu sırada: R174, çerçevenin protokol fazında canlı bir veri yoluna ulaşmadığını ölçtü (konsol IDX=375 R173 ile aynı, FLAGS=0x00000001 trap/assert taşımıyor, WRITES=0) ve kapıyı host tarafına döndürdü. Mühürlü Linux izi üç fark verdi: Linux'un İLK kontrol çerçevesi transport başlangıcındaki bus:txglomalign'dır ve R157'nin üç çerçeveli sırası onu tamamen atlıyordu; ölçülen ulp_sdioctrl declared uzunluğu 29'dur (R157 15 kullanıyordu); ve Linux çerçeveyi sabit 64 değil ALIGN8(frame_len) baytla yazar. R175 bu üçünü tek değişkende birleştirdi.
KOŞULDU ve DEĞİŞKEN İCRA EDİLDİ — boot 2 mühürlü: evidence/rpi5/radio/attempt-r175-preinit-measured-uart-capture-repeat-01 (VARİS VAR / yorumlanabilir; aynı imajın boot 1'i CR4 abort'uydu ve yorumlanmadı). Kimlik: image_sha256=d58d532fde53ba7f71e5fc8a9a0e5fbd51b38050a25b9246c6be0bab5fd13277 · CR4START RSTVEC_OK=1 ALIAS_OK=1 RSTVEC_C53=1 PHASE=COMPLETE ABORTED=0 · ASELSAN/WIFIPREINITSEQ SENT=4 EXPECTED=4 CRC_ACCEPTED=3 WRITE_FAULTS=0 SOURCE=linux-r136-preinit-measured · dört ASELSAN/WIFIPREINITBYTES satırı Linux ölçümüyle BAYT BAYT aynı: FRAME=0 SEQ=255 FRAMELEN=48 XFER=48 CMD=263 ID=1 SET=1 · FRAME=1 SEQ=0 FRAMELEN=57 XFER=64 CMD=262 ID=2 SET=0 · FRAME=2 SEQ=1 FRAMELEN=43 XFER=48 CMD=263 ID=3 SET=1 · FRAME=3 SEQ=2 FRAMELEN=56 XFER=56 CMD=263 ID=4 SET=1; HEK'lerin tamamı extract-linux-preinit-frames.py çıktısıyla eşit · ASELSAN/WIFIFWREADYCAP_PLAN ARMED=1 MAX_WRITES=3 CONCLUSION=HYPOTHESIS_ELIMINATED · ASELSAN/WIFIFWREADYPRESERVE ATTEMPTED=1 WRITES=3 CAPPED=1 MAX_WRITES=3 FWREADY_BEFORE=0 DEVREADY_BEFORE=1 LAST_SEEN=0x00040002 SAMPLES=97 VERSION_WRITES=3 (R173'te 113 yazmaydı) · ASELSAN/WIFIMBOXWATCH SAMPLES=97 CHANGES=0 DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION_WRITES=3 LAST=0x00040002 · ASELSAN/WIFIF2CRC ACCEPTED=1 REQUESTED=48 BYTES=48 ERR_STATUS=0x0020 (ALIGN8 birimi telde) · ASELSAN/WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=9 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · konsol Disable=0 tx_submit_failed=0.
build/rpi5-wifi-scan-r175/aselsanos-rpi5-radio.img sha256 d58d532fde53ba7f71e5fc8a9a0e5fbd51b38050a25b9246c6be0bab5fd13277 · PROFILE.txt sha256 0473b8d2b5c1f5a33d7906111cd59280858a7aa030390a4f13e50be3b0de2405 · attempt-r175-preinit-measured-uart-capture-repeat-01 (boot 2 MÜHÜRLÜ, VARİS VAR / yorumlanabilir, TRIALS_RUN=9/11 REPLIED=0)
Kapattığı: R174'ün ikinci dalı (çerçeve canlı veri yoluna ulaşmadı) host tarafında ölçüldü: dört preinit çerçevesi alan alan ve bayt bayt Linux'un aynı kartta ölçtüğü sırayla aynı çıktı ve R173'ün 113 yinelemesi 3'e indi (CAPPED=1) — buna rağmen dongle tek bir cevap vermedi (REPLIED=0, süpürme 9/11 trialda kapandı). Yani çerçeve İÇERİĞİ ve SIRASI host tarafında elendi; eşleştirmediğimiz ilk çerçeve artık ölçülen sıranın BEŞİNCİSİDİR (glom, seq=3, cmd=98, id=5, len=68, veri ad taşımıyor); bizim sweep orada GET cur_etheraddr (cmd=262, id=5) gönderiyor. Bu kayıt Wi-Fi PASS değildir.
Risk: Düşük — yeni kayıt yazması, reset veya retry yok; preinit çerçeveleri pending kurmaz ve cevap beklemez; elenen R173 onayı 3 yazmada bırakılır. İmaj üç boot hakkının ikisini kullandı (boot 1 varışsız, boot 2 ölçümü tamamladı).
Değişiklik / kapsam: Tek değişken: sweep'in İLK kontrol çerçevesinin içeriği. R175 dört preinit çerçevesini Linux ölçümüyle bayt bayt eşitledi; ölçülen sıranın beşinci çerçevesi glom düzeninde, seq=3, cmd=98 (262/263 değil), id=5, declared len=68 ve verisi bir iovar adı taşımıyor. Bizim sweep aynı sırada GET cur_etheraddr (cmd=262, id=5) gönderiyordu. R176 yalnız bu ilk kontrol çerçevesini ölçülen beşinci çerçeveyle değiştirdi; preinit sırası, taşıma birimi (ALIGN8), seq devamlılığı (3), kabul kuralı ve R173 sınırı (3 yazma) dondu.
Neden bu sırada: R175 host tarafındaki en güçlü iki adayı eledi: çerçeveler Linux ölçümüyle birebir ve sıra doğru (WIFIPREINITBYTES ×4 eşit), buna karşılık REPLIED=0 ve süpürme 9/11 trialda kapandı. Geriye kalan ölçülü fark ilk ÇAĞRI çerçevesinin kimliğiydi: Linux aynı noktada cmd=98 taşıyan 104 baytlık glom çerçevesini gönderiyor (dcmd id=5), biz ise cmd=262 GET gönderiyorduk.
KOŞULDU — iki mühürlü boot. Boot 1 (attempt-r176-measured-fifth-frame-uart-capture, uart10.raw 67.995 bayt, success=true) mekanizmasına varamadan kapandı: WIFITRIALEND STOP=NOT_REARMABLE TRIALS_RUN=0 TRIALS_PLANNED=11 REPLIED=0. Boot 2 (attempt-r176-measured-fifth-frame-uart-capture-repeat-01, uart10.raw 155.238 bayt, success=true) değişkeni tam icra etti: ASELSAN/WIFIREVINFO_PLAN ARMED=1 CMD=98 ID=5 SEQ=3 FRAMELEN=104 XFER=104 BCDCLEN=68 LAYOUT=GLOM ve on iki kez ASELSAN/WIFIREVINFO ANSWERED=0 (EXPECT_LINUX_VENDORID=0x14e4 EXPECT_LINUX_DEVICEID=0x43ab EXPECT_LINUX_CHIPNUM=0x4345); ANSWERED=1 hiç görülmedi. Terminal makbuzlar: WIFIPREINITSEQ SENT=4 EXPECTED=4 CRC_ACCEPTED=3 WRITE_FAULTS=0 · WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(RevInfo)) · CR4START PHASE=COMPLETE HT_CSR_FIN=0xd2 HT_REQ_AVAIL=1.
Kapattığı: R175'in karar tablosunun ikinci dalı gerçekleşti. Koşu öncesi bilinen en güçlü olgu şuydu: AYNI mühürlü izde, AYNI kartta, AYNI fazda dongle tam bu çerçeveye CEVAP VERİYOR (satır 162/164, 96 bayt = 12+16+68, vendorid=0x14e4, deviceid=0x43ab, chipnum=0x4345). Cevap gelmediğine göre bu, çerçeve yolunun daraltılması değil KAPATILMASIDIR: içerik (R175) ve kimlik (R176) host tarafında elendi. Kapı artık çerçeve katmanında değildir. Wi-Fi PASS değildir.
Risk: Yok — koşu tamamlandı ve iki paket de mühürlendi. UYARI: R176'nın paylaşılan kod değişiklikleri (TX_EVIDENCE_BYTES 48→64 ve makbuz satırları) R175 imajını da etkiler; diskteki mühürlü R175 imajı (d58d532f…) DEĞİŞMEDİ ve kasten yeniden derlenmedi, ama bugün yeniden derlenseydi bayt-özdeş olmazdı (R127'deki aynı durum).
Değişiklik / kapsam: Tek değişken: firmware callback'inden sonra HT saatinin yeniden istenmesi (linux-brcmf_sdio_firmware_callback yolu). ÖLÇÜM SINIRI: bu imaj R176'nın revinfo-first değişkenini de taşır, yani R175'e göre İKİ değişken değişmiştir; ayrıştırma ancak R176'nın kendi mühürlü boot'larıyla karşılaştırarak yapılabilir.
Neden bu sırada: R176 ölçülen beşinci çerçeveyi gönderdi ve cevap alamadı. İki soru açıktı: saat katmanı cevabı engelliyor mu, ve SDPCM kredi penceresi tükeniyor mu. R177 ikisini de aynı boot'ta ölçer.
KOŞULDU ve MÜHÜRLENDİ — attempt-r177-post-cr4-clock-uart-capture-repeat-02, uart10.raw 159.535 bayt sha256 2d9e7fd33f6ddbc789d1a164077ec09438f857493219380407ae637aed177ee0, mode 0444, capture_closed=true terminal_seen=true grace_complete=true success=true. SAAT: ASELSAN/WIFICLOCKRECOVERY ATTEMPTED=1 BEFORE=0xd2 AFTER_REQ=0xd0 FINAL=0xd0 POLLS=1 AVAIL=1 WRITES=2 — HT_AVAIL biti (0x80) hem önce hem sonra set; yeniden istek yalnız FORCE_HT bitini (0x02) temizledi. CR4START HT_CSR_FIN=0xd2 HT_REQ_AVAIL=1, R176 ile aynı. KREDİ: ASELSAN/WIFIREADCREDIT_SAMPLE on bir denemenin tamamında WINDOW=21 sabit, SEQUENCE 4→10, CREDIT 17→11, PUBLISHED 8→14 — host altı kredi harcadı, on bir kredi arttı, pencere hiç tükenmedi. Terminal: WIFITRIALEND STOP=EXHAUSTED TRIALS_RUN=11 TRIALS_PLANNED=11 UNMATCHED_TOTAL=0 REPLIED=0 · WIFISCAN_RESULT STATUS=ERROR ERROR=Session(CommandDeadline(RevInfo)) · WIFIPREINITSEQ SENT=4 EXPECTED=4 WRITE_FAULTS=0 · WIFIF2CRCSCOPE ACCEPTED_PREINIT=3 ACCEPTED_CONTROL=5 SILENT_ACCEPT=0 · PINMUXW VERIFIED=10/10. İmaj: build/rpi5-wifi-scan-r177/aselsanos-rpi5-radio.img sha256 4686a43d6e4accb94fbccb07ee0533246d161290cdff1fec1bf2209afda76ef4.
Kapattığı: İki hipotezi ölçerek kapatır. KREDİ: tx_window on bir denemede hiç ilerlemedi ve host'un kredisi hiç bitmedi — akış kontrolü duvar değildir; WINDOW'un donuk kalması firmware'in tek bir SDPCM çerçevesi bile göndermediğini söyler. SAAT: R176 repeat-01 (post-CR4 yeniden isteği YOK) ile R177 (VAR) aynı sonucu verdi — TRIALS_RUN=11/11, REPLIED=0, Session(CommandDeadline(RevInfo)), HT_CSR_FIN=0xd2; iki koşu arasındaki tek fark FORCE_HT bitidir ve sonucu değiştirmemiştir. Ayrıca R75 makbuzu firmware, NVRAM ve CLM'in Linux'un aynı Pi 5'te kullandığı dosyalarla BAYT-ÖZDEŞ olduğunu gösterir (ca709be8… · d608f866… · 9823842c…) ve firmware konsolu NVRAM'ımızı uyguladığını kendi ağzından söyler (Overriding vendor id = 0x14e4, Overriding device id = 0x43ab). Wi-Fi PASS değildir.
Risk: Yok — koşu tamamlandı ve mühürlendi.
Değişiklik / kapsam: Tek değişken: R177'nin post-CR4 saat yeniden isteği (WIFICLOCKRECOVERY) olmadan aynı çerçeve yolunu tekrarlamak. R176 repeat-01 tam olarak bu değişkendi — iki koşu arasındaki TEK fark firmware callback'inden sonraki HT saat yazmalarıdır.
Neden bu sırada: R177 kredi ve saat katmanını aynı boot'ta ölçerek iki hipotezi kapattı. Ancak tek-değişken disiplini gereği, saat katmanının bağımsız etkisini ayırmak için saatsiz bir koşu gerekir. R178 bu koşu olarak planlandı — ancak R176 repeat-01 zaten aynı imaj, aynı kod tabanı ve saatsiz yoldu.
GEREKSİZ — imaj derlendi (build/rpi5-wifi-scan-r178/aselsanos-rpi5-radio.img sha256 dbaeda475519410235ba25b7eec1b2432be9e0d9d92b6c1ace29d78b40e9eb95) ancak flash edilmedi.
KARŞILAŞTIRMA: R176 repeat-01 (saatsiz) vs R177 (saatli) — iki koşu arasındaki TEK fark WIFICLOCKRECOVERY'dır.
R176 repeat-01 R177 repeat-02
İmaj 5be9f31b… 4686a43d…
WIFICLOCKRECOVERY YOK ATTEMPTED=1 BEFORE=0xd2
AFTER_REQ=0xd0 FINAL=0xd0
POLLS=1 AVAIL=1 WRITES=2
HT_CSR_FIN 0xd2 0xd2 (aynı)
TRIALS_RUN 11/11 11/11 (aynı)
REPLIED 0 0 (aynı)
STOP EXHAUSTED EXHAUSTED (aynı)
SCAN_RESULT CommandDeadline CommandDeadline
(RevInfo) (RevInfo) (aynı)
KREDİ WINDOW 21 sabit 21 sabit (aynı)
KREDİ SEQUENCE 4→10 4→10 (aynı)
KREDİ CREDIT 17→11 17→11 (aynı)
KREDİ PUBLISHED 8→14 8→14 (aynı)
PINMUXW VERIFIED=10/10 VERIFIED=10/10 (aynı)
F2CRC 0x0020 her yazma 0x0020 her yazma (aynı)
SONUÇ: Post-CR4 saat yeniden isteği (FORCE_HT biti 0x02 temizleme) sonucu
DEĞİŞTİRMEDİ. HT_AVAIL (0x80) her iki koşuda da set; HT saati duvar değildir.
Kredi penceresi her iki koşuda da özdeş ilerledi — akış kontrolü duvar değildir.
R178 neden koşulmadı: R176 repeat-01 (imaj 5be9f31b…) zaten saatsiz yoldur.
R178 (imaj dbaeda47…) R176 repeat-01 ile FONKSİYONEL ÖZDEŞ olacaktır — aynı
çerçeve yolu, aynı kredi davranışı, aynı REPLIED=0 sonucu. Tek-değişken
disiplini gereği, R176 repeat-01 R178'in yerini tutar ve R178 flash edilmemiştir.
R75 Linux kontrolü çapraz doğrulama: Aynı Pi 5'te Linux/brcmfmac firmware
konsolunu döker (ca709be8… · d608f866… · 9823842c… = AselsanOS blob'larıyla
bayt-özdeş) ve 'Overriding vendor id = 0x14e4, Overriding device id = 0x43ab'
ile NVRAM'ımızı uyguladığını söyler. Wi-Fi PASS değildir.Kapattığı: Hiçbir hipotezi kapatmaz — R176 repeat-01 zaten kapatmıştı. Aşağıdaki karşılaştırma tablosu R177'nin tek-değişken izolasyonunu doğrular.
Risk: Yok — koşulmadı, hiçbir donanım etkilenmedi.
Değişiklik / kapsam: Tek değişken ölçümün yapıldığı taraftı; AselsanOS imajı DEĞİŞMEDİ. Aynı Pi 5 Model B Rev 1.1 üzerinde Raspberry Pi OS (trixie, çekirdek 6.18.50+rpt-rpi-2712) USB bellekten açıldı ve brcmfmac BCM43455'i eksiksiz bring-up etti.
Neden bu sırada: R177'nin ham kaydındaki firmware konsolu iki satır taşıyordu: 'wlc_stf_txcore_shmem_write: No clock' ve 'wlc_attach_antgain_init: Invalid antennas available in srom, using 2dB'. Bu satırların ARIZA mı iyi huylu mu olduğu ölçülmemişti ve firmware iç başlatma (Katman 3) hipotezinin tek dayanağıydı.
KOŞULDU ve MÜHÜRLENDİ — evidence/rpi5/radio/linux-r179-control (6 dosya, 0444, EVIDENCE_SHA256SUMS 6/6 OK). PLANLANAN ÖLÇÜM YAPILAMADI: stok Raspberry Pi çekirdeğinde CONFIG_BRCMDEBUG derlenmemiş, bu yüzden /sys/kernel/debug/brcmfmac/ hiç oluşmuyor ve fwcon dökümü bu çekirdekle mümkün değil. YERİNE ölçülen iki şey soruyu daha keskin cevapladı. (1) GİRDİLER BAYT-ÖZDEŞ, canlı doğrulama: çalışan sistemin Pi 5 için çözdüğü dosyalar d608f866…6b4a36c3 (bin), ca709be8…a3ce9e3d (txt), 9823842c…0eee29cc1 (clm_blob) — üçü de AselsanOS'un firmware/wifi/ blob'larıyla aynı. (2) İLK BCDC KONTROL KOMUTU CEVAPLANIYOR: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b — bu dize firmware'in ver iovar cevabından basılır. Çip de aynı: F1 signature read @0x18000000=0x15264345. Tarama 12 ağ gördü (üçüncü taraf SSID'leri kasıtlı kaydedilmedi).
Kapattığı: Katman 3'ü kapatır. Aynı firmware, aynı NVRAM, aynı CLM ve aynı çiple, 'No clock' ve 'Invalid antennas' satırlarını üreten attach yolundan geçildikten SONRA firmware Linux'a cevap veriyor. Dolayısıyla o satırlar kontrol cevabı üretilmesini engellemiyor ve AselsanOS'taki REPLIED=0 duvarı host sıralamasındadır. SINIR: firmware konsolu Linux tarafında dökülmedi; sonuç konsol diff'inden değil cevap alınmasından gelir. Wi-Fi PASS değildir.
Risk: Yok — yalnız okuma yapıldı; Pi'de hiçbir değişiklik yapılmadı, AselsanOS imajı ve mühürlü paketler etkilenmedi.
Değişiklik / kapsam: Tek değişken: her kontrol çerçevesinden sonra kesme durumunu servis etmek ve F2'yi KOŞULSUZ okumak. Çerçeve içeriği, kimliği, preinit sırası, taşıma birimi ve sınırlar donar.
Neden bu sırada: R175 çerçeve içeriğini, R176 çerçeve kimliğini, R177 krediyi ve saati, R179 firmware iç başlatmasını eledi. Geriye host sıralamasında tek adlandırılmış boşluk kaldı ve mühürlü R177 kaydı onu sayıyla gösteriyor: on bir denemenin tamamında FIFO_READS=0 ve FRAME_IND=0. R128 aynı boşluğu kendi sonucunda adlandırmıştı: düşen iki yazmanın ikisi de cevapsız kalan bir çerçeveden sonraki ilk yazmaydı ve Linux'un DPC'sinin çerçeveler arası yaptığı hiçbir şey bizde yok.
KOŞULDU ve MÜHÜRLENDİ — attempt-r180-f2-post-send-uart-capture, uart10.raw sha256 a30bd4188efbf1b28b6e0f7673ce9d1cd6492402533f13d9fe5b1c0cfbca68f0, mode 0444, capture_closed=true. F2 OKUMA: ASELSAN/WIFIREAD OP=ReadFifo FUNCTION=2 ADDRESS=0x00008000 BYTES_READ=64 R5_FLAGS=0x10 ERROR_STATUS=0x0020 TIMEOUT_TRANSFER=1 COMMAND_COMPLETE=1 — ilk kez F2'den veri okundu (BYTES_READ=64) ancak SDIO DATA_CRC hatası (0x0020). TRIAL: FRAME_IND=1 HOST_INT=1 CORE_OR=0x000000c0 ERR=Session(Transport(Io())) — ilk kez frame indication ve host interrupt birlikte görüldü; SDIO transport katmanında Io hatasıyla kapandı. CR4START: RSTVEC_OK=1 PHASE=COMPLETE ABORTED=0 HT_CSR_FIN=0xd2 HT_REQ_AVAIL=1 WRITE_OK=1 MBOX=0x00000000 INTSTAT=0x00000000 EXECUTED=0 STARTED=0 HT_AVAIL=0. İmaj: build/rpi5-wifi-scan-r180/aselsanos-rpi5-radio.img sha256 5604031a4eaac00068ec95e560170d6b39acf84c08d0f4783fdb6b310d0e40c6.
Kapattığı: F2 okuma tarafını AÇAR: R177'de FIFO_READS=0/FRAME_IND=0 olan boşluk, R180'de BYTES_READ=64/FRAME_IND=1 oldu — yani kart F2'ye veri koydu ve host okudu. Ancak okuma 0x0020 DATA_CRC hatasıyla düştü; PRESENT_STATE=0x01ff0206 DAT_INHIBIT+DAT_LINE_ACTIVE set — bus önceki yazmadan boşalmamış. REPLIED=0 hâlâ; okunan 64 bayt geçerli bir tümleyen taşımadı. Duvar okuma TARAFINDA değil, okuma YOLUNDA (bus zamanlama). Wi-Fi PASS değildir.
Risk: Yok — okuma eklendi, yazma yolu değişmedi. DATA_CRC hatası bir sonraki kapıyı adlandırdı: R181 DAT_INHIBIT bekleme.
Değişiklik / kapsam: Tek değişken (plan): F2 okumasından ÖNCE SDHCI PRESENT_STATE (0x24) okunarak DAT_INHIBIT+DAT_LINE_ACTIVE bitlerinin temizlenmesini beklemek.
Neden bu sırada: R180 F2'den 64 bayt okudu (FRAME_IND=1) ama okuma DATA_CRC=0x0020 ile düştü; PRESENT_STATE=0x01ff0206 DAT_INHIBIT ve DAT_LINE_ACTIVE bitlerini gösteriyordu.
DÜZELTME (2026-09-17). evidence/rpi5/radio/attempt-r181-dat-inhibit-wait-uart-capture mühürlü DEĞİL: EVIDENCE_SHA256SUMS ve README yok, dosyalar 0444 değil. İkinci dizin (…-uart-capture-uart-capture) 132 baytta capture_closed=true success=false terminal_seen=false ile kapanmış. Ham kayıt, 11:43'te derlenen rpi5-wifi-scan-r181 imajının (bootloader: Read aselsanos-rpi5-radio.img bytes 3903208) TEK açılışıdır. Aynı kayıtta WIFIR185, WIFIR185B, WIFIR190, WIFIR190WAIT ve WIFIR191 satırları da basılıdır; satırların bir kısmı bayt kaybıyla bozuk. Aynı kayıtta WIFIPREINITSEQ SENT=0 EXPECTED=4 ve WIFITRIAL_RESULT SENT=0: hiçbir çerçeve gönderilmedi. Önceki metnin PSTATE=0x00000000 → 'bus tamamen boştaydı' okuması yanlış. Boştaki hat 0x01ff0000 okur: bit 24 CMD, bit 23:20 DAT[3:0] seviyeleridir ve boşta yüksektir. Tamamen sıfır geçerli bir hat okuması değildir (R1'de 0x000f0000 'çip beslenmiyor' diye okunmuştu). FRAME_IND=0, HOST_INT=0 ve FIFO_READS=0 ile koşu değişkene ulaşmadı.
Kapattığı: Hiçbir hipotezi kapatmaz. 'Bus contention elendi' ve 'duvar yazma tarafında' sonuçları geri çekildi. Wi-Fi PASS değildir.
Risk: Düşük — salt-okunur PRESENT_STATE yoklaması.
Değişiklik / kapsam: Tek değişken (plan): SDIO saat bölücüsü /256 → /16.
Neden bu sırada: Yazma yolundaki DATA_CRC=0x0020'nin saat hızına bağlı olup olmadığı sorulmuştu.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). Rozet 'gereksiz' iken metin 'koşuldu' diyordu. '/16 backplane yazmaları için çok hızlı' sonucu sayfanın mühürlü geçmişiyle çelişir: R54–R58 609 KB firmware'in tamamını /16'da yükledi (R58 PASS ×2). R192 USB baz koşusu (attempt-r192-usb-baseline-uart-capture) staging'i SDCLK DIV=0x08 ile yaptı, ardından WIFIR191 CLK=0x0207 HS50=1 ile CR4CTRL PHASE=COMPLETE ERR=0x0000 aldı. Frekans etiketleri de doğrulanmalı: WIFIINV CAPS=0x55eec832 taban saati 0xc8 = 200 MHz bildiriyor. SDHCI 3.00 bölücüsüyle 0x80 ≈ 781 kHz, 0x08 = 12,5 MHz, 0x02 = 50 MHz eder; sayfadaki ~390 kHz ve 6,25 MHz etiketleri 100 MHz taban varsayar.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — saat bölücüsü yazıldı, çip resetlenmedi.
Değişiklik / kapsam: Tek değişken (plan): SDIO saat bölücüsü /64.
Neden bu sırada: R182'nin geri çekilen '/16 çok hızlı' sonucuna dayanıyordu.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). CMD52 zaman aşımının saat hızına bağlanması R182'nin geri çekilen sonucuna dayanır; ölçülmüş bir sınır değildir.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — saat bölücüsü yazıldı, çip resetlenmedi.
Değişiklik / kapsam: Tek değişken (plan): CR4 başlangıcından sonra ilk F2 okuması.
Neden bu sırada: Linux DPC'sinin ilk F2 okumasını taklit etmek.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). Önceki metin kodun hiç çalışmadığını kendisi söylüyor (wifi_scan_core=None, HT_REQ_WRITE_OK=0). Değişkene ulaşmayan bir koşu, sayfanın kuralı gereği bir yerleşim sonucunu 'kanıtlayamaz'. 'Saat değişikliği CR4START'tan sonra yapılmalı' bir hipotez olarak kalır.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — kod çalışmadı.
Değişiklik / kapsam: Tek değişken (plan): CR4 oturumu başladıktan sonra F2 FIFO'dan okuma.
Neden bu sırada: R180'deki F2 okumasını temiz bir bağlamda tekrarlamak.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). Aynı tanı satırı R192'nin mühürlü USB baz koşusunda da basılıdır: WIFIDBG R185=11 FLEN=12 CH=15 SEQ=256 INT=0x008000c0 B0=0c00f3ff0001000c. Baytların brcmfmac SDPCM başlığına göre çözümü: bayt 0–1 uzunluk 0x000c = 12 bayt 2–3 tümleyen 0xfff3 (0x000c XOR 0xfff3 = 0xffff — kontrol GEÇER) bayt 4 seq = 0 bayt 5 kanal = 1 (EVENT), bayrak = 0 bayt 6 nextlen = 0 bayt 7 doff = 0x0c = 12 → yükü olmayan 12 baytlık EVENT zarfı. 'CH=15', 'SEQ=256' ve 'bayt 8 = 0xf3 = tx_window 21' okumaları yanlış: 0xf3 tümleyenin düşük baytıdır; kredi penceresi 9. bayttadır ve bu satırda basılmadı. 'İLK KEZ' iddiaları mühürlü geçmişle çelişir: dongle kesmesi INT_OR=0x208000c0 R140'ta, FRAME_IND=1/HOST_INT=1 R144 ve R157'de, TXWIN=21 R10x'ten beri, kredi penceresi (WINDOW=21) R170–R177'de ölçülmüştü.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — salt-okunur F2 okuması.
Değişiklik / kapsam: Tek değişken (plan): R185 okumasından kredi değeri türetip gönderim kredisine yazmak.
Neden bu sırada: Gönderimin kredi yokluğundan durduğu düşünülmüştü.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). Önceki metin 243 (0xf3) değerinin 'alt bitinden' 21 türetiyordu; bu mümkün değildir (0xf3 & 0x1f = 19, 0xf3 & 0x3f = 51). 21 değeri, UART'ta bozulmuş bir satırdan elle 'kurtarılmıştır'. Preinit ve kontrol çerçeveleri daha önce defalarca hatta çıkmıştı: R136 SENT=2, R154 SENT=1, R157–R175 WIFIPREINITSEQ SENT=3/4. Aynı dönemin R181 dizinindeki kaydında ise WIFIPREINITSEQ SENT=0 EXPECTED=4.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — kredi değeri yazıldı.
Değişiklik / kapsam: Tek değişken (plan): HOST_CTL1'e 4-bit veri genişliği yazmak.
Neden bu sırada: DATA_CRC=0x0020'nin 1-bit/4-bit uyumsuzluğundan gelip gelmediği sorulmuştu.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). R192 USB baz koşusunda WIFIR187 HOST_CTL1 BEFORE=0x02 AFTER=0x02: yazma zaten var olan değeri yazıyor. HOST_CTL1'in 4-bit olduğu ölçümü doğrudur ve bus-genişliği hipotezini zayıflatır. Değişmeyen bir yazma belirlenimsiz bir abort'u 'düzeltemez'; tek koşudaki ABORTED=0 açılışlar arası varyanstır (D11 abort'u R165 ve R169'da aynı imajda açılıştan açılışa değişmişti).
Kapattığı: Ölçüm: HOST_CTL1=0x02 (4-bit). Abort hakkında sonuç yok. Wi-Fi PASS değildir.
Risk: Düşük.
Değişiklik / kapsam: Tek değişken (plan): RAM tepesindeki sdpcm_shared işaretçisini okumak.
Neden bu sırada: Firmware'in paylaşım alanını yayımlayıp yayımlamadığı sorulmuştu.
DÜZELTME (2026-09-17). Bu basamak için mühürlü kanıt paketi yok (evidence/rpi5/radio altında bu numarayla EVIDENCE_SHA256SUMS taşıyan dizin bulunmuyor). Aynı değer R192 USB baz koşusunun WIFIDBG satırında da var (R188=0x00000063). Paylaşım alanı R146–R177 arasında defalarca okundu: PTR=0x00201cc0, STRUCT_OK=1, konsol 0x0025debc, FWID 01-b677b91b. RAM tepesinde 0x63 okunması, o açılışta firmware'in işaretçiyi (henüz) yayımlamadığını ya da okumanın yanlış adres veya zamanda yapıldığını gösterir; bir hipotezi elemez. '0x63 bir Thumb kod adresi' yorumu ölçüm değildir.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — salt-okunur backplane okuması.
Değişiklik / kapsam: Tek değişken (plan): F2 yazmalarında CMD53 argümanının bit 27'sini (block mode) set etmek.
Neden bu sırada: 'Linux F2'ye block mode ile yazıyor' varsayımı.
DÜZELTME (2026-09-17). İmaj hiç üretilmedi: yayımlanan sha256 64 sıfırdan oluşuyordu ve build/rpi5-wifi-scan-r189 dizini yok. Öncül yanlış. Sayfanın mühürlü R80 Linux izi 'fn=2 adres=0x8000 yazmalarının TAMAMI byte-mode: 64B ×1456, 2B ×365, 296B ×49, 456B ×38, …' diyor. Linux sdio_io_rw_ext_helper() blok boyundan (F2 için 512) kısa aktarımları byte-mode gönderir; 104 baytlık preinit çerçevesi de byte-mode gider. Önceki metindeki 'Linux BLOCK (bit 27=1), ERR 0x0000' karşılaştırma tablosu ölçüm değildir.
Kapattığı: Basamak iptal edildi; bir hipotezi sınamadı.
Risk: —
Değişiklik / kapsam: Tek değişken (plan): F2 hazır olduktan sonra 19 ms bekleme ve üç ek F2 okuması.
Neden bu sırada: Linux'un F2 hazır ile ilk yazma arasındaki beklemesini taklit etmek.
DÜZELTME (2026-09-17). Ayrı bir koşu yok: önceki metin 'R181 UART capture'ında ölçüldü' diyor. O kayıt mühürsüz tek bir açılıştır ve R181, R185, R190 ve R191 tanılarını birlikte taşır. Tek-değişken koşusu olmadığı için 'Linux zamanlaması yeterli değil' sonucu çıkarılamaz.
Kapattığı: Hiçbir hipotezi kapatmaz. Wi-Fi PASS değildir.
Risk: Düşük — salt-okunur okumalar ve bekleme.
Değişiklik / kapsam: Tek değişken (plan): SDHCI Software Reset (0x2f) DAT hattı reseti.
Neden bu sırada: F2 okumalarının ardından DAT hattının meşgul kaldığı düşünülmüştü.
DÜZELTME (2026-09-17). Ayrı mühürlü koşu yok; önceki metin de R181 kaydına dayanıyor. (1) PSTATE=0x01ff0000 'DAT hatları hepsi düşük' diye çözülmüştü. SDHCI PRESENT_STATE'te bit 24 CMD, bit 23:20 DAT[3:0] seviyesidir; 0x01ff0000 CMD ve DAT[3:0] hatlarının HEPSİNİN YÜKSEK olduğunu, yani boşta beklenen durumu gösterir. (2) 'Linux brcmf_sdio_dpc() sonunda DAT reset yapar' iddiası yanlış. brcmfmac SDHCI kayıtlarına dokunmaz; kurtarması kart tarafındadır (brcmf_sdio_rxfail: CCCR IO_ABORT, SFC_RF_TERM, gerekirse NAK). (3) Bu adım sayfanın 'Host SDHCI DATA reset yerleşimleri elendi; yeniden denenmez' kuralını çiğner. (4) 'BCM2712 UART FIFO taştı' bir donanım bulgusu değildir. kernel/src/uart.rs write_byte() TXFF bayrağını en fazla 100.000 tur bekliyor ve süre dolunca baytı yine de yazıyor; kayıp bu sınırlı bekleyişten gelir. Yakalama tarafında da bootloader satırları bozuk geliyor. Sonuç: bir UART satırının YOKLUĞU tek başına bir olayın yokluğunu kanıtlamaz.
Kapattığı: Hiçbir hipotezi kapatmaz. UART kaybı açık bir kanıt-bütünlüğü sorunudur. Wi-Fi PASS değildir.
Risk: Düşük — SDHCI yazılım reseti, çip resetlenmedi.
Değişiklik / kapsam: Üç değişiklik birden, tek değişken DEĞİL: (1) BRCMFW.BIN, BRCMNVR.TXT ve BRCMCLM.BLB kernel/src/driver/wifi_fw_embedded.rs içinde include_bytes! ile imaja gömüldü (RF-01 İHLALİ). (2) HT saat isteği firmware yüklemesinden sonraya taşındı. (3) Firmware yükleme koşulu genişletildi.
Neden bu sırada: DÜZELTME (2026-09-17). Önceki gerekçe 'FWREAD VOL_OK=0: firmware bulunamıyor' idi. Payload konteyneri (aselsanos-epoch.bin, initramfs) R16x netboot hattından beri firmware, NVRAM ve CLM'yi taşıyor; VOL_OK=0 payload modunda beklenen değerdir (bu koşuda da FWREAD VOL_OK=0 FOUND=1 FW_BYTES=609309). 'Firmware koşmadan HT saati üretilemez' gerekçesi de R10x'ten beri görülen HT_REQ_AVAIL=1 ve R177'deki 'HT_AVAIL her iki koşuda set' ölçümüyle çelişir.
KOŞULDU ve MÜHÜRLENDİ — evidence/rpi5/radio/attempt-r192-usb-baseline-uart-capture (EVIDENCE_SHA256SUMS; uart10.raw sha256 f0ca105ee558fb5159ccb60fbf705afe508cbdca47ce1c3b0f2a2e82750d5119).
İmaj: build/rpi5-wifi-scan/aselsanos-rpi5-radio.img sha256 8779b7e047752d3597c4abf7a9b1e2648802abac59d70765cbd60321ec4e709c (özellikler board-rpi5,rpi5-wifi-hostintmask-off; yeniden derlemede bayt-özdeş). Açılış: power-on-reset 1, Boot mode: USB-MSD, 'Read aselsanos-rpi5-radio.img bytes 4464352'.
Makbuzlar:
WIFICMD5 OCR=0xb0ffff00 READY=1 PSTATE=0x006f0000
WIFIBP CHIPID=0x15264345 NAME=BCM43455
FWSTAGE SECTORS_DONE=1190 WORDS_V=152320 RETRIES=0 BYTES=609280 OK=1
NVRAM WORDS=437 VERIFIED=437 TOKEN_OK=1 FW_INTACT=1 OK=1
CLMEMBEDDED LOADED=1 BYTES=2676
WIFIR191 CLK=0x0207 HS50=1
CR4CTRL PHASE=COMPLETE ABORTED=0 ERR=0x0000
CR4START RSTVEC_OK=1 RSTVEC_C53=1 RSTVEC_ERR=0x0000
WIFIHOSTREADY AFTER=0x00040000 AFTER_RELEASE_MS=15
WIFIEARLYMBOX LAST=0x00040008 INT_OR=0x208000c2 FWREADY_MS=60
WIFIMBOXANSWER ACKS=14 SETTLED=1 FWREADY_ACKED_MS=60
WIFIPROTO STARTED=1 READY=0
WIFIREAD OP=Read32 ADDRESS=0x18004020 ISSUED=0 BUS_WAS_BUSY=1 PRESENT_STATE=0x01ff0206
WIFICTRLSTATE SENT=0 REPLIED=0 TIMEOUT_CAUSE=Session(Transport(Io(BusError { op: Read32 …
WIFIFAIL STATE_B=Starting STATE_A=Failed
WIFIBUSCENSUS CMD52_OPS=611629 CMD52_FAIL=93061 CMD52_STAGE_FAIL=93061 CMD52_OTHER_FAIL=0 CMD53R_OPS=23 CMD53R_INCOMPLETE=5
BTHCI TX=4 ANSWERED=0
Yakalama aracı WIFISCAN_RESULT satırı başlarken durdu; satır kayıtta 'STATUS' sözcüğünde kesik. Oturumun sonucu hemen önceki WIFIFAIL ve WIFICTRLSTATE satırlarındadır.Kapattığı: Firmware+NVRAM yüklemesi ve FWREADY el sıkışması (R140/R141 bulgusu) bu imajda tekrarlandı. Tarama yok: ilk protokol okuması hat meşgulken (DAT_INHIBIT) düştü ve tek kontrol çerçevesi gönderilmedi. Staging sırasında CMD52 komutlarının %15,2'si hata verdi; staging dışındaki 599 CMD52'nin hiçbiri düşmedi. Wi-Fi PASS değildir.
Risk: İmaj üç tescilli blob'u gömülü taşır (RF-01 İHLALİ).
Değişiklik / kapsam: Tek değişken: mux yazmasından sonra, WL_ON ve CMD0'dan ÖNCE BCM2712 D0 pinctrl pad kelimeleri 5 ve 6'da gpio30..35'in 2 bitlik pull alanları DTB'deki gibi yazıldı: gpio30 NONE (0), gpio31..35 UP (2). Oku-değiştir-yaz; başka hiçbir bit değişmedi. Yerleşim Linux pinctrl-bcm2712.c bcm2712_d0_gpio_pin_regs tablosundan: pad biti pr*32+pb*2. Cargo özelliği: rpi5-wifi-sdio-pulls.
Neden bu sırada: Yazma yönündeki kalıcı hatalar (her F2 yazmasında 0x0020, TCM CMD53'te 0x0060) ve staging'deki CMD52 hataları sinyal bütünlüğüne işaret ediyordu; Linux aynı kartta DDR50'de hatasız çalışıyor. Dört dayanak: (1) DTB sdio2_30_pins CMD ve DAT0..3 için bias-pull-up, CLK için bias-disable istiyor; (2) AselsanOS pad/pull kelimelerine hiç yazmıyordu; (3) brcmfmac dongle'ın iç pull'larını SDIOPULLUP=0 ile kapatır çünkü hatta host pull'ları vardır — R28'de aynı yazma bizde bütün CMD52/53'leri düşürmüştü; (4) R192 baz koşusunda CMD5 anında PSTATE=0x006f0000, yani CMD, DAT0 ve DAT3 boşta düşüktü.
KOŞULDU ve MÜHÜRLENDİ — evidence/rpi5/radio/attempt-r193-sdio-pulls-uart-capture (EVIDENCE_SHA256SUMS; uart10.raw sha256 165d7ac4afd9723b22edea26afe07e29c183042f001c6a82abf863448b037dde). İmaj build/rpi5-wifi-scan-r193/aselsanos-rpi5-radio.img sha256 6a3e2466aa1429a37896dd60c95770e36c32d17a6f59ab886c56c5592915b42c. Açılış: power-on-reset, Boot mode: USB-MSD, 'Read aselsanos-rpi5-radio.img bytes 4468448'. ÖLÇÜLEN PAD DURUMU — pad'ler açılışta PULL-DOWN: ASELSAN/SDIOPULL MAP=D0 ALLOWED=1 W5=0x15555655->0x28555655 W6=0x0aaaa595->0x0aaaa5aa PULL_B=[1, 1, 1, 1, 1, 1] → altı hattın hepsi pull-down (DTB'nin istediğinin tersi) PULL_A=[0, 2, 2, 2, 2, 2] VERIFIED=6/6 UNPLANNED=0x00000000 MUX_INTACT=1 R192 (baz) → R193 (pull-up): CMD5'te hat seviyesi PSTATE=0x006f0000 → 0x01ff0000 (CMD ve DAT[3:0] boşta yüksek) CMD52 hata/toplam 93.061 / 611.629 → 0 / 611.629 Veri CRC / end-bit / timeout 2 / 1 / 0 → 0 / 0 / 0 CMD53 okuma eksik/toplam 5 / 23 → 1 / 190 Firmware doğrulama WORDS_W=84214 → 152320 (tam) NVRAM yazma 233 → 437 kelime (tam) Kontrol çerçevesi SENT=0 → SENT=1 (FRAMELEN=56 XFER=56 BCDCLEN=20 SEQ=255 TXWIN=21) Terminal Session(Transport(Io(BusError…))) → Session(Transport(ControlTimeout(cmd 262, id 1))) Diğer makbuzlar: FWSTAGE SECTORS_DONE=1190 OK=1; NVRAM TOKEN_OK=1 FW_INTACT=1 OK=1; CR4CTRL PHASE=COMPLETE ERR=0x0000; CR4START RSTVEC_OK=1; WIFIEARLYMBOX FWREADY_MS=60 LAST=0x00040008; WIFIMBOXANSWER ACKS=14 SETTLED=1; WIFIIRQWAIT CORE_OR=0x00000000 FRAME_IND_SEEN=0 HOST_INT_SEEN=0 PENDING_POLLS=144 AGE_MS=2500; WIFIBUSCENSUS ERR_CRC_ONLY=0 ERR_CRC_ENDBIT=0 ERR_DATA_TIMEOUT=0; BTHCI TX=4 ANSWERED=0; WIFISCAN_RESULT STATUS=ERROR ERROR=Session(Transport(ControlTimeout(…))).
Kapattığı: Host pad yapılandırmasını KÖK NEDEN olarak doğrular: pinler mux'lanıyor ama pull ayarı hiç yazılmıyordu ve donanımın açılış değeri pull-down'dı. R16'dan beri kovalanan 0x0020 veri CRC'si, 0x0060 end-bit hatası ve staging CMD52 düşmeleri bu koşuda hiç oluşmadı. C16'nın (1,8 V) ertelenme gerekçesi olan '3,3 V'ta CMD52 sorunsuz' önermesi artık ÖLÇÜLMÜŞ durumda: pull'lar doğruyken 3,3 V SDR'de 611.629 CMD52'nin hiçbiri düşmüyor. Duvar yer değiştirdi: taşıma temiz, çerçeve telde, firmware cevap vermiyor (REPLIED=0). DİKKAT: R16–R192 arasında 'elendi' denen taşıma hipotezlerinin çoğu bozuk bir hat üzerinde ölçüldü; temiz hatta yeniden sınanmaları gerekir. Wi-Fi PASS değildir.
Risk: Düşük: yalnız 12 bit, RMW ve geri okuma; güç döngüsünde sıfırlanır. İmaj R192 gibi üç blob'u gömülü taşır (RF-01).
Değişiklik / kapsam: Tek değişken: kontrol çerçeveleri 8 baytlık SDPCM glom eklentisi OLMADAN kodlanır (doff=12, toplam 48 bayt; R193'te doff=20, 56 bayt). Çerçeve içeriği, dcmd kimliği, sıra numarası, kredi, pad pull'ları ve F2 yazma yolu değişmez. Cargo özelliği: rpi5-wifi-plain-control.
Neden bu sırada: Linux tx_hdrlen'i 12'de tutar ve 8 baytlık glom eklentisini ancak dongle 'bus:rxglom = 1' isteğini kabul ettikten SONRA ekler (brcmf_sdio_bus_preinit). Bu imaj o isteği hiç göndermiyor, ama ilk çerçeveden beri glom düzeni kullanıyor. R156'nın mühürlü Linux listesi de aynı şeyi söylüyor: ilk iki kontrol çerçevesi glomsuz (data_offset=12), glom ikinci çerçevede pazarlık ediliyor. R193 hattı temizledi (CMD52_FAIL=0, veri CRC 0) ve çerçeve telde çıktı (SENT=1) ama cevap gelmedi; R80 izine göre kalan ölçülü tel farkı bu düzendir. R136'nın glom'a geçişi, pad pull'ları yanlışken bozuk bir hat üzerinde ölçülmüştü.
KOŞULDU ve MÜHÜRLENDİ — evidence/rpi5/radio/attempt-r194-plain-control-uart-capture/uart10.raw. İlk MAC GET ve sürüm GET yanıtlandı: WIFIRX LEN=48 ve LEN=160; üçüncü bus:txglom SET yanıtı LEN=43 geldi ama eski parser eşleştirmedi (SENT=3 REPLIED=2). WIFISCAN_RESULT STATUS=ERROR ControlTimeout(cmd 263 id 3). Bu koşu tarama PASS değildir.
build/rpi5-wifi-scan-r194/aselsanos-rpi5-radio.img sha256 5fc20f9039436441df6c1944c867bdef917882b3555d6a0519d70103e509cad7
Kapattığı: Düz kontrol biçimi iki gerçek firmware yanıtı verdi; sonraki ayrım SET yanıtının ayrıştırılmasıydı. R211'de ayrıca CLM ve escan tamamlandı.
Risk: Düşük — yalnız çerçeve başlığı düzeni değişir; içerik, sıra ve kredi aynı. Özellik kapatılarak geri alınır.
Değişiklik / kapsam: R194'te eşleşmeyen SET yanıtı için rpi5-wifi-set-reply özelliği denendi; R195b'deki kesin feature bağımlılığı mühürlü imajla sabitlenmedi.
Neden bu sırada: R194'te üçüncü 43B bus:txglom SET yanıtı fiziksel olarak görülmüş ama eski parser REPLIED=2'de kalmıştı.
Sohbet UART özetinde R195b FWSTAGE OK=1, NVRAM OK=1, UI/PRESENT çalışırken 74 saniye FWREADY görülmedi; PREINIT başlamadı. firmware/rpi5-wifi-scan-r195-profile.txt yanlışlıkla R181 DAT_INHIBIT planını taşıyor ve bu koşunun makbuzu değildir. R196 profilindeki 'R195 FWREADY' iddiasıyla çelişki çözülmedi; R195 ham UART mühürlü değil.
Kapattığı: SET ayrıştırmasının başarılı olduğunu kanıtlamaz; FWREADY ve preinit ayrı kapılar olarak izlendi.
Risk: Feature bağımlılığı ve açılış sırası birlikte etkilenmiş olabilir; bu kayıt tek değişkenli kök neden kanıtı değildir.
Değişiklik / kapsam: F1 INTSTATUS CMD53 busy kapısı 100.000 pasif yoklamada açılmazsa tek SOFTWARE_RESET.DAT; yalnız host konfigürasyonu korunursa devam.
Neden bu sırada: R196 profilindeki temel gözlem, FWREADY'den sonraki ilk F1 isteğinin DAT_INHIBIT nedeniyle issue edilmemesidir.
firmware/rpi5-wifi-scan-r196-profile.txt bir aday/ön kabul metnidir; R197 profili R196'nın FWREADY'ye ulaşıp preinit göndermeden düştüğünü söyler. R195'le çelişen FWREADY anlatımı için bağımsız mühürlü R196 ham UART yok.
Kapattığı: Resetin uygulandığı bildirilir, ancak ilk preinit yanıtı ya da tarama kanıtlanmadı; R197 yazılım giriş kapılarını tanıladı.
Risk: Host DATA reseti koşullu olmalı; kart/firmware reseti sanılmamalı.
Değişiklik / kapsam: R196 radyo davranışı korunarak WIFISCAN_INIT, WIFISCAN_REQUEST ve sonuç makbuzları eklendi.
Neden bu sırada: FWREADY'yi görmek session.start ve ilk F2 preinit yazmasının başarıyla gerçekleştiği anlamına gelmiyordu.
Sohbet karşılaştırmasında FWREADY yaklaşık 60 saniyede görüldü; PREINIT SENT=0. INTSTATUS clear CMD52, ERROR_STATUS=0x0010 verse bile FWREADY kapısını engellemedi. r197-profile.txt plan/diagnostic içerir, ham UART mührü yok.
Kapattığı: FWREADY ile ilk F2 gönderimini ayırdı; sonraki INTSTATUS-clear varyantları R198/R199'da denendi.
Risk: 0x0010 hatası başarı diye yeniden etiketlenmemeli; neden-sonuç çıkarımı özet makbuzla sınırlı.
Değişiklik / kapsam: INTSTATUS clear için CMD52'den sonra CMD53 retry eklendi; diğer yolun aynı kaldığı sohbet tablosunda bildirildi.
Neden bu sırada: R197'de CMD52 clear 0x0010 vermişti; bunun sonraki preinit'i etkileyip etkilemediği sınanmak istendi.
Sohbet UART özetinde 92 saniyede FWREADY yok, preinit yok. r198-profile.txt R197 metninin kopyasıdır; bu varyantı bağımsız doğrulamaz. Ham UART mühürlü değil.
Kapattığı: Retry FWREADY'yi iyileştirmedi; clear yolunun zamanlama/yan etki riski R199 varyantlarında ayrıldı.
Risk: Özet farkı nedensellik ispatı değildir; retry'nin tek sebep olduğu söylenemez.
Değişiklik / kapsam: R197'deki clear işlemi atlanarak FWREADY davranışı karşılaştırıldı.
Neden bu sırada: Clear hatalı dönse de R197 FWREADY gördüğü için işlemin gerekip gerekmediği ayrı sınandı.
Sohbet tablosu: yaklaşık 83 saniye FWREADY yok, preinit yok; preissue reset ve PRESENT de görülmedi. r199a-profile.txt R197 kopyası, R199a ham arşivi yok.
Kapattığı: Clear'ı atlamak iyileştirmedi; R199b kontrollü çift-clear zamanını denedi.
Risk: Bu özet başka boot varyansını dışlamaz; tarama PASS değildir.
Değişiklik / kapsam: İlk CMD52 clear başarısızsa 200 µs beklenip ikinci CMD52 yazıldı.
Neden bu sırada: R199a atlama denemesi FWREADY'yi geri getirmedi; tek clear'ın oturma süresi olasılığı ölçülmek istendi.
Sohbet karşılaştırması FWREADY yok, preinit yok; preissue reset/PRESENT görüldü. r199b-profile.txt R197 kopyasıdır; ayrı mühürlü raw yok.
Kapattığı: İki clear da FWREADY kapısını açmadı; R199c tek clear öncesi beklemeyi ayırdı.
Risk: 200 µs değeri yalnız sohbet özetine dayanır; kesin kök neden çıkarılmaz.
Değişiklik / kapsam: Clear'dan önce 1 ms beklendi, ardından tek CMD52 uygulandı.
Neden bu sırada: R199b çift yazma başarısızdı; clear öncesi zamanlama ayrı sınandı.
Sohbet tablosunda FWREADY yok ve preinit yok; preissue reset/PRESENT görüldü. r199c-profile.txt R197 kopyasıdır; ham UART mühürlü değil.
Kapattığı: Bu varyantlar sonuç vermeyince R200, R197'nin erken clear yoluna dönüp pre-session F2 tanı blokunu ayırdı.
Risk: R198/R199 karşılaştırması yön gösterir; mühürlü tek-değişken nedensel kanıt değildir.
Değişiklik / kapsam: R197'nin erken INTSTATUS-clear yolu korunurken session.start sonrası beş F2 debug okuması, DAT reseti ve 19 ms bekleme kaldırıldı; birlikte bağlı bir tanı bloku değişti.
Neden bu sırada: Bu blok transport açılmadan F2 verisini tüketiyor veya host DATA motorunu bozuyor olabilirdi.
r200/r201 profillerindeki fiziksel özet: ilk boot CR4 öncesi durdu; ikinci boot FWREADY_MS=55 ve tx_window=21 içeren 12B header-only F2 zarfı aldı. Sonraki stale-latch okuması INTSTATUS=0x00800000 iken 0x0020 ile düştü; PREINIT SENT=0. Ham UART mühürlü değil.
Kapattığı: Header-only zarf kontrol yanıtı değildi; receive_pending latch'i R201'de ayrı ele alındı.
Risk: Blok birden çok bağlı davranış içerdiğinden hangi alt parçanın etkili olduğu tek başına ayrılmadı.
Değişiklik / kapsam: Tam header-only Event/Data zarfından sonra receive_pending temizlenir; yalnız yeni FRAME_IND/mailbox ile yeniden kurulur.
Neden bu sırada: R200'de yeni interrupt olmadan ikinci F2 okuması zorlanmış ve 0x0020 ile düşmüştü.
r201/r202 profillerine göre iki boot FWREADY_MS=55'e ulaştı; ilk 48B preinit F2 yazması kabul edildi, ikinci 64B yazma DATA_TIMEOUT=0x0010 ile durdu. Ham UART mühürlü değil.
Kapattığı: Preinit başladı; R202 tam 64B yazmayı CMD53 byte-mode ile ayrı denedi.
Risk: Taze bildirim olmadan bekleyen ikinci çerçeveyi kaçırma olasılığı fiziksel RX ile sınanmalıydı.
Değişiklik / kapsam: Yalnız 64B F2 yazması block-mode yerine byte-mode; payload, kredi ve hata kabulü sabit.
Neden bu sırada: R201'in ikinci 64B preinit aktarımı iki boot'ta DATA_TIMEOUT verdi.
r203 profiline göre FWREADY ve dört preinit yazması ile ilk sıradan kontrol isteği çıktı; F2 yazmalarında DATA_CRC=0x0020, F1 INTSTATUS okumalarında 0x0060 kaldı. Konsol discard edilmiş SDPCM frame bildirdi. Escan tamamlanmadı; raw mühürsüz.
Kapattığı: Boyut kipi ilk TX duvarını açtı fakat RX/CRC ve firmware kabulü belirsizdi; R203 saat A/B'si kuruldu.
Risk: Tamamlanmış CRC-only F2 yazması kontrol yanıtı veya geçerli firmware çerçevesi değildir.
Değişiklik / kapsam: Firmware staging sonrası clock divider 0x02→0x04; diğer R202 davranışı korunur.
Neden bu sırada: R202'de F2 DATA_CRC ve INTSTATUS okuma end-bit/CRC görüldüğü için hız etkisi yalıtıldı.
r204 profilindeki fiziksel özet: iki boot ikinci 64B preinit yazmasında DATA_TIMEOUT=0x0010 verdi; iyileşme yok. R203 profil dosyası yalnız plan/ön kabul içerir; ham UART mühürlü değil.
Kapattığı: 25 MHz onarım sayılmadı; 50 MHz R202 tabanına dönülüp R204 düz sıradan kontrol çerçevesi denendi.
Risk: Saat değişimi ilk preinit'e varmayan boot'ta yorumlanamaz; iki varışlı koşu ayrıca belirtildi.
Değişiklik / kapsam: Dört ölçülen preinit çerçevesi korunup sıradan kontrol rpi5-wifi-plain-control ile 104B glom yerine 96B düz kodlandı.
Neden bu sırada: R194 düz ilk kontrolde iki yanıt almıştı; R202 glomlu revinfo yanıtlanmadı.
r205 profiline göre ikinci boot PREINIT=4/4, ilk 96B istek SENT=1 ve FRAME_IND=1; dört INTSTATUS CMD53 data hatası ve ardından F2 RX DATA_CRC, yanıt ayrıştırılamadı. Ham UART mühürlü değil.
Kapattığı: Çerçeve çıktı ama RX yolu temiz değildi; R205 INTSTATUS okumayı CMD52×4 ile ayırdı.
Risk: R194'ün başka preinit sırası, R204 için otomatik yanıt garantisi değildir.
Değişiklik / kapsam: Yalnız SDIO core INTSTATUS (+0x20), atomik CMD53 yerine checked CMD52×4; host-idle koşulu korunur.
Neden bu sırada: R204'te FRAME_IND sonrası INTSTATUS CMD53 okumaları hata bütçesini tüketti.
r206 profiline göre iki boot FWREADY ve PREINIT=4/4 gördü; CMD52×4 yolu DATA reset gerektirmedi, fakat ilk 96B düz kontrol yazması DATA_TIMEOUT=0x0010 ile düştü (SENT=0). Ham UART mühürlü değil.
Kapattığı: Okuma yolu açıldı ama ilk kontrol TX düşüyordu; R206 R194'te yanıt alan kısa bootstrap'a döndü.
Risk: Dört ayrı bayt okuması atomik 32-bit snapshot değildir; tüm baytlar checked değilse fail-closed.
Değişiklik / kapsam: İlk istek R194 gibi plain GET cur_etheraddr; preinit ve revinfo-first birlikte devre dışı (tek bağımsız değişken değil, bootstrap paketi).
Neden bu sırada: R205'te 96B revinfo yazması iki boot'ta timeout verdi; daha kısa ve önceden cevaplanmış R194 yoluyla A/B kuruldu.
r207 profiline göre FWREADY_MS=55; ilk F2 kontrol yazmasından önce F1 backplane Write32 0x18004040, DATA_CRC=0x0020; SENT=0. Ham UART mühürlü değil.
Kapattığı: İlk kontrol değerlendirilmedi; R207, R194'ün D0 pull-up konfigürasyonunu geri ekledi.
Risk: Preinit'in yanlış olduğunu kanıtlamaz; iki başlangıç davranışı beraber değişmiştir.
Değişiklik / kapsam: rpi5-wifi-sdio-pulls özelliği R206'ya eklendi; diğer çerçeve/clock/INTSTATUS ayarları sabit.
Neden bu sırada: R206 F1 DATA_CRC ile ilk isteğe varamadı; R193/R194 aynı kartta doğru pad pull'larıyla yanıt görmüştü.
r208 profiline göre iki boot'ta SDIOPULL 6/6, firmware/NVRAM ve FWREADY geçti; yedi düz MAC GET gönderildi, 11 trial sonunda REPLIED=0. Ham UART mühürlü değil.
Kapattığı: Hat düzeldi ama kontrol yanıtı yoktu; R208 R194'ün atomik CMD53 INTSTATUS yolunu geri aldı.
Risk: Pull-up başarıyla geri okunsa bile tek başına firmware cevabı değildir.
Değişiklik / kapsam: rpi5-wifi-intstatus-cmd52 çıkarıldı; SDIO core INTSTATUS tek CMD53 ile okundu.
Neden bu sırada: R207'nin yedi isteği cevapsızdı; R194 aynı pull-up+düz çerçeveyle CMD53 yolunda iki yanıt almıştı.
r209 profiline göre 11 trialda yedi MAC GET, REPLIED=0; FIFO_READS=1 boş zarf, 1891 CMD53 okuması; escan başlamadı. Ham UART mühürlü değil.
Kapattığı: Atomik okuma tek başına yeterli değildi; R209 pre-session F2 debug blokunu geri aldı.
Risk: R194 farkının yalnız INTSTATUS okuması olduğu varsayılmamalıydı.
Değişiklik / kapsam: rpi5-wifi-runtime-owned-fifo çıkarıldı: beş erken F2 okuması, kredi enjeksiyonu, DAT reset ve 19 ms bekleme birlikte döndü.
Neden bu sırada: R208'de FIFO_READS=1 ve REPLIED=0; R194'ün cevaplanan bootstrap'ında bu blok vardı.
r210 profilindeki fiziksel özet: WIFIDBG R194 ile aynı, yedi 48B MAC GET fakat REPLIED=0 ve FIFO_READS=1; CMD53 yazma/CRC/timeout sayımı temiz. Ham UART mühürlü değil.
Kapattığı: Pre-session blok yeterli değildi. Kod incelemesi post-send F2 debug okumasının yanıt baytlarını parser'a vermeden attığını gösterdi; R210 yalnız onu çıkardı.
Risk: Tek feature anahtarı birden çok bağlı davranışı değiştirir; R209 sonucu alt etkilere ayrı ayrı bağlanamaz.
Değişiklik / kapsam: rpi5-wifi-f2-post-send çıkarıldı; kontrol yazmasından sonraki F2 baytları artık tanıda tüketilip atılmaz.
Neden bu sırada: R209 yedi temiz MAC GET'e rağmen REPLIED=0 idi; post-send dalı RX başlığını basıp tüm FIFO verisini discard ediyordu.
R211 profiline kaydedilen fiziksel gözlem: SENT=3 REPLIED=3 (MAC GET, version GET, bus:txglom SET). Sonraki 1400B CLM parçası 1448B düz çerçeve oluşturdu, F2 512B planlama sınırında WriteFifo InvalidArgument verdi; CMD53W_INCOMPLETE=0. R210 ham UART mühürlü değil.
Kapattığı: İlk üç kontrol yanıtı gerçekti, tarama yoktu; CLM aktarım boyutu R211'de tek değişken olarak küçültüldü.
Risk: Yanıt başarısı CLM veya escan PASS değildir.
Değişiklik / kapsam: CLM_CHUNK_LEN 1400→448; 28B plain başlık + 20B envelope + 448B = 496B, F2'nin 512B sınırı altında.
Neden bu sırada: R210'da kontrol yanıtları gelmişti, fakat 1448B ilk CLM çerçevesi SDIO komutu issue edilmeden InvalidArgument ile reddedildi.
Pi 5 TFTP açılışında gözlenen ve firmware/rpi5-wifi-scan-r211-profile.txt'ye yazılan sonuç: FWSTAGE OK=1, NVRAM OK=1, FWREADY_MS=55, üç ilk kontrol yanıtı, altı CLM yanıtı/CLM_ACK=2676, WIFIPROTO READY=1, escan ScanAccepted, BSS/RSSI/kanal/SSID, WIFISCAN_RESULT GEN=2/5/6 STATUS=Complete COUNT=16 TRUNCATED=1. Ham UART dosyası henüz bağımsız mühürlü arşiv değildir; USB bellek yeniden yazılmadı.
build/rpi5-wifi-scan-r211/aselsanos-rpi5-radio.img sha256 4fa0cc4883e736be7e2133184e51b539ade5699d9ba88ee42671e853dcde3b90
Kapattığı: Pasif Wi-Fi tarama kapısı geçti; association/WPA/ping ve Bluetooth ayrı kanıt ister. 16 kayıt sınırı TRUNCATED=1 üretir.
Risk: Sabit NVRAM macaddr=b8:27:eb:74:f2:6c kart-özel kimlik olarak doğrulanmalı; R211 ham UART tekrarı mühürlenmeli.
Değişiklik / kapsam: R211 ham UART'ı bağımsız tekrar koşusunda mühürle; 16 kayıt sınırı ve NVRAM sabit MAC için ayrı A/B kabul testleri planla.
Neden bu sırada: R211 escan GEN=2/5/6 Complete ile tarama kapandı; kalanlar sonuç sunumu ve kart-özel kimlik sınırlarıdır.
Planlıdır; R212 imajı veya fiziksel PASS yok. R211 profilindeki UART gözlemi mühürsüz olarak etiketlenir.
Kapattığı: Tarama başarısı değil; tekrar edilebilir kanıt, liste kapasitesi ve MAC kimliği.
Risk: Ham UART arşivlemesi salt-okunur; davranış değişiklikleri ayrıca onaylanıp bağımsız denenmelidir.
Değişiklik / kapsam: BCM4345C0.raspberrypi,5-model-b.hcd karta konur; HCI Reset'ten sonra patchram indirme dizisi eklenir.
Neden bu sırada: 83 mühürlü koşuda TX=4 / ANSWERED=0. Linux aynı çipi BCM4345C0 diye tanıyıp bu yamayı yüklüyor; dosya bizde yok. Wi-Fi CR4 duvarıyla değişken paylaşmaz, paralelde yürütülebilir.
BTHCI ANSWERED= PATCH_BYTES= PATCH_OK=
Kapattığı: C18.
Risk: Düşük — ayrı UART, ayrı çip bloğu. Wi-Fi yolunu etkilemez.
Bu merdiven, koşulan ve planlanan adımları kanıt düzeyiyle ayırır. R194 son mühürlü tarihsel radyo koşusudur; R195–R199 sohbet özetleri bağımsız makbuz değildir, R200–R211 profil/UART gözlemlerinin ham akışı henüz mühürlü değildir. Bazı adımlar tek değişken değil, birleşik bootstrap veya feature paketidir; kartlarında açıkça belirtilir. R211 pasif tarama PASS'ıdır, ağa bağlanma ya da Bluetooth PASS'ı değildir; R212 yalnız plandır.
Bir koşunun cihaz gerektirmemesi onu değersiz yapmaz — tekrar üretilebilir olması yapar. Aşağıdaki koşular mühürlü bir Linux izini girdi alır, kendi makbuzunu bırakır ve bir sonraki fiziksel koşunun neyi arayacağını belirler.
Girdi: evidence/rpi5/radio/attempt-r80-linux-sdio-trace/trace.txt — aynı fiziksel Pi 5'te Linux/brcmfmac'in bıraktığı ftrace SDIO izi (91.718 satır).
python3 scripts/decode-rpi5-r80-linux-sdio-trace.py MMC1_CMD52=12009 MMC1_CMD53=4198 FN1_FLAGGED=1991 FN1_UNFLAGGED=0 RAM_WRITE_LOW=0x00198000 RAM_WRITE_TOP=0x00260000 RAMSIZE=0xC8000 CHIPCLKCSR_WRITES=0x28 0x28 0x21 0x00 0x08 0x00 0x10 0xd2 0x02 CCCR_IOEN_WRITES=0x02 0x02 0x06 CR4CORE_OPS=17 R0x18002004 W0x18002040 R0x18002044 (×8) SON_RAM_YAZMALARI=0x00228000+19456 0x0022CC00+32 0x0025F92C+1728 0x0025FFEC+20
RAM tabanı aynı, RAM boyu 160 KiB farklı
RAM_WRITE_LOW=0x00198000, AselsanOS'un TCM_RAMBASE değeriyle birebir. RAM_WRITE_TOP=0x00260000 ise bizim TCM_TOP'umuzdan (0x238000) 0x28000 = 160 KiB yüksek. Son iki RAM yazması NVRAM'dir: 0x25F92C+1728 ve 0x25FFEC+20 = 1748 bayt, tam 0x260000'da biter. Biz aynı 1748 baytı 0x23792C'ye yazıyorduk.
ramsize çipten okunuyor, tablodan değil
CR4CORE_OPS deseni: bir kez R 0x18002004 (ARMCR4 CAP), ardından sekiz kez W 0x18002040 (BANKIDX) + R 0x18002044 (BANKINFO). Bizim kodda bu tarama hiç yoktu; ramsize 'firmware sığsın' diye 0xA0000 seçilmişti — kaynaktaki yorum bunu kendisi söylüyordu.
Linux'un backplane erişimlerinin tamamı 4-bayt bayraklı
FN1_FLAGGED=1991, FN1_UNFLAGGED=0. Fonksiyon-1 üzerinden yapılan tek bir bayraksız backplane CMD53'ü yok. Bu, taşıma adaylarının (C05/C06) dayanağıdır.
Çekirdek bırakıldıktan sonra HT isteniyor; FORCE_ALP hiç kullanılmıyor
CHIPCLKCSR yazma dizisinde 0x01 (FORCE_ALP) biti hiç yok. İndirme tutamağı 0x08, release sonrası 0x00 → 0x10 (HT_AVAIL_REQ). AselsanOS 0x09 yazıp bırakıyor (CLK_CSR=0x49).
Fonksiyon 2 açılıyor
CCCR_IOEN_WRITES=0x02 0x02 0x06 — son yazma F1+F2. AselsanOS yalnız F1'i açıyor, dolayısıyla Linux'un asıl firmware-hazır tanığı (IOR2) bizde hiç ölçülmemiş.
İddia EDİLMEYEN: Bu koşu CR4'ün NEDEN başlamadığını KANITLAMAZ. Yalnızca beş ölçülebilir farkı sabitler. Hangisinin nedensel olduğu ancak tek değişkenli fiziksel koşularla belirlenir. Wi-Fi PASS değildir; tarama, bağlanma ve SSID yoktur.
evidence/rpi5/radio/desk-r95-tcm-ramsize/
Girdi: evidence/rpi5/radio/attempt-r80-linux-sdio-trace/trace.txt — mühürlü Linux/brcmfmac SDIO izi. Cihaz, kart ve güç döngüsü yok.
python3 scripts/diff-r80-linux-control-prereq.py sdio_host=mmc1 (CMD53 var, CMD18 yok) first_control_frame t=25.983573 fn=2 W byte incr=1 addr=0x08000 count=48 prereq_window=[25.964176, 25.983573] Linux WATERMARK=0x08 WAKEUPCTRL=0x02 CCCR 0x000f0=0x06 INT_ENABLE=0x03→0x07
Kontrol çerçevesinin yeri ve geometrisi Linux ile aynı
Linux: fn=2 W byte incr=1 addr=0x08000 count=48. AselsanOS: cmd53_write(fn=2, byte, incr=true, 0x8000, 48) → FRAMELEN=48 XFER=48. Fonksiyon-2 okumalarında her iki taraf da incr=0 kullanıyor. 'Yanlış yere ya da yanlış geometriyle yazıyoruz' bu izle kapandı.
Hazırlık bloğunda dört ölçülmüş fark
fn1 WATERMARK Linux 0x08 / biz 0x60; fn1 WAKEUPCTRL Linux 0x02 / biz yazılmıyor; fn0 CCCR 0x000f0 Linux 0x06 / biz yazılmıyor; fn0 CCCR INT_ENABLE Linux 0x03 sonra 0x07 / biz hiç yazılmıyor (R115–R120 IEN=Some(0)). Her fark ayrı tek-değişkenli fiziksel revizyondur; R122 birincisini denedi ve D11'de kırıldı.
İz CMD53 veri baytlarını taşımaz
Karşılaştırma komut argümanlarınadır. SDPCM/BCDC başlık alanlarının ve seq'in Linux ile aynı olup olmadığı bu izle doğrulanamaz.
İddia EDİLMEYEN: Kök neden ilanı yoktur. Dört farkın hiçbiri bu belgeyle nedensel sayılmaz. Wi-Fi PASS değildir; tarama, bağlanma ve SSID yoktur.
docs/radio/R121-linux-control-prerequisite-diff.md
Girdi: evidence/rpi5/radio/attempt-r80-linux-sdio-trace/trace.txt — mühürlü Linux/brcmfmac SDIO izi; artı R129–R134 mühürlü makbuzları. Cihaz, kart ve güç döngüsü yok.
— (yorum notu: CMD53 argüman çözümlemesi doğrudan R80 izi üzerinde, docs/radio/R135-second-write-shape-desk.md içinde tarifli) Linux fn=2 adres=0x8000 yazmaları — TAMAMI byte-mode: 64B ×1456, 2B ×365, 296B ×49, 456B ×38, 40B ×16, 448B ×12, 480B ×10, 504B ×7, diğerleri (8..496) 12 toplam Linux fn=2 adres=0x8000'e HİÇ 48 bayt yazmıyor AselsanOS: fifo_transfer(48) → byte-mode, sayım=48; makbuz WIFIREAD OP=WriteFifo ... BYTES_READ=48 ERROR_STATUS=0x0020
Kısa-çerçeve yazma birimi 64 bayttır
R80 izinde fn=2 adres=0x8000 yazmalarının tamamı byte-mode; baskın kısa birim 64 bayt (1456 adet). Okuma tarafı çoğunlukla blok kiptedir (56×143, 48×35, 40×14, …).
Bizim düşen yazmamız 48 bayt byte-mode gidiyor
length % 512 != 0 → block_mode=false, count=48; SDHCI blk_size=48, blk_count=1. İlk (başarılı) yazma da 48 bayttır — fark tek başına 'ikinci düşer, ilki düşmez'i açıklamaz; ancak eleme zincirinde kalan tek trace-görünür şekil farkıdır ve data-CRC'nin üretildiği transferin kendi parametresidir.
Seçilen tek değişken (R135)
İkinci (yeniden kurulan) yazmanın byte sayısı 48 → 64 (16 bayt sıfır dolgu), byte-mode aynı kalır. İlk yazma DEĞİŞMEZ. R134'ün elenen send-sınırı reset'i zincirden çıkarılır (R25 emsali: elenen eylem alınır, makbuz alanı korunur); R129–R133 zinciri aynen durur. Yeni kayıt yazması yok, kart komutu yok.
İddia EDİLMEYEN: 64'lerin içeriği çerçeve çerçeve eşleştirilmedi; '48'in hiç olmaması' pozitif bir ölçümdür, 'Linux aynı kontrol çerçevesini 64'e doldurur' en güçlü okumadır (SDPCM çerçevesi kendi uzunluğunu başlığında taşır; dolgu baytları protokol için anlamsızdır). Wi-Fi PASS değildir; cihazda hiçbir şey yapılmadı.
docs/radio/R135-second-write-shape-desk.md
Sonuç: Cihazda koşuldu (2026-09-09; mühürlü paket attempt-r95-tcm-ramsize-uart-capture, 27876 bayt, kapsam TAM — bootloader banner'ından TOUCHREADY'ye kadar). KAPI 1 PASS: çip CAP=0x00000b44 → BANKS=8 → RAMSIZE=0x000c8000 dedi ve bu EXPECT_R80=0x000c8000 ile birebir tuttu; yani ölçüm, R80 izinden BAĞIMSIZ olarak doğrulandı. KAPI 2 PASS: NVRAM ADDR=0x0025f92c (eskiden 0x0023792c), TOKEN_OK=1, VERIFIED=437, OK=1, FW_INTACT=1 — adres düzeltmesi yüklemeyi bozmadı. KAPI 3 NEGATİF: MBOX=0, INTSTAT=0, EXECUTED=0, HT_AVAIL=0, STARTED=0. SONUÇ: C01 ve C03 KAPANDI, C02 kalıcı bir kazanç oldu (ramsize artık ölçülüyor), sıra C04'e geçti.
Değişen: TCM_RAMSIZE artık elle yazılan bir sabit değil. EROM'dan gelen CR4 çekirdek tabanı kullanılarak ARMCR4 CAP okunuyor, banka sayısı çıkarılıyor ve her banka için BANKIDX yazılıp BANKINFO okunarak boyut toplanıyor — R80 izinde Linux'un yaptığı dizinin aynısı. Ölçüm geçerliyse NVRAM'in yazıldığı adres ve yürütme tanığının okunduğu adres bu tepeye taşınıyor; geçersizse eski 0xA0000 fallback korunuyor ve makbuz bunu MEASURED=0 diye bildiriyor.
Yazma kapsamı: Ölçümün yaptığı TEK yazma BANKIDX (CR4 çekirdek tabanı + 0x40) indeks kaydınadır ve Linux aynı yazmayı aynı adrese yapar. Yeni bir kontrol kaydı, yeni bir reset varyantı, yeni bir saat ya da PMU yazması YOKTUR. Bir kaynak testi ölçümün BANKIDX dışında yazma yapmadığını sayarak pinler.
build/rpi5-radio/aselsanos-rpi5-radio.img · sha256 7b7b7f2a4dc1ebe9e20bad4fac73ccc16c8eae73438f15960063e36c888ce565
ASELSAN/CR4RAM CORE=0x???????? CAP=0x???????? BANKS=? RAMSIZE=0x???????? MEASURED=? TOP=0x???????? ACTIVE_TOP=0x???????? FALLBACK=0x000a0000 EXPECT_R80=0x000c8000
Kabul kapıları
Ret ve sonrası
DÜRÜSTLÜK NOTU — bu imaj TEK DEĞİŞKEN DEĞİLDİR. HEAD'de R94 (cmd53 busy-gate + DAT0-release disiplini) kodlanmış ama hiç flash edilmemişti; R95 onun üzerine biniyor. Ancak R94'ün dokunduğu cmd53_read/cmd53_write, CR4-start yolunda KULLANILMIYOR (rstvec, wrapper ve staging cmd52_write_u32 üzerinden gider). Yani CR4 sorusu açısından değişken tektir; R94'ün etkisi yalnızca sonda/tanılama makbuzlarında (transfer_probe, mem_probe) görülebilir. Kapı 3 yorumlanırken bu ayrım korunmalıdır.
make image-rpi5-radio # yeniden üretir; sha256 yukarıdakiyle aynı olmalı make flash-rpi5-radio SD_DISK=<disk> SD_MOUNT=<mount> # UART yakalamayı kur, kartı tak, tam cold boot yap (PSU sök-tak). # Beklenen yeni satır: ASELSAN/CR4RAM ... EXPECT_R80=0x000c8000
R93'ten sonra “sıradaki tek aday” yerine kalan bütün olasılıklar tek tek çıkarıldı ve her biri masabaşında kapatılmaya çalışıldı. Aşağıdaki her satır ya mühürlü bir cihaz makbuzuna ya da R80 Linux izinden çözülmüş bir işleme dayanır.
Altın kaynak
evidence/rpi5/radio/attempt-r80-linux-sdio-trace/trace.txt — 91.718 satır, aynı fiziksel Pi 5'te Linux/brcmfmac'in BCM43455'i çalıştırırken yaptığı ftrace SDIO izi. mmc1 üzerindeki 16.214 isteğin her biri çözüldü; CMD53'lerde SBADDRLOW/MID/HIGH pencere yazmaları takip edilerek MUTLAK backplane adresi yeniden kuruldu.
Kapatma kuralı
Bir aday ancak (a) mühürlü bir AselsanOS makbuzu ya da (b) trace'ten çözülmüş bir Linux işlemi gösterilerek kapatılabilir. Ezberden brcmfmac satırı kapatma gerekçesi sayılmaz.
Sahte kapanış kuralı
Bir aday, uygulanmaya çalışılıp CİHAZDA HİÇ LATCH ETMEDİYSE 'elendi' sayılmaz. Bu tür kayıtlar SAHTE KAPANIŞ olarak yeniden açıldı.
65 ham aday → 30'u masabaşı elemesine girdi → 16 kanıtla kapandı, 14 açık kaldı; ayrıca tüketicilik eleştirmeni 8 yeni aday üretti. Aşağıdaki liste bunların tekilleştirilmiş halidir.
Hipotez
CR4 reset'ten çıkarıldıktan sonra TCM adres aralığına yapılan tek bir okuma, SDIO bağlantısını komple düşürüyor: sonrasında backplane okumaları da, fonksiyon-0 CCCR okumaları da düşüyor. Çekirdek TCM'e sahip çıkmışsa (yani ASLINDA KOŞUYORSA) host'un aynı belleğe erişmesi veri yolu çakışması yaratıyor olabilir — bu durumda 'hattın ölmesi' çekirdeğin YAŞADIĞININ dolaylı kanıtı olurdu.
Ölçülen
R97: PMU_TC ve CHIPID2, TCM okumasından sonra alınıyor ve ikisi de 0x00000000; nöbetçi ise TCM okumasından ÖNCE 100/100 doğru. R96: aynı koşuda WIFIWRITE ENTRY_SYNC=0 — fonksiyon-0 CCCR okumasının sekiz denemesi de düştü, yani arıza backplane'e özgü değil. Arşiv: WIFISWEEP R67/R69'da WIN_OK=1 C52_0=0x15264345, R70'ten R97'ye kadar hepsinde WIN_OK=0. R70 tam olarak TCM okumasını ekleyen koşu.
Karar: AÇIK ve 2. öncelik. Bu adayın çekici yanı şu: eğer TCM'e erişim çakışması hattı düşürüyorsa, CR4 belleğe sahip çıkmış demektir ve 'çekirdek hiç başlamıyor' resmi yanlış olabilir. Alternatif ve daha sıkıcı açıklama: TCM okuması SDHCI'da kurtarılamayan bir veri-fazı hatası üretiyor ve sürücüde kurtarma yok (C30 kod eksikliği gerçekti).
Sıradaki iş: PMU ölçümünden sonra ayrı koşu: TCM okumasının hemen ardından host NORMINT, ERRINT ve PSTATE okunur. Kurtarma ve reset altında karşılaştırma ayrı değişkenler olarak sınanır; bu iş R99'a dahil değildir.
Hipotez
Tanık döngüsündeki MBOX=0, INTSTAT=0, SHARED_RAW=0 ve PMU_TA/TB/TC=0 okumaları çipin sessizliğini DEĞİL, ölü bir okuma yolunu ölçüyor. Öyleyse 'CR4 yürütmüyor' sonucu R70'ten R96'ya kadar hiçbir koşuda kanıtlanmamıştır.
Ölçülen
R96'da CC_CHIPID=0x15264345 ama CHIPID2=0x00000000 — AYNI kaydın, AYNI fonksiyonun (backplane_read32_data), AYNI adresin iki okuması. ChipCommon chip id sıfır olamaz. Bağımsız tanık: cr4_start'tan hemen sonra koşan WIFISWEEP kendi pencere yazmasını yapıp geri okuyor — R67 ve R69'da WIN_OK=1 C52_0=0x15264345, R70'ten R96'ya kadar HEPSİNDE WIN_OK=0 C52_0=0x00000000. Aynı koşuda WIFIWRITE ENTRY_SYNC=0: fonksiyon-0 CCCR okumasının sekiz denemesi de düştü — pencere/backplane muhasebesi bir F0 okumasını bozamaz, yani arıza SD bağlantısının tamamında.
Karar: R97'de KAPANDI ve ikiye ayrıldı. (a) Tanıklar GERÇEKTEN güvenilmezdi: R70–R96 arasındaki bütün EXECUTED=0 makbuzları geçersizdir. (b) Ama TCM okuması döngüden sonraya alınınca hat canlı kaldı (nöbetçi 100/100) ve MBOX=0 ilk kez GERÇEK bir ölçüm oldu — sonuç aynı, kanıt değeri artık var. Geriye kalan soru C34 olarak ayrıldı: TCM okumak neden hattı düşürüyor? Kırılma noktası R69→R70. R70 bu okumayı (TCM shared word) tanık döngüsünden ÖNCE eklemiş ve kendi README'sinde 'çekirdek serbest bırakılınca TCM okuması da karardı' diye kaydetmiş — ama karartmanın ARDINDAN GELEN HER ŞEYİ de karattığı görülmemiş. Bu bir gerileme değil teşhis: R96'nın salt-okunur C15 ayırt edicisi tam bunu ölçmek için eklenmişti.
Hipotez
Firmware, NVRAM tablosunu ve uzunluk token'ını RAM'inin TEPESİNDE (rambase+ramsize-4) arar. AselsanOS ramsize'ı 0xA0000 varsayıyor, dolayısıyla NVRAM'i 0x23792C'ye koyuyor. Gerçek tepe 0x260000 ise firmware oraya baktığında başlatılmamış RAM görür, NVRAM'i çözemez ve erken init'te durur — host'a hiçbir sinyal ulaşmaz. FWSTAGE OK=1 + NVRAM OK=1 + MBOX=0 tablosunun tam açıklaması budur.
Ölçülen
Kaynak: rpi5_sdio_wifi.rs:3812 `pub const TCM_RAMSIZE: u32 = 0x000A_0000; // 640 KB (609 KB firmware bunu gerektirir)` — yorumun kendisi değerin ölçülmediğini, 'firmware sığsın' diye seçildiğini söylüyor. R80 trace'i aynı 1748 baytlık NVRAM blob'unu iki parça hâlinde 0x25F92C'ye (1728 B) ve 0x25FFEC'e (20 B) yazıp TAM 0x260000'da bitiriyor. 0x260000 − 0x198000 = 0xC8000 (800 KiB). Bizim makbuzumuz: ASELSAN/NVRAM ADDR=0x0023792c VARSZ=1748.
Karar: R95'te CİHAZDA KAPANDI. Kusur gerçekti: çip RAMSIZE=0x000c8000 dedi ve NVRAM artık Linux'un yazdığı adrese (0x0025f92c) iniyor. Ama CR4 yine başlamadı (MBOX=0, EXECUTED=0). Yani 160 KiB'lik yanlış yerleşim GERÇEK bir kusurdu ve düzeltildi — CR4'ün başlamamasının NEDENİ değildi. rambase (0x198000) zaten iki tarafta aynıydı.
Hipotez
C01'in kök nedeni budur. Linux ramsize'ı tablodan değil çipten alır: CR4 core tabanında CAP okunur, banka sayısı çıkarılır, sonra her banka için BANKIDX yazılıp BANKINFO okunur ve boyutlar toplanır. AselsanOS EROM taramasında CR4 core tabanını ZATEN topluyor (CR4_BASE=0x18002000 basıyor) ama bu tabanı hiç kullanmıyor.
Ölçülen
Trace'te CR4 core bölgesine (0x18002xxx) tam 17 erişim var ve deseni birebir şu: 1× R 0x18002004 (CAP), ardından 8 kez (W 0x18002040 = BANKIDX, R 0x18002044 = BANKINFO). Depoda `0x18002004`, `0x18002040`, `BANKIDX`, `BANKINFO` dizgeleri HİÇ geçmiyor.
Karar: R95'te UYGULANDI ve CİHAZDA DOĞRULANDI: CAP=0x00000b44 → 4 A-bankası + 4 B-bankası = BANKS=8 → RAMSIZE=0x000c8000, MEASURED=1. Bu, R80 izinden bağımsız ikinci bir ölçümdür ve aynı sayıyı verdi. Kalıcı kazanç: ramsize artık tahmin değil; bir kaynak testi ölçümün BANKIDX dışında yazma yapmadığını sayarak pinliyor.
Hipotez
cr4_start yürütme kanıtı olarak TCM_TOP−4 = 0x237FFC'yi okuyor. Firmware ayağa kalkınca sdpcm_shared yapısının adresini RAM tepesine, yani 0x25FFFC'ye yazar. Yani firmware KOŞSA BİLE bizim baktığımız dört bayt hiç değişmez: SHARED_RAW=0 'çekirdek ölü' değil, 'yanlış pencereden bakıyoruz' anlamına gelebilir.
Ölçülen
rpi5_sdio_wifi.rs:3413 `out.shared_addr = TCM_TOP - 4;` → 0x237FFC. TCM_TOP deponun tamamında yalnız iki yerde kullanılıyor: bu satır ve :3833 NVRAM yerleşimi. Trace'te Linux firmware hazır olduktan sonra 0x25FFFC'yi okuyup dönen işaretçiyi dereference ediyor.
Karar: R95'te adres kusuru düzeltildi: tanık artık ölçülen TCM tepesinden, 0x25FFFC'den okunuyor. Fakat R97 bu okumanın hattı düşürdüğünü gösterdi; SHARED_RAW=0 firmware'in oraya hiçbir şey yazmadığını kanıtlamaz. Adres düzeltmesi kalıcı, okuma geçerliliği C34'te açık.
Hipotez
CR4 ve TCM yüksek hız (HT) saat alanındadır. AselsanOS reset dizisinden sonra CHIPCLKCSR'ye bir daha yazmıyor ve hattı FORCE_ALP'te bırakıyor; bu backplane'i yavaş ALP saatine çivileyebilir. Linux ise çekirdeği bıraktıktan hemen sonra HT istiyor ve HT gelmeden F2'yi açmıyor.
Ölçülen
R98: HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_CLR=0x40 HT_CSR_REQ=0x50 HT_CSR_FIN=0x50 HT_REQ_MS=60 HT_REQ_AVAIL=0. R80 Linux dizisi 0x28, 0x28, 0x21, 0x00, 0x08, 0x00, 0x10, 0xd2, 0x02: 0x21 FORCE_ALP içerir; indirme tutamağı 0x08'dir. 'Linux FORCE_ALP hiç kullanmıyor' yorumu yanlıştı.
Karar: R98'de KAPANDI: eksik HT isteği tek başına açıklama değil. İstek latch etti ve FORCE_ALP bırakıldı, fakat HT yoklamada gelmedi. Bu sonuç PMU kaynak ailesini öne çıkarır; diğer saat/başlatma farklarını elemez.
Hipotez
SB_ACCESS_4B_FLAG (0x8000) karta 'bu erişim 32 bitliktir' der. R93 bayrağı ekledi ama taşımayı değiştirmedi: backplane_write32_4b bayraklı ofseti cmd52_write_u32'ye veriyor, o da dört ayrı bayt işlemi gönderiyor. Kart, her biri '32 bitim' diyen dört ayrı bayt yazması görüyor; kontrol kaydı atomik olarak commit edilmemiş olabilir.
Ölçülen
rpi5_sdio_wifi.rs:2525 backplane_write32_4b → :3489 cmd52_write_u32 → dört ayrı cmd52. Linux aynı kayda (0xA408 / 0xA800) TEK bayt-kipi CMD53 yazıyor: blocks=1, block_size=4. Trace'te o pencerede fonksiyon-1 CMD52 yazması HİÇ yok.
Karar: AÇIK. R101 ilk D11 yazmasında DAT inhibit nedeniyle issue edilmedi; bu yüzden tek CMD53 kontrol yazmasının cihazda latching yaptığı henüz sınanmadı. Not: bu aday, C01'in yanında ikinci sıradadır çünkü C01 yanlışsa bile firmware NVRAM'ini bulamaz — önce yerleşim düzeltilmeli.
Sıradaki iş: R107'den sonra: D11 inhibit kapısı temiz bir cold boot'ta geçerse wrapper IOCTL/RESET_CTL için tek CMD53-4B yazmasının latching sonucu yeniden ölçülür; BCDC/RX tanısı bu adayın yerine geçirilmez.
Hipotez
stage_to_tcm ve write_words_to_tcm pencere ofsetine 0x8000 bayrağını koymadan dört bayt-CMD52 yazıyor; doğrulama da aynı bayraksız yoldan yapılıyor. Köprü bayraksız bayt erişimlerini farklı ele alıyorsa, hem yazma hem doğrulama aynı hatayı yapıp birbirini onaylıyor olabilir.
Ölçülen
rpi5_sdio_wifi.rs:4046/4053 (stage_to_tcm) ve :4171/:4193 (write_words_to_tcm) bayraksız. Linux TCM'e yalnız bit15 set (0x08000/0x0F92C/0x0FFC0) ve blok kipinde 64 baytlık CMD53'lerle yazıyor; trace'te backplane bölgesine bayraksız TEK BİR erişim yok.
Karar: AÇIK ama düşük öncelikli: FW_INTACT ve WORDS_V=152448 aynı yolun kendini doğrulaması olduğu için bu aday ancak çapraz bir taşımayla (yaz CMD52 / oku CMD53-4B) ayırt edilebilir.
Sıradaki iş: R107'den sonra ayrı koşu: staging'den sonra firmware kelimeleri bayraklı CMD53 ile geri okunup CMD52 okumasıyla karşılaştırılır. Uyuşmazlık taşıma yollarının ayrıştığını gösterebilir.
Hipotez
cr4_start EXECUTED'i yalnız SDIO çekirdeğinin mailbox ve intstatus kayıtlarından türetiyor. Linux'un firmware-hazır kanıtı bu değil: F2 açılır ve CCCR IOReady biti beklenir; ayrıca RAM tepesindeki sdpcm_shared işaretçisi okunur. Yani 'yürütme yok' cümlesi, Linux'un kullanmadığı bir pencereden bakılarak kuruldu.
Ölçülen
Trace'te CR4 release ile firmware-hazır arasındaki pencerede Linux 0x1800404C'yi (mailbox) HİÇ okumuyor; 0x18004020'yi yalnız release'ten ÖNCE bir kez temizliyor. Buna karşılık CCCR 0x02'ye 0x06 yazılıp (F1+F2 enable) CCCR 0x03 (IORx) 10.268 kez yoklanıyor. AselsanOS'ta SDIO fonksiyon 2 HİÇ etkinleştirilmiyor.
Karar: AÇIK. Bu aday tek başına CR4'ü başlatmaz ama başladığını GÖREBİLMEMİZİ sağlar. C03 ile birlikte, mevcut 'EXECUTED=0' sonuçlarının ne kadarının ölçüm körlüğü olduğunu belirler.
Sıradaki iş: R107'den sonra: R106'nın doğruladığı RX başlık/payload sınırı ve INTSTATUS Read32 sahipliği korunarak C08'in IOReady/IOR2 makbuzu ayrıca tamamlanır.
Hipotez
R92 F2/hostintmask/watermark'ı 'post-MBOX; CR4 firmware-ready'e hiç ulaşmıyor' diye erteledi. Trace bu sıra varsayımını çürütüyor: SDPCM sürüm kelimesinin tosbmailboxdata'ya yazılması ve F2'nin açılması, firmware-hazır kanıtından ÖNCE gelir.
Ölçülen
Trace sırası: HT gelir → 0x18004048'e (tosbmailboxdata) yazılır → F2 açılır (CCCR 0x02 ← 0x06) → firmware-hazır kanıtı ~54 ms sonra gelir. hostintmask (0x18004024) ise firmware hazır olduktan SONRA yazılır. AselsanOS SDIO çekirdeğine yalnız intstatus temizliği yapıyor (rpi5_sdio_wifi.rs:3330-3336).
Karar: R92'nin 'post-MBOX' etiketi YANLIŞ; doğrusu 'post-HT / post-CR4-release'. Bu bir sahte kapanış değil (aday hiç denenmedi) ama gerekçesi hatalıydı ve düzeltildi.
Sıradaki iş: C07 ile birleşik koşulur: HT geldikten sonra tosbmailboxdata'ya SDPCM sürümü yazılır ve F2 açılır. Ancak C01/C04'ten sonra sıraya girer.
Hipotez
R84/R85/R86 PMU kaynak yeniden yükleme adayını denedi ve 'elendi' diye kapatıldı. Ama makbuzlar yazmanın hiç inmediğini söylüyor: değişken uygulanamadı, dolayısıyla sınanmadı.
Ölçülen
ASELSAN/PMUREL BASE=0x18000000 CTL_B=0x01770181 CTL_W=0 CTL_A=0x01770181 RELOAD=0 PATH=C53_4B C53_OK=0 C53_B=0 C53_ERR=0x0020 — yazma bayrağı 0, önce/sonra değerler aynı, taşıma CRC ile düştü. İkinci koşuda CTL_A=0x18181818 (veri yolu zehirlenmesi).
Karar: SAHTE KAPANIŞ. R98'de ALP hazır ve HT isteği latch etmişken HT gelmedi. Bu, PMU kaynak ailesini öne çıkarır; RES_RELOAD'un çözüm olduğunu kanıtlamaz. R84/R85/R86 değişkeni cihaza indiremediği için C09 açık kalır.
Sıradaki iş: R99 PMU görüntülerini geçerli ama eşit olarak aldı; R100 clock/timeout kusurunu ayırdı. RES_RELOAD hâlâ ayrı adaydır ve yalnız temiz yazma + geri okuma makbuzuyla sınanabilir; R106/R107 read tanısı bunun önüne geçmez.
Hipotez
Linux firmware'i YAZMADAN ÖNCE CR4'ü tam bir reset döngüsünden geçiriyor (set_passive). AselsanOS'ta bu adım bilerek devre dışı — ama gerekçesi 'işe yaramadı' değil, 'yazmaları sessizce düşüyordu'.
Ölçülen
rpi5_sdio_wifi.rs:2607 `eski cmd53 yolu halt_cr4'un yazmalarini sessizce dusuruyordu (WRITE_OK=0)` ve :3030 `halt_cr4 BURADA YOK (TCM yazmasini bozdu)`; main.rs:2596 `halt_cr4 stays out.` Trace'te Linux CR4 wrapper'ına indirmeden ~108 ms ÖNCE tam bir disable+resetcore dizisi uyguluyor.
Karar: SAHTE KAPANIŞ. Dışlama nedeni taşıma kusuruydu; R94 o kusuru düzeltti ama halt_cr4 hâlâ dışarıda. Linux'un yaptığı bir ön koşulu, artık geçerli olmayan bir gerekçeyle atlıyoruz.
Sıradaki iş: R107 read sınırından sonra ayrı koşu: firmware indirmeden ÖNCE CR4 set_passive geri açılır ve TCM yazmalarının bozulmadığı (FWSTAGE OK=1) doğrulanır.
Hipotez
R76 aday listesinde NVRAM token/dolgu biçimi 'doğru' diye elendi. Ama doğrulama, blob'u bizim yazdığımız yerden bizim okuma yolumuzla geri okuyarak yapıldı — yani biçim kendi kendine onaylandı; Linux'un cipe ne yazdığıyla karşılaştırılmadı.
Ölçülen
Bizim token: TOKEN=0xfe4b01b4, VARSZ=1748, TOKEN_OK=1 — hepsi kendi hesabımızın kendi geri okumamızla tutması. Trace'teki Linux yazması aynı boyutta (1728+20 = 1748 bayt) çıktı; yani BİÇİM muhtemelen doğru. Sapan şey biçim değil, ADRES (C01).
Karar: Kapanış SONUÇ olarak doğru ama GEREKÇE olarak geçersizdi. Biçim trace ile karşılaştırıldığında tutuyor; bu yüzden C11 artık biçim adayı olarak kapanabilir — ama kapanışın dayanağı R76 değil, R80 trace'idir.
Hipotez
Firmware staging'i hızlandırmak için komut-tamamlandı yoklama sınırı 50.000'den 2.000'e indiriliyor ve SDIO saati /16'ya alınıyor. Bunları geri alan ikinci bir çağrı yok; dolayısıyla NVRAM yazması ve CR4 serbest bırakma dizisinin TAMAMI bu daraltılmış bütçeyle koşuyor. Reset dizisindeki bir yazmanın 'inmiş' sayılıp aslında zaman aşımına uğraması mümkün.
Ölçülen
`grep -rn set_issue_status_polls kernel/src/` üç satır döndürüyor: tanım (rpi5_sdio_wifi.rs:304), bir yorum (:318) ve TEK çağrı (main.rs:2668). Geri yükleyen çağrı yok. Saat main.rs:2731'de /16'ya alınıyor ve cr4_start main.rs:2895'te koşuyor.
Karar: R96'da CİHAZDA KAPANDI. Geri alma çalıştı (CR4PRE POLLS=50000 CLKDIV=0x80 CLK_STABLE=1, cr4_start içinde POLLS=50000) ve EXECUTED yine 0. Yani daraltılmış bütçe tek başına açıklama değildi. Kusur gerçekti ve düzeltildi; neden değildi.
Hipotez
cr4_start tanık döngüsünün başında ve sonunda PMUTimer okuyor. Kodun kendi yorumu şunu söylüyor: ilerlediyse LPO kesin çalışıyor, sabitse LPO gerçekten ölü. Ölçüm sabit çıktı ve bu sonuç karara hiç yansımadı.
Ölçülen
13 mühürlü koşuda `PMU_TA=0x00000000 PMU_TB=0x00000000` (2 koşuda 0x18181818 — veri yolu zehirlenmesi). R95'te yeniden üretildi: PMU_TA=PMU_TB=0x00000000, buna karşılık PMU_STAT=0x0000002a ve RES_ST=0x0fcaff77 aynı yoldan sağlıklı dönüyor — yani okuma yolu ölü değil.
Karar: R97'de KAPANDI — ve bir ARTEFAKT çıktı. Canlı hatta ölçüldüğünde sayaç ilerledi: PMU_TA=0x00776d9e → PMU_TB=0x007cdaaa. LPO çalışıyor. 13 koşuluk 'sayaç sabit' gözlemi, ölü bir okuma yolunun ürünüymüş. Ders: bir ölçümün sıfır çıkması, ölçüm aletinin çalıştığı doğrulanmadan yorumlanamaz.
Hipotez
WORDS_W, cmd52 yazmasının başarılı döndüğü kelime sayısıdır; WORDS_V geri okumada eşleşen kelime sayısı. Her koşuda WORDS_V tam 152.448 çıkıyor ama WORDS_W 101.000–121.000 arasında değişiyor ve RETRIES=0. Yani on binlerce yazma 'başarısız' raporlanıyor, buna rağmen veri doğru; ya yazma-başarı göstergesi anlamsız ya da doğrulama gerçek veriyi okumuyor.
Ölçülen
Mühürlü makbuzlardan örnekler: WORDS_W=101526 / WORDS_V=152448, WORDS_W=111786 / WORDS_V=152448, WORDS_W=121065 / WORDS_V=152448 — hepsinde RETRIES=0. R95'te yeniden üretildi: WORDS_W=95683 / WORDS_V=152448, RETRIES=0.
Karar: AÇIK. Bu, firmware'in gerçekten sağlam yüklendiğine dair güvenin bir kısmını zayıflatır: iki sayaçtan biri yalan söylüyor ve hangisi olduğu bilinmiyor.
Sıradaki iş: Ölçüm: staging sonrası firmware'in tamamı ayrı bir taşıma yoluyla (bayraklı CMD53) yeniden okunup SHA benzeri bir özetle karşılaştırılır. C06 ile birlikte koşulabilir.
Hipotez
R58'de bilinçli bir karar verildi: okuma yolunda issue()'nun döndürdüğü durum atılıyor ve yanıt kaydı koşulsuz okunuyor. Bu, /16'da 'completion biti gelmiyor ama veri doğru' gözlemine karşı mantıklıydı; bedeli, komut GERÇEKTEN inmediğinde bir önceki komutun yanıtının okunmasıdır.
Ölçülen
rpi5_sdio_wifi.rs:1720-1724 `let _ = issue(...)` — dönüş değeri atılıyor, ardından yanıt kaydı okunuyor.
Karar: AÇIK. Bu, MBOX=0 / INTSTAT=0 / SHARED_RAW=0 gibi 'sıfır' sonuçların bir bölümünün bayat yanıt olabileceği anlamına gelir. C12 ile birleştiğinde risk artar: dar bütçe + durum yok sayma.
Sıradaki iş: Ölçüm: kritik okumalarda (MBOX, INTSTAT, SHARED) durum bayrağı da makbuza basılır (ör. MBOX_ST=). Davranış değişmez, yalnız görünürlük artar.
Hipotez
Linux, brcmfmac yüklenmeden önce CMD5'i S18R ile sorup CMD11 gerilim anahtarlaması yapıyor ve kartı DDR50'ye alıyor. AselsanOS 3,3 V SDR'de kalıyor ve HOST_CONTROL2'ye hiç yazmıyor. Sinyalleşme farkı, küçük CMD53 yazmalarının veri fazındaki kırılganlığını açıklayabilir.
Ölçülen
rpi5_sdio_wifi.rs:209 `write_volatile(reg8(0x29), 0x0e | 0x01)` (3,3 V + güç). Dosyada 0x3c (HOST_CONTROL2) için tek yazma yok. Linux tarafında CCCR 0x13 = 0x09 (BSS=DDR50) yazılıyor.
Karar: AÇIK ama RİSKLİ ve en sona bırakıldı: gerilim anahtarlama yanlış yapılırsa kart sinyalleşmesi kalıcı olarak bozulabilir ve bu, tek değişkenli bir denemenin geri alınabilirlik sözleşmesini zorlar. Ayrıca 3,3 V SDR'de CMD52 ve CMD53 OKUMA sorunsuz çalışıyor — sinyalleşme tek başına yazma kusurunu açıklamıyor.
Sıradaki iş: Diğer bütün adaylar tükendikten sonra. Önce salt-okunur bir sonda: CMD5'in S18R yanıtı ve host kapasite kayıtları makbuza basılır.
Hipotez
BLKSIZE/BLKCNT'e gerçekte ne yazıldığı, o andaki TIMEOUT_CONTROL, CLOCK_CONTROL, HOST_CONTROL1/2 değerleri 91 koşunun hiçbirinde başarısız aktarım anında okunmuyor. WIFIINV anlık görüntüsü bring_up ÇALIŞMADAN ÖNCE alınıyor ve ölü durumu gösteriyor.
Ölçülen
Makbuzlardaki WIFIINV satırı TIMEOUT=0x00 PWRCTL=0x00 CLKCTL=0x0000 HOSTCTL1=0x00 — hepsi bring_up öncesi.
Karar: AÇIK. Taşıma adaylarının (C05/C06) hiçbiri, bu ölçüm olmadan mekanizma düzeyinde ayırt edilemez.
Sıradaki iş: Ölçüm koşusu: cmd53_write başarısız döndüğünde host register anlık görüntüsü alınıp ASELSAN/C53FAIL satırı olarak basılır. Hiçbir davranış değişmez.
Hipotez
BT cevapsızlığı (83 mühürlü koşuda TX=4 / ANSWERED=0) Wi-Fi CR4 duvarından bağımsızdır. Linux aynı çipi BCM4345C0 diye tanıyıp bir patchram yaması yüklüyor; o dosya bizde yok.
Ölçülen
R75 dmesg: `Bluetooth: hci0: BCM4345C0` ve `brcm/BCM4345C0.raspberrypi,5-model-b.hcd Patch`. Depoda `*.hcd` dosyası yok; firmware/wifi/ yalnız üç Wi-Fi blob'u ve LICENSE taşıyor.
Karar: AÇIK ve CR4'ten bağımsız. BT hattı Wi-Fi'yi beklemeden yürütülebilir.
Sıradaki iş: Ayrı hat: .hcd dosyası karta konur, HCI Reset'ten sonra patchram indirme dizisi eklenir. Wi-Fi CR4 çalışmasıyla değişken paylaşmaz.
Hipotez
Düşen CMD53'lerin 0x0060 vermesi veri hattı bütünlüğü sorunudur.
Ölçülen
Arşivde tek değişkenli bir çift koşu var (R29 → R30) ve hipotezi tersine çeviriyor. Ayrıca R40'ta aynı 0x0060 bir CMD53 OKUMASINDAN geldi (TCM_C53_ERR=0x0060), yani kod yön-özgü değil.
Karar: KAPALI. Bu, R93/R94'ün 'READ-vs-WRITE' çerçevesinin de dayanağını zayıflatır: ayrım yön değil, muhtemelen adres bölgesi (ChipCommon çalışıyor, backplane RAM düşüyor).
Hipotez
rstvec yazması bayraklı olsaydı çekirdek başlardı.
Ölçülen
Adayın kendi çürütme koşulu üç bağımsız mühürlü koşuda zaten ölçülmüş: bayraklı bayt-CMD52'nin ofset 0'da backplane verisi TAŞIMADIĞI R19'da makbuza yazıldı; R89 bayraksız yolla RSTVEC_OK=1 ve ALIAS_OK=1 aldı.
Karar: KAPALI — hem bayraklı hem bayraksız varyant ölçüldü, ikisi de CR4'ü başlatmadı.
Hipotez
CR4 0x18102000, IOCTL +0x408, RESET_CTL +0x800 ve reset sırası hatalı olabilir.
Ölçülen
R80 trace'inden çözülen Linux adresleri ve sırası, AselsanOS'un yaptığıyla birebir aynı. R92 trace-diff'i reset DEĞERLERİNİN ve SIRASININ da eşleştiğini göstermişti.
Karar: KAPALI. Bu alanda yeni varyant denemek yasaktır — 'tekrar edilmeyecekler' listesindedir.
Hipotez
Firmware yanlış tabana yazılıyor ya da giriş vektörü yanlış yorumlanıyor.
Ölçülen
Blob'un ilk kelimesi 0xb83ef198; cihaz makbuzu FW_WORD0=0xb83ef198 ile aynısını okuyor. rambase 0x198000 iki tarafta da AYNI — trace'teki indirme pencereleri 0x198000'den başlıyor.
Karar: KAPALI. Sapan tek şey rambase değil, ramsize (C01).
Hipotez
1748 baytlık NVRAM, TCM'deki firmware'in üzerine biniyor olabilir.
Ölçülen
Firmware 0x198000–0x22CC20 arasını dolduruyor. NVRAM mevcut (yanlış) adreste 0x23792C, düzeltilmiş adreste 0x25F92C — ikisi de firmware'in ÜSTÜNDE. Çakışma yok. FW_INTACT=1 de bunu doğruluyor.
Karar: KAPALI. C01'in etkisi 'ezme' değil, 'firmware'in baktığı yerde hiçbir şey olmaması'dır.
Hipotez
Regülasyon tablosu (CLM) TCM'e aktarılmadığı için firmware ayağa kalkmıyor.
Ölçülen
Trace'te Linux de CR4 release'ten ÖNCE CLM'i TCM'e yazmıyor; CLM firmware çalışmaya başladıktan sonra ayrı bir kanaldan gider.
Karar: KAPALI — CLM bir CR4-start ön koşulu değildir. (Yayın için hâlâ ön koşuldur; güvenlik tablosundaki RF-09 bunu ayrıca söyler.)
Hipotez
Blob'un sonundaki trailer doğrulanmadığı için firmware kendini reddediyor olabilir.
Ölçülen
Blob python ile ayrıştırıldı: dosya bir ASCII sürüm dizgisiyle bitiyor (…FWID 01-b677b91b / DVID 01-16dd0023). Sonda uzunluk ya da CRC alanı YOK.
Karar: KAPALI — doğrulanacak bir trailer mevcut değil.
Hipotez
R92 'NVRAM generated-byte / token form' farkını açık bırakmıştı.
Ölçülen
nvram_transform python'da birebir yeniden koşuldu: n=1742 → dolgulu 1744 → varsize=436 → varsz=1748, token=0xfe4b01b4. Cihaz makbuzuyla aynı. Linux'un trace'te yazdığı blob da tam 1748 bayt.
Karar: KAPALI — biçim doğru. R92'nin bu maddesi kapatılabilir; sapan şey adres (C01).
Hipotez
Fazladan yazılan 480 bayt sektör artığı firmware'i bozuyor olabilir.
Ölçülen
Fark, firmware'in sonundan sonraki kullanılmayan RAM'e düşüyor ve firmware'in kendi uzunluk bilgisi dosyada yok (C25). Adayın kendi PASS ölçütü ('Linux'la birebir aynı bayt kümesi') fiziksel olarak sağlanamaz.
Karar: KAPALI — ayırt edici gücü yok.
Hipotez
Linux bunları yalnız probe slotunda bir kez yapıyor; tekrarımız zarar veriyor olabilir.
Ölçülen
Kod okuması doğru ama üç bağımsız kanıt katmanı etkisiz olduğunu gösteriyor: her iki yazma da idempotent bit-set ve makbuzlar KSO_SET=1 / KSO_DEVON=1 ile aynı sonucu veriyor.
Karar: KAPALI.
Hipotez
Linux CR4-start slotunda D11'e hiç dokunmuyor; bizim D11-disable dizimiz orada koşuyor.
Ölçülen
Olgu doğru (rpi5_sdio_wifi.rs:3294-3320). Ama adayın kendi çürütme koşulu R74'te zaten ölçüldü: D11-disable uygulandı, yazmalar landı (D11_WRAP=0x18101000) ve yürütme yine gelmedi.
Karar: KAPALI — olgular doğru, mekanizma değil.
Hipotez
Kurtarma yapılmadığı için sonraki işlemler de bozuluyor ve zincir çöküyor.
Ölçülen
IO_ABORT gerçekten hiç kullanılmayan bir sabit (rpi5_sdio_wifi.rs:55). Ama düşen CMD53'lerden SONRAKİ CMD52 işlemleri makbuzlarda sağlıklı değer döndürüyor — zincir çökmüyor.
Karar: KAPALI kök neden olarak. Kod eksikliği gerçek ama CR4'ün başlamamasını açıklamıyor.
Hipotez
PMU kaynakları eksik olduğu için CR4 hiç beslenmiyor (R64–R66 dönemi teşhisi).
Ölçülen
Trace'te Linux PMU min/max kaynak maskelerine (0x618/0x61c) HİÇ yazmıyor ve 0x608/0x614'ü hiç okumuyor. Yani çalışan bir başlatma bu register'lara dokunmadan gerçekleşiyor.
Karar: KAPALI — teşhis kaynaksızdı. Not: PMUTimer'ın hiç ilerlememesi (C13) hâlâ AÇIK bir ölçüm sorusudur; bu iki şey karıştırılmamalı.
Hipotez
Kart aslında farklı bir stepping ve pin planı/firmware ailesi yanlış.
Ölçülen
chipid, chip rev ve firmware kimliği cihazda birebir eşleşiyor (CHIPID=0x15264345). R14 overlay'i D0 ölçtü ve R15'ten beri pin planı D0. R75'te Linux aynı kartta aynı blob ailesiyle çalıştı.
Karar: KAPALI.
Bu tablo bir yol haritası değil, bir eleme defteridir. 'Kapalı' satırların hiçbiri Wi-Fi'nin çalıştığını göstermez; yalnızca o açıklamanın artık aranmayacağını söyler. 'Sıradaki' satırlar da bir söz değildir: her biri tek değişkenli bir cihaz koşusu gerektirir ve koşulmadan hiçbiri PASS sayılmaz. Bu sayfadaki hiçbir aday, kaynakta ya da R80 Linux izinde görülmeyen bir register yazması önermez.
Bir cihaz koşusunun beklenen cevabı vermemesi, koşunun başarısız olduğu anlamına gelmez. R1 aradığı kimliği bulamadı ama zincirde eksik bir ön koşulu ve kendi kodumuzdaki bir kusuru ortaya çıkardı; ikisi de ancak gerçek donanımda görülebilirdi.
Sorulan: Çipin iç veri yoluna ulaşabiliyor muyuz? Beklenen cevap CHIPID=0x4345.
Cevap: Cevap gelmedi — ve gelmemesinin sebebi zincirdeki gerçek bir eksiği ortaya çıkardı. Bu bir RED değil, teşhis.
Wi-Fi çipi hiç beslenmemiş
CMD0 ve CMD5 tamamlandı ama cevap tamamen sıfırdı: OCR=0, FUNCS=0, READY=0. Denetleyici sağlıklıydı. Teşhisi PSTATE=0x000f0000 verdi — CARD_INSERTED=1 ve CARD_STATE_STABLE=1, ama DAT[3:0] ve CMD hatlarının hepsi düşük. Beslenmeyen bir çipin imzası. Sebep DTB'de yazıyordu ve atlanmıştı: sdio2'nin vmmc-supply'ı wl_on_reg, o da GPIO hat 28 (WL_ON), aktif-yüksek, 150 ms başlangıç gecikmesiyle. Wi-Fi yuvasının beslemesi bir GPIO regülatörü; hattı sürmeden CMD5 sormak kapalı bir cihaza soru sormaktır.
GPIO canlılık kapısı yanlış kayda bakıyordu
Bluetooth tarafında BT_ON sürülemedi ve suç bizimdi. gpio_write_allowed() IODIR=0xffffffff okuyup pencereyi ölü saydı. Yanlıştı: IODIR bir YÖN kaydıdır ve hepsi bir olması 'hepsi giriş' demektir — bir GPIO bankasının tamamen normal açılış durumu. Pencerenin canlı olduğunun kanıtı aynı satırda duruyordu: DATA=0x00500002, karışık bir desen ve S1 sensör koşusunda birebir aynı değer. İki bağımsız koşuda aynı çıkan karışık bir değer canlılık kanıtıdır. Karar artık yalnızca DATA'ya bakıyor.
Doğru çalışanlar
imaj a655bddc50219b303274121bb0b81a80888eeffb5557a6fea6f67096709e47cb
kanıt evidence/rpi5/radio/attempt-r1-backplane-gate-uart-capture/
Sorulan: R1'in bulduğu eksik giderildi. WL_ON sürülünce çip cevap veriyor mu?
Cevap: Düzeltmeler çalıştı ve ölçülebilir bir fiziksel etki üretti — ama iki radyo da hâlâ sessiz. Bu koşu sebebi ölçülebilir tek bir soruya indirgedi.
Güç geldi, veri hatları hareket etti, cevap yine yok
WIFIPWR ASSERTED=1 ve tam olarak bizim bitimiz uygulandı; BT_ON'a dokunulmadı. PSTATE 0x000f0000'dan 0x006f0000'a çıktı — DAT[3:0] 0000 iken 0110 oldu, yani WL_ON gerçekten bir şeyi besledi. BT tarafında UART programlandı (bölen 52) ve HCI Reset'in dört baytı da gönderildi (TX=4, LSR=0x60). Buna rağmen Wi-Fi CMD5'e OCR=0 döndü ve Bluetooth 500 ms boyunca tek bayt göndermedi.
Ölçülebilir hâle gelen hipotez: pin mux hiç uygulanmıyor
DTB, sdio2_30_pins için gpio30–35'in 'sd2', uarta_24_pins için gpio24–27'nin 'uart0' fonksiyonunda olmasını istiyor. ON hatlarının çalışması gpio28/29'un 'gpio' fonksiyonunda olduğunu kanıtlar, ama veri pinleri bilinmiyordu: pinctrl@7d504100 sayfası hiçbir profilde haritalı değildi, yani ne uygulanabiliyor ne okunabiliyordu. Bağlanmamış bir pede yazan sürücü, ölü bir karşı taraftan ayırt edilemez. Blok 0x30 bayt = 12 kelime; salt okuma bir envanter her pinin fonksiyonunu söyler ve bu koşudan sonra eklendi.
Kendi ölçümümüzdeki kusur: giriş hattı dalgalanması yazma sayıldı
BITS=3 çıktı, 2 bekleniyordu. Değişenlerden ikisi bizimdi (IODIR ve DATA'da bit 29 = BT_ON), üçüncüsü bit 31 = WIFI_SDIO_CMD — bir GİRİŞ hattı, okuma ile geri-okuma arasında kendiliğinden değişti. Ayrıca çip güçlenince bit 24–27 (BT UART pinleri) yükseldi. Tek bir bits_changed sayısı, giriş hatlarının doğal hareketini bizim yazmamızla aynı kefeye koyuyordu. Metrik ikiye ayrıldı: own_bit_applied ve foreign_data_bits / foreign_iodir_bits.
Doğru çalışanlar
imaj f3b97d5ee996277912c4311378b5f38bcd77fb8e60b40fb1fcd68b8bdf457c55
kanıt evidence/rpi5/radio/attempt-r2-wl-on-power-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: R2'nin hipotezi doğru mu — pedler çevre birimlerine bağlı mı?
Cevap: Doğrulandı. İki radyonun da sessiz kalmasının sebebi kesin olarak biliniyor: pedler bağlı değildi.
BT UART'ın dört pini de gpio fonksiyonundaydı, uart0 değil
gpio24–27 (BT_RTS/CTS/TXD/RXD) fsel=0 okuyor, yani gpio. DTB uart0 istiyor ve bunun için gereken fsel 3 ya da 4. Dört baytlık HCI Reset gerçekten gönderildi (TX=4, LSR=0x60 = verici boş) ama UARTA'nın çıkışı pedlere bağlı değildi. Gönderilen baytlar hiçbir yere gitmedi.
SDIO'nun saat ve komut hatları da bağlı değildi
gpio30 (WIFI_SDIO_CLK) ve gpio31 (WIFI_SDIO_CMD) fsel=0 okuyor. CLK ve CMD bağlanmadan SDIO veri yolu hiç çalışamaz; veri hatlarının durumu bunu değiştirmez. CMD5'in sıfır cevabı tamamen açıklandı.
fsel=0'ın gpio olduğu tahminle değil iki bağımsız kanıtla belirlendi
Ölçüm: gpio28 (WL_ON) ve gpio29 (BT_ON) 0 okuyor ve R2'de ikisi de fiziksel olarak çipleri besledi. Kaynak: pinctrl-bcm2712.c içinde fsel_set, funcs[i-1] == func için fsel = i atıyor ve i birden başlıyor, yani 0 func_gpio için ayrılmış. Yol boyunca bir çıkarım hatası yapıldı ve düzeltildi: envanter SDIO_UNIFORM=0 deyince alan yerleşimi varsayımının yanlış olduğu sanıldı; gerçek sürücü kaynağı yerleşimin baştan doğru olduğunu gösterdi. Yanlış olan 'grup tekdüze olmalı' çıkarımıydı — grup tekdüze değildi ve bu, hatanın kendisi değil bulgunun kendisiydi.
Açıklanamayan: gpio32 ve gpio33 aralık dışı okuyor
İkisi de 9 okuyor; BCM2712_FSEL_COUNT 9, yani geçerli aralık 0–8. gpio34/35 ise vc_spi3 çözülüyor. Bu üç değer açıklanamıyor ve uydurulmuyor. Sonucu değiştirmiyorlar: CLK ve CMD bağlanmadan veri hatlarının ne olduğu önemsiz.
Doğru çalışanlar
imaj 3bd06ec5fd7e58e9211e44e1e346440d7ca9ad94278a368e70e295a935cf3270
kanıt evidence/rpi5/radio/attempt-r3-pinmux-inventory-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Pedler çevre birimlerine bağlanabilir mi?
Cevap: Sekiz pin kabul edildi, iki pin donanım tarafından reddedildi — ve reddedilenler tam olarak SDIO'nun en kritik iki hattı.
8/10 tuttu; CLK ve CMD yazdırtmadı
gpio24–27 (BT UART) ve gpio32–35 (SDIO D0–D3) istenen değerleri aldı. gpio30 (WIFI_SDIO_CLK) ve gpio31 (WIFI_SDIO_CMD) 0 kaldı. Kelimeye tek bir 32-bit store yazıldı (0x44004443); alt 16 bit tuttu, üst 8 bit tutmadı. Aynı bloktaki komşu kelime yazmayı tamamen kabul etti. Sebebi bilinmiyor ve uydurulmuyor. CLK ve CMD bağlanmadan SDIO veri yolu çalışamaz.
Güvenlik kapıları temiz raporladı — ama yanlış yerleşimi göremediler
UNPLANNED=0x00000000 ve REF_INTACT=1 çıktı. İkisi de C0 kelime haritasına dayanıyordu ve bu kart D0. Aynı makbuz satırında W4=0x15555699->0x15553434 duruyor: kelime 4 gerçekten değişti ve hiçbir kapı bunu yakalamadı — D0'da orası boot SPI pad/pull kaydıdır (pin 1/2/3 = BOOT_CS_N / BOOT_MISO / BOOT_MOSI). Deponun kendi düzeltme defteri bunu R4'ten R13'e kadar her koşuda olmuş bir yan etki diye kaydediyor ve 'gözlenen bir arıza yok — ama bu bir şans, tasarım değil' diyor (evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md:54-60). Ders: bir kapı yalnızca beslendiği harita kadar doğrudur. R15'ten itibaren kelime 4 hiç yazılmıyor.
Veri yolu durumu değişti ama yetmedi
PSTATE 0x006f0000'dan 0x011f0000'a geçti: CMD hattı ilk kez yüksek. CMD5'in başarısızlık biçimi de değişti — 'tamamlandı ama sıfır cevap' yerine artık zaman aşımı. Veri yolu gerçekten farklı bir durumda. Bluetooth'un dört pini de artık uart0 fonksiyonunda ve dört bayt gönderiliyor, ama hâlâ cevap yok; sebebi bu koşudan çıkarılamıyor.
Siyah ekran bizim değildi
Bir önceki güç verme denemesinde ekran siyah kaldı ve pin mux yazmasından şüphelenildi. UART'ta bizim çekirdekten tek satır yoktu; gelen baytlar Raspberry Pi önyükleyicisine aitti ve altı kez 'Failed to open device: sdcard' diyordu. Kart okunamadığı için çekirdek hiç yüklenmemişti. Kart yeniden takılınca açılış normale döndü.
Doğru çalışanlar
imaj 3a5ad8de93b3aaa871df99455a86289bcf472cad0cefa8e0d438c01fd75c89f6
kanıt evidence/rpi5/radio/attempt-r4-pinmux-write-uart-capture/
Sorulan: Pin 30/31 reddi hangi sebepten, ve riskli tekrar deneme makbuzdan sonraya alınınca ne oluyor?
Cevap: İki koşu sıfır bayt verdi (R5 ve R6-tekrar), bir koşu (R6-oturma) tam makbuz setini verdi ve R7 retry sonucunu bağımsız olarak tekrarladı.
R6-oturma: 27 159 bayt, aynı 8/10
Kablolar yerine oturtulduktan sonra hat konuştu ve tam mux makbuzunu verdi: VERIFIED=8/10 MISMATCH=2, PINMUXRETRY RETRIED=2 OK=0, PINMUXLATE W3=0x00004443 AFTER_MS=150, W4=0x15555699->0x15553434. Bu değerlerin hepsi R7 retry koşusuyla birebir aynı — yani o sonuç iki kez ölçüldü, tek koşuya dayanmıyor.
R5 ve R6-tekrar: sıfır bayt, makbuz yok
Bu iki koşudan hiçbir ölçüm alınamadı ve hiçbir sonuç iddia edilmiyor. Yakalama kuruluydu; cihazdan tek satır gelmedi.
Sıfır baytlar iki kez yanlış yere yorumlandı
Önce kendi teşhis kodumuzun UART'ı susturduğu sanıldı; sonra kablo/adaptör suçlandı ve boşuna donanım söküldü. Gerçek sebeplerden biri ölçüm yöntemiydi: macOS'ta stty -f ile yapılan ayarlar cihaz kapanınca kaybolur, bu yüzden ayrı stty ve cat komutlarıyla yapılan her okuma portu varsayılan 9600 baud'da açıyordu. 'Gürültü' sanılan şey yanlış hızda çözülmüş gerçek veriydi. Sekiz farklı baud denemesinin hepsinde ~70 bayt çıkması da bunu gösteriyordu ve ters okundu. Doğrusu portu açık tutup (exec 3<>) ayarı o açıklık içinde uygulamaktır; yakalama betiğinin C motoru zaten böyle yapıyor. Diğer bir sebep fizikseldi: USB-C hub bir kez yerinden çıkmış çıktı.
Kalıcı bir tasarım dersi
R5'te riskli yazma, onu açıklayacak makbuzdan ÖNCE konmuştu. Bir şey ters gitseydi olan biteni anlatacak satır hiç basılamayacaktı. Sıra değiştirildi: önce ne bilindiğini söyle, sonra riskli şeyi dene, sonra sonucu söyle. Bir kaynak testi bu sıralamayı pinliyor.
Doğru çalışanlar
imaj kaydedilmedi — bu koşuların paketlerinde imaj kimliği yok
kanıt evidence/rpi5/radio/attempt-r5-*, attempt-r6-retry-after-receipt-*, attempt-r6-reseat-live-*
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Toplu yazmadan sonra uyuşmayan pinler tek tek tekrar denenirse tutar mı, ve yazdığımız değer 150 ms sonra yerinde kalır mı?
Cevap: Hayır ve evet: tekrar deneme de tutmadı (RETRIED=2 OK=0), ve değer 150 ms sonra değişmedi — yani kimse üzerine yazmıyor, yazma baştan tutmuyor.
Toplu yazma da, tekrar deneme de tutmadı
PINMUXW VERIFIED=8/10 (toplu 32-bit store), PINMUXRETRY RETRIED=2 OK=0 (uyuşmayan iki pin tek tek yeniden yazıldı), PINMUXLATE W3=0x00004443 AFTER_MS=150 (değer yerinde kaldı). Bu koşu tek nibble'ı SIFIR kelimeden denemedi — o R7-staged ve R8'in işi.
Buradan 'salt okunur, VPU sahiplenmiş' sonucu çıkarmak yanlış olurdu
Aynı adreste, kelime hâlâ sıfırken bu iki nibble'ı tek tek yazıp tutturan bir bare-metal koşu bildiriliyor. Ayrıca Linux sürücüsünde kilit ya da şifre kaydı yok, yerleşim doğrulandı, ve DTB'deki non-removable 'firmware Wi-Fi'yi yönetir' demek değil. Bu yüzden VPU sahipliği bu sayfada iddia EDİLMEZ; ölçülmemiştir.
Wi-Fi çipi cevap verdi ama cevabı alınmadı
CMD5=1 OCR=0xfc000000 FUNCS=7 READY=1 geldi. Üç sebeple güvenilmez sayıldı: gerilim penceresi sıfır, FUNCS=7 mümkün olan maksimum, ve STATUS'te hata biti kurulu — hemen ardından CMD3 tamamen başarısız. 'Çip uyandı' değil, 'cevap kaydı çöp okundu' okunuşu tercih edildi.
Doğru çalışanlar
imaj 7ee5cc98a0fb5227cbf785bd682585cf6a0ca7dde5a08c17d80528a1176c72b4
kanıt evidence/rpi5/radio/attempt-r7-retry-after-receipt-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Kelime tertemiz sıfırken önce yalnızca CLK+CMD yazılırsa tutar mı? (Sıra hipotezinin ilk biçimi.)
Cevap: Tutmadı. Sıra hipotezinin bu biçimi de bu kartta çalışmadı.
Aşama 1 sıfır kelimeden yazdı ve tutmadı
S1_WROTE=0x44000000 S1_READ=0x00000000 S1_HELD=0. Ardından aşama 2'de UART yazıldı ve tuttu (S2_UART=1), CLK/CMD yine gelmedi (S2_CLKCMD=0). Aynı koşuda komşu kelime 4 (SDIO D0–D3) da yazmayı aldı.
Sıra hipotezinin iki biçimi de elendi
Bu koşu CLK+CMD'yi BİRLİKTE, kelime sıfırken denedi. R8 ise pin 30'u TEK BAŞINA, yine sıfır kelimeden denedi. İkisi de tutmadı. Yazma yolu çalışıyor — UART nibble'ları ve kelime 4 alıyor — reddedilen üst bitler. (R13 düzeltmesi: sınır bit 24'te değil bit 16'da; kelimenin alt yarısı yazılıyor, üst yarısı yazılmıyor.)
Doğru çalışanlar
imaj kaydedilmedi — bu paketin boşluğu
kanıt evidence/rpi5/radio/attempt-r7-staged-mux-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Forum'un sırası — önce pin 30, sonra pin 31 — bu kartta tutar mı?
Cevap: Tutmadı. Sıra hipotezi bu kartta yeniden üretilemedi.
Kelime tertemiz sıfırken, tek nibble, yine tutmadı
W3_INIT=0x00000000 P30_WROTE=0x04000000 P30_READ=0x00000000 P30_HELD=0. Forum koşusunun başlangıç koşulu birebir kuruldu. Ardından pin 31 de tutmadı. Aynı koşuda UART nibble'ları (bit 15:0) ve komşu kelime 4 (SDIO D0–D3) yazmayı ALDI.
Erişim genişliği hipotezi de zayıfladı
Geriye kalan desen — alt yarı yazılıyor, üst yarı yazılmıyor — kaydın 16 bit olması gibi görünüyordu. Ama Linux sürücüsü bu bloğa yalnızca 32-bit erişiyor (writel/readl; dosyada tek bir writew/writeb yok) ve Pi OS'ta bu pinleri sd2'ye muxlayıp Wi-Fi'yi çalıştırıyor. Kayıt 16 bit olsaydı Linux'un yazması da başarısız olurdu.
Doğru çalışanlar
imaj kaydedilmedi — koşuyu akıtan oturum imaj sha256'sını yazmadı
kanıt evidence/rpi5/radio/attempt-r8-pin30-then-pin31-uart-capture/
Sorulan: Erişim genişliği (8/16/32 bit) CLK/CMD mux yazmasını değiştirir mi?
Cevap: Bilinmiyor: cihazdan TEK BAYT gelmedi. Bu koşudan hiçbir ölçüm yoktur ve hiçbir sonuç iddia edilmez.
Sıfır bayt, makbuz yok
Yakalama kuruldu (capture_armed=YES) ama 0 bayt alındı, kapanış satırı hiç yazılmadı ve süreç dışarıdan sonlandırıldı. ASELSAN/PINMUXWIDTH makbuzu ALINMAMIŞTIR. Ekranın yaşaması SoC'un asılı kalmadığını söyler; sondanın yürüdüğünü söylemez.
Bu paketin kendi mühür kusuru kayıtlı
İlk mühür yanlıştı: EVIDENCE_SHA256SUMS, yakalama hâlâ koşarken ve uart10.raw boş/0600 iken alınmıştı. Bir paket kendi yakalaması sürerken mühürlenemez. Mühür sonlandırma sonrası yeniden alındı, ama paket yine de TAMAMLANMAMIŞ bir yakalamadır ve öyle okunmalıdır.
Sessizliğin sebebi bu koşuda belirlenmedi
O oturumun UART hattı kırılgandı: USB-C hub yerinden çıktı, adaptör birkaç kez yeniden numaralandı ve macOS'ta stty -f ayarları cihaz kapanınca kaybolduğu için port varsayılan 9600 baud'da açılıyordu. Kesin sebep bu koşu için belirlenmemiştir.
Doğru çalışanlar
imaj kaydedilmedi — R9 paketinde imaj kimliği yazılmadı
kanıt evidence/rpi5/radio/attempt-r9-width-probe-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Erişim genişliği (8/16/32 bit) CLK/CMD yazmasını değiştirir mi?
Cevap: Hayır. Üç genişlik de tutmadı; erişim genişliği ölçülerek elendi.
8, 16 ve 32 bit — üçü de yazmadı
Pin 30 ve 31 aynı baytta yaşadığı için (0x10_7D50_410F) üç genişlik de tam olarak aynı iki nibble'ı hedefledi: 8 bit 0x44, 16 bit 0x4400, 32 bit 0x44000000. Hepsi W8_HELD=0 W16_HELD=0 W32_HELD=0. Ayrıca üç genişlikte okuma da yapıldı ve üçü uyuştu (R32=0, R16=0, R8=0) — kayıt haritası varsayımı doğru.
Zaten zayıflamış bir hipotezdi, artık ölçüldü
Linux sürücüsü bu bloğa yalnızca 32-bit erişiyor (writel/readl; dosyada tek bir writew/writeb yok) ve Pi OS'ta bu pinleri sd2'ye muxlayıp Wi-Fi'yi çalıştırıyor. Kayıt 16 bit olsaydı Linux'unki de başarısız olurdu. R10 bunu çıkarım olmaktan çıkarıp ölçüme dönüştürdü.
Doğru çalışanlar
imaj 256104c4880f40bde9ab74f6ea6ebfbb988d2d7efa23f31979d9bc75af7487bd
kanıt evidence/rpi5/radio/attempt-r10-width-probe-uart-capture/
Sorulan: sdio2 DTB'de kapatılırsa pinler serbest kalır mı?
Cevap: GEÇERSİZ KOŞU. Overlay yüklendi ama uygulanmadı; hipotez sınanmadı. Bu bir sonuç değil, bir başarısızlık kaydıdır.
Dosya kartta olmak yetmiyor
config.txt'ye genel ad yazılmıştı (dtoverlay=disable-wifi) ve iki .dtbo da karttaydı, imzaları doğrulanmıştı. Yine de: overlay_map.dtb not found → firmware genel adı Pi 5 varyantına yönlendiremedi → temel dosyayı yükledi (387 bayt, bcm2835) → o dosya &mmc/&mmcnr hedeflediği ve Pi 5 DTB'sinde bu düğümler bulunmadığı için 'Failed to resolve overlay' verdi. sdio2 hiç kapanmadı.
Bu koşudaki P30_HELD=0 hiçbir şey kanıtlamaz
Deneyin bağımsız değişkeni uygulanmadığı için firmware hipotezi sınanmamıştır. Satırlar yalnızca R10'u tekrarlıyor.
Geçerlilik şartı yetersizmiş, düzeltildi
Şart 'overlay yüklendi mi' idi; dosya yüklenebilir ve yine de uygulanmayabilir. Yeni şart iki parçalı: UART'ta disable-wifi-pi5.dtbo bytes 267 görülmeli VE 'Failed to resolve overlay' görülmemeli. Bayt sayısı hangi dosyanın yüklendiğini tek başına söyler.
Doğru çalışanlar
imaj 256104c4880f40bde9ab74f6ea6ebfbb988d2d7efa23f31979d9bc75af7487bd
kanıt evidence/rpi5/radio/attempt-r11-disable-wifi-overlay-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: sdio2 gerçekten kapatıldığında pinler serbest kalır mı?
Cevap: Hayır. Overlay doğrulanmış biçimde yüklendi ve uygulandı; yazılabilirlik değişmedi.
Geçerlilik bu kez sağlandı
Read /overlays/disable-wifi-pi5.dtbo bytes 267, ardından Loaded overlay 'disable-wifi-pi5'. 'Failed to resolve overlay' sıfır kez geçiyor. Overlay'in yaptığı tek şey &sdio2 düğümüne status = disabled.
Sonuç değişmedi
Kelime tertemiz sıfırken (W3_INIT=0x00000000) tek nibble yazıldı ve tutmadı: P30_HELD=0 P31_CLK=0 P31_CMD=0. R8 ile birebir aynı. Olumlu kontrol yerinde: UART_OK=1.
Sonucun sınırı
Bu koşu şunu söyler: disable-wifi-pi5 / sdio2 status=disabled yazılabilirliği değiştirmedi. VPU sahipliğinin kanıtı DEĞİLDİR; bütün firmware hipotezinin çürütülmesi de DEĞİLDİR — denenen tek bir düğmedir. Firmware'in o pinleri başka bir yoldan tutuyor olması hâlâ mümkün ve hâlâ ölçülmemiştir.
Doğru çalışanlar
imaj 256104c4880f40bde9ab74f6ea6ebfbb988d2d7efa23f31979d9bc75af7487bd
kanıt evidence/rpi5/radio/attempt-r12-disable-wifi-pi5-overlay-uart-capture/
Düzeltme (R14 sonrası): R14 bu kartin silikonunun D0 oldugunu olctu. Bu kosu pin→kelime cevirisini C0 kuraliyla (pin / 8) yapti; D0'da her pin bir kelime asagida. Olculen sayilar — hangi adrese ne yazildi, ne geri okundu — gecerli. Onlara verilen PIN ADLARI degil. Ayrinti: evidence/rpi5/radio/CORRECTIONS-C0-TO-D0.md
Sorulan: Sınır tam olarak nerede — bit 24'te mi, yoksa daha aşağıda mı?
Cevap: Bit 16'da. Altı koşudur söylenen 'reddedilen tam olarak bit 31:24' ifadesi yanlıştı ve bu ölçüm onu düzeltti.
Bit 23:16 hiç test edilmemişti
Orası ON hatları (pin 28 WL_ON, pin 29 BT_ON) ve onlara her zaman 0 yazılmıştı — zaten 0'dılar. O yazma hiçbir şey kanıtlamayan bir no-op'tu, ama 'reddedilen tam olarak bit 31:24' iddiası ona dayanıyordu.
Pin 28 de yazmayı almadı
ON_WROTE=0x00010000 ON_READ=0x00000000 ON_HELD=0. fsel=1 (C0 tablosunda funcs[0]=mtsif) yazıldı, tutmadı. Geri alma temiz (ON_RESTORED=0x00000000), pin 29'a dokunulmadı, SAFE=1 — mux ve güç normal devam etti.
Ölçülen hücreleri açıklayan tek kural
ÖLÇÜLEN hücrelerde bir mux alanı kelimenin ALT 16 bitinde ise yazılıyor, ÜST 16 bitinde ise yazılmıyor — erişim genişliğinden bağımsız (R10: 8, 16 ve 32 bitlik store'ların üçü de üst yarıda başarısız). pin 24–27 kelime 3 alt yarı: yazıldı. pin 28, 30, 31 kelime 3 üst yarı: yazılmadı. pin 32–35 kelime 4 alt yarı: yazıldı. Yani pin 32–35 CLK/CMD'den 'daha şanslı' değil, sadece alt yarıdalar.
Kural 12 kelimelik bloğa YAYILMADI
Tablo yalnızca kelime 3 ve kelime 4'ün alt yarısı içindir. Ölçülmeyenler ölçülmemiş olarak duruyor: kelime 4'ün üst 16 biti (pin 36–39) hiç yazılmadı, pin 29 (bit 23:20) hiç yazılmadı, kelime 0/1/2/5–11 hiç yazılmadı. Pin 29 aynı üst yarıda olduğu için sonucu değiştirmesi beklenmez, ama beklenti ölçüm değildir. Bankanın gpio-line-names'i 36 hat sayıyor, yani pin 36–39 diye bir hat da yoktur.
Açık kalan gerilim
Linux bu bloğa yalnızca 32-bit writel ile erişiyor ve Pi OS'ta pin 30–35'i sd2'ye muxlayabiliyor. Yani üst yarı Linux altında yazılabiliyor olmalı. Bizim ortamımızda neyin farklı olduğu açık bir sorudur. Pin 29 da hâlâ test edilmemiştir; aynı üst yarıda olduğu için sonucu değiştirmesi beklenmez ama ölçülmemiştir.
Doğru çalışanlar
imaj 3820ef8396f5f47e904cca8dd9a5c7289cfd524fd600fa0fb17f2aa1e0c1dc9d
kanıt evidence/rpi5/radio/attempt-r13-on-nibble-boundary-uart-capture/
Sorulan: Bu kartın silikonu C0 mu D0 mı? Yalnızca overlays/bcm2712d0.dtbo kartın üstüne konulacak, config.txt'ye tek satır eklenmeyecek.
Cevap: D0. Firmware dosyayı kendisi aradı ve yükledi. On üç koşudur yanlış pin tablosunu kullanıyormuşuz.
İpucu on üç koşudur açılış logunda duruyordu
Her açılışta 'overlays/bcm2712d0.dtbo not found' satırı geçiyordu ve gözden kaçmıştı. Firmware o dosyayı yalnızca silikon D0 ise arar; C0'da atlar. Dosya kartın üstüne konulunca 'Read /overlays/bcm2712d0.dtbo bytes 1363' ve ardından overlay'in yüklendiği satır geldi. config.txt'ye dtoverlay=bcm2712d0 YAZILMADI — zorlamak C0'da kelime 2'deki PWR_GPIO'ya DTB yapıştırırdı; ölçmek istediğimiz şey firmware'in kendi kararıydı.
D0'da her pin bir kelime aşağıda
pin 24–27 (BT UART) ve 28–31 (WL_ON / BT_ON / CLK / CMD) kelime 3'te değil kelime 2'de; pin 32–35 (SDIO D0–D3) kelime 4'te değil kelime 3'te. Yani 'BT UART'ı muxladık' dediğimiz yazma aslında WIFI_SDIO_D0..D3'ün mux'ıydı; 'CLK/CMD reddediliyor' dediğimiz hücreler ise var olmayan pin 38–39'du.
Kelime 4 mux kaydı bile değil
D0'da kelime 4 pad/pull kaydıdır. R4'ten R13'e kadar oraya yaptığımız yazmalar boot SPI pad ayarlarını (pin 1/2/3 = BOOT_CS_N / BOOT_MISO / BOOT_MOSI) değiştiriyordu. Gözlenen bir arıza olmadı — kart her seferinde açıldı — ama bu şanstı, tasarım değil.
On üç koşuluk 'kilit' bir kilit değildi
VPU sahipliği, erişim genişliği, sdio2'nin açık olması, kaydın 16 bit olması — hepsi tek tek elendi ve hiçbiri sebep değildi. Sebep bizim tablomuzdu. Bu sayfadaki R3–R13 kartlarının ölçümleri geçerli, pin adlandırmaları geçersiz; her birinin üstünde düzeltme notu var.
Doğru çalışanlar
imaj 3820ef8396f5f47e904cca8dd9a5c7289cfd524fd600fa0fb17f2aa1e0c1dc9d
kanıt evidence/rpi5/radio/attempt-r14-d0-stepping-probe-uart-capture/
Sorulan: Pin planı D0 tablosuna taşındığında yazma tutuyor mu? Beklenti şuydu: bu, D0 tablosunun çalışacağını göstermez; doğru kayda yazdığımızı ölçer.
Cevap: Tuttu — VERIFIED=10/10. Ve beklentinin ötesine geçti: SDIO arka düzlemi cevap verdi, çip kendini BCM43455 olarak tanıttı. Wi-Fi hâlâ YOK.
On pinin onu da muxlandı
W2_CLK=0x01000000 CLK=1, W2_CMD=0x11000000 CMD=1, W2_UART=0x11004444 UART=1, W3_DAT=0x00001111 DAT=1, VERIFIED=10/10, UNPLANNED=0x00000000, REF_INTACT=1. On üç koşudur reddedilen üst yarı, doğru kelimeye yazıldığında kabul etti. Donanımda kısıt yoktu; yanlış kelimeye yazıyorduk.
Fail-closed kuralları tuttu
ON28=0 ON29=0 ON_INTACT=1 — WL_ON ve BT_ON nibble'ları hiç maskelenmedi. W4=0x15555699->0x15555699 W4_UNTOUCHED=1 — kelime 4 okundu, aynen geri okundu, yazılmadı; boot SPI pad ayarları bu koşuda korundu. PINMUXLATE 150 ms sonra üç kelimeyi de yerinde buldu.
OCR ilk kez anlamlı
R14'te OCR=0xfc000000 idi: FUNCS=7 (azami), MEM=1 (SDIO-only bir kartta olamaz), gerilim penceresi tamamen boş — çöp. R15'te OCR=0xb0ffff00: FUNCS=3, MEM=0, gerilim penceresi 0xffff00, yani 2,7–3,6 V. Sabit-1'e çekilmiş bir hat 0xffffffff verir, ölü bir hat 0x00000000; bu ikisi de değil.
Çip kendini tanıttı: BCM43455
CMD3 bir RCA verdi (0x0001), CMD7 kartı seçti, CCCR_REV=0x43 okundu, fonksiyon 1 açıldı ve ilk yoklamada hazır oldu (FN1_EN=1 FN1_READY=1 READY_POLLS=1), arka düzlem penceresi kuruldu ve geri okundu (WINDOW=1). CHIPID=0x15264345 → id=0x4345 = BCM43455, rev 6, pkg 2. Değer uydurulmadı: 16 CMD52 ile ChipCommon 0x1800_0000'dan okundu. Karttaki firmware dosyaları zaten bu parça için seçilmişti; çip artık kendisi de öyle olduğunu söylüyor.
Wi-Fi hâlâ yok — kapı açıldı, odaya girilmedi
CMD53=0, FIRMWARE=0, SCAN=0, SSID=0. Blok aktarımı yazılmadı, firmware indirilmedi, tarama yapılmadı, tek bir SSID okunmadı. Ağ listesi ekranı hâlâ ölçülmüş veri taşımıyor. Bu koşu Wi-Fi'nin çalıştığını göstermez; firmware indirmesinin ön koşulunun sağlandığını gösterir.
Bluetooth cevap vermedi
BT pinleri artık doğru kelimede (UART=1), BT_ON kaldırıldı (BT_ON_WAS=0 → BT_ON=1), dört baytlık HCI Reset gönderildi (TX=4 TXTO=0), ama yedi baytlık olay çerçevesi gelmedi: RXLEN=0 RXTO=1 EVENT=0 ANSWERED=0. Kalkış süresi mi, baud bölücü (DIV=52) mü — bu koşu ikisini ayırt etmiyor.
Bu koşuda bulunan kusur: envanter satırı hâlâ C0 etiketliyor
ASELSAN/PINMUX (salt-okunur envanter) pin→kelime çevirisini hâlâ pin/8 ile yapıyor. Yazma yolu D0'a taşındı, envanter taşınmadı. Aynı yakalamanın içinde SDIO=[Some(0), Some(0), Some(9), Some(9), Some(6), Some(5)] duruyor; son dört hücre kelime 4'ten okunuyor ve D0'da orası pad kaydı — o 9, 9, 6, 5 değerleri fonksiyon seçici değil, pad bitleri. Rakamlar doğru okundu, adları yanlış. Envanter taşınana kadar bu koşunun mux kanıtı yalnızca PINMUXW satırıdır.
Doğru çalışanlar
imaj feca85dc53963589a5b5f1c2d3114e7c255510dc4099940d71a1b61e1bab6932
kanıt evidence/rpi5/radio/attempt-r15-d0-pinplan-uart-capture/
Sorulan: Kapı 1: CMD53 blok aktarımı doğru veri taşıyor mu? Sınırlar, zaman aşımı, hata dönüşleri, veri bütünlüğü — dördü de ayrı ayrı.
Cevap: GATE1=0. CMD53 gerçek veri taşıdı (64 bayt, hatasız, ölü desen değil) ama iki aktarım düştü ve bütünlük ölçülemedi. Ölçülememesinin sebebi benim makbuz kusurumdu.
Olumlu kontrol hata yolunun canlı olduğunu kanıtladı
Var olmayan fonksiyon 7'ye gönderilen CMD53'ü kart FUNCTION_NUMBER hatasıyla reddetti (NEG_R5=0x92). Kapının en önemli tek sonucu bu: bu adım olmadan aşağıdaki başarısızlıklar 'belki hatayı göremiyoruz' diye açıklanabilirdi. Göremiyor değiliz — hatalar gerçek.
Üç bekleyişi ayırmak işe yaradı
TO_CMD=000 TO_BUF=000 TO_XFER=100. Üç bekleyişten yalnızca biri, yalnızca bir aktarımda takıldı. Tek bir 'olmadı' bayrağı olsaydı bu, komutun hiç gitmemesiyle karıştırılırdı.
İki düşüş aynı tür değil
4 baytlık okuma: R5 temiz (0x10), SDHCI hata kaydı 0x0020 = DATA_CRC — veri hattı. Blok kipi: R5=0x90 = COM_CRC — komut hattı. R5 ile SDHCI hata kaydını ayrı alanlarda tutmak bunu görünür kıldı; tek bir 'hata' bayrağı ikisini aynı sanmamıza yol açardı.
Makbuz kusuru 1: REPEAT iki olguyu tek bite ezdi
Kod repeat.complete() && veri_eşit hesaplayıp tek bit basıyordu. 'Tekrar okuma başarısız oldu' ile 'veri farklı geldi' ayırt edilemiyordu. R2'de düzeltilen bits_changed kusurunun aynısı: iki ayrı olguyu tek sayaca sıkıştırmak.
Makbuz kusuru 2: bütünlük düşen okumaya bağlanmıştı
MATCH52 karşılaştırması başarısız olan 4 baytlık okumaya bağlıydı. Oysa 64 bayt ChipCommon ofset 0'dan geldi, yani ilk dört baytı chipid'dir ve CMD52 ile karşılaştırılabilirdi. Başaran tek aktarımın verisi hiç yazdırılmadı.
Doğru çalışanlar
imaj 56563785750ab404f2a8316f39d5633d91786dae6afaa944492f040a803e26e7
kanıt evidence/rpi5/radio/attempt-r16-cmd53-gate1-uart-capture/
Sorulan: 4 baytlık okumanın düşme sebebi SIRA mıydı? Aynı okuma, bu kez 64 baytlıklardan sonra. (Bu deney boy ile BLKSIZE=4 hizalamasını AYIRMAZ.)
Cevap: Hayır. B4 ve B4A ikisi de düştü. Sıra elendi. Geriye kalan boy ve hizalama bu koşuda ayrılmadı ve ayrıldığı iddia edilmiyor.
Aynı istek, iki farklı arıza
İlk deneme: TO_XFER + DATA_CRC (0x0020), R5 temiz. Sonraki deneme: zaman aşımı yok, SDHCI hatası yok, R5=0x90 COM_CRC. Konumu değiştirmek başarısızlığı kaldırmadı ama TÜRÜNÜ değiştirdi. Ölçülen bir olgudur; açıklaması yoktur.
Makbuz kusurunu düzeltmek hemen karşılığını verdi
RP_OK=0 ama RP_MATCH=1. Tekrar okuması 64 baytın hepsini getirdi ve veri birinciyle birebir aynı çıktı — ama cevabı COM_CRC taşıdığı için aktarım tam sayılmadı. R16'nın tek bitlik REPEAT=0'ı bunu 'tutmadı' diye gösterir, verinin kusursuz geldiğini gizlerdi.
Blok kipi bu koşuda çalıştı — yani kararsız
BLK_OK=1 BLK_MATCH=1. R16'da aynı yol R5=0x90 ile düşmüştü. Kod aynı, kart aynı, blok boyu aynı. R16'nın tek koşusuna bakıp 'blok kipi çalışmıyor' demek yanlış olurdu.
Asıl bulgu: CMD53 kendiyle tutarlı, CMD52 ile değil
Aynı adres (fonksiyon 1, adres 0, pencere ChipCommon'da): CMD52 0x15264345 döndü, CMD53 0x00804253. Ve CMD53 tarafı gürültü değil, kararlı — RP_MATCH=1, BLK_MATCH=1, ölü desen değil. Üç bağımsız CMD53 aktarımı birbiriyle uyuşuyor; üçü de CMD52 ile uyuşmuyor. Kapının varlık sebebi tam olarak budur: bu doğrulama olmadan firmware indirmek 609 309 baytı sessizce yanlış içerikle yazmak olurdu.
Doğru çalışanlar
imaj f3970f5e7a67368b467761ddc41a83140e1426ce5d530331cf96e3fd887d72d0
kanıt evidence/rpi5/radio/attempt-r17-cmd53-order-discriminator-uart-capture/
Sorulan: Pencere enumerate() ile transfer_probe() arasında kaymış mıydı? Pencereyi yeniden yaz, geri oku, taze CMD52 ile karşılaştır.
Cevap: Hayır. WIN_OK=1, taze CMD52 chipid'i görüyor, CMD53 hâlâ 0x00804253 görüyor. Kayma bu anlaşmazlığı açıklamıyor.
Pencere doğrulanmış ChipCommon iken bile uzlaşmazlık duruyor
Üç SBADDR baytı 0x18000000 olarak yazıldı ve geri okundu. Hemen ardından: taze CMD52 = 0x15264345, CMD53 64 baytın ilk dördü = 0x00804253. R16/R17'deki değerle birebir aynı.
Karşılaştırma tabanı taşındı
R17'ye kadar MATCH52'nin tabanı enumerate()'in chipid'iydi — başka bir zamanda, başka bir pencere durumunda okunmuş bir değer. R18 tabanı aynı fonksiyonun kendi taze okumasına taşıdı. enumerate değeri WIFIBP satırında durur, MATCH52'ye girmez.
Bu koşunun ölçmediği
Yeniden yazmadan ÖNCE pencerenin nerede durduğu ölçülmedi. Ölçülen şey: pencere doğrulanmış ChipCommon iken iki mekanizma aynı adresten farklı sayı döndürüyor.
Doğru çalışanlar
imaj 4a61d6477253b85f590c7d13e16f44ef8d6958493024d8711204c28450a7b8cf
kanıt evidence/rpi5/radio/attempt-r18-window-rewrite-uart-capture/
Sorulan: Sebep arka düzlemdeki 4 baytlık erişim bayrağı (0x8000) mı? Dört hücre aynı pencerede: CMD52 ve CMD53, adres 0x0000 ve 0x8000.
Cevap: Hayır. Bayrak veri yoluna çıktı (FLAGADDR=0x8000) ve CMD53'ün gördüğünü değiştirmedi. Aday elendi.
Yazarken bulunan ve deneyi geçersiz kılacak olan kusur
cmd52_read_u32 adresi WINDOW_MASK = 0x7fff ile maskeliyordu, yani bit 15'i siliyordu. Oraya 0x8000 geçirilseydi sessizce 0 olur ve makbuz 'bayrak hiçbir şeyi değiştirmedi' derdi — oysa bayrak hiç gönderilmemiş olurdu. R13'teki 'zaten sıfır olan alana sıfır yazmak' kusurunun aynısı. Maske artık yalnızca ofsete uygulanıyor, bayrak sonra ekleniyor.
2×2 beklenmedik bir asimetri gösterdi
CMD52: adres 0x0000'da 0x15264345, adres 0x8000'de 0x00000000 — gördüğü adrese BAĞLI. CMD53: her iki adreste de 0x00804253 — gördüğü adrese bağlı DEĞİL. Bayrak boş bir işlem değil; o adres CMD52 için gerçekten başka bir yer.
Geçerlilik şartı önceden yazıldı ve tuttu
FLAGADDR alanı 0x0000 bassaydı bayrak veri yoluna hiç çıkmamış olurdu ve koşu geçersiz sayılacaktı. 0x8000 bastı.
Doğru çalışanlar
imaj 1374429f31c12a0c7cace50967f2864e5d8c81a4282e0111a532061c7dc85480
kanıt evidence/rpi5/radio/attempt-r19-4byte-access-flag-uart-capture/
Sorulan: CMD53 argümanındaki adres alanını dikkate alıyor mu? R19 yalnızca iki nokta ölçmüştü ve iki nokta eğri çizmez.
Cevap: GEÇERSİZ KOŞU. Kendi önceden yazılmış şartına takıldı. Sonuç okunmadı ve okunmayacak.
Kusur 1: dördüncü okuma tamamlanmadı
OK3=0. Geçerlilik şartı dört CMD53 okumasının dördünü de istiyordu. Üçü tamamlandı. Şart önceden yazılmıştı ve tuttu.
Kusur 2: adresler ölçülmeden seçildi, ve geçerlilik bayrağı bunu yakalayamadı
CMD52 dört adresin üçünde sıfır okudu; yer gerçeği yalnızca 0x0000'da vardı. C52_ALL_SAME=0 bayrağı yine de geçti çünkü 'dördü de aynı mı' diye soruyordu ve biri farklıydı. Sorması gereken 'dördü de birbirinden farklı mı' idi. OK3=1 gelseydi tarama geçerli SAYILACAK ama yine de hiçbir şey ayıramayacaktı — bayrak yanlış soruyu soruyordu.
Kaydedilen gözlem — sonuç DEĞİL
C53 @ 0x0000 = 0x00804253, C53 @ 0x0004 = 0x20008042. İki değer aynı değil, yani 'CMD53 adresi hiç dikkate almıyor' hipotezi bu koşuda desteklenmedi. Bu bir sonuç değildir: koşu geçersizdir ve geçersiz bir koşudan çıkarım yapılmaz. İki değer arasındaki ilişkiye bakıp bir örüntü okumak da yapılmadı — bu zincir daha önce tam olarak böyle yanıldı.
Doğru çalışanlar
imaj 9375916dc366ad2805e0faa5dc0293b6eb750be13209b8b2810d4faf720887bf
kanıt evidence/rpi5/radio/attempt-r20-address-sweep-uart-capture/
Sorulan: Adres alanı bayt granülerliğinde çalışıyor mu? R20'nin iki kusuru düzeltilmiş: geçerlilik şartı 'hepsi birbirinden farklı', adresler CMD52 ön taramasıyla ölçülerek doğrulanıyor.
Cevap: GEÇERSİZ KOŞU — ama ön tarama tuttu ve bir şey ölçtü. Bu sefer kusur adres seçimimde: CMD53'ün servis edemediği adresleri seçtim.
Ön tarama çalıştı — koşunun gerçek kazancı bu
PRESCAN=1 C52_DISTINCT=1. Dört CMD52 değeri ikişer ikişer farklı çıktı: 0x15264345, 0x09152643, 0x00091526, 0x68000915. Birleştirilmiş akış 45 43 26 15 09 00 68. CMD52 adres başına TAM BİR BAYT kayıyor — adres alanı CMD52 tarafında bayt granülerliğinde çalışıyor, ölçüldü. R20'nin 'yer gerçeği tahminle seçilmiş' kusuru kapandı.
Kusur: ön koşulu optimize ederken deneyin tamamlanabilirliği kırıldı
Adresleri (0x0001, 0x0002, 0x0003) CMD52 yer gerçeğini mükemmelleştirmek için seçtim — kayan pencereler zorunlu olarak farklı çıkar. CMD53'ün o adresleri servis edip edemeyeceğini hesaba katmadım. Etmedi: üçü de R5=0x90 COM_CRC ile düştü, NC=1. Geçerlilik şartı bu adreslerle HİÇBİR ZAMAN geçemezdi.
Üç başarısızlığın imzası aynı
R5=0x90 COM_CRC, ERR=0x0000, zaman aşımı yok. Komut tarafında hata, veri tarafında yok. Adres 0x0000 ise temiz tamamlandı (R5=0x10).
Hizalama bir işaret — ama kural DEĞİL
R20 ve R21 birlikte: 0x0000, 0x0004, 0x0100 tamamlandı; 0x0001, 0x0002, 0x0003 düştü. 'Hizalı çalışıyor, hizasız düşüyor' okuması bunlarla tutarlı — ama R20'de 0x1000 hizalıydı ve o da düştü. Beşinci satır kuralı çürütüyor. Burada bir kural yazılmıyor: iki geçersiz koşudan kural çıkarmak, bu zincirin C0 tablosuyla on üç koşu boyunca yaptığı şeydir.
Doğru çalışanlar
imaj f019b2f711e0b035ab0d6f4c7f73c20de1cdd83360365cdb489be2ac673f1d4e
kanıt evidence/rpi5/radio/attempt-r21-byte-granularity-sweep-uart-capture/
Sorulan: Adres alanı 4 baytlık hizalı adreslerde çalışıyor mu? Tarama 0x0000·0x0004·0x0008·0x000c'ye taşındı — hem hizalı hem ölçülerek ayırt edilebilir.
Cevap: GEÇERSİZ (VALID=0) — ama hizalama hipotezini ÇÜRÜTTÜ. Aynı adres 0x0004 R20'de tamamlandı, R22'de düştü. Hizalama sebep değil.
Hizalama kuralı çürüdü
R21'den sonra 'hizalı çalışıyor, hizasız düşüyor' diye bir işaret kaydedilmişti ama kural yazılmamıştı. İyi ki: 0x0004 hizalıydı, R20'de tamamlandı, R22'de düştü. İki geçersiz koşudan kural çıkarmak, bu zincirin C0 tablosuyla on üç koşu boyunca yaptığı hataydı.
Asıl bulgu ön taramanın ortaya çıkardığı desen
R21 ve R22'de bütün CMD52'ler öne alınıp CMD53'ler arka arkaya koşunca iki bağımsız koşuda aynı desen çıktı: R5=0x10/0x90/0x90/0x90. İlk CMD53 temiz, ardından gelen her CMD53 COM_CRC bildiriyor. B64_HEAD hâlâ 0x00804253, CMD52 ile uzlaşmıyor.
Doğru çalışanlar
imaj 03dcb7987d5a4f5e61d4b9fa81e4d73897983fa439b4231982faa306489ab2bd
kanıt evidence/rpi5/radio/attempt-r22-aligned-sweep-uart-capture/
Sorulan: Kesme onayı eksikliği sebep mi? Sürücü, cihazda PASS almış microSD yolunun deseni gibi her tüketilen kesmeyi (CMD_COMPLETE, BUFFER_READ_READY, TRANSFER_COMPLETE) geri yazsın.
Cevap: Hayır — aday ELENDİ. R5 deseni birebir aynı kaldı (0x10/0x90/0x90/0x90). Ama eklenen BUSY alanı asıl mekanizmayı gösterdi.
Kesme onayı sebep değildi
CMD_COMPLETE ve TRANSFER_COMPLETE artık onaylanıyor; R5 deseni değişmedi. Düzeltme yine de kalıyor — kanıtlanmış yolun deseni bu.
Komutlar meşgul veri yoluna gönderiliyordu
Yeni alan dokuz koşudur görünmeyeni gösterdi: BUSY=1111 (tarama), BUSY=011111 (kapı 1). Önceki okuma aktarımı denetleyiciye göre hâlâ sürerken komut gönderiliyor. PSTATE = DAT_INHIBIT + DAT_LINE_ACTIVE + READ_XFER_ACTIVE.
Meşgul olmak tek başına başarısızlığı açıklamıyor
Boş yolda başlayan tek aktarım (B4) düştü; meşgul yolda başlayan ikisi (B64, BLK) tamamlandı. Kural yazılmadı.
Doğru çalışanlar
imaj db772c75b004c834cfe0e88708802485578e983150138c3f7e5b585611ab3f49
kanıt evidence/rpi5/radio/attempt-r23-interrupt-ack-fix-uart-capture/
Sorulan: Meşgul veri hattı sebep mi? Yol meşgulse SOFTWARE_RESET_DAT ile veri hattı yazılım sıfırlaması uygula, kanıtlanmış microSD yolunun deseni gibi geri okuyarak doğrula.
Cevap: GERİLEME. Sıfırlama mekanik olarak çalıştı (RST_OK=1111, STILL=0000) ve HER ŞEYİ bozdu. Üçüncü kendi kusurum da elendi — ama beklenen yönde değil.
Sıfırlama çalıştı ve her şeyi bozdu
R23'te tamamlanan iki aktarım (B64, BLK) düştü, DATA_CRC her aktarıma yayıldı (NC=0). Tek değişken sıfırlamaydı, taban bir önceki koşuydu.
Giriş anındaki meşgul hat bir arıza durumu değildi
Onu temizlemek başarısızlığı gidermedi, ÜRETTİ. Neden bozduğu ölçülmedi (faz kayması akla yatkın ama iddia edilmiyor); ölçülen tek şey sıfırlamanın zararlı olduğu.
Doğru çalışanlar
imaj 48921d5e2f06ac0166c19568354195958e4f477c391888ad26c824e3b9cbf573
kanıt evidence/rpi5/radio/attempt-r24-data-line-reset-uart-capture/
Sorulan: R24'ün zararlı sıfırlaması geri alınınca R23 davranışı geri gelir mi? Ölçüm alanları kalır, sıfırlama çıkarılır.
Cevap: Evet — taban geri geldi. B64 ve BLK yine tamamlandı; sıfırlama alanları artık hep sıfır kalıyor, bu da geri almanın makbuzdaki izi.
Geri alma sessiz değil
Blok ölü kodla bırakılmadı, tamamen çıkarıldı ve neden geri alındığı kaynağa yazıldı. Bir test artık sıfırlamanın uygulanmadığını pinliyor — sessiz bir geri gelmeyi engelliyor.
Alanın yokluğu ile 'uygulanmadı' aynı şey değil
Sıfırlama alanları makbuzda kaldı ve hep sıfır. Makbuz, alanın hiç olmaması ile ölçülüp sıfır çıkması arasını ayırt edebilmeli.
Doğru çalışanlar
imaj ce23234c9af68ad92b478ebbe13e73014b3c8fbe28d38ca9171030a75b61661e
kanıt evidence/rpi5/radio/attempt-r25-data-line-reset-revert-uart-capture/
Sorulan: COM_CRC zamansal mı? Komutlar arasına 2 ms donanım sayacı beklemesi konsun; ayrıca 64 baytlık tamponun ilk dört sözcüğü makbuza yazılsın.
Cevap: Hayır — zamansal değil. 2 ms beklemeye rağmen R5=0x10/0x90/0x90/0x90 deseni değişmedi. Ama tampon telemetrisi asıl gizemi büyüttü.
COM_CRC zamana bağlı değil
RP_R5=0x90 ve B4A_R5=0x90 aynen korundu. Kart CMD53 sonrası durumunu zamanla serbest bırakmıyor. Buna karşılık araya bir CMD52 girdiğinde sonraki CMD53 temiz 0x10 dönüyor — CMD52 durum makinesini senkronize ediyor.
Tamponun dört sözcüğü de aynı sabit
B64_W=0x00804253/0x00804253/0x00804253/0x00804253. Artan adres kipinde (increment=true) okunmasına rağmen dört sözcük de birebir aynı. CMD53 adresi artırmadan aynı 32-bit veriyi tekrarlıyor gibi. (R30 bunun 1-bit host kipinin kaydırdığı çöp olduğunu gösterecek.)
Doğru çalışanlar
imaj 9f55ef909e27a9c96f24ddd220d1d106e7d4f687bd940627f003bf0c9514b3e4
kanıt evidence/rpi5/radio/attempt-r26-settling-delay-uart-capture/
Sorulan: Arka düzlem saati eksik mi? Function 1 CHIPCLKCSR (0x1000E) üzerinden HT saati istensin ve telemetrisi ölçülsün.
Cevap: HT saati hiç gelmedi: CLK_R=0x50. Ve bu değer, Linux brcmfmac'in PLL programlanmadan HT istediğinde aldığı meşhur timeout değeriyle birebir aynı.
CLK_R=0x50 — bit 7 (HT_AVAIL) hiç yükselmedi
CLK_INIT=0x40 (ALP kristali devrede), CLK_W=0x10 (HT_AVAIL_REQ yazıldı), CLK_R=0x50 (0x40|0x10). PLL yapılandırılmadığı için donanım HT saatini üretemiyor ve durum makinesi 0x50'de asılı kalıyor.
Linux brcmfmac dizilimi gerekiyor
Çekirdek erken aşamada (buscoreprep) HT değil ALP zorlar: CHIPCLKCSR'a 0x28 (FORCE_HW_CLKREQ_OFF | ALP_AVAIL_REQ), ALP hazır olana kadar bekle, sonra 0x21 (FORCE_ALP) ile ALP'yi kilitle, 65 µs bekle. HT ancak firmware yüklendikten sonra açılır.
Doğru çalışanlar
imaj d1b6a7e716216199f54b84888eab4271c45b609d42283412720505093d3bf930
kanıt evidence/rpi5/radio/attempt-r27-backplane-clock-uart-capture/
Sorulan: brcmfmac buscoreprep dizilimi (FORCE_ALP + 65 µs + SDIOPULLUP=0) uygulanınca ne olur?
Cevap: ALP kilidi tuttu (CLK_R=0x61) ama SDIOPULLUP=0 veri yolunu çökertti. Kesin sonuç: dahili çekme dirençleri asla kapatılmamalı.
CLK_R=0x61 — ALP başarıyla kilitlendi
0x40 (ALP_AVAIL) | 0x20 (FORCE_HW_CLKREQ_OFF) | 0x01 (FORCE_ALP). Saat ALP kipine kilitlendi, donanım saat istekleri devre dışı.
SDIOPULLUP=0 sinyal bütünlüğünü yok etti
Dahili pull-up'lar kapatılınca R16-R27 boyunca kusursuz çalışan CMD52 çöktü: C52=0, SMB=0, komutlar Wait 1'de zaman aşımı (TO=100), R5=0x08. Pi 5 PCB'sinde SDIO hatlarında yeterli harici pull-up yok; dahili dirençler açık kalmalı.
Doğru çalışanlar
imaj 4b9e76102719f3249de37e5b13c82d315e9e3ad22458e65324919263b6d4917e
kanıt evidence/rpi5/radio/attempt-r28-force-alp-buscoreprep-uart-capture/
Sorulan: SDIOPULLUP=0 kaldırılıp FORCE_ALP korunursa veri yolu bütünlüğü ile ALP saati birlikte gelir mi?
Cevap: Evet — ikisi birlikte doğrulandı. Ama 0x00804253 hâlâ duruyor: ALP'de ve pull-up'lar açıkken bile CMD53 aynı sabiti veriyor. Soru artık CMD53 adres/aktarım kipinde.
Veri yolu ve ALP saati birlikte sağlam
C52=0x15264345 (chip ID birebir), SMB=1, BLKSZ_SET=1, WIN_OK=1, CLK_R=0x61. Sinyal bütünlüğü kusursuz, saat ALP'de kilitli.
0x00804253 sabiti sürüyor
CMD52 bayt bayt ChipCommon'ı görürken, CMD53 aynı adreste (0x0000 ve 0x8000) bu 32-bit sabiti tekrarlıyor. Sorun saat ya da güç değil; CMD53 aktarım yolunda. Bir sonraki koşu tam da orayı — host aktarım genişliğini — bulacak.
Doğru çalışanlar
imaj 49e86534a9598f527706eb0e731accdcc595666d1bf210d5a0768a2cd45a1a3d
kanıt evidence/rpi5/radio/attempt-r29-force-alp-pullup-kept-uart-capture/
Sorulan: Host denetleyicisi kart ile aynı veri yolu genişliğinde mi? Kart CCCR 0x07 ile 4-bit'e alınmıştı (BUS=0x42); host HOST_CONTROL_1 (0x28) 1-bit'te unutulmuş olabilir.
Cevap: KIRILMA. Host 4-bit'e alınınca (HCTL1=0x02) R16'dan beri süren uzlaşmazlık ÇÖZÜLDÜ: MATCH52=1, B4 temiz, CMD53 çip kimliğini okuyor. Ama GATE1 hâlâ 0.
Kök neden: host/kart veri yolu genişliği asimetrisi
Kart 4-bit'te veri ve CRC16'yı dört hattan gönderirken host yalnızca DAT0'ı 1-bit dinliyordu. 4 baytlık transferde kart 8 çevrimde bitirip host 32 çevrim beklediği için her seferinde DATA_CRC üretiliyordu; 64 baytlıkta tampona kaymış çöp doluyordu — işte 0x00804253.
İki bağımsız mekanizma ilk kez aynı sayıyı verdi
B4_OK=1 B4_ERR=0x0000 (R16'dan beri düşen 4 baytlık okuma ilk kez temiz), B64_HEAD=0x15264345, MATCH52=1. Tamponun ilk dört sözcüğü (B64_W) CMD52 taramasının 0/4/8/c değerleriyle birebir örtüştü. DATA_CRC sıfırlandı.
Kapı hâlâ açık: ardışık CMD53 durum makinesi
GATE1=0. Doğrudan art arda gelen repeat ve byte4_after hâlâ R5=0x90 (COM_CRC) alıyor; araya bir CMD52 girdiğinde sonraki CMD53 temiz dönüyor. Adres taraması da hâlâ garezli (VALID=0). Bu, R31'in settle_card ile hedeflediği kalan pürüz.
Doğru çalışanlar
imaj 5eb0d9b6ff9fc8e3109c71b2dff4ceaaefb203a02ff0284102a7739e7ec21771
kanıt evidence/rpi5/radio/attempt-r30-host-4bit-bus-uart-capture/
Sorulan: R30 host'u 4-bit'e aldı ama ardışık CMD53'ler hâlâ COM_CRC alıyordu. settle_card (CMD53'ler arasına Function 0 CCCR 0x00 CMD52 okuması) bu kaskadı temizler mi?
Cevap: Evet — KAPI 1 GEÇTİ. GATE1=1. Altı CMD53 aktarımının altısı da temiz; MATCH52=1. Bu Wi-Fi çalışıyor demek DEĞİL — firmware indirmenin ölçülü ön koşulu sağlandı.
Dört bağımsız yol aynı sayıda buluştu
MATCH52=1 (CMD53=CMD52), MATCHF=1 (bayraklı adres 0x8000), RP_MATCH=1 (tekrar okuma), BLK_MATCH=1 (blok kipi) — dördü de 0x15264345 = BCM43455. Her transfer ERR=0x0000, R5=0x10. Olumlu kontrol hâlâ reddediyor (NEG_R5=0x90), hata yolu canlı.
settle_card ardışık COM_CRC'yi temizledi
R30'da RP_OK=0 B4A_OK=0 (art arda gelen CMD53'ler R5=0x90 alıyordu). R31'de ikisi de temiz (R5=0x10) ve BUSY=000000 — artık hiçbir transfer meşgul veri yoluna girmiyor. R26'da denenen saf zaman beklemesi bunu yapamamıştı; gereken zaman değil, bir komut modu geçişiydi (CMD52).
Kalan pürüz çip değil, teşhis harness'i
WIFISWEEP hâlâ VALID=0 (BUSY=1111). Sebep biliniyor: address_sweep fonksiyonu settle_card çağırmıyor, bu yüzden R30'daki back-to-back durumu hâlâ yiyor. Kapı yolu settle_card kullanıyor ve geçiyor. Bu harness tutarsızlığı; Kapı 1'in kanıtı WIFICMD53 satırıdır, WIFISWEEP değil.
Doğru çalışanlar
imaj 7fd6e438ad1265d85c47837cc9485e115e2d5bb99052d4c35502830d071fae3b
kanıt evidence/rpi5/radio/attempt-r31-settle-card-uart-capture/
Sorulan: Kapı 2a: CMD53 YAZMA yolu, atıl CR4 RAM'ine (0x199000) bir gidiş-dönüşle doğrulanabilir mi? İlk gerçek yazma yolu — güvenlik eşiği.
Cevap: GEÇERSİZ. Yazma yolu hiç çalışmadı: pencere kurulamadı (WIN_OK=0), erken dönüldü. Yazma kusuru değil, harness sıralama kusuru.
write_probe sweep'in kirli durumunu miras aldı
Aynı yakalamada: gate1 (settle kullanır) temiz çıktı (BUSY=000000); sweep (settle kullanmaz) kartı COM_CRC kaskadında bıraktı (R5=…0x90, BUSY=1111); write_probe hemen ardından koştu ve ilk pencere CMD52'si kirli duruma çarptı → WIN_OK=0. Yazma, geri okuma, gidiş-dönüş hiç çalışmadı.
Güvenlik mimarisi yerinde
cmd53_write yalnızca write_probe'dan çağrılıyor, o da yalnızca ATIL CR4 RAM'ine (0x199000) yazıyor — ChipCommon'a değil; işlem sonunda chip id yeniden okunup referans doğrulanıyor. Üçü de testle pinli. CR4 reset'te olduğu için RAM atıl.
Doğru çalışanlar
imaj 80eae414db8462d91776d0aa0b48439b2fa36355ac9e902f1c78ca06ef77c3f1
kanıt evidence/rpi5/radio/attempt-r32-cmd53-write-roundtrip-uart-capture/
Sorulan: R32'deki WIN_OK=0 miras kirli durumdan mı, yoksa 0x199000 penceresinin kendisinden mi? Girişe robust senkronizasyon koyup ayır.
Cevap: Ayrıştırıcı çalıştı: ENTRY_SYNC=1 (kirli durum elendi) ama WIN_OK=0 (sebep pencerenin kendisi). Kök neden: 32 KB hizalama.
Sebep pencere hizalaması
Backplane penceresi 32 KB hizalı (SBSDIO_SBWINDOW_MASK = 0xffff8000); kodumuz 256 bayt hizalıyordu. 0x199000 için SBADDRLOW=0x90 yazıyorduk, donanım [14:0] bitlerini yok sayıp 0x80 tutuyor, geri okuma tutmuyor → WIN_OK=0. 30+ koşu gizlendi çünkü her erişim ChipCommon'du (0x18000000, zaten 32 KB hizalı).
Ayrıştırıcı tasarımı doğrulandı
Temiz girişten sonra WIN_OK=1 gelseydi sebep kirli durum olacaktı; WIN_OK=0 geldi → pencere. R33 tam da bunu ayırdı.
Doğru çalışanlar
imaj 5a6d80e8edb812b2792e1a385277cdc4df8c0c68101ec992b8e62a9cec063d93
kanıt evidence/rpi5/radio/attempt-r33-write-entry-sync-uart-capture/
Sorulan: Pencere hizalaması 32 KB'ye düzeltilince (0xffff_ff00 → 0xffff_8000) RAM erişimi çalışır mı?
Cevap: Pencere düzeldi (WIN_OK=1) ama RAM erişimi hâlâ düşüyor. Sıradaki eksik: 4-bayt erişim bayrağı (referans ramrw her blokta koyar).
Hizalama düzeltmesi doğrulandı
WIN_OK=1 — pencere artık RAM'e (0x198000 tabanı) kuruluyor ve geri okunuyor. R33'ün ayırıcı tahmini doğrulandı, tek satırla çözüldü.
RAM erişimi 0x0060 ile düşüyor
ORIG_OK=0, WR_ERR=0x0060 (DATA_CRC + DATA_END_BIT). Fark kanıtlanmış gate1'den tek şey: pencere-içi ofset. gate1 ofset 0'da çalışıyor; write_probe ofset 0x1000'de düşüyor. Referans brcmf_sdiod_ramrw her blok aktarımında (ofset & 0x7fff) | SB_ACCESS_2_4B_FLAG (0x8000) kullanır; biz bayrağı atlıyorduk.
Doğru çalışanlar
imaj 96c33ee31119971d728564219bd067366fec3ae1cba83e07bfef6d70da3964a0
kanıt evidence/rpi5/radio/attempt-r34-window-32kb-align-uart-capture/
Sorulan: 4-bayt erişim bayrağı (0x8000) eklenince RAM gidiş-dönüşü tutar mı?
Cevap: Hayır — değişmedi. O zamanki yorum: TCM erişimi çekirdek hazırlığı (CR4 HALT) gerektiriyor. (R38 bunu sonradan çürüttü.)
Bayrak da değil
sb_offset(…, true) ile 4-bayt bayrağı eklendi; RAM erişimi yine 0x0060 ile düştü. Aday elendi.
O anki (sonradan çürütülen) çıkarım: TCM çekirdek hazırlığı istiyor
Referans firmware'den önce CR4'ü HALT eder (brcmf_chip_cr4_set_passive → disable_arm). O yüzden 2a ile 2b ayrılamaz sanıldı ve erom+halt yoluna girildi. R38 sonradan CR4'ün zaten açılışta halt olduğunu ölçtü — bu premis yanlıştı, ama makul bir okumaydı.
Doğru çalışanlar
imaj 64df431b82d4dae65f381a3e1e403c1f23c39db4da567220fbaa4ad530a7d388
kanıt evidence/rpi5/radio/attempt-r35-write-4byte-flag-uart-capture/
Sorulan: Kapı 2b-1: EROM'u yürüyüp çekirdekleri sayabilir, CR4 wrapbase'ini bulabilir miyiz? (HALT'ın yazacağı adres.)
Cevap: EROM işaretçisi 0 okundu, sayım yapılamadı. Ofset doğru (0xfc, upstream struct'tan); sorun okuma yolunun sırasıydı.
Ofset doğrulandı, sorun sıra
eromptr ofseti Linux chipcommon.h struct chipcregs'ten birebir (eromptr /* 0xfc */); SI_ENUM_BASE=0x18000000 kendi chipid okumamızla doğrulandı. erom_scan en sonda, write_probe'un wedged bıraktığı Function 1'i miras alarak koştu; giriş senkronizasyonu Function 0'ı kurtarıyor ama backplane Function 1 gerektiriyor.
Doğru çalışanlar
imaj f170e07b92c7210089ef229de367d82193ea84529953e9210c84b9db69ffa8d6
kanıt evidence/rpi5/radio/attempt-r36-erom-core-scan-uart-capture/
Sorulan: erom_scan temiz durumdan (gate1'den sonra, sweep/write'tan önce) koşarsa çekirdekleri sayar mı? Aynı yolla chipid öz-testiyle doğrula.
Cevap: GEÇTİ (2b-1). SELFTEST=0x15264345, 7 çekirdek, CR4 wrapbase=0x18102000, READY_FOR_HALT=1.
Öz-test okuma yolunu kanıtladı, sayım tuttu
SELFTEST=0x15264345 (aynı backplane_read32 yoluyla ofset 0). SCAN_OK=1, NCORES=7, CC_FOUND=1. CR4_BASE=0x18002000, CR4_WRAP=0x18102000, REV=9. R36'daki 0 gerçekten miras kirli durumdu.
RAM_ID=0 beklenen ve tutarlı
Ayrı bir INTERNAL_MEM/SYS_MEM çekirdeği yok — CR4 çipinde RAM, çekirdeğin TCM'idir (sabit 0x198000). rambase'i sabit tablodan almamızın sebebi de bu.
Doğru çalışanlar
imaj 2cc074f1a0061a68e718b523ea81c155f8a00e73f726904dd110e6fe1f123f0e
kanıt evidence/rpi5/radio/attempt-r37-erom-reorder-selftest-uart-capture/
Düzeltme (R14 sonrası): R38'in 'asıl engel cmd53_write' okuması sonradan daraltıldı. R41/R42: cmd52 TCM'e YAZIYOR (kanıtlı) — çalışan bir yazma yolu var, cmd53 tek yol değil. R51: backplane_write32 cmd52'ye alınınca wrapper yazmaları da indi (WRITE_OK=1); 'cmd53 yazma hiç çalışmadı' bunun cmd53 kullanmasındandı. R53: firmware indirmenin önündeki asıl engel cmd53_write değil, cmd52 yolunun timeout-spin HIZI.
Sorulan: Kapı 2b-2: CR4'ü HALT edince TCM erişilebilir olup write_probe (2a) geçer mi? İlk çekirdek-reset yazması.
Cevap: İki reframe: (1) CR4 açılışta ZATEN halt (IOCTL=0x21, reset dışı) — R35 hipotezi çürüdü. (2) Asıl engel cmd53_WRITE.
CR4 açılışta zaten halt
IOCTL_BEFORE=0x00000021 = CPUHALT | CLK, RST_BEFORE=0. Çekirdek halt, saatli, reset dışı — istenen durumun ta kendisi. Referans savunma amaçlı halt eder; bu çip zaten o durumda. erom+halt bir sapmaydı — makul ama gereksiz.
Asıl engel: cmd53_write (R34'ten beri)
WRITE_OK=0 — wrapper kaydına (erişilebilir hedef, TCM değil) yazma başarısız. Oysa okuma her yerde çalışıyor: cmd52 (chipid, wrapper 0x21), cmd53 (ChipCommon). cmd53 YAZMA hiç çalışmadı. Çekirdek-halt değil, firmware indirmenin önündeki gerçek engel bu.
Doğru çalışanlar
imaj d2f5fe981f24a954cdaac092c434a5d3f71add27ef5f732024b27a0c66ccab18
kanıt evidence/rpi5/radio/attempt-r38-cr4-halt-uart-capture/
Düzeltme (R14 sonrası): R40 bu yorumu düzeltti: TCM'e cmd52 ile erişilebiliyor; R39'un 'hiç erişilemedi' sonucu cmd53 düşmesi ve wedge sonrası ölçüm sırasıyla karışmıştı.
Sorulan: cmd53_write nerede düşüyor, ve cmd52 (bayt bayt) backplane yazması çalışıyor mu? Atıl TCM'de ölç.
Cevap: cmd53 yazma komut-tamamdan önce data hatasıyla düşüyor; cmd52 temiz izole edilemedi; ve 0x198000'e hiçbir yolla erişilemedi.
cmd53 yazma: komut-tamamdan önce 0x0060
C53_CMD=0, C53_TO=000, C53_ERR=0x0060 (DATA_CRC+DATA_END_BIT), R5 temiz. Data fazı hatası komut-tamamdan önce — write kurulum/zamanlama sorununa benziyor ama tek başına kanıtlamaz.
cmd52 yazma temiz izole edilemedi
C52_WOK=0 C52_TOOK=0 — ama cmd53_write'ın başarısızlığından + settle'dan sonra koştu. cmd53 kartı wedge ettiyse settle toparlamamış olabilir. R39'un tasarım kusuru: cmd52 önce koşmalıydı.
Daha derin gerçek: 0x198000'e hiç erişilmedi
R34/R35 (okuma), R39 (okuma+yazma) — hepsi backplane 0x198000/0x199000'de düştü. Başarılı her erişim 0x18xxxxxx aralığında (ChipCommon + çekirdekler). Pencere 0x198000'e kuruluyor (WIN_OK=1) ama orada hiçbir şey cevap vermiyor. Sorun yalnız yazma yönü değil, TCM bölgesinin kendisi olabilir.
Doğru çalışanlar
imaj 925af072398703fd1c0966cf43fb2752908ec1a498c9f92bb2980937a2f3bdc4
kanıt evidence/rpi5/radio/attempt-r39-write-diag-uart-capture/
Sorulan: R39'un 'TCM'e hiç erişilemiyor' yorumu doğru mu? Temiz durumdan cmd52 ve cmd53 ile 0x198000'i ayır.
Cevap: DÜZELTME: TCM cmd52 ile okunuyor. Sorun TCM'in kendisi değil, cmd53 blok aktarımının TCM bölgesinde 0x0060 ile düşmesi.
TCM cmd52 ile okunabiliyor
CTRL_CHIPID=0x15264345, TCM_WIN_OK=1, TCM_C52=0xc44a0c18 ve TCM_C52F=0xc44a0c18. Değer sıfır ya da 0xffffffff değil; temiz durumdan, bayraklı ve bayraksız cmd52 aynı gerçek içeriği okudu.
cmd53-TCM hâlâ düşüyor
TCM_C53_OK=0, TCM_C53_ERR=0x0060. CMD53 ChipCommon'da Gate1'i geçiriyor ama TCM'de DATA_CRC+END_BIT ile düşüyor. R39'un hatası cmd52'yi cmd53 wedge'inden sonra ölçmekti.
cmd52 yazma hâlâ açık kaldı
W_PAT=0x00000000; mem_probe yazmadan önce riskli cmd53 okuma yaptı ve sonraki write aşaması ölçülemedi. R41 cmd52 yazmayı cmd53'ten önce, izole ölçecek.
Doğru çalışanlar
imaj 689a7ba8c7e8824c2b003bed0186c956e1ea58d777438b4fd8fc0d2ee0fb1e49
kanıt evidence/rpi5/radio/attempt-r40-tcm-read-probe-uart-capture/
Sorulan: cmd52 bayt erişimi TCM'e gerçekten yazıp geri okuyabiliyor mu? cmd53 wedge'inden önce izole ölç.
Cevap: YAZMA YOLU KANITLANDI: cmd52 çip RAM'ine yazıyor ve geri okuyor; cmd53 blok TCM'de düşmeye devam ediyor.
cmd52 çip RAM'ine yazıyor
WIN_OK=1, ORIG=0xe855bad4, W_C52_OK=1, W_PAT=0x5a5a5a5a, W_RB=0x5a5a5a5a, W_TOOK=1 ve RESTORE_OK=1. Dört bayt yazıldı, doğru geri okundu, sonra orijinal değer geri yüklendi.
cmd53 blok TCM'de bayraktan bağımsız düşüyor
C53NF_ERR=0x0060 ve C53F_ERR=0x0060. Sorun 4-bayt bayrağı değil; cmd53 ChipCommon'da çalışırken TCM bölgesinde çalışmıyor.
Doğru çalışanlar
imaj f0d6323b10dfb7e8014ecbb658dadd5f0c94257f552622d52396e88d9f2c246c
kanıt evidence/rpi5/radio/attempt-r41-cmd52-write-isolated-uart-capture/
Sorulan: Tek kelime değil, firmware için gereken ardışık TCM alanına cmd52 toplu yazma kusursuz çalışıyor mu?
Cevap: Evet. 1024/1024 kelime yazıldı ve doğrulandı; firmware staging mekanizmasının çekirdeği kanıtlandı.
1024/1024 kelime tuttu
ASELSAN/BULK WIN_OK=1 WORDS=1024 WRITTEN=1024 MATCHED=1024 OK=1. Deterministik desen 4 KB boyunca TCM'e yazıldı ve uyumsuzluk olmadan geri okundu.
Ölçek uyarısı: cmd52 çok yavaş
4 KB bile boot'u gözle görülür geciktirdi. 609 309 baytlık BRCMFW.BIN yaklaşık 150 kat daha büyük; cmd52 doğru ama pratik hız için saat ve bekleme davranışı ayrıca ölçülmeli.
Doğru çalışanlar
imaj c9f3f0ab42bcaa41f72d16464f6b4078ac5c4616bb331d3550c7b43b81b94cb6
kanıt evidence/rpi5/radio/attempt-r42-cmd52-bulk-write-uart-capture/
Sorulan: Radyo imajı BRCMFW.BIN'i microSD/FAT32 kaynağından bulup doğru okuyabiliyor mu?
Cevap: Okuma yarısı geçti: BRCMFW.BIN bulundu, boyutu doğru, ilk içerik yerel dosyayla birebir eşleşti.
FAT32 locate + içerik doğrulama geçti
PART_LBA=32768, VOL_OK=1, FOUND=1, FW_BYTES=609309, FW_SECTORS=1191, EXPECTED=1. FIRST_WORD=0xb83ef198 yerel BRCMFW.BIN'in ilk little-endian word'üyle aynı.
microSD radyo bring-up sayfalarından ayrı tutuldu
Firmware kaynağı ayrı ve adlandırılmış MMIO aralığı olarak eklendi; blob imaja gömülmedi. Bu yalnızca karttan okuma kanıtıdır, TCM'e yazma değil.
Doğru çalışanlar
imaj 6f0ab5bc1835659049f96b67681a76041121b58f20ae5c05e8b621f6df8b2716
kanıt evidence/rpi5/radio/attempt-r43-firmware-read-uart-capture/
Düzeltme (R14 sonrası): R45 bu koşunun yorumunu düzeltti: R44'te görülen sessizlik EROM hang'i değil, ilerleme çıktısı olmayan yavaş staging'di.
Mühürsüz paket: Bu paket MÜHÜRSÜZDÜR: dizinde EVIDENCE_SHA256SUMS ve README yok — 91 koşu içindeki tek istisna. Erken kesilen bir yakalamadır ve zaten sonuç iddia etmez; ama diğer kartların aksine imzasıyla doğrulanamaz.
Sorulan: 64 sektörlük ilk firmware staging denemesi gerçekten EROM'da mı donuyor, yoksa uzun/sessiz bir döngü mü?
Cevap: Bu koşu sonuç üretmeden erken kesildi: yakalama terminal görmedi ve FWSTAGE makbuzu gelmedi. R45 bunu sonradan 'hang değil, sessiz yavaş staging' diye düzeltti.
Makbuz yok, terminal yok
capture_closed=true ama terminal_seen=false ve success=false. UART'ta Gate1 ve EROM'a kadar sağlıklı satırlar var; FWSTAGE sonuç satırı yok. Bu koşudan staging başarısı veya başarısızlığı iddia edilmez.
R45 sonrası okuma: sessizlik hang sanıldı
R44'te ilerleme çıktısı yoktu; uzun cmd52 staging sırasında UART sessiz kaldı ve UI henüz çizilmedi. R45 faz-başı ilerleme satırları ekleyince döngünün ilerlediği görüldü.
Doğru çalışanlar
imaj kaydedilmedi — R44 paketinde imaj kimliği yazılmadı
kanıt evidence/rpi5/radio/attempt-r44-firmware-stage-64-uart-capture/
Sorulan: İlerleme çıktısıyla 8 sektörlük firmware staging döngüsü karttan oku → TCM'e yaz → doğrula sırasını tamamlıyor mu?
Cevap: Evet. 8/8 sektör, 1024/1024 kelime doğrulandı; R44 hang değil, sessiz slow staging idi.
8 sektör doğru indirildi
FWSTAGE_P fazları ilerledi; ASELSAN/FWSTAGE SECTORS_DONE=8 WORDS_W=1024 WORDS_V=1024 BYTES=4096 OK=1. Okuma hatası ve uyumsuzluk yok.
Gerçek sorun hız
SDIO veri yolu hâlâ tanımlama hızında (/256, ~400 kHz). 1191 sektör bu hızda yaklaşık saat mertebesine çıkar; önce saat yükseltmesi ölçülmeli.
Doğru çalışanlar
imaj dd0c25a3daa1a6e83cb37d4377f09f87e92bd8f202758f2adc9a511d1fdebdb2
kanıt evidence/rpi5/radio/attempt-r45-firmware-stage-progress-uart-capture/
Sorulan: SDIO saati tanımlamadan sonra /256'dan /16'ya yükselirse staging hızlanır mı ve veri bütünlüğü korunur mu?
Cevap: Veri doğru ve hızlı; ama R5 komut-yanıt durumu /16'da gürültülü. OK=0 yanlış-negatifti çünkü başarı R5-temiz sayısına bağlanmıştı.
Veri bütünlüğü kusursuz
SDCLK DIV=0x08 STABLE=1. FWSTAGE WORDS_V=1024; 8 sektörün tamamı doğru geri okundu. Hız belirgin arttı.
R5 gürültüsü başarı ölçütünü bozdu
WORDS_W=824; yaklaşık 200 yazma R5-temiz dönmediği halde veri doğru indi. OK=0 bu yüzden yanlış-negatif. Başarı ölçütü verify-readback olmalı.
Doğru çalışanlar
imaj ea164310d1e667c5b284de4106d2e6974a9de430248c5c672f56b4bbcede9418
kanıt evidence/rpi5/radio/attempt-r46-sdio-clock-raise-uart-capture/
Sorulan: Başarıyı verify ile tanımlayıp verify uyuşmazlığında retry eklenirse /16 staging sağlam raporlanır mı?
Cevap: Evet. R5 gürültüsüne rağmen 1024/1024 verify ile OK=1; retry altyapısı hazır ve bu koşuda gerekmedi.
Verify-tabanlı ölçüt doğru raporluyor
SECTORS_DONE=8, WORDS_V=1024, RETRIES=0, OK=1. WORDS_W=821 yalnızca R5-temiz sayısı; veri bütünlüğünün ölçütü değil.
Tam indirme için ön koşul hazır
Okuma yolu, cmd52 yazma, saat /16, verify ve retry birleşti. R48 artık STAGE_SECTORS=tüm dosya ile 1191 sektörü deneyecek.
Doğru çalışanlar
imaj e3490bf9ef8a09ff615cbb48472666022fa4a9fe04af87b2b423176651dc3c23
kanıt evidence/rpi5/radio/attempt-r47-stage-verify-retry-uart-capture/
Sorulan: Tam 1191 sektörlük BRCMFW.BIN staging'i /16 + verify/retry ile biter mi?
Cevap: Bitmedi ama 128 sektör/64 KB doğru indi. Abort sebebi veri değil, sektör 128'de pencere-kurma retry'siz geçici hata.
64 KB doğrulandı
SECTORS_REQ=1191, SECTORS_DONE=128, WORDS_V=16384, BYTES=65536. İlk 128 sektörün tamamı TCM'e doğru yazıldı ve doğrulandı; RETRIES=14 gerçek retry yolunun çalıştığını gösterdi.
Pencere-kurmaya da retry gerekiyor
MM_SECTOR=128, MM_WORD=0, REWINDOWS=2. 0x1a8000 penceresine geçerken set_backplane_window bir geçici R5 gürültüsüne takıldı ve retry olmadığı için stage break etti.
Doğru çalışanlar
imaj 81bceb23711d48daddcf9d688e33d865d77f2963edb7ad79e415562a70c547c9
kanıt evidence/rpi5/radio/attempt-r48-firmware-full-download-uart-capture/
Sorulan: Pencere-kurma retry'si eklendiğinde tam indirme takılmadan ilerler mi ve hız yeterli mi?
Cevap: Takılmadı ama hız pratik değil: yaklaşık 8,08 s/sektör; tam indirme yaklaşık 160 dakika ederdi.
Staging başladı ve ilerledi
GATE1=1, EROM sağlıklı, SDCLK /16 kararlı. FWSTAGE_P S=0 ve S=64 fazları görüldü; tüm beklemeler sınırlıydı, sistem hang olmadı.
Kök hız duvarı: komut tamamlanmasını bekleme
S=0 PH=3 → S=64 PH=3 arası ~517 s, yani 8,08 s/sektör. /16'da çoğu cmd52 INT_CMD_COMPLETE üretmediği için issue() 1.000.000 poll cezasını ödüyordu.
Doğru çalışanlar
imaj 2419879e5ba5908965405fdf7d1aedf5eb8e83d036f01ef85331b81e27f39f64
kanıt evidence/rpi5/radio/attempt-r49-firmware-full-download-retry-uart-capture/
Sorulan: Komut-tamamlama beklemesi 1.000.000'den 50.000'e inerse tam indirme pratik hıza gelir mi?
Cevap: Kısmen hızlandı ama yetmedi: yaklaşık 4,8 s/sektör. Asıl sorun granülerlik ve kalan inhibit beklemesi.
Hızlandı ama hâlâ çok yavaş
Aynı wall-time penceresinde R49 ~S=64 iken R50 S=192'ye ulaştı; ~1,7× hızlanma. Tam indirme hâlâ yaklaşık 95 dakika sürecekti, güç elle kesildi.
Sektör başına 1024 cmd52 pratik değil
cmd52_write_u32 dört tek-bayt cmd52; 128 kelimelik bir sektör yaz+verify ile yaklaşık 1024 cmd52 demek. Completion sınırı indi ama inhibit 100K kaldı; cmd53 blok yazma hâlâ gerçek hızlı yol adayı.
Doğru çalışanlar
imaj 0207cf9b011e2ea076e34ef6e539edd5f74fe40a87f4535a0f3e767cbe5e2668
kanıt evidence/rpi5/radio/attempt-r50-firmware-full-download-fast-complete-uart-capture/
Sorulan: Wrapper yazmaları cmd52'ye alınır ve gerçek ai_resetcore denenirse cmd53-TCM açılır mı?
Cevap: Hayır. Resetcore hipotezi çürüdü; cmd53-TCM açılmadı ve bozuk reset dizisi TCM erişimini kararttı.
Wrapper cmd52 yazmaları iniyor
HALT WRITE_OK=1. backplane_write32'nin cmd52'ye alınması wrapper kayıtlarına yazmayı R5-temiz hale getirdi; bu ayrı düzeltme çalıştı.
Resetcore TCM'i bozdu
RST_ASSERT=0, IOCTL_A=0x00, CPUHALT=0, HALTED=0. CLK biti kayboldu; TCM_C52=0x00000000 ve W_TOOK=0. Boot-ROM'un bıraktığı clocked+halted durum bozulunca TCM erişilemez oldu.
cmd53-TCM ayırt edicisi çekirdek saati değil
R40'ta CLK açıkken cmd53-TCM 0x0060 ile düşüyordu. R51 resetcore'u bozuldu diye cmd53 açılmadı; hızlı yol hâlâ kapalı.
Doğru çalışanlar
imaj ee14647c40b6b837d26fc56c402a10ab47d2dd1b31449f468867ae6398e30484
kanıt evidence/rpi5/radio/attempt-r51-resetcore-cmd53-tcm-probe-uart-capture/
Düzeltme (R14 sonrası): R53 bu probu düzeltti ve gerçek ölçümü aldı; R52'deki sıfır süreler performans sonucu değildir.
Sorulan: Saat-süpürme probu /16, /32 ve /64'te cmd52 yaz+verify hızını gerçek ölçebilir mi?
Cevap: Hayır. Prob pencere ok'ine fazla güvendi, ok=false'ta erken döndü; üç saatte de ölçüm yapılmadı.
SECTOR_US=0 gerçek ölçüm yok demek
CLKSWEEP DIV=0x08/0x10/0x20 için MATCHED=0 ve SECTOR_US=0. 1024 cmd52'lik döngü çalışsa süre sıfır olamazdı; set_backplane_window ok=false dönüşü erken return ettirdi.
R53 düzeltmesi belirlendi
Pencere baytları R5 gürültüsüne rağmen inebiliyor. R53 probu pencere ok'ine güvenmeyecek: 5x retry, koşulsuz ölçüm, WIN_OK/WIN_TRIES telemetrisi.
Doğru çalışanlar
imaj 8afc6f3b3159202afb34d79852c1e5eb52f350b71f0785fdddfc57ad17f1bbb1
kanıt evidence/rpi5/radio/attempt-r52-clock-sweep-uart-capture/
Sorulan: Düzeltilmiş saat-süpürme probu gerçek ölçüm verdiğinde yavaş saat cmd52 bütünlüğünü veya hızı iyileştiriyor mu?
Cevap: Hayır. R53 son durum: yavaş saat yardımcı değil; süre veri aktarımından değil, sabit timeout-spin beklemelerinden geliyor.
Saat-süpürme ilk kez ölçtü
DIV 0x08 (/16): WIN_OK=1, MATCHED=100/128, SECTOR_MS=4976, FULL_MIN=98. DIV 0x10 (/32): MATCHED=46/128, SECTOR_MS=4274, FULL_MIN=84. DIV 0x20 (/64): WIN_OK=0, MATCHED=0/128, SECTOR_MS=3442, FULL_MIN=68.
Süre saatten bağımsız, timeout domine
SECTOR_MS saatle ölçeklenmiyor; /64 hafif daha hızlı bile görünüyor. Bu, gerçek veri hızından çok issue() içindeki sabit inhibit 100K + completion 50K poll sınırlarının takılmış status bitlerinde tüketildiğini gösteriyor.
R54 kaldıraç noktası
MATCHED yavaş saatte düştü (100→46→0), bu yüzden saat /16'da kalmalı. Asıl sonraki hamle, inhibit bekleme sınırını completion gibi fail-fast düşürmek; bütünlük verify+retry ile korunuyor.
Doğru çalışanlar
imaj 01fdc49c2adef3207f4b9a89f77557eb445c560ab1875b885ccd8f43dd6a34ea
kanıt evidence/rpi5/radio/attempt-r53-clock-sweep-measured-uart-capture/
Sorulan: issue() bekleme sınırı faza göre 2K'ya çekilince cmd52 indirmesi /16'da pratik hıza gelir mi, bütünlük bozulur mu?
Cevap: Evet, ~45× hızlandı: /16'da 4976 ms → 109 ms/sektör, tam indirme ~2 dk; bütünlük bozulmadı.
Faza bağlı sınır 2K: ~45× hızlanma
ISSUEBOUND N=2000. CLKSWEEP DIV=0x08 (/16): WIN_OK=1, MATCHED=106/128, SECTOR_MS=109 (R53'te 4976 idi), FULL_MIN_EST=2. Gate1/erom /256'da 50K korundu; yalnız staging /16'da 2K'ya çekildi. Süre saatten değil, issue() timeout-spin'lerinden geliyordu; sınır düşünce çözüldü.
Fail-fast bütünlüğü bozmadı
MATCHED=106/128 — R53'ün 100'ünden bile iyi. /32=43, /64=0; slower saat yine kötü, /16 tatlı nokta doğrulandı. Prob settle'sız write+immediate-read yapar (kötümser); gerçek stage_to_tcm settle+verify+retry ile kalan uyuşmazlıkları toplar.
Doğru çalışanlar
imaj a765ded00f1c1c76198237d8934699889c089f7e3007f9a702c625654289ec16
kanıt evidence/rpi5/radio/attempt-r54-staging-poll-bound-uart-capture/
Sorulan: Faza bağlı 2K sınırla tam 1191-sektör firmware indirme TCM'e tam ve doğru iner mi?
Cevap: PASS. 609 KB firmware CR4 TCM'e TAM ve DOĞRULANMIŞ indirildi: SECTORS_DONE=1191, WORDS_V=152448, RETRIES=0, OK=1, ~2–3 dk.
Tüm dosya doğrulandı (OK=1)
FWSTAGE SECTORS_DONE=1191 WORDS_W=152448 WORDS_V=152448 (=1191×128) RETRIES=0 REWINDOWS=19 BYTES=609792 OK=1. Her kelime cmd52 ile TCM'e yazıldı ve geri okumada doğrulandı; hiç yeniden yazma gerekmedi (RETRIES=0).
Kapı 2b (firmware indirme) geçti
Aylarca (R44→R55) süren yavaşlığın kök nedeni /16'da tamamlama bitinin set olmaması ve her cmd52'nin sabit timeout-spin'i ödemesiydi (R48'de 8 s/sektör, ~160 dk). Faza bağlı sınırla ~2–3 dk. cmd53 TCM'de bölge-özgü düştüğü için indirme cmd52 + verify + R49 pencere-retry ile yapıldı.
Doğru çalışanlar
imaj bccd414122c07a6ea54c4761c61fbbd7d3f787c7bbb8bc5ef404202001ca436b
kanıt evidence/rpi5/radio/attempt-r55-full-download-fast-uart-capture/
Düzeltme (R14 sonrası): R57 retry artırdı ama yetmedi; asıl kök nedeni (R5-temiz ok kriteri) R58 DATA-tabanlı doğrulamayla çözdü.
Sorulan: Firmware indikten sonra NVRAM RAM tepesine (0x238000 − varsz) yüklenip doğrulanır mı?
Cevap: Bu boot'ta test edilemedi: firmware indirme şanssız /16 boot'unda sektör 128'de abort etti; NVRAM (st.ok'a bağlı) çalışmadı.
Firmware sektör 128'de abort
SECTORS_DONE=128 WORDS_V=16383 OK=0. FWSTAGE kodu R55 (PASS) ile BAYT-BAYT aynı; fark yalnız boot-to-boot /16 değişkenliği — 5-retry pencere + 3-retry kelime şanssız boot'ta yetmedi.
NVRAM kodu koşturulmadı (doğru davranış)
NVRAM adımı if st.ok(stage_sectors)'a bağlı; firmware OK=0 olunca atlandı. nvram_transform host-test edildi (gerçek BRCMNVR.TXT'de token doğru) ama cihazda henüz çalışmadı.
Doğru çalışanlar
imaj f9aaf05702ad4f5defa50b6d74c9a85f8acdb4622944ef70138756f69f1e6554
kanıt evidence/rpi5/radio/attempt-r56-nvram-load-uart-capture/
Düzeltme (R14 sonrası): R58 doğrulamayı DATA-tabanlı yaptı (completion/R5 yoksayılır) ve firmware+NVRAM geçti.
Sorulan: Pencere-retry 5→16 ve kelime-retry 3→8 firmware'i şanssız boot'ta kurtarır mı?
Cevap: Hayır — daha da erken abort etti (sektör 64). Retry SAYISI kök neden değil.
Retry artışı yetmedi
SECTORS_DONE=64 WORDS_V=8191 OK=0. 16 window retry de İLK pencere geçişinde (0x1a0000) tükendi. Bu boot R56'dan daha gürültülüydü.
Kök: R5-temiz ok kriteri, retry değil
set_backplane_window'un ok'i cmd52 write+read'in R5-TEMİZ olmasını istiyor; /16'da kötü boot'ta R5 hiç temizlenmiyor. Ama SBADDR baytları iniyor ve card doğru DATA döndürüyor (R47/R53). Aynı sorun kelime-verify'da: cmd52_read_u32 completion set olmayınca None döner.
Doğru çalışanlar
imaj 31838a2e9997194abf6bf5391740ab6e389e6fa9d7a7598ecb4fb1d055161cea
kanıt evidence/rpi5/radio/attempt-r57-nvram-load-robust-uart-capture/
Sorulan: Verify ve pencere-set completion/R5'i yoksayıp DATA baytıyla doğrularsa firmware güvenilir iner ve NVRAM yüklenir mi?
Cevap: PASS ×2. Gürültülü boot'ta bile firmware WORDS_V=152448 RETRIES=0 OK=1, ve NVRAM ilk kez yüklendi (OK=1, TOKEN_OK=1, FW_INTACT=1).
Firmware gürültülü boot'ta %100 doğrulandı
WORDS_W=101526 (152448'in yalnız %67'si R5-temiz yazma) = R56/R57'yi abort ettiren gürültü seviyesi. Ama DATA-tabanlı verify ile WORDS_V=152448, RETRIES=0, REWINDOWS=19, OK=1. Status yerine gerçek veriyi okumak gürültülü boot'u sorunsuz geçirdi.
NVRAM ilk kez TCM'de
FOUND=1 SRC_LEN=2074 VARSZ=1748 ADDR=0x23792c TOKEN=0xfe4b01b4 TOKEN_OK=1 WORDS=437 VERIFIED=437 OK=1. FW_WORD0=0xb83ef198 FW_INTACT=1 — NVRAM firmware'in üstüne binmedi (0x238000 − varsz, token 0x237FFC'de).
Doğru çalışanlar
imaj a984c16b3664be504b70b4abfb5e3b6c9b9da9d72e8ddfa75d3e5a984dce4a61
kanıt evidence/rpi5/radio/attempt-r58-nvram-data-verify-uart-capture/
Sorulan: CR4 çekirdeği (reset vektörü + reset döngüsü IOCTL 0x23→0x03→0x01) başlatılabilir mi?
Cevap: 3 denemede başarısız. R59a boot USB-init döngüsüne takıldı, R59b SD kart firmware tarafından okunamadı (ikisi de kart oturması); R59c reseat sonrası firmware+NVRAM 3. kez PASS ama CR4 START başarısız — reset döngüsü saati kesti (R51 gibi).
Kök neden R59a/b: kart oturması
Firmware USB-boot döngüsü / SD okunamaması bizim kodumuz değil, kart yuvası oturmasıydı; Mac kartı sorunsuz okudu, SHA doğrulandı. Reseat düzeltti.
CR4 START saati kesiyor
R59c: firmware+NVRAM OK=1 ama çekirdek serbest bırakılınca wrapper/TCM karardı; ilk hipotez 'reset döngüsü saati kesiyor'.
Doğru çalışanlar
imaj 6c54b6ed0cbfdff19381d13c0218b548c4f62d342510984f7d9229edc396eb21
kanıt evidence/rpi5/radio/attempt-r59c-cr4-start-uart-capture/
Sorulan: Reset döngüsü yerine doğrudan CPUHALT temizlense saat düşmesi önlenir mi?
Cevap: Hayır. Clear-CPUHALT de saati kesti (IOCTL_F=0x00, STARTED=0). Sorun reset döngüsü değil; çekirdek serbest bırakılınca backplane saat-tutması kayboluyor.
Reset değil, saat-tutma
Reset döngüsünü atlayıp doğrudan CPUHALT temizlemek de wrapper'ı kararttı → suçlu reset dizisi değil, saatin tutulmaması.
Doğru çalışanlar
imaj aec507b4630d9f3aef2c568e79b1c8772664d94f7e50e9d82858e3743814a0d3
kanıt evidence/rpi5/radio/attempt-r60-cr4-start-cpuhalt-clear-uart-capture/
Sorulan: Backplane saati (ALP) tutulursa çekirdek serbest bırakılınca ayakta kalır mı?
Cevap: R61a çok gürültülü boot'ta firmware sektör 576'da abort etti (CR4-start test edilemedi). R61b temiz PASS'te: ALP tutuldu ama CR4-start yine saati kesti — HT gerekiyor ve verilemiyor.
ALP tutmak yetmiyor
ALP tutulmuş olsa da çekirdek un-halt olunca wrapper karardı; asıl gereken HT ve o gelmiyor.
Doğru çalışanlar
imaj a8d547da552a2a97042ef550c71ad7ecc2f4a52f4948f54e70519f719f9447d8
kanıt evidence/rpi5/radio/attempt-r61b-cr4-start-clkhold-retry-uart-capture/
Sorulan: FGC (Force Gated Clock) biti saati zorlar mı?
Cevap: Yetmedi. CLK_CSR=0x58 CLK_ALP=1 ama IOCTL_F=0x00 STARTED=0. Saat ZORLANMADIĞI için ALP kaynağı çekirdek un-halt olunca düştü.
FGC tek başına çözmedi
FGC ile de wrapper karardı; o an 'saat zorlanmalı' diye yorumlandı.
Doğru çalışanlar
imaj acd3a6b503b3d55e8521f255bb6b0c8628e735127eee1727f2b466c4bb9f2f6c
kanıt evidence/rpi5/radio/attempt-r62-cr4-start-fgc-uart-capture/
Sorulan: Zorlanmış ALP + FGC birlikte HT'yi getirir mi?
Cevap: Hayır (5. deneme). CLK_CSR=0x69 CLK_HT=0 CLK_ALP=1 IOCTL_F=0x00 STARTED=0. CR4-start bir HT/PMU duvarı gibi görünüyor.
HT/PMU duvarı ilk kez adlandırıldı
Zorlanmış ALP+FGC de HT üretmedi; duvarın saat/PMU kaynaklı olabileceği ilk kez yazıldı.
Doğru çalışanlar
imaj 7d2b4efc764d92127b581ca736604301b6732bbaf50fb4d9a6fc370880948d96
kanıt evidence/rpi5/radio/attempt-r63-cr4-start-force-alp-uart-capture/
Düzeltme (R14 sonrası): R72/R73: boşluk bitleri 3/16/18 saat kaynağı DEĞİL (HSICLDO/PERST/ILP); PMU-force ölüydü.
Sorulan: PMU salt-okunur tanısı: duvar takılı-silikon mu, düzeltilebilir-PMU mu?
Cevap: Salt-okunur PMU tanısı: PMU kararlı (takılı-transition değil), minimum kaynaklarda. RES_STATE=0x0fcaff77 == MINRES, MAXRES=0x0fcfff7f (fark: bit 3/16/18), RES_PEND=0, PMU STAT=0x2a.
PMU kararlı, minimumda
RES_STATE==MINRES ve RES_PEND=0 → PMU takılı değil; MAXRES daha fazlasına izin veriyor → o an 'düzeltilebilir-PMU' sanıldı (R72/R73 bu boşluk bitlerinin saat olmadığını gösterdi).
Doğru çalışanlar
imaj eb79f153839db56e5d75f4750e78ddede4061b3b63ef605351d50e86a0f94797
kanıt evidence/rpi5/radio/attempt-r64-pmu-probe-uart-capture/
Düzeltme (R14 sonrası): R72/R73: HT host-tarafı açılamaz (max_res_mask HT bitlerini kapatır) → PMU-force yapısal olarak etkisiz.
Sorulan: min_res_mask'i MAXRES'e çekmek HT/PLL kaynağını açar mı?
Cevap: Sonuçsuz. min_res_mask=MAXRES yazıldı ama RES_STATE değişmedi, HT gelmedi (CLK_HT=0, OK=0). Yazmanın gerçekten oturduğu teyit edilmedi.
PMU-force etkisiz
İlk PMU yazması; RES_STATE hareket etmedi. Yazma teyidi gerekiyordu → R66.
Doğru çalışanlar
imaj 4b950251d6791ea3ddce4c84dacd01766c93ccb1560d525609176f10313fb16b
kanıt evidence/rpi5/radio/attempt-r65-pmu-force-cr4-start-uart-capture/
Sorulan: PMU-force yazması gerçekten oturuyor mu (geri-okuma)?
Cevap: Geri-okuma da gürültülü: MINRES_SET geri 0x0f000f00 okundu, IOCTL_F=0x18181818. /16 SD saatinde cr4_start-içi okumalar güvenilmez — bu, sonraki denemelerde DATA-tabanlı okumaya geçişi motive etti.
/16'da cr4_start-içi okuma güvenilmez
Geri-okumalar gürültülü/garbage → makbuz güvenilirliği için DATA-tabanlı okuma ve doğru oracle gerektiği anlaşıldı.
Doğru çalışanlar
imaj 32740a16d365409765c68b278fa081c9b23d166433fc69311679b95e98cd9bb5
kanıt evidence/rpi5/radio/attempt-r66-pmu-force-readback-uart-capture/
Sorulan: cyw43/brcmf'in DOĞRU dizisi + doğru oracle ile çekirdek çalışır mı?
Cevap: Firmware çalışmadı (HT 1 sn'de gelmedi, STARTED=0). Reframe: HT firmware-sürümlü (~29ms SONRA), kararmış wrapper NORMAL hand-off. Ama RST_ASSERT=0 → o an 'yanlış wrapper (idle slave)' şüphesi doğdu.
Doğru dizi de çalıştırmadı
rstvec adres-0'a, reset döngüsü, terminal 0x01; RSTVEC_OK=1 ALIAS_OK=1 IOCTL_B=0x21 ama HT_AVAIL=0. Araştırma: HT firmware-sürümlü, dark wrapper normal.
Doğru çalışanlar
imaj 0e794c4ecb86d55185100e77a5e1962e2df8c5aaffb2afde1e42d751bce9e30d
kanıt evidence/rpi5/radio/attempt-r67-cr4-start-ht-oracle-uart-capture/
Düzeltme (R14 sonrası): R73: 'FGC suçlu' YANLIŞTI — karanlık okuma FGC saat-gate'inin beklenen etkisi; FGC geri konunca da çekirdek çalışmadı.
Sorulan: 0x18102000 gerçek CR4 wrapper mı yoksa idle slave mı (yazmaya yanıt veriyor mu)?
Cevap: Wrapper GERÇEK: IOCTL_B=0x21 reset döngüsünden ÖNCE temiz okundu (idle slave bunu vermezdi). Ama 0x23 (CPUHALT|FGC|CLK) yazınca sonraki TÜM okumalar 0x00 = wrapper karardı. O an FGC suçlu sanıldı.
Yanlış-wrapper ipucu çürüdü
IOCTL_B=0x21 temiz → 0x18102000 doğru CR4 wrapper. Yazmadan sonra 0x00 → o an 'FGC backplane okuma yolunu kesiyor' diye yorumlandı.
Doğru çalışanlar
imaj e31c8ed7e153b3c650388167cba86ac7ffe1a8446526a11c09067497b1195517
kanıt evidence/rpi5/radio/attempt-r68-wrapper-response-diag-uart-capture/
Düzeltme (R14 sonrası): R72/R73: karartma zaten CR4/HT saat-domeninin beklenen etkisi; wrapper canlılık göstergesi değildi.
Sorulan: FGC reset döngüsünden çıkarılırsa wrapper okunabilir kalır mı?
Cevap: Hayır. Aynı 0x21 değerini (FGC yok) yazınca da IOCTL_PRE=0x00 (wrapper karardı). O an 'yazmanın kendisi, değerden bağımsız, wrapper'ı karartıyor' diye yorumlandı.
FGC-özgü değil
0x21 (değişmeyen değer, FGC yok) yazınca da karardı → FGC hipotezi o an çürütüldü sanıldı; asıl neden sonra anlaşıldı.
Doğru çalışanlar
imaj c4a3100887175454c97b98418d71c55b8454d2b8a719bce4a506c0d774478b9a
kanıt evidence/rpi5/radio/attempt-r69-reset-no-fgc-uart-capture/
Sorulan: Doğru başarı-göstergesi (sdpcm_shared @ 0x237FFC) çekirdeğin koştuğunu gösterir mi?
Cevap: Araştırma: HT_AVAIL ve wrapper CR4 yürütmesini raporlayamaz. Doğru gösterge 0x237FFC (rambase+ramsize-4). Ama saat temizken SHARED_RAW=0x00 (token bile değil) — çekirdek serbest bırakılınca TCM okuması karardı.
Yeni olgu: release sonrası TCM karardı
Adım 2'de (halt) adres-0 TCM okundu; adım 5'te (serbest) 0x237FFC=0x00. O an 'saati temizlediğimiz için backplane saati düştü' diye yorumlandı → R71.
Doğru çalışanlar
imaj ffce629f31a01cde65524b678884d2fce95af096d928a05a326ef22de2349fde
kanıt evidence/rpi5/radio/attempt-r70-shared-word-oracle-uart-capture/
Sorulan: Backplane saati (ALP) tutulursa release sonrası 0x237FFC okunabilir mi?
Cevap: Hayır. CLK_CSR=0x49 (ALP tutuldu) ama SHARED_RAW yine 0x00. Karartma saatten BAĞIMSIZ: çekirdeğin reset'ten çıkması host'un TCM erişimini saatten bağımsız karartıyor.
Saat-tut hipotezi çürüdü
ALP zorla-tutulsa bile TCM okunamadı → sorun host clock isteği değil.
Doğru çalışanlar
imaj eeb8e70d6fe78007e0cd6455c376d03a61257d6b0a647ffddfc2cb32606bef4d
kanıt evidence/rpi5/radio/attempt-r71-hold-alp-clock-uart-capture/
Düzeltme (R14 sonrası): R73: 'LPO donanım duvarı' FAZLA-ÇIKARIMDI — EXT_LPO_AVAIL=0 normaldir (43455 iç LPO; Pi'de harici 32kHz yok); HAVEALP=1+res_pend=0 iç LPO'yu kanıtlar.
Sorulan: Çekirdek bölgesi DIŞINDA, always-on tanıklar çekirdeğin koştuğunu gösterir mi?
Cevap: EROM'dan SDIO çekirdeği (0x829 @ 0x18004000) bulundu. CC_CHIPID=0x4345 (backplane canlı) ama MBOX=0, INTSTAT=0 (1 sn), RES_PEND=0, EXECUTED=0 → yürütme tanığı yok. O an EXT_LPO_AVAIL=0 görülüp 'LPO donanım duvarı' sanıldı.
Doğru gösterge: yürütme yok
Always-on SDIO mailbox/intstatus + PMU (CR4/HT domeni dışında) hiç yürütme sinyali göstermedi.
Doğru çalışanlar
imaj 720c459005a27c78a559ed8a181899f8b84e6ad7ff602aa4dd170ba1bfce50cc
kanıt evidence/rpi5/radio/attempt-r72-execution-witness-uart-capture/
Sorulan: FGC geri yüklenirse (R69'u tersine çevir) + doğru oracle ile çekirdek koşar mı?
Cevap: Hayır. FGC geri (0x23/0x03) ama MBOX=0, INTSTAT=0, RES_PEND=0, EXECUTED=0 — R72 ile aynı. FGC de belirleyici değil. PMU_TA=PMU_TB=0x00 (belirsiz). İki fazla-çıkarım düzeltildi.
İki yorum dürüstçe düzeltildi
(a) EXT_LPO_AVAIL=0 normaldir (iç LPO aktif); (b) FGC var/yok fark etmiyor. Kalan tek spesifik hipotez: 4345 CR4 rstvec/giriş semantiği (backplane-0 vs rambase).
Doğru çalışanlar
imaj aa17c94c852b077e6004b05d9b89173f9355f5fa3fb63242a9fddb258fb49311
kanıt evidence/rpi5/radio/attempt-r73-fgc-restore-witness-uart-capture/
Sorulan: Kaynak-teyitli tek KESİN sapma — brcmf'in cr4_set_passive'de D11 (802.11 MAC) çekirdeğini disable etmesi — uygulanırsa CR4 koşar mı?
Cevap: Hayır (16. CR4-start denemesi; radyo kapanışı). Önce rstvec kaynakla DOĞRU teyit edildi (brcmfmac chip.c:1343 ve sdio.c:3903-3905 — backplane adres-0 yazması CR4 için doğru, CM3-ism değil). Bu satır numaraları R75 kontrol koşusunun çalıştırdığı ağaca aittir: Linux 6.18.34+rpt-rpi-2712, drivers/net/wireless/broadcom/brcm80211/brcmfmac/. Kaynak dosyalar bu depoda YOKTUR; iddia depoda yalnızca R80 trace'i ve R75 dmesg'i ile bağımsız olarak doğrulanabilir. Sonra D11-disable uygulandı: EROM D11'i buldu (D11_WRAP=0x18101000), yazmalar landı — ama yürütme yine YOK (MBOX=0, INTSTAT=0, RES_PEND=0, EXECUTED=0). Firmware 17. kez PASS.
rstvec kaynak-teyitli DOĞRU (elenen 4. lead)
brcmfmac cr4_set_active gerçek rstvec'i ops->activate'e geçirir (chip.c:1343, Linux 6.18.34+rpt-rpi-2712 ağacı); sdio.c:3903-3905 rstvec'i backplane ADRES 0'a yazar; cm3_set_active 0 geçer (guard atlar) → adres-0 yazması CR4'ün doğru yoludur, CM3-ism değil. Bizim yaptığımız birebir doğru. Vektör hata DEĞİL.
D11-disable uygulandı, çekirdek yine koşmadı
Tek KESİN upstream sapması (brcmf cr4_set_passive D11'i disable eder, chip.c:1334; biz atlıyorduk). EROM D11'i (0x812) 0x18101000'de buldu; ai_coredisable yazmaları R5-temiz. Ama MBOX/INTSTAT/RES_PEND/EXECUTED hepsi 0. D11 de elendi. (D11 wrapper'ı CR4 gibi yazma-sonrası karardığından disable geri-okumayla teyit edilemez, ama yazmalar landı.)
Radyo dürüstçe kapatıldı
Elenen kaynak-teyitli/spesifik ipuçları: reset-dizisi (FGC/saat/oracle), rstvec (doğru), D11-disable (uygulandı, sonuç yok). Kalan iki olasılık doğrulanmış sdio.c/chip.c yolunun DIŞINDA ve zayıf: nvram trailing-token biçimi (firmware.c), fw[0] entry bu imaj için. Fiziksel döngüyü hak edecek güçte değil.
Doğru çalışanlar
imaj 0d171f223ce4766813a130a49a18c2c140d88c57500dbd9e90880155101fa25b
kanıt evidence/rpi5/radio/attempt-r74-d11-disable-uart-capture/
Sorulan: Aynı fiziksel Raspberry Pi 5 kartı tam cold boot sonrası Linux/brcmfmac ile BCM43455'i çalıştırabiliyor mu?
Cevap: Evet. R75 Linux kontrolü pozitif: brcmfmac aynı F1 imzasını/CHIPID'i okudu, aynı 43455 firmware ailesiyle firmware preinit'i tamamladı, wlan0 arayüzü oluştu ve Bluetooth HCI hci0 çalıştı. Bu association/ping kanıtı değildir; WLAN soft-blocked kaldı.
Linux Wi‑Fi firmware yolu çalıştı
dmesg: brcmfmac F1 signature read @0x18000000=0x15264345; brcmf_fw_alloc_request brcm/brcmfmac43455-sdio kullandı; brcmf_c_preinit_dcmds firmware satırı geldi: BCM4345/6 wl0, version 7.45.265, FWID 01-b677b91b. Negatif aramada HT Avail timeout veya brcmf firmware-start failure satırı yok.
Aynı firmware kimlikleri
Linux kartındaki 43455 dosyalarının SHA256'ları AselsanOS sayfasındaki pinlerle aynı: standard firmware d608f866…, NVRAM txt ca709be8…, CLM blob 9823842c…. Yani R75, farklı blob ailesiyle alınmış bir başarı değil.
Bluetooth HCI de çalıştı
Bluetooth hci0 UP/RUNNING, BCM43455 37.4MHz satırı görüldü; hciconfig RX/TX event/command sayacı pozitif; btmon başarılı HCI Command Complete olayları kaydetti. R2–R53'teki AselsanOS TX=4 ANSWERED=0 suskunluğu Linux'ta tekrar etmedi.
Doğru çalışanlar
imaj Raspberry Pi OS 64-bit · Linux 6.18.34+rpt-rpi-2712 · Raspberry Pi 5 Model B Rev 1.1
kanıt evidence/rpi5/radio/attempt-r75-linux-control/
Sorulan: Linux brcmf_sdio_buscore_activate() gibi SDIO core intstatus'u rstvec'ten önce temizlemek CR4 yürütmesini başlatır mı?
Cevap: Hayır. R76 tek semantik değişkeni doğru uyguladı: SDIO_INT_B=0x00020000, SDIO_INT_CLR=1, SDIO_INT_A=0x00000000. Latch temizlendi ama MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0 kaldı.
intstatus clear yazması gerçekten landı
R76'nın yeni CR4START makbuzu SDIO core interrupt latch'inin önce 0x00020000 olduğunu, 0xffffffff clear yazmasının başarıyla çıktığını ve sonrasında 0x00000000 okunduğunu gösterdi.
CR4 yürütme tanığı yine yok
MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0. Bu yüzden intstatus temizliği tek başına Linux/AselsanOS first-diff değil.
Doğru çalışanlar
imaj 168bd3bb47464bddf0ef33e4b0e365ea946206d959985e6ed77d74712726551d
kanıt evidence/rpi5/radio/attempt-r76-intstatus-first-diff-uart-capture/
Sorulan: Linux brcmf_sdio_kso_init() gibi SLEEPCSR KSO bitini D11/rstvec öncesi set etmek CR4 yürütmesini başlatır mı?
Cevap: Hayır. R77 ölçtü: KSO_REV=21, KSO_B=0x03, KSO_W=1, KSO_A=0x03, KSO_SET=1, KSO_DEVON=1. KSO/DEVON zaten iyiydi; MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0 kaldı.
KSO init uygulanabilir ama eksik halka değil
SDIO core rev 21 olduğu için Linux KSO init kuralı geçerliydi. Ancak KSO_B=0x03, KSO ve DEVON bitlerinin yazmadan önce zaten 1 olduğunu gösterdi. Yazma yolu KSO_W=1 ile tamamlandı, KSO_A=0x03 kaldı.
CR4 yürütme tanığı yine yok
R76 intstatus clear yine land etti, fakat MBOX/INTSTAT/EXECUTED/STARTED sıfır kaldı. KSO init tek başına Linux/AselsanOS first-diff değil.
Doğru çalışanlar
imaj bd7d86e59b0ac8c083738e9455619169ff3accb23f946ebd041769820220cebb
kanıt evidence/rpi5/radio/attempt-r77-kso-init-uart-capture/
Sorulan: Exact Linux brcmf_sdio_buscoreprep clock dizisini (CHIPCLKCSR 0x28→0x21) KSO/D11/rstvec öncesine almak CR4 yürütmesini başlatır mı?
Cevap: Hayır. R78 clock dizisini uyguladı: CLK_REQ=0x28, CLK_R=0x68, CLK_HOLD=0x21, CLK_CSR=0x61. Ama MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0 kaldı; ayrıca WRITE_OK=0 ile bu yerleşim zararlı çıktı.
Exact clock landed, CR4 başlamadı
Linux buscoreprep byte'ları ölçüldü: 0x28 isteği, 0x68 readback, 0x21 hold, 0x61 son CSR. Buna rağmen host-görünür yürütme tanığı yok.
Yan etki: WRITE_OK düştü
R76/R77'de WRITE_OK=1 iken R78'de WRITE_OK=0 oldu. Bu yüzden sonraki adaylarda exact 0x28→0x21 tutulmayacak; R77'nin non-harmful 0x29→0x09 clock baseline'ına dönülecek.
Doğru çalışanlar
imaj bc3889b94248af6c7f1b24298beee134be7ea1c1af8eb16662ce94eb46a26925
kanıt evidence/rpi5/radio/attempt-r78-exact-buscoreprep-clock-uart-capture/
Sorulan: Linux probe_attach() gibi Function-0 CARDCTRL_WLANRESET bitini KSO sonrası, D11/rstvec öncesi set etmek CR4 yürütmesini başlatır mı?
Cevap: Hayır. R79 ölçtü: CARD_B=0x01, CARD_W=1, CARD_A=0x03, CARD_WLANRST=1, CLK_REQ=0x29, CLK_HOLD=0x09, WRITE_OK=1. Bit land etti ama MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0 kaldı.
CARDCTRL_WLANRESET yazması gerçekten landı
Function-0 0xf1 önce 0x01 okundu, bit 1 set edildi, sonra 0x03 geri okundu. CARD_WLANRST=1. R77 clock baseline korundu ve WRITE_OK=1 geri geldi.
CR4 yürütme tanığı yine yok
MBOX=0, INTSTAT=0, HT_AVAIL=0, EXECUTED=0, STARTED=0. Bounded first-diff 1–4 (intstatus, KSO, exact clock, CARDCTRL) tek başına elendi.
Doğru çalışanlar
imaj 8892f43599572bd3f23a5aeb3091490258ecdec35a20e1a53cc164271f06070f
kanıt evidence/rpi5/radio/attempt-r79-cardctrl-wlanreset-uart-capture/
Sorulan: Aynı Pi 5'te Linux brcmfmac/mmc/sdio işlem sırası boot-time ftrace ile yakalanır mı?
Cevap: Evet. Manuel collector `R80 done` yazdı. wlan0 managed (ch 36), hci0 UP RUNNING, CHIPID 0x15264345, firmware 7.45.265. 27 MB function trace: buscoreprep @25.714586, htclk @25.823750, ramrw @25.823769.
Linux buscoreprep firmware indirmeden önce
brcmf_sdio_buscoreprep probe'da, ramrw'dan ~109 ms önce. R78 aynı clock byte'larını CR4-start sonrasına koyduğu için yanlış yere uyguladı ve WRITE_OK=0 oldu.
htclk hemen ramrw öncesi
firmware_callback → htclk → ramrw. KSO watchdog thread firmware ayaktayken geliyor; R77'nin rstvec-öncesi KSO'su bu izdeki ilk kso_control değil.
Doğru çalışanlar
imaj linux-r80-manual-collector
kanıt evidence/rpi5/radio/attempt-r80-linux-sdio-trace/
Sorulan: Linux probe_attach (KSO+CARDCTRL+PMU RES_RELOAD+D11) firmware'den önce ve htclk ALP_AVAIL_REQ 0x08 ramrw hemen öncesi CR4'ü başlatır mı?
Cevap: Hayır; koşu CR4-start'a ulaşmadı. ATTACH KSO/CARDCTRL land etti, HTCLK REQ=0x08 ALP=1 HT=0, sonra firmware heartbeat S=64/1191'de durdu. SCREEN0/TOUCHREADY/CR4START yok. PMU RELOAD=0 ve D11_RST=0 (0x18181818 gürültü).
HTCLK 0x08 ramrw öncesi TCM yolunu durdurdu
Buscoreprep hold 0x21'i ALP_AVAIL_REQ 0x08 ile değiştirdikten sonra stage_to_tcm S=64'te takıldı. R79 aynı kartta FWSTAGE OK=1 ve TOUCHREADY üretmişti. R70 saat temizlemenin TCM'i kararttığını zaten göstermişti; Linux alp_only bu yuvaya kopyalanamaz.
KSO ve CARDCTRL attach yuvasında land etti
KSO_B=0x03 KSO_A=0x03 SET=1 DEVON=1; CARD_B=0x01 CARD_A=0x03 WLANRST=1. Bunlar R77/R79 ile aynı bitler, Linux probe_attach yerinde.
Doğru çalışanlar
imaj 90d221007f6d834e3176b0f4de1d96f5bf15769b42455c7dd8225406722b716c
kanıt evidence/rpi5/radio/attempt-r81-linux-order-combined-uart-capture/
Sorulan: R81 HTCLK 0x08 yazmadan, buscoreprep ALP hold 0x21 ile firmware indirmek CR4 yolunu açar mı?
Cevap: Hayır. HTCLK SKIP=1 CSR=0x61 ALP=1 doğru hold'u gösterdi ama FWSTAGE yine S=64'te durdu. SCREEN0/CR4START yok. 0x08 tek neden değil.
ALP hold ramrw'ya kadar durdu, TCM yine takıldı
REQ=0x00 SKIP=1 CSR=0x61 = FORCE_ALP|ALP_AVAIL. Firmware heartbeat S=0 sonra S=64, UART 12959 B'de dondu. Yeşil LED söndü.
R79 farkı: attach'te PMU+D11 firmware öncesi
R79 firmware'i bitirdi; KSO/CARDCTRL CR4-start'taydı. R81/R82 attach PMU RES_RELOAD ve D11 disable'ı ramrw öncesine aldı. R83 bunları atlar.
Doğru çalışanlar
imaj b41f096b0d82aadc1bd211aa07a39d5933be3e5ea234a9d4e7be9a1a3c0cedca
kanıt evidence/rpi5/radio/attempt-r82-alp-hold-through-ramrw-uart-capture/
Sorulan: Attach'te yalnız KSO+CARDCTRL (PMU RES_RELOAD ve D11 disable ramrw öncesi yok) firmware'i R79 gibi bitirir ve CR4'ü başlatır mı?
Cevap: Firmware evet, CR4 hayır. SKIP_PMU=1 SKIP_D11=1, HTCLK SKIP=1 CSR=0x61, FWSTAGE OK=1, NVRAM OK=1, TOUCHREADY. CR4START WRITE_OK=1 ama MBOX=0 INTSTAT=0 EXECUTED=0 STARTED=0 HT_AVAIL=0. Wi-Fi PASS değil.
R81/R82 S=64 takılması PMU+D11 ramrw öncesinden
Aynı HTCLK skip ile R82 S=64'te durdu; R83 o iki yazmayı atlayınca SECTORS_DONE=1191 OK=1 ve NVRAM OK=1 geldi. KSO+CARDCTRL attach yuvası TCM ile uyumlu.
CR4 tanığı R79 ile aynı sıfır
CLK_REQ=0x29 CLK_HOLD=0x09 WRITE_OK=1. CARD_B=0x03 (attach'te zaten 0x03). D11_RESET=0. MBOX/INTSTAT/EXECUTED/STARTED/HT_AVAIL=0.
SCREEN0 UART makbuzu; operatör görüntü görmedi
UART BACKLIGHT=15 PANEL_ENABLE=1 DMA_IRQ=0x45 TOUCHREADY yazdı ama PHYSICAL=0 PIXEL=0. Operatör panele görüntü gelmediğini bildirdi. Bu R81/R82 S=64 takılması değil (yeşil LED sönmedi, FWSTAGE OK=1).
Doğru çalışanlar
imaj 69014605ca9f5fa94030e8976d2a719f67a86abfcfbadf290b3f9e5558372d01
kanıt evidence/rpi5/radio/attempt-r83-attach-kso-cardctrl-only-uart-capture/
Sorulan: Attach'te KSO+CARDCTRL'ye yalnız PMU RES_RELOAD eklemek (D11 ramrw sonrası) firmware'i bozar mı, CR4'ü başlatır mı?
Cevap: Firmware bozuldu, CR4'e ulaşılmadı. SKIP_PMU=0 SKIP_D11=1, HTCLK SKIP=1 CSR=0x61. PMU CTL_W=0 CTL_A=0x18181818 RELOAD=0. FWSTAGE_P S=0'da durdu. SCREEN0/CR4START yok. PASS değil.
Pre-ramrw PMU yazması D11 olmadan da TCM'i durdurur
R83 aynı HTCLK skip ile FWSTAGE OK=1 verdi. R84 yalnız PMU RES_RELOAD ekledi; yazma land etmedi (0x18181818) ve heartbeat S=0'da kaldı. R82 S=64 takılması D11'e indirgenemez.
PMU okunurdu, yazma bozdu
CTL_B=0x01770181 (R83 NVRAM sonrası dump ile aynı aile). CTL_W=0, sonra CTL_A=0x18181818. Linux probe_attach yuvasındaki bu yazma bu bus'ta kopyalanamaz.
Doğru çalışanlar
imaj 0973ea248156e82d956ecb502104b7b8f7f868630d77089f80daa6375c01a239
kanıt evidence/rpi5/radio/attempt-r84-attach-pmu-reload-uart-capture/
Sorulan: PMU RES_RELOAD'u NVRAM'den sonra, ramrw öncesi değil, yazmak CR4'ü başlatır mı?
Cevap: Hayır. Firmware ve NVRAM OK=1. PMUREL CTL_B=0x01770181 CTL_W=0 CTL_A=0x18181818 RELOAD=0. CR4START RSTVEC_OK=0 WRITE_OK=0, bütün tanıklar 0x18181818. EXECUTED=1 STARTED=1 WITNESS_MS=0: mailbox!=0 gürültüye denk geldi, ARM yürütmesi değil. PASS değil.
Aynı yazma ramrw sonrasında da bus'ı bozuyor
R84 ramrw öncesi S=0 takılması; R85 firmware'i bitirdi sonra aynı PMUControl yazması 0x18181818 üretti. CTL okunuyor, yazma land etmiyor.
EXECUTED=1 yanlış pozitif
cr4_start mbox_data!=0 görünce executed=true diyor. 0x18181818 sıfır değil; WITNESS_MS=0. R83'te MBOX=0 EXECUTED=0 WRITE_OK=1 idi.
Operatör DSI panelde görüntü gördü
UART SCREEN0 PHYSICAL=0 PIXEL=0 (çekirdek piksel iddiası yok). Operatör R85 imajında panele görüntü geldiğini bildirdi. R83'te aynı protokolde görüntü yoktu. Bu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj 44340ede7b0e251b6bd1001fc8cbda7de61dd84468918647031937c0d75aa22a
kanıt evidence/rpi5/radio/attempt-r85-post-nvram-pmu-reload-uart-capture/
Sorulan: PMUControl'ü Linux sdiod_writel gibi tek CMD53 4 bayt + 4B bayrağı ile yazmak biti land eder mi, bus'ı bozar mı?
Cevap: Land etmedi, bus bozulmadı. PATH=C53_4B C53_OK=0 C53_B=0 C53_ERR=0x0020, CTL_A=0x01770181 RELOAD=0. CR4START RSTVEC_OK=1 WRITE_OK=1 MBOX=0 EXECUTED=0 WITNESS_MS=1000 (R83 kalıbı, R85 gürültüsü değil). PASS değil.
4× CMD52 zehirdi; CMD53 4B CRC ile düştü ve kaydı değiştirmedi
R85 CTL_A=0x18181818. R86 aynı yuvada Linux writel: DATA CRC 0x0020, C53_B=0, PMUControl aynı kaldı. 0x18181818 yok.
CR4 tanıkları yine dürüst sıfır
EXECUTED=0 STARTED=0 WRITE_OK=1 CHIPID=0x15264345. RES_RELOAD bu host'ta CR4-start kolu değil.
Doğru çalışanlar
imaj 47ed584bb1c67474cd8f64b1933079dc5dcda44ae6cfa2d1694b79674ae7d1e8
kanıt evidence/rpi5/radio/attempt-r86-pmu-writel-uart-capture/
Sorulan: pmu_res_reload'u boot yolundan çıkarmak R83 firmware+CR4 tanık kalıbını geri getirir mi?
Cevap: Evet kalıp, hayır CR4. PMUREL yok. FWSTAGE OK=1, NVRAM OK=1. CR4START RSTVEC_OK=1 WRITE_OK=1 MBOX=0 EXECUTED=0 WITNESS_MS=1000. 0x18181818 yok. PASS değil.
RES_RELOAD bu host'ta CR4-start kolu değil
R84/R85 yazınca bus öldü; R86 CMD53 CRC; R87 yazmayınca R83 tanıkları döndü. Bit land etmiyor ve çekirdeği başlatmıyor.
Doğru çalışanlar
imaj db99ca474e96b88fa22538f90cabbf1f35285b196e4ab3ed7f3b85808badfbf2
kanıt evidence/rpi5/radio/attempt-r87-drop-pmu-reload-uart-capture/
Sorulan: Linux buscore_activate ramrw gibi rstvec'i adres 0'a CMD53 4 bayt + 4B bayrağı ile yazmak vektörü land eder mi, CR4'ü başlatır mı?
Cevap: Land etmedi, CR4 başlamadı. RSTVEC_C53=0 RSTVEC_B=0 RSTVEC_ERR=0x0060 RSTVEC_OK=0. WRITE_OK=1 MBOX=0 EXECUTED=0 WITNESS_MS=1000. 0x18181818 yok. PASS değil.
Linux ramrw CMD53 4B bu host'ta rstvec'e de kopyalanamaz
R87 4× CMD52 aynı adreste RSTVEC_OK=1 verdi. R88 CMD53 DATA CRC+END BIT 0x0060 (R40 TCM CMD53 ailesi), C53_B=0, vektör inmedi. Bus zehirlenmedi.
Operatör DSI panelde görüntü gördü
UART SCREEN0 PHYSICAL=0 PIXEL=0. Operatör R88 imajında panele görüntü geldiğini bildirdi. Bu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj d3289b2f0d293ed0ecc62ba5e1c0562d6e043b81c1c3b2a6c9fbd9a27ae59ea5
kanıt evidence/rpi5/radio/attempt-r88-set-active-vs-cr4-start-uart-capture/
Sorulan: R88'in CMD53 ramrw rstvec yazmasını R87 cmd52_write_u32'ye geri almak vektörü tekrar land eder mi, CR4'ü başlatır mı?
Cevap: Vektör indi, CR4 başlamadı. RSTVEC_OK=1 ALIAS_OK=1 RSTVEC_C53=0 RSTVEC_ERR=0x0000. WRITE_OK=1 MBOX=0 EXECUTED=0 WITNESS_MS=1000. 0x18181818 yok. PASS değil.
CMD52 rstvec landing R87 kalıbına döndü
R88 RSTVEC_OK=0 ERR=0x0060. R89 aynı adreste 4× CMD52: RSTVEC_OK=1 C53 kullanılmadı. CR4 yine EXECUTED=0.
Operatör DSI panelde görüntü gördü
UART SCREEN0 PHYSICAL=0 PIXEL=0. Operatör R89 imajında panele görüntü geldiğini bildirdi. Bu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj 57bae63ce3c33cec1a4d969da380ca9bd45872e5d47dd195fce28993cbf7315a
kanıt evidence/rpi5/radio/attempt-r89-rstvec-cmd52-restore-uart-capture/
Sorulan: Linux cr4_set_active gibi aynı rstvec sözcüğünü halt penceresinde CR4 rambase'e yazmak CR4'ü başlatır mı?
Cevap: Hayır. RAM_W=0 RAM_OK=0. RSTVEC_OK=1 (adres 0 önce indi). Sonra IOCTL_TERM/CHIPID/MBOX/INTSTAT=0x18181818, WRITE_OK=0, WITNESS_MS=0 EXECUTED=1 STARTED=1: R85 gürültüsü, ARM yürütmesi değil. PASS değil.
Halt penceresinde rambase yazması bus'ı zehirledi
Firmware aynı rambase'e cr4_start'tan önce cmd52 ile inmişti (FW_INTACT=1). Reset assert sonrası backplane_write32(CR4_RAM_BASE) RAM_W=0 verdi ve sonraki okumalar 0x18181818 oldu.
EXECUTED=1 yanlış pozitif
MBOX=0x18181818 sıfır değil; WITNESS_MS=0. R89'da MBOX=0 EXECUTED=0 WRITE_OK=1 idi.
Operatör DSI panelde görüntü gördü
UART SCREEN0 PHYSICAL=0 PIXEL=0. Operatör R90 imajında panele görüntü geldiğini bildirdi. Bu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj 34f127f9a65fcb241b6412880cffa6f2aa600e8853f314da6e530e05a5a3f5f7
kanıt evidence/rpi5/radio/attempt-r90-rambase-rstvec-second-write-uart-capture/
Sorulan: R90 rambase rstvec yazmasını boot yolundan çıkarmak R89 firmware+CR4 tanık kalıbını geri getirir mi?
Cevap: Evet kalıp, hayır CR4. RAM_W=0 RAM_OK=0 (yazma yok). RSTVEC_OK=1 WRITE_OK=1 MBOX=0 EXECUTED=0 WITNESS_MS=1000. 0x18181818 yok. PASS değil.
Rambase ikinci yazma bu host'ta CR4-start kolu değil
R90 yazınca bus zehirledi; R91 yazmayınca R89 dürüst sıfırlar döndü. Firmware zaten rambase'de (FW_INTACT=1).
Operatör DSI panelde görüntü gördü
UART SCREEN0 PHYSICAL=0 PIXEL=0. Operatör R91 imajında panele görüntü geldiğini bildirdi. Bu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj 3553027c3a857179381ae82f374c5762ee8b37e6430f041bd9dacda8c43aaf46
kanıt evidence/rpi5/radio/attempt-r91-drop-rambase-rstvec-uart-capture/
Sorulan: CR4+D11 wrapper erişimlerine 4-bayt bayrağı (0x8000) eklenirse (Linux gibi atomik) çekirdek koşar mı?
Cevap: Hayır — ama aday kök nedeni daralttı. Flagged OKUMA çalıştı (IOCTL_B=0x21 flagged yolla okundu) ama flagged BAYT-CMD52 atomik 32-bit commit vermedi: MBOX=0 INTSTAT=0 EXECUTED=0 (firmware+NVRAM 30. PASS). R92 trace-diff'i (R80) göstermişti: reset değer/sıra Linux'la birebir; tek fark erişim — Linux wrapper'a CMD53 byte-mode 4-byte atomik yazıyor, biz 4×CMD52.
ADAY KÖK NEDEN: küçük-CMD53 yazma transportu (ölçülen ile çıkarımı ayır)
Linux CR4 wrapper register'larını (IOCTL 0x18102408, RESET_CTL 0x18102800) CMD53 byte-mode blocks=1 block_size=4 ile ATOMİK 32-bit yazıyor (R80 trace: cmd_arg=0x95481004/0x95500004 @ 0xA408/0xA800). ÖLÇÜLEN: bizim küçük CMD53 YAZMAMIZ cihazda düşüyor (R86 0x0020, R88 0x0060) ve CMD53 OKUMA ChipCommon'da çalışıyor (R30 gerçek chip-id döndü). ÖLÇÜLMEYEN üç şey açıkça kayıtlıdır: (1) 0x0060 yalnızca yazmaya özgü DEĞİL — R40'ta bir CMD53 OKUMASI da TCM'de TCM_C53_ERR=0x0060 verdi, yani ayrım yön değil ADRES BÖLGESİ olabilir (ChipCommon çalışıyor, TCM/backplane RAM düşüyor); o klasörün README'si de bunu böyle yazıyor. (2) 'cmd53_write busy DAT hattına issue ediyor' mekanizması hiçbir makbuzda ölçülmedi: bus_was_busy alanı yalnız CMD53 OKUMA satırlarında (WIFICMD53/WIFISWEEP) basılıyor ve ölçülen tüm BUSY değerleri sıfır. (3) '4×CMD52 atomik commit vermiyor' bir çıkarımdır; FWSTAGE zaten CMD52 kullanıyor ve sorunsuz. R94 düzeltmesi (busy-gate + DAT0-release poll) kodlandı ama HEAD'in CR4-start yolunda hâlâ tek bir CMD53 yazma yok — yani düzeltme cihazda SINANMADI.
Bir cr4_start tweak'i DEĞİL — SDHCI sürücü işi
Önerilen yol: küçük CMD53 DATA-fazı hatasını düzeltmek (BLKSIZE/BLKCNT, byte-mode, timeout, PIO/DMA, DAT hattı disiplini). Referans implementasyon R80 Linux trace'inde. Flagged okuma çalıştığı için (IOCTL_B=0x21) erişim yolu doğru; hipotez, eksik olanın atomik 32-bit yazma transportu olduğu. Bu hipotez cihazda henüz sınanmadı ve R40'ın okuma tarafındaki 0x0060'ı da açıklamak zorunda.
Doğru çalışanlar
imaj 5d9ae1a1022ace2af9e190f96e7f7011e20e840a47e919d624aa1fb24a95f838
kanıt evidence/rpi5/radio/attempt-r93-wrapper-4byte-flag-uart-capture/
Sorulan: CR4 TCM boyutu çipten ölçülüp NVRAM ile yürütme tanığı RAM'in GERÇEK tepesine taşınırsa çekirdek koşar mı?
Cevap: Hayır — ama iki adayı birden KAPATTI ve kalıcı bir kazanç bıraktı. Çip kendi banka tablosundan RAMSIZE=0x000c8000 dedi (EXPECT_R80 ile birebir); NVRAM artık Linux'un yazdığı adrese (0x0025f92c) iniyor ve yükleme bozulmadı (FW_INTACT=1, 31. PASS). Buna rağmen MBOX=0, INTSTAT=0, EXECUTED=0, HT_AVAIL=0.
KAPI 1 PASS — ramsize artık tahmin değil, ölçüm
ASELSAN/CR4RAM CORE=0x18002000 CAP=0x00000b44 BANKS=8 RAMSIZE=0x000c8000 MEASURED=1 TOP=0x00260000 EXPECT_R80=0x000c8000. CAP'in düşük nibble'ı 4 A-bankası, üst nibble'ı 4 B-bankası veriyor = 8 banka; bu, R80 izindeki sekiz BANKIDX/BANKINFO turuyla da uyuşuyor. Depodaki 0xA0000 sabiti gerçekten 160 KiB eksikti ve yorumu bunu zaten itiraf ediyordu ('609 KB firmware bunu gerektirir'). Ölçüm, izden BAĞIMSIZ ikinci bir kaynaktan aynı sayıyı verdi.
KAPI 2 PASS — yerleşim Linux'la birebir, yükleme bozulmadı
ASELSAN/NVRAM ADDR=0x0025f92c (R93'te 0x0023792c) TOKEN_OK=1 WORDS=437 VERIFIED=437 OK=1 FW_INTACT=1; FWSTAGE SECTORS_DONE=1191 WORDS_V=152448 RETRIES=0 OK=1. 1748 baytlık blob artık tam 0x00260000'da bitiyor — R80 izinde Linux'un yaptığının aynısı.
KAPI 3 NEGATİF — ve bu sefer tanık DOĞRU adresten baktı
MBOX=0x00000000 INTSTAT=0x00000000 EXECUTED=0 HT_AVAIL=0 STARTED=0 SHARED_RAW=0x00000000. Kritik olan şu: SHARED_RAW bu koşuda 0x25FFFC'den okundu, yani C03'ün 'yanlış pencereden bakıyoruz' açıklaması ELENDİ. Firmware oraya hiçbir şey yazmadı. 'CR4 yürütmüyor' cümlesi artık bir ölçüm körlüğüne dayanmıyor.
C04 öne çıktı: FORCE_ALP hâlâ tutuluyor, HT hiç istenmiyor
CLK_REQ=0x29 CLK_R=0x69 CLK_HOLD=0x09 CLK_CSR=0x49. Linux release sonrası 0x00 → 0x10 yazıp HT bekliyor. R98 bu farkı sınadı: istek latch etti, HT gelmedi. Düzeltme: Linux'un erken 0x21 yazması FORCE_ALP içerir; indirme tutamağı 0x08'dir.
İki açık aday yeniden üretildi
PMU_TA=0x00000000 PMU_TB=0x00000000 — PMU serbest-koşan zamanlayıcısı 1 saniyede yine hiç ilerlemedi, oysa PMU_STAT=0x0000002a ve RES_ST=0x0fcaff77 aynı yoldan sağlıklı dönüyor (C13). WORDS_W=95683 ama WORDS_V=152448 ve RETRIES=0 — yazma sayacı ile doğrulama sayacı yine tutmuyor (C14).
Doğru çalışanlar
imaj 7b7b7f2a4dc1ebe9e20bad4fac73ccc16c8eae73438f15960063e36c888ce565
kanıt evidence/rpi5/radio/attempt-r95-tcm-ramsize-uart-capture/
Sorulan: cr4_start, staging için daraltılan bütçe yerine tanımlama fazının bütçesiyle koşarsa çekirdek çalışır mı?
Cevap: Hayır — ve çok daha ağır bir şey ortaya çıktı: tanık okumaları GÜVENİLMEZ. C12 kapandı (geri alma çalıştı, sonuç değişmedi), ama aynı koşuda CC_CHIPID=0x15264345 iken CHIPID2=0x00000000 ölçüldü. Bu ikisi AYNI kaydın aynı yoldan iki okuması.
C12 uygulandı ve kapandı
ASELSAN/CR4PRE POLLS=50000 CLKDIV=0x80 CLK_STABLE=1 WAS_POLLS=2000 WAS_CLKDIV=0x08; cr4_start içinde ölçülen POLLS=50000. Geri alma çalıştı, EXECUTED yine 0. Daraltılmış bütçe tek başına açıklama değildi.
ASIL BULGU: CHIPID2=0x00000000 — sıfır olamayacak bir kayıt sıfır döndü
CC_CHIPID (cr4_start girişinde) 0x15264345; CHIPID2 (tanık döngüsünden sonra) 0x00000000. Aynı fonksiyon (backplane_read32_data), aynı adres (ChipCommon 0x18000000). ChipCommon chip id sıfır olamaz. Yani tanık penceresinde okuma yolu gerçek veri döndürmüyor ve MBOX=0 / INTSTAT=0 / SHARED_RAW=0 / PMU_TA-TB-TC=0 hiçbiri 'çekirdek sessiz' olarak okunamaz.
Bağımsız tanık: hat R70'ten beri ölü
cr4_start'tan hemen sonra koşan WIFISWEEP kendi pencere yazmasını yapıp geri okuyor ve taze bir CMD52 ile chipid okuyor. R67 ve R69: WIN_OK=1 C52_0=0x15264345 — hat CANLI. R70'ten R96'ya kadar HEPSİ: WIN_OK=0 C52_0=0x00000000 — hat ÖLÜ. Kırılma noktası R69→R70 ve R70 tam olarak TCM shared-word okumasını tanık döngüsünden ÖNCE ekleyen koşudur. R70'in kendi README'si olguyu görmüş ('çekirdek serbest bırakılınca TCM okuması da karardı') ama karartmanın ardından gelen her şeyi de karattığı fark edilmemiş.
Arıza backplane'e özgü değil, SD bağlantısının tamamı
Aynı koşuda WIFIWRITE ENTRY_SYNC=0: fonksiyon-0 CCCR okumasının sekiz denemesi de düştü. F0/CCCR okuması pencere ve backplane kullanmaz; bir pencere muhasebesi hatası onu bozamaz. Ayrıca kaynak iki katmanda da durumu yok sayıyor: backplane_read32_data pencere yazmasının ok bayrağını atıyor (let _ = set_backplane_window) ve cmd52_read_byte_data komut tamamlanmasa bile yanıt kaydını koşulsuz okuyor — birlikte bir 'sessiz sıfır' makinesi.
C17 ilk kez gerçek host durumunu gösterdi
HOST_TMO=0x00 — veri zaman aşımı sayacı EN KISA değerde. HOST_CLK=0x8007 (/256, iç saat + kararlı + SD saati açık), HOST_CTL1=0x02 (4-bit), HOST_BLK=0x0004, HOST_CTL2=0x0000. Bugüne kadar makbuzdaki host değerleri bring_up ÖNCESİ ölü durumdu.
Doğru çalışanlar
imaj 226d3b018301764ec3a3f246806cdc968689dceb36da12322d9e2cae6ed5fd51
kanıt evidence/rpi5/radio/attempt-r96-cr4pre-budget-uart-capture/
Sorulan: Tanık okumaları sırasında SD hattı gerçekten canlı mı? MBOX=0 bir ölçüm mü, yoksa ölü bir hattın sessizliği mi?
Cevap: Hat CANLIYDI: MBOX=0 ve INTSTAT=0 ilk kez canlılık kontrolüyle ölçüldü. Bu, host-görünür sinyal gözlenmediğini gösterir; CR4'ün hiç komut yürütmediğini tek başına kanıtlamaz. R70–R96 tanıkları geçersiz kaldı ve ilerleyen PMU sayacı 'LPO ölü' yorumunu çürüttü.
NÖBETÇİ: hat tanık döngüsü boyunca canlıydı
SENT_N=100 SENT_OK=100 — yüz turun yüzünde ChipCommon ofset 0'dan beklenen 0x45 okundu. SENT_LAST_OK_MS=990 (1000 ms'lik pencerenin sonu), SENT_BAD_MS=4294967295 (u32::MAX = hiç bozulmadı), WIN_OK_END=1, WIN_W=WIN_R=0x18000000. Nöbetçi MBOX ile AYNI 32 KB pencerede ve aynı komut tipiyle okunuyor (0x18004000 & 0xffff8000 == 0x18000000), yani yan kanal değil eş-konumlu kontrol okuması.
Sonuç: canlı hatta host-görünür sinyal gözlenmedi
MBOX=0x00000000, INTSTAT=0x00000000, EXECUTED=0; nöbetçi 100/100. FENCE=0xdeadbeef beklenen sabitle uyumlu. HT_AVAIL ve SHARED_RAW ise TCM okumasından sonra gelen ölçüm sınırlarına tabidir; geçerli HT sonucu R98'in istek bloğunda alındı.
C13 ÇÖKTÜ: PMU sayacı aslında çalışıyormuş
PMU_TA=0x00776d9e → PMU_TB=0x007cdaaa: sayaç İLERLEDİ. Önceki 13 mühürlü koşuda PMU_TA=PMU_TB=0x00000000 görünüyordu ve kodun kendi yorumu 'sabit → LPO gerçekten ölü' diyordu. O sabitlik LPO'nun değil, ÖLÜ HATTIN eseriymiş. 'Donanım duvarı' yorumunun bu ayağı da düştü.
C33 mekanizması doğrulandı: TCM okumak hattı düşürüyor
PMU_TC=0x00000000 ve CHIPID2=0x00000000 — ikisi de TCM okumasından SONRA alınıyor ve ikisi de sıfır. SHARED_AFTER=1, SHARED_RAW=0x00000000, WIFISWEEP yine WIN_OK=0 C52_0=0x00000000. Yani 0x0025FFFC (CR4 TCM) okumak SDIO bağlantısını düşürüyor; R70 bu okumayı döngünün önüne koyarak R70–R96 arasındaki bütün tanıkları zehirlemiş.
Bir alanın sıfır olması okunduğu anlamına gelmez
F0_REV=0x00 F0_OK=0 bu koşuda ÖLÇÜM DEĞİLDİR: bu alanlar yalnızca nöbetçi ilk kez bozulduğunda doldurulur ve nöbetçi hiç bozulmadı, dolayısıyla Default sıfırları olarak basıldılar. Aynı tuzak arşivde daha önce de var (erken dönen fonksiyonların Default alanları).
Doğru çalışanlar
imaj 16f4a7566614ed34a510514ff5424c26384382cc3086fe2a4e4b82ac147efa2f
kanıt evidence/rpi5/radio/attempt-r97-witness-sentinel-uart-capture/
Sorulan: CR4 release sonrası FORCE_ALP bırakılıp HT istendiğinde yüksek hız saati geliyor mu?
Cevap: İstek latch etti, HT gelmedi. CHIPCLKCSR 0x40 → 0x50 oldu; 60 ms yoklama sonunda yine 0x50. C04'ün 'HT hiç istenmiyor' açıklaması tek başına elendi; PMU kaynak ailesi sıradaki ölçüm alanı.
İstek cihazda görüldü
HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_CLR=0x40 HT_CSR_REQ=0x50 HT_CSR_FIN=0x50 HT_REQ_MS=60 HT_REQ_AVAIL=0. FORCE_ALP temizlendi, ALP hazır kaldı ve HT_AVAIL_REQ biti okundu. R80 Linux izinde HT 24–31 ms'de geliyordu.
Hat canlı; host-görünür yürütme sinyali yok
FENCE=0xdeadbeef SENT_N=100 SENT_OK=100 SENT_LAST_OK_MS=990 SENT_BAD_MS=4294967295 WIN_OK_END=1. MBOX=0x00000000 INTSTAT=0x00000000 EXECUTED=0 STARTED=0. HT_AVAIL=0 alanı TCM okumasından sonra alındığı için saat sonucu HT_REQ_AVAIL ve HT_CSR_FIN üzerinden okunur.
PMU sayacı ilerledi; C09 yeniden önde
PMU_TA=0x00775ee2 → PMU_TB=0x007cc944; PMU_STAT=0x0000002a RES_ST=0x0fcaff77 RES_PEND=0x00000000. Bunlar istek sonrası tek görüntüdür; öncesi/sonrası karşılaştırması henüz yok. R84/R85/R86'da CTL_W=0 RELOAD=0 olduğu için RES_RELOAD elenmiş sayılamaz. PMU'nun kök neden olduğu henüz kanıtlanmadı.
Doğru çalışanlar
imaj 134c197de2846d381dbf80c055628138f85a889a761f7714703a29b7473c034a
kanıt evidence/rpi5/radio/attempt-r98-post-release-htclk-uart-capture/
Sorulan: HT isteği öncesi ve sonrası PMU kaynak görüntüleri değişiyor mu?
Cevap: İki geçerli PMU görüntüsü aynı kaldı; HT_REQ_AVAIL=0. PMU sayacı ilerledi, ancak kaynak ailesi kök neden olarak kanıtlanmadı.
PMU pencereleri geçerli ve eşit
PRE/POST WIN_OK=1 READ_OK=0x3f VALID=1, CHIP_B=CHIP_A=0x15264345. CTL=0x01770181, STAT=0x2a, RES_ST=0x0fcaff77, RES_PEND=0, MINRES=0x0fcaff77, MAXRES=0x0fcfff7f iki görüntüde de aynı.
HT hâlâ gelmedi
HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_CLR=0x40 HT_CSR_REQ=0x50 HT_CSR_FIN=0x50 HT_REQ_MS=60 HT_REQ_AVAIL=0. FENCE=0xdeadbeef, SENT_N=100, SENT_OK=100 ve WIN_OK_END=1 korundu.
Doğru çalışanlar
imaj 66587e93977600e654c2b937d080fb3eb104965bb2c98fcfade03cbcd4a3c80b
kanıt evidence/rpi5/radio/attempt-r99-pmu-ht-snapshot-uart-capture/
Sorulan: SDHCI clock register yazması bitişik TIMEOUT_CONTROL alanını bozuyor mu?
Cevap: u16 erişim HOST_TMO=0x0e değerini korudu; HT_REQ_AVAIL=0 kaldı. Bu bir radyo başarı sonucu değildir.
Clock/timeout kusuru ayrıldı
HOST_TMO=0x0e, HOST_CLK=0x8007, HOST_CTL1=0x02 ve POLLS=50000. R99/R98'deki HOST_TMO=0x00 yerine timeout korunmuş oldu.
Radyo hâlâ hazır değil
HT_CLR_OK=1 HT_REQ_OK=1 HT_CSR_CLR=0x40 HT_CSR_REQ=0x50 HT_CSR_FIN=0x50 HT_REQ_MS=60 HT_REQ_AVAIL=0; MBOX=0 INTSTAT=0 EXECUTED=0.
Doğru çalışanlar
imaj 194c569b0496008cda4e878230cefca9a742b794546b3eb5b88f9f89cddf62c6
kanıt evidence/rpi5/radio/attempt-r100-clock-register-width-uart-capture/
Sorulan: İlk D11 wrapper CMD53 yazması cihazda gerçekten issue ediliyor mu?
Cevap: İlk D11 yazması DAT inhibit nedeniyle issue edilmedi; işlem tamamlanmadan durdu. Wi-Fi yolu bu koşuda başlamadı.
Transport kapısı yazmayı engelledi
CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT, ADDR=0x18101408, WRITE=1, VALUE=0x0000000f, ISSUED=0, COMPLETE=0, BUSY=1.
HT sonucu ölçülmedi
HT_ATTEMPTED=0; PMUHT, witness ve geç dönem host okumaları uygulanmadı. DAT[3:0] seviyesi 7 ve DAT_INHIBIT, yalnız DAT0 yüksek olmasının yeterli olmadığını gösterdi.
Doğru çalışanlar
imaj ec88daa88871fe689513ee230e0666e991779a548ec0571eb4173184963893b7
kanıt evidence/rpi5/radio/attempt-r101-single-word-control-uart-capture/
Sorulan: Host DATA kurtarma ve wrapper tamamlanınca HT ile FullMAC başlatılabiliyor mu?
Cevap: Host DATA reseti ve wrapper tamamlandı, HT_REQ_AVAIL=1 görüldü; ilk TOSB_DATA yazmasında response ownership kusuru nedeniyle başlatma durdu.
Host ve CR4 kapıları geçti
CR4HOSTDATA MEASURED=1 APPLIED=1 CLEARED=1 READY=1; CR4CTRL COMPLETE=1, OPS=18, R5=0x10 ERR=0; HT_CSR_FIN=0xd0 ve HT_REQ_AVAIL=1.
Dış reddetme sonraki CMD53 yanıtından geldi
İç CMD53 temiz tamamlandı: ISSUED=1, command/buffer/transfer complete, BYTES=4, R5=0x10, ERR=0. Sonraki settle CMD52'sinin 0x9043 yanıtı önceki yazmaya mal edildi; gerçek kontrol cevabı gözlenmedi.
Doğru çalışanlar
imaj b79befa75e24bfad32352733aaf3dd9318e943b8f3a0c406a3c84493d92263d0
kanıt evidence/rpi5/radio/attempt-r102-host-data-scan-uart-capture/
Sorulan: CMD53 sonucunu kendi işleminin makbuzuyla taşıyınca runtime parser sınırı geçiliyor mu?
Cevap: Runtime STARTED=1 oldu; ardından Session(Wire(Truncated)) ile durdu. Kontrol cevabı ya da BSS gözlenmedi.
Önceki INIT_ERROR sınırı geçildi
Host DATA kurtarma, 18 wrapper işlemi, HT_REQ_AVAIL=1 ve WIFIPROTO STARTED=1 aynı koşuda görüldü.
Eksik çerçeve içeriği bilinmiyor
WIFISCAN_RESULT STATUS=ERROR ERROR=Session(Wire(Truncated)). R103 hata yolunda WIFIRX yazmadığı için olay zarfının boş mu, kısa mı olduğu bu kayıttan çıkarılamaz.
Doğru çalışanlar
imaj 01243db4a02ccf4c356ce46687ba9fdbd64eecc4543d65c4777a55e79d1aba17
kanıt evidence/rpi5/radio/attempt-r103-owned-transfer-response-uart-capture/
Sorulan: Boş Event/Data zarfları güvenli biçimde tüketilip kontrol isteği ilerliyor mu?
Cevap: İki header-only Event/Data zarfı doğrulandı; kontrol isteği gönderildi ama cevap gelmedi ve ControlTimeout oluştu.
R103 parser sınırı ayrıştırıldı
WIFIPROTO STARTED=1 READY=0; iki WIFIRX kaydı LEN=12, DOFF=12, EMPTY=1, SEQ=0/1, TXWIN=21 olarak basıldı.
Kontrol cevabı hâlâ yok
WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 öncesinde controls_sent=1; WIFIFAIL sonrası controls_replied=0 ve ControlTimeout görüldü.
Doğru çalışanlar
imaj 510333c7f0c71cb0ed06e79bf4456a0dba1bbff4314f91d552f83e9ec568ad00
kanıt evidence/rpi5/radio/attempt-r104-empty-event-data-uart-capture/
Sorulan: BCDC GET_VAR isteğinde veri uzunluğu isim ve kapasiteyi birlikte taşıyor mu?
Cevap: Evet. 48 bayt çerçeve ve BCDC len=20 fiziksel olarak gönderildi; iki boş RX zarfından sonra kontrol cevabı gelmedi.
R105 değişikliği fiziksel olarak görüldü
WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 SEQ=255 TXWIN=21 SENT=1 REPLIED=0. BCDC arithmetic hipotezi bu ölçümle kapandı.
Sınır RX/control transport tarafında
WIFIPROTO STARTED=1 READY=0; iki WIFIRX LEN=12 DOFF=12 EMPTY=1 sonrası WIFIFAIL frames_received=2, header_only_frames=2, controls_sent=1, controls_replied=0 ve ControlTimeout.
Doğru çalışanlar
imaj f0d8f63bfa7a6e8e631a43adf17fe85568b024946e05a7e6c0793ae18d6e0691
kanıt evidence/rpi5/radio/attempt-r105-bcdc-reply-capacity-uart-capture-repeat-03/
Sorulan: R105'in değişmez 48/20 BCDC isteği sonrası RX başlığı/payload ve kontrol cevabı sahipliği görünür kılındığında gerçek durma sınırı nerede?
Cevap: İki header-only RX frame ham başlıklarıyla doğrulandı; kontrol cevabı gelmeden host Read32(INTSTATUS) SDIO transfer hatasıyla durdu.
RX transport fiziksel olarak görünür
WIFIRX/WIFIRX_RAW iki frame için LEN=12, HEADER_LEN=12, PAYLOAD_LEN=0, SEQ=0/1, RX_NEXT=1/2, TXWIN=21 ve CTRL_PENDING=1 gösterdi.
BCDC isteği korunuyor, cevap yok
WIFICTRLTX FRAMELEN=48 XFER=48 BCDCLEN=20 olarak gönderildi; WIFICTRLSTATE SENT=1 REPLIED=0 kaldı ve timeout nedeni core+INTSTATUS Read32 SDIO Transfer/R5 hatası oldu.
Doğru çalışanlar
imaj eedf04afb5d48b7b66e9ade7a575da66d02deadf763d67af3bce86c09f208c1a
kanıt evidence/rpi5/radio/attempt-r106-rx-header-control-ownership-uart-capture/
Sorulan: R107 imajı Pi 5'e takılı ve güç verilmişken fiziksel açılış ile INTSTATUS Read32 makbuzu birlikte kanıtlanıyor mu?
Cevap: Fiziksel açılış kanıtlandı: firmware/NVRAM/CR4 hazırlığı geçti, iki header-only RX frame görüldü ve koşu ControlTimeout ile sonlandı. Hedef Read32 makbuzu oluşmadı.
Kart + güç + boot kanıtı artık ayrı mühürlü
UART akışı FWSTAGE'den başlayarak WIFISCAN_RESULT terminal satırına kadar gözlendi. Bu, kartın Pi'de takılı ve R107 imajının gerçekten çalışır durumda olduğuna dair fiziksel koşu kanıtıdır; güç geçişinin kendisi capture öncesinde gerçekleştiği için yalnızca UART'ın gördüğü boot sınırı iddia edilir.
Read32 hedefi hâlâ açık
WIFIPROTO STARTED=1 READY=0, WIFIRX SEQ=0/1 header-only, WIFICTRLSTATE SENT=1 REPLIED=0 ve WIFISCAN_RESULT STATUS=ERROR ControlTimeout görüldü. WIFIREAD satırı oluşmadı; R107 Read32 sahipliği PASS sayılmaz.
Doğru çalışanlar
imaj 149e234c466938fb3822b3804b66812550553f6bca7c59cd2ab9cb3df05fa88e
kanıt evidence/rpi5/radio/attempt-r107-live-attach-after-power-uart-capture/
Sorulan: UART güç döngüsünden önce arm edilirse F1 INTSTATUS Read32 CMD53 issue/complete/R5/error sınırı aynı boot kaydında görülebilir mi?
Cevap: Firmware, NVRAM, host-data ve iki RX header geçti; ilk F1 Read32 aktarımı timeout'a ulaşmadan data-CRC/transfer hatasıyla düştü.
İlk F1 aktarım sınırı ölçüldü
WIFIREAD OP=Read32 FUNCTION=1 ADDRESS=0x18004020, STATUS=0x00208001, R5_FLAGS=0x10, ERROR_STATUS=0x0020, ISSUED=1 fakat COMMAND_COMPLETE=0, BUFFER_READY=0, TRANSFER_COMPLETE=0 ve BYTES_READ=0 görüldü.
Timeout snapshot'ı bilinçli olarak yok
WIFICTRLWAIT CAPTURED=0 kaldı; hata control timeout öncesinde gerçekleştiği için timeout makbuzu uydurulmadı. Bu sonuç Wi-Fi PASS değildir.
Doğru çalışanlar
imaj 3547c2c8f5271a12b7503362280a79e7b6d571518f5b26d046cb93ada944383b
kanıt evidence/rpi5/radio/attempt-r108-read32-transfer-error-uart-capture/
Sorulan: R108'de ölçülen F1 data-CRC sonucu birleşik CRC/end-bit maskesiyle güvenli CMD52×4 fallback'e ayrılabilir mi?
Cevap: Hayır; gerçek hata ERROR_STATUS=0x0060 olarak geldi ve R109'un tam-eşitlik kapısı fallback'i açmadı. F1 sınırı daha geniş maskeyle ölçülmesi gereken ayrı bir transport dalı oldu.
Birleşik hata fiziksel olarak tekrarlandı
FWSTAGE/NVRAM/CR4HOSTDATA geçti; iki header-only frame alındı. F1 Read32 `ERROR_STATUS=0x0060`, R5=0x10, COMMAND_COMPLETE=0 ve TRANSFER_COMPLETE=0 ile düştü.
Fallback bilinçli olarak uygulanmadı
R109 yalnız exact DATA_CRC=0x0020 eşitliğini kabul etti; 0x0060 başka bir SDHCI sınıfı gibi muamele gördü. Bu koşu Wi-Fi veya CR4 PASS değildir.
Doğru çalışanlar
imaj f07d31239c57ed7dab35e4847d7e81dffec17f9edaa1644e490e00d57880a7f3
kanıt evidence/rpi5/radio/attempt-r109-data-crc-endbit-uart-capture/
Sorulan: R109'un birleşik DATA_CRC bit-mask fallback'i fiziksel koşuda F1 sınırını geçip D11 kontrol yoluna ulaştırıyor mu?
Cevap: Bu koşuda fallback'e ulaşılmadı; ilk D11 CMD53 kontrol yazması DATA_TIMEOUT=0x0010 ile abort oldu ve CORE_READY=0 kaldı.
D11, F1 fallback'inden önce ayrı bir transport dalı açtı
CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT OPS=1 ISSUED=1 CMD=1 BUF=1 XFER=1 BYTES=4 R5=0x10 ERR=0x0010 görüldü.
Hata sınıfları karıştırılmadı
R109 F1 data-CRC/end-bit sonucu ile R110 D11 data-timeout sonucu ayrı tutuldu; R110 Read32 CMD52×4 fallback'i bu boot'ta denenmedi.
Doğru çalışanlar
imaj d32d5b520157b76f04f0ef33226f1e300dcd4ddf52705b9f24ef63a5992a8952
kanıt evidence/rpi5/radio/attempt-r110-cr4-d11-transport-uart-capture/
Sorulan: Ölçülen D11 timeout dalına tek bounded retry uygulanınca ilk SDPCM control-response sınırı nerede kalıyor?
Cevap: D11 kontrolü temiz geçti; iki header-only RX frame ve 48/20 BCDC isteği görüldü, fakat eşleşen control reply gelmeden timeout oluştu.
D11 ve ilk SDPCM RX yolu geçti
CR4CTRL COMPLETE=1/ERR=0x0000, D11_RETRY_ATTEMPTED=0, WIFIPROTO STARTED=1 READY=0, SEQ=0/1, TXWIN=21 ve payload=0 görüldü.
İlk BCDC cevabı yok
FRAMELEN=48, XFER=48, BCDCLEN=20 gönderildi; REPLIED=0 ve READ_FAILURES=0 kaldı. Timeout snapshot'ında INTSTATUS=0 idi.
Doğru çalışanlar
imaj ba2fb47ee74f0f6f68ab64dff89f303d88459a026feccdc25ed4b3f800e19199
kanıt evidence/rpi5/radio/attempt-r111-sdpcm-control-timeout-uart-capture/
Sorulan: Bekleyen SDPCM FIFO frame'leri yeni init/scan/abort kontrolünden önce tüketilirse ilk BCDC timeout'u çözülüyor mu?
Cevap: Bu koşuda FIFO-drain hipotezi ölçülemedi; D11 geçtikten sonraki CR4 activation yazması data-CRC=0x0020 ile düştü ve SDPCM oturumu başlamadı.
CR4 activation transport varyansı ölçüldü
FWSTAGE, NVRAM ve CR4HOSTDATA geçti; D11_RESET=1/D11_IOCTL=0x00000007 sonrasında CR4CTRL PHASE=CR4, OPS=17, ADDR=0x18102408 yazısı R5=0x10/ERR=0x0020 ile abort oldu.
FIFO sırası hakkında sonuç çıkarılmadı
WIFIPROTO veya control-response ordering sonucu oluşmadı. D11_RETRY_ATTEMPTED=0, hatanın D11-only retry sınırından sonra oluşmasıyla uyumludur; R112 FIFO değişikliğini PASS/FAIL olarak etiketlemez.
Doğru çalışanlar
imaj f40aab719df8d91e06c604fab6fa16a47ccb011be8fc266a6734d34f6de0a2d7
kanıt evidence/rpi5/radio/attempt-r112-sdpcm-fifo-drain-uart-capture/
Sorulan: R112 FIFO-drain değişikliği korunurken bounded ilk-D11 retry ve ilk BCDC kontrol alımı temiz açılışta birlikte ölçülebiliyor mu?
Cevap: Firmware, NVRAM, host-data ve D11 kontrol yazması geçti; ancak CR4START makbuzu STARTED=0/OK=0 kaldı. İki header-only RX frame ve doğru 48/20 BCDC isteği görüldü, kontrol cevabı gelmeden ControlTimeout oluştu. D11 retry dalı bu koşuda tetiklenmedi.
Host-data ve D11 transport makbuzları temiz
FWSTAGE 1191/1191, NVRAM VERIFIED=437, CR4HOSTDATA READY=1 ve CR4CTRL COMPLETE=1/R5=0x10/ERR=0x0000 görüldü. D11_RETRY_ATTEMPTED=0 olduğu için R113, retry başarısını değil temiz birincil D11 geçişini kanıtlar.
CR4 yürütme ve ilk kontrol cevabı hâlâ kanıtlanmadı
CR4START STARTED=0/OK=0 kaldı. WIFIPROTO STARTED=1 READY=0 sonrasında SEQ=0/1, LEN=12, DOFF=12, EMPTY=1, TXWIN=21 iki RX frame alındı; ilk BCDC GET_VAR isteği FRAMELEN=48/XFER=48/BCDCLEN=20 olarak gönderildi ama REPLIED=0 kaldı.
R114'ün ölçmesi gereken dar sınır
WIFICTRLWAIT CAPTURED=1, INTSTATUS=Some(0) ve READ_FAILURES=0 ile terminal hata ControlTimeout oldu. Bu, firmware yüklemesini ya da BCDC uzunluğunu yeniden değiştirmek yerine ilk control-response receive/interrupt sahipliğinin ayrıştırılmasını gerektirir.
Doğru çalışanlar
imaj 77eec6d48b1ff00486e330ad750bf5aca1a44ec05ccea0ef74754d1f6b3969db
kanıt evidence/rpi5/radio/attempt-r113-d11-crc-retry-uart-capture/
Sorulan: İlk BCDC control-response bekleyişinde exact TX, interrupt geçmişi ve FIFO/host sahipliği aynı request ID ile ayrılabilir mi?
Cevap: Exact 48-byte ID=1 isteği doğrulandı; ancak koşu ControlTimeout'a ulaşmadı. F1 INTSTATUS CMD53 ERROR_STATUS=0x0060 sonrası CMD52×4 fallback sıfır döndürdü, sonraki SBADDR_LOW erişimi DAT_INHIBIT nedeniyle issue edilmeden durdu.
İlk kontrol TX'i byte-for-byte doğrulandı
WIFICTRLTX_RAW COMMAND=262 REQUEST_ID=1 INTERFACE=0 SET=0 LOGGED=48 kaydı, FRAMELEN=48/XFER=48/BCDCLEN=20 isteğini exact hex ile sabitledi. İki SEQ=0/1 header-only Event yine istekten önce tüketildi.
Fallback host-data durumunu temizlemeden başarı döndürdü
WIFIREAD_FALLBACK ADDRESS=0x18004020, ERROR_STATUS=0x0060, PRESENT_STATE=0x01ff0206, RESULT=PASS, VALUE=0 sonrasında F1 0x1000a SBADDR_LOW Write8 işlemi reason=Inhibit ile ve issued=false durumda kesildi.
Control-response sahipliği bu koşuda ölçülmedi
WIFICTRLWAIT CAPTURED=0, IEN/INT_PENDING/WFRAMEBC/RFRAMEBC=None ve CTRL_SEEN=0 kaldı; terminal sonuç ControlTimeout değil pre-deadline transport I/O hatasıdır. Birikimli CORE_OR sayaçları startup trafiğini de içerir.
Doğru çalışanlar
imaj d82ce641084d0c893a65be5ccb0b2eafdfa676bcd8b10111ce5db5cfc54848f5
kanıt evidence/rpi5/radio/attempt-r114-first-control-interrupt-ownership-uart-capture/
Sorulan: R114'ün fallback false-success dalı host idle ile kapılanır ve timeout dışı pending hata makbuzu korunursa fiziksel sınır nereye taşınır?
Cevap: R115 kapıları doğru çalıştı, fakat Wi-Fi hazır olmadı. F1 INTSTATUS CMD53 saf DATA_CRC=0x0020 aldı; CMD52×4 VALUE=0 üretmesine rağmen host veri motoru 100.000 pasif kontrolde idle olmadı ve primary Read32 hatası korundu.
Fallback değeri artık host sağlığı olmadan kabul edilmiyor
WIFIREAD_FALLBACK RESULT=PASS VALUE=0 yanında HOST_IDLE=0, PSTATE_B=0x01ff0206, PSTATE_A=0x017f0206, POLLS=100000 ve DAT0=1 ölçüldü. R114'teki SBADDR_LOW Write8 bu koşuda hiç denenmedi.
Pending terminal sahipliği timeout olmadan yakalandı
WIFICTRLWAIT CAPTURED=1 PENDING_BEFORE=1 AGE_MS=994 oldu. F1 tanı okumaları düşse de host PRESENT_STATE=0x017f0206, INT_STATUS=0x00000101 ve HOST_CARD_INT=true alanları korundu.
Sayaçlar yalnız request ID 1 sonrasını gösteriyor
CORE_OR, FRAME_IND_SEEN, HOST_INT_SEEN, FIFO_READS, CTRL_SEEN ve CTRL_UNMATCHED sıfır kaldı; iki startup Event frame ve protocol mailbox artık pending control cevabına mal edilmedi.
Doğru çalışanlar
imaj 7f7ca549198b87c4308833331a8cd2270f4a3313c2c43b131f4efd574ba4b770
kanıt evidence/rpi5/radio/attempt-r115-f1-fallback-host-idle-uart-capture/
Sorulan: R115'in 100.000 pasif kontrolde temizlenmeyen host veri motoru, tek ve bir kez sahiplenilen host-only SDHCI DATA reset ile açılır mı; açılırsa Wi-Fi hazır olur mu?
Cevap: Reset dalı tam tasarlandığı gibi çalıştı ve tıkanan tarafın HOST olduğunu ölçtü: DAT_INHIBIT 2 yoklama / 10 µs içinde temizlendi. Wi-Fi yine hazır olmadı; aynı registerın bir sonraki CMD53'ü saf DATA_CRC yerine DATA_CRC+DATA_END_BIT=0x0060 aldı ve orijinal hata korundu.
Tıkanan taraf ölçüldü: host SDHCI veri motoru
WIFIREAD_RECOVERY ELIGIBLE=1 APPLIED=1 RESET_FIRST=0x04 RESET_A=0x00 RESET_POLLS=2 ELAPSED_US=10; PSTATE 0x017f0206 → 0x017f0000, HOST_IDLE=1, CONFIG_SAME=1, POST_MATCH=1, ACCEPTED=1. Saat, timeout, host-control, güç, blok ve control2 registerları değişmedi.
Bir kez kullanım disiplini tuttu
İkinci olayda USED_BEFORE=1 ELIGIBLE=0 APPLIED=0 ACCEPTED=0 oldu; ikinci reset denenmedi, CMD53 hiç tekrarlanmadı ve primary Read32 hatası korundu.
Firmware çalışıyor ve konuşuyor; arıza taşındı
Arıza makbuzunda clock=0xd0 (HT_AVAIL|ALP_AVAIL), io_ready=6 (F1+F2 hazır), mailbox=0x00040002 (DEVREADY, sürüm alanı 0x04), iki header-only Event ve TXWIN=21 var. Kurtarma bir CMD53 denemesi kazandırdı: PENDING_POLLS 56 → 121, AGE_MS 994 → 2183; sonraki hata 0x0020 yerine 0x0060 oldu.
Doğru çalışanlar
imaj 39e7de9d92563b5efd2a9f124a60ef4cb025683d27b5954b4553793ae13e45d6
kanıt evidence/rpi5/radio/attempt-r116-sdhci-data-reset-uart-capture/
Sorulan: 0x18004020 CMD53 okumasını kıran değişken veriyolu durumu mu, transfer modu mu, yoksa adres mi?
Cevap: Adres. Kırılan işlemin tam şekli — bayraklı 4 baytlık byte-mode CMD53 — aynı pencerede, mikrosaniyeler sonra ChipCommon'da kusursuz çalıştı; CMD52×4 ve tek-blok 64 baytlık CMD53 de çalıştı, üçü de 0x15264345 döndürdü. VERDICT=ADDRESS_SPECIFIC. Aynı koşuda taşıma sona kadar ayakta kaldı ve terminal hata BusError'dan gerçek ControlTimeout'a döndü. Wi-Fi yine hazır olmadı.
Veriyolu durumu ve transfer modu elendi
WIFIREAD_MATRIX CMD52_OK=1 BYTE_OK=1 BLOCK_OK=1, üçünde de V=0x15264345 ve M=1, ERR=0x0000; her probun öncesinde ve sonrasında PRESENT_STATE=0x01ff0000, TAIL_IDLE=1 TAIL_POLLS=0. Pencere yazılmadı (WINDOW_W=WINDOW_R=0x18000000), kırılan register CMD53 ile bir daha okunmadı.
İlk kez okunabilen firmware durumu
READ_FAILURES=0 (R115/R116'da 13'tü): CLOCK=0xd2 (HT hazır), SLEEP=0x03 (KSO+DEVON), IO_READY=0x06 ve F2_ENABLED=0x06, MAILBOX=0x00040002 (DEVREADY, sürüm alanı 4), INTSTATUS=0, IEN=0, INT_PENDING=0, FRAMECTRL/WFRAMEBC/RFRAMEBC=0.
Arıza sınıfı değişti: taşıma değil, cevapsızlık
Host doğru 48/20 cur_etheraddr isteğini gönderdi, 136 yoklama boyunca tam 2500 ms bekledi ve veriyolu sonuna kadar boş kaldı (PRESENT_STATE=0x01ff0000). Terminal hata Session(Transport(ControlTimeout)) oldu; hiçbir CMD53/CMD52 okuması düşmedi.
Doğru çalışanlar
imaj e4e1583dcc9cb21d782d563e00dd05d0267a4b98f5982475df0572ac089dc5f0
kanıt evidence/rpi5/radio/attempt-r117-failure-moment-read-matrix-uart-capture/
Sorulan: Sürücünün 136 kez yokladığı INTSTATUS=0 değeri gerçek register mı, yoksa 4-baytlık erişim bayrağı olmayan yolun ürettiği bir yanılsama mı?
Cevap: Cevap alınamadı. Bu boot'ta ilk veri hatası saf 0x0020 değil 0x0060 geldi; R116 kurtarma kapısı saf DATA_CRC istediği için uygun değildi, host 100.000 pasif kontrolde idle olmadı ve hem R117 matrisi hem R118 prob çifti takılı bir host'u ölçmeyi reddetti. VERDICT=INCOMPLETE. Veri üretilmedi, ama yanlış veri de üretilmedi.
Zincir fail-closed davrandı
WIFIREAD_RECOVERY ELIGIBLE=0 APPLIED=0; WIFIREAD_MATRIX CMD52_SKIP=1 ve tüm problar A=0; WIFICORE_ACCESS INT_SKIP=1, INT_PLAIN=None, MBOX_PLAIN=None. TAIL_IDLE=0, TAIL_POLLS=100000, TAIL_PSTATE=0x017f0206.
İlk hata sınıfı koşudan koşuya değişiyor
R115/R116/R117'de ilk hata 0x0020 ve SDHCI STATUS kart-kesme bitini taşıyordu (0x00208101); R118'de 0x0060 ve o bit yok (0x00608001). Hangi dala düşüldüğü deterministik değil.
R117'nin hükmü bu yüzden nitelenmeli
ADDRESS_SPECIFIC, kurtarılabilir dala düşmüş tek bir boot'un doğru ölçümüdür; henüz tekrarlanmış bir sonuç değildir.
Doğru çalışanlar
imaj db5809cb08acd6244b589c0e951d7c67e9eb561f38f96672cbe75bc89026d4ef
kanıt evidence/rpi5/radio/attempt-r118-flagged-vs-plain-backplane-read-uart-capture/
Sorulan: Sahiplenilmiş DATA reset kapısı veri-hatası sınıfının tamamına açılınca, ölçüm artık boot'un hangi dala düştüğüne bağlı kalmayacak mı?
Cevap: Bu koşuda kapı hiç sınanmadı: veri hatası olmadı. Kayıtta tek bir WIFIREAD/FALLBACK/RECOVERY/MATRIX/CORE_ACCESS satırı yok — 0x18004020 CMD53 okuması bu boot'ta hiç kırılmadı. Buna karşılık koşu daha değerli bir şey verdi: taşıma sona kadar kusursuz kaldı, hiçbir okuma düşmedi ve firmware yine cevap vermedi. R117'den sonra ikinci temiz-taşıma ControlTimeout'u.
Taşıma arızası aralıklı: belirti, kök neden değil
Beş koşu, beş farklı taşıma davranışı: R115/R116/R117 ilk hata 0x0020, R118 0x0060, R119 hiç hata yok. 0x18004020 her zaman okunamaz değil; R117'nin ADDRESS_SPECIFIC hükmü o boot'un doğru ölçümüydü, adresin özelliği değil.
Tam süre, tamamen boş veri yolunda beklendi
READ_FAILURES=0, PENDING_POLLS=144, AGE_MS=2500, PRESENT_STATE=0x01ff0000. CLOCK=0xd2, SLEEP=0x03, IO_READY=0x06, F2_ENABLED=0x06, MAILBOX=0x00040002, INTSTATUS=0, IEN=0, INT_PENDING=0, FRAME_IND_SEEN=0, RFRAMEBC=0.
seq=255 kontrol edildi: hata değil
Gönderilen SDPCM başlığı seq=0xff taşıyor. brcmf_sdio.rs tx_sequence'i kasıtlı 255'e ilklendiriyor ve kredi hesabı sarmalı: tx_window.wrapping_sub(tx_sequence) = 21−255 (mod 256) = 22, yani çerçeve pencere içinde. Mühürlü R80 izi CMD53 veri baytlarını taşımadığı için Linux'un ilk çerçevesine karşı doğrulanamadı; açık kontrol olarak kaydedildi.
Doğru çalışanlar
imaj c2818abf67d0b8f63852ad94081f5c20f0ae87564b0b80a0e6804e83ea72faca
kanıt evidence/rpi5/radio/attempt-r119-widened-data-error-gate-uart-capture/
Sorulan: BCM43455'te BT ve WLAN aynı kalıpta PMU/saat paylaşıyor ve BT_ON, SDPCM başlamadan hemen önce yükseliyor. BT bring-up'ı çıkarılırsa kontrol isteği cevaplanır mı?
Cevap: Hayır. BT_ON hiç sürülmemiş ve UARTA'ya hiç yazılmamışken sonuç R119 ile ölçülen her alanda birebir aynı — PENDING_POLLS=144'e kadar. Paylaşılan-PMU hipotezi bu arızayı açıklamıyor; Linux'ta bu çip için bildirilen dtoverlay=miniuart-bt çözümü bizimkinden başka bir arızaya bakıyor.
İzolasyon uygulandı ve yalnız izolasyon uygulandı
PINMUX BT_ON=Some(0) WRITES=0, WIFIPWR BT_ON_TOUCHED=0, BTINV MAP=OK BT_WRITES=0, BTHCI SKIPPED=1 REASON=PMU_ISOLATION BT_ON_DRIVEN=0 UARTA_WRITES=0. Salt-okunur envanter korundu; hiçbir şey eklenmedi.
Wi-Fi sonucu alan alan aynı
İki koşuda da hiç WIFIREAD satırı yok, READ_FAILURES=0, PENDING_POLLS=144, AGE_MS=2500, CLOCK=0xd2, SLEEP=0x03, IORx=IOEx=0x06, MAILBOX=0x00040002, INTSTATUS=IEN=INT_PENDING=0, 2 çerçeve / 0 cevap, terminal ControlTimeout.
Yedi koşudan sonra tekrarlayan tek olgu
Firmware açılıyor, DEVREADY + sürüm alanı 4 bildiriyor, F1+F2 açıyor, HT kaldırıyor, tam iki header-only Event ve 21 kredi veriyor — sonra ilk BCDC isteğine hiç cevap vermiyor, kesme kaldırmıyor, host'a bayt kuyruğa koymuyor. Sağlıklı ve bozuk taşımada, BT'li ve BT'siz aynı.
Doğru çalışanlar
imaj 2f220c4bbcdfb6a9e200a670ac2a9a50f85fb9dc7758a1af2ee14852c4a3961d
kanıt evidence/rpi5/radio/attempt-r120-bt-isolation-uart-capture/
Sorulan: R121'in ölçtüğü F2 watermark farkı (Linux 0x08, biz 0x60) tek değişken olarak 0x08 yazılırsa ilk BCDC isteği cevaplanır mı?
Cevap: Değişken hiç icra edilmedi. Koşu watermark yazmasından önce, D11 aşamasında backplane pencere geri-okumasında kırıldı. WIN_OK=0, istenen pencere 0x18100000, okunan 0x18181800 (üç bayt da 0x18), ISSUED=0; terminal UNAVAILABLE CORE_READY=0, ControlTimeout değil. R115–R120'de WIN_OK=0 hiç yoktu.
F2 watermark bu boot'ta yazılmadı
Watermark yazması SDPCM'in Function2Pending → ProtocolPending geçişindedir; CR4 başladıktan ve fonksiyon 2 hazır olduktan sonra gelir. Bu boot CR4'ü başlatmadı. Bir baytlık revizyon hakkında ne lehte ne aleyhte sonuç çıkmaz.
Üçüncü arıza imzası: CMD52 pencere geri-okuma uyuşmazlığı
CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT WIN_OK=0 WIN_W=0x18100000 WIN_R=0x18181800 COMPLETE=0 ISSUED=0. Fail-closed yol tasarlandığı gibi komutu karta göndermedi. WIN_OK=0 bu kayıtta üç kez basıldı; R115–R120'de sıfır kez.
Üç imza tek hipoteze sığar, henüz oran yoktur
CMD53 veri-fazı hatası (R115–R118), temiz taşımada cevapsız ilk BCDC (R117/R119/R120) ve CMD52 pencere uyuşmazlığı (R122). R121 çerçeve hedefi ve geometrisinin Linux ile aynı olduğunu kapattı. Tek koşu tek veri noktası verir; R123 her SDIO işlemini sayarak oran üretir.
Doğru çalışanlar
imaj 8fd85b5a7e38bdba33a271809a05679dc1dc5d39c88ed619db4690e330f5a29c
kanıt evidence/rpi5/radio/attempt-r122-f2-watermark-uart-capture/
Sorulan: Her SDIO işlemi sayılırsa, üç arıza imzası (CMD53 CRC, cevapsız BCDC, CMD52 pencere uyuşmazlığı) aralıklı veriyolu bozulmasının oranı mıdır, yoksa arıza yapısal mıdır?
Cevap: CMD53 yazmaları tamamlandı (0/15 incomplete), pencere uyuşmazlığı olmadı, 48 baytlık kontrol çerçevesi XFER=48 çıktı. İki CMD53 okuma CRC'si (2/164) bilinen INTSTATUS yolunda; kurtarma sonrası bekleme yolu READ_FAILURES=0 ve INTSTATUS=0 her iki erişimle doğrulandı. Terminal yine ControlTimeout. F2 watermark 0x08 bu boot'ta icra edildi ve cevap üretmedi. Arama protokole döner.
Sayım makbuzu her sonuç dalında basıldı
WIFIBUSCENSUS STAGE=ERROR CMD52_OPS=612077 CMD52_FAIL=83469 CMD53R_OPS=164 CMD53R_INCOMPLETE=2 CMD53W_OPS=15 CMD53W_INCOMPLETE=0 ERR_CRC_ONLY=1 ERR_CRC_ENDBIT=1 ERR_DATA_TIMEOUT=0 ERR_CMD_CLASS=0 ERR_OTHER=0 WINDOW_MISMATCH=0. Linux R80 ~12.000 CMD52 / ~4.200 CMD53; biz firmware'i hâlâ cmd52+verify ile indirdiğimiz için CMD52 51×, CMD53 1/23.
CMD52_FAIL TCM bozulması değildir
cmd52() None (issue not-ok veya R5) sayılır. FWSTAGE yine OK=1 RETRIES=0 WORDS_V=152448; R58 DATA-doğrulaması R5 kirliyken baytı kabul eder. 83.469/612.077 (%13,6) üç imzanın oranı değildir.
Cevapsız ioctl'ü aralıklı CMD53 yazma bozulması karşılamıyor
CMD53W_INCOMPLETE=0, XFER=48, WINDOW_MISMATCH=0. İki okuma CRC'si INTSTATUS 0x0020 ve bir DATA_CRC|END_BIT; kurtarma ACCEPTED=1, sonra 2500 ms boyunca READ_FAILURES=0. WIFICORE_ACCESS VERDICT=POLLED_VALUE_CONFIRMED: INTSTATUS=0 düz ve bayraklı yolda aynı.
Doğru çalışanlar
imaj 8ab16337d0e0c000ff1ae73c80ed94e3795e61240d6385dde9083811dfbffeb2
kanıt evidence/rpi5/radio/attempt-r123-sdio-transport-census-uart-capture/
Sorulan: Linux'un ilk kontrol çerçevesinden hemen önce yazdığı CCCR INT_ENABLE 0x03 sonra 0x07, IEN=0 iken firmware'in cevapsız ioctl'ünü açar mı?
Cevap: Değişken hiç icra edilmedi. Koşu Function2Ready'den önce, D11 aşamasında CMD53 veri-CRC ile kırıldı. WIN_OK=1, ISSUED=1, ERR=0x0020, XFER=0; WIFIEN yok; terminal UNAVAILABLE CORE_READY=0. INT_ENABLE hakkında ne lehte ne aleyhte sonuç çıkmaz.
Census kırılımı çalıştı
CMD52_STAGE_OPS=611542 STAGE_FAIL=78837; CMD52_OTHER_OPS=457 OTHER_FAIL=0. 78.837 fail'in tamamı firmware/NVRAM cmd52 yazması (R46 sahte R5). Staging dışı CMD52 bu boot'ta temiz.
D11 taşıması pencere değil, CMD53 CRC
CR4CTRL PHASE=D11 ABORTED=1 REASON=TRANSPORT ADDR=0x18101800 WRITE=0 WIN_OK=1 WIN_W=WIN_R=0x18100000 COMPLETE=0 ISSUED=1 R5=0x10 ERR=0x0020. R122'nin WIN_R=0x18181800 imzası yok (WINDOW_MISMATCH=0). Komut çıktı, veri fazı DATA_CRC aldı.
INT_ENABLE yazılmadı
Yazma Function2Ready'de, CR4 start ve F2 hazır olduktan sonra. Bu boot CR4'ü başlatmadı. WIFIPROTO ve WIFIEN satırı yok.
Doğru çalışanlar
imaj 644ed7aad9eae7998bf4a64ae2256bb79061d15186deb05de32ab708cf3bc10c
kanıt evidence/rpi5/radio/attempt-r124-cccr-int-enable-uart-capture/
Sorulan: R124 imajı Function2Ready'ye kadar giderse, CCCR INT_ENABLE 0x03 sonra 0x07 ilk BCDC isteğini cevaplar mı?
Cevap: Kapı açıldı ve kapalı kaldı; cevap gelmedi. WIFIEN W1=3 W2=7 READBACK=7, timeout IEN=Some(7) INT_PENDING=Some(0). 48/20 cur_etheraddr XFER=48 SENT=1 REPLIED=0, INTSTATUS=0, ControlTimeout. R115–R124 IEN=Some(0) okuyordu; bu boot Linux çiftini yazdı. INT_ENABLE cevapsız ioctl'ün nedeni değil.
INT_ENABLE icra edildi ve latch etti
Function2Ready'de 0x03 sonra 0x07 yazıldı. Geri-okuma 7. 2500 ms sonra WIFIIRQWAIT hâlâ IEN=Some(7). INT_PENDING=0, CORE_OR=0, FRAME_IND_SEEN=0.
Protokol yolu R123 ile aynı, artı açık kesme kapısı
CR4CTRL COMPLETE WIN_OK=1, CR4START RSTVEC_OK=1, WIFIPROTO STARTED=1, iki header-only RX SEQ=0/1 payload=0, exact 48/20, READ_FAILURES=0, WIFICORE_ACCESS VERDICT=POLLED_VALUE_CONFIRMED. CMD53W_INCOMPLETE=0/15. İlk INTSTATUS 0x0060; kurtarma ACCEPTED=1.
Census kırılımı yine STAGE'e hapsetti
CMD52_STAGE_FAIL=74995, CMD52_OTHER_FAIL=0/535. WINDOW_MISMATCH=0.
Doğru çalışanlar
imaj 644ed7aad9eae7998bf4a64ae2256bb79061d15186deb05de32ab708cf3bc10c
kanıt evidence/rpi5/radio/attempt-r125-cccr-int-enable-uart-capture/
Sorulan: R121'in dört ölçülmüş hazırlık farkından üçüncüsü — fn1 WAKEUPCTRL (0x1001e) = 0x02 (HT-wait), Linux'un yazdığı noktada — yazılırsa cevapsız ioctl açılır mı?
Cevap: İlk boot D11'de Function2Ready'den önce düştü, değişken hiç icra edilmedi (STATUS=UNAVAILABLE CORE_READY=0). Tekrar koşu — aynı imaj, reflash YOK, yeni güç döngüsü — değişkeni icra etti: WIFIWAKEUP BEFORE=Some(0) WROTE=Some(2) READBACK=Some(2); ardından 48/20 isteği XFER=48 SENT=1 REPLIED=0, IEN=Some(7) INT_PENDING=Some(0), ControlTimeout. WAKEUPCTRL=0x02 cevapsız ioctl'ün nedeni DEĞİL: dört farktan üçü elendi, tek kalan fn0 CCCR 0x000f0=0x06.
İlk boot değişkene ulaşmadı
D11 aşamasında kırıldı (R124 sınıfı bir varışsızlık); WIFIWAKEUP satırı yok, kontrol çerçevesi gönderilmedi. Aynı imajla tekrar koşu gerekti — R125'in R124'e olan ilişkisi.
Tekrar boot değişkeni icra etti ve eledi
Kartın güç-açılış değeri Some(0) ölçüldü — 0x02 gerçek bir değişiklikti, boş yazma değil. Yazıldı, latch etti, firmware yine cevap vermedi. Watermark (R123), INT_ENABLE (R125), WAKEUPCTRL (R126) elendi; geriye CCCR 0x000f0=0x06 kaldı.
Tekrar yakalama PARTIAL olarak beyan edildi
UART güçten SONRA kurulduğu için başı eksik (ilk satır ASELSAN/FWSTAGE_P S=128 PH=0); eksik bölüm WAKEUPCTRL sorusuna ait değildir ama paket tam-boot yakalama diye kullanılamaz. İlk paket bu imajın tam-boot kaydıdır.
Doğru çalışanlar
imaj 0e4fb7ae33ad4caa97fef2c4b65c76fd634b0187c6fd65290c159de5f5783e2c
kanıt evidence/rpi5/radio/attempt-r126-wakeupctrl-uart-capture/ · attempt-r126-wakeupctrl-uart-capture-repeat-01/
Sorulan: On bir hazırlık profili tek boot'ta süpürülürse (deneme 0 = R126 tabanı, LINUX_EXACT dahil), dört farktan hangi kombinasyon kontrol cevabını üretir?
Cevap: İlk boot D11'de düştü — WIFITRIALPLAN bile basılmadı (yine de CMD52_FAIL=0/611999, kayıttaki en temiz CMD52 boot'u; CMD53W_INCOMPLETE=2/2). Tekrar boot'ta motor çalıştı: TRIAL=0 tabanı birebir doğruladı (ControlTimeout), TRIAL=1 LINUX_EXACT altı hazırlık kaydının tümünü uyguladı ve geri okumayla doğruladı — zincirde İLK KEZ tam Linux hazırlık eşitliği. Hemen ardından WriteFifo fn=2 error_status=0x0020; Io kalıcı terminal oldu, STOP TRIALS_RUN=1/11 REPLIED=0. LINUX_EXACT elenmedi: çerçevesi hiç iletilemedi, sorusu sorulmadı.
Süpürme motoru cihazda çalışıyor
Arm oldu, denemeler koştu, makbuzlar basıldı, tek sonlandırma işareti ile yakalama temiz kapandı.
İlk tam Linux hazırlık eşitliği uygulandı ve geri okundu
WM 0x08, WC 0x02, DEVCTL 0x10→0x00, MESBUSY 0xd0→0x00, CARDCAP 0x00→0x06, IEN 0x07 — hepsi geri okumayla doğrulandı; CCCR 0x000f0=0x06 hiçbir koşuda karta ulaşmamıştı.
Aday (n=1): DEVICE_CTL bit 4
O boot'taki 16 CMD53 yazmasından düşen tek yazma, biti temizleyen profilin hemen ardından geldi; bitin upstream adı bu pakette doğrulanmadı ve DEVICE_CTL hiç tek başına temizlenmedi — R128 tam bunu sınar.
Doğru çalışanlar
imaj 882c67867b88a4af3d72d427e2172be91937eabc905f2c31f725addbe4938bbd
kanıt evidence/rpi5/radio/attempt-r127-prereq-sweep-uart-capture/ · attempt-r127-prereq-sweep-uart-capture-repeat-01/
Sorulan: R127'nin adayı doğru mu: DEVICE_CTL bit 4'ün temizlenmesi ikinci F2 yazmasını mı düşürüyor?
Cevap: ÇÜRÜTÜLDÜ. R128'de düşen deneme biti KORUDU (DEVICE_CTL 0x10→0x10, geri okumayla doğrulandı; MESBUSY 0xd0→0xd0, tek değişiklik CARDCAP 0x00→0x06) ve aynı işlemde aynı hatayı aldı: WriteFifo fn=2 addr=0x8000, CMD53W_OPS=16 INCOMPLETE=1, STOP=NOT_REARMABLE TRIALS_RUN=1/11. DEVICE_CTL sebep değil.
İki boot, adayın adını verdiği bitte farklılaşan iki profil, birebir aynı sonuç
R127 TRIAL=1 LINUX_EXACT biti temizledi (0x10→0x00); R128 TRIAL=1 CARDCAP_06 biti korudu (0x10→0x10, geri okumayla); MESBUSY de farklı (0xd0→0x00 / 0xd0→0xd0). İkisi de aynı WriteFifo fn=2 hatası.
Kartın gerçek güç-açılış watermark'ı 0x20 ölçüldü
Deneme 0 güç-açılış durumunu kaydetti: WM=0x20 WC=0x00 DEVCTL=0x00 MESBUSY=0x00 CARDCAP=0x00 IEN=0x00 — ne bizim 0x60'ımız ne Linux'un 0x08'i.
Kalan tek ortak nokta daha keskin
İki düşen yazma da CEVAPSIZ KALAN bir çerçeveden SONRAKİ ilk çerçeveydi; iki boot'ta da 16 CMD53 yazmasından düşen tek yazma oydu. İki okuma: (a) yeniden kurmamız eksik — her mühürlü koşuda FIFO_READS=0; (b) kart yoksaydığı çerçeveden sonra F2 yazması kabul etmiyor. R129 ikisini ayırır.
Doğru çalışanlar
imaj 19d1caafb30d73e258f62161716884ecf802947b6b44ab1653eca8a7d97f3c1e
kanıt evidence/rpi5/radio/attempt-r128-prereq-sweep-ordered-uart-capture/
Sorulan: Her yeniden kurmadan ÖNCE maskeli core INTSTATUS temizliği + koşulsuz tek F2 FIFO boşaltması yapılırsa, ikinci yazma kurtulur mu? (R128'in 'yeniden kurmamız eksik' ve 'F2'de toplanmamış cevap var' okumaları)
Cevap: Kurtarma tamamlandı ve ikinci yazmayı kurtarmadı. WIFIRECOVER ATTEMPTED=1 INTSTATUS=Some(0) CLEARED=0 FIFO_OK=1 FIFO_FAILED=0 LENGTH=Some(0) LEN_COMPLEMENT_OK=0, host veri motoru idle. FIFO boştu, kesme yoktu — ve yeniden kurulan çerçeve üçüncü boot üst üste aynı WriteFifo fn=2 0x0020 ile düştü. İki okuma da çürüdü.
FIFO'da bekleyen çerçeve yoktu
Boşaltma okuması LENGTH=Some(0) döndü; 'kart, toplamadığımız bir cevabı F2 FIFO'da tutuyor' okuması çürüdü.
INTSTATUS zaten sıfırdı, host idle'dı
CLEARED=0 (temizlenecek bit yok), PSTATE idle; 'eksik yeniden kurma' okumasının somut biçimi elendi.
Üçüncü boot aynı imza
R127/R128/R129 üç boot'ta da cevapsız çerçeveden sonraki ilk F2 yazması aynı 0x0020 data CRC ile düştü; kart F2 okumayı kabul ediyor, yazmayı reddediyor.
Doğru çalışanlar
imaj aedd2f1c1450fabb34a0bbec0bff1ee3a6c71bf6d2f8e286152e33df49734c4a
kanıt evidence/rpi5/radio/attempt-r129-inter-trial-recovery-uart-capture/
Sorulan: CCCR IO_ABORT (0x06) kaydına function 2 seçimi (0x02) ikinci yazmadan hemen önce yazılırsa, F2 yazma yolu kurtulur mu?
Cevap: Abort tamamlandı ve kurtarmadı. WIFIF2ABORT ATTEMPTED=1 OK=1 FAILED=0; hemen ardından yeniden kurulan ikinci F2 yazması aynı işlemde, aynı data CRC sınıfıyla düştü. IO_ABORT tek başına — bu sınırda — elendi.
IO_ABORT ilk kez issue edildi ve geçti
Hiçbir koşuda issue edilmemiş mekanizma cihazda tamamlandı: ATTEMPTED=1 OK=1 FAILED=0, FUNCTION=2 REGISTER=0x06 VALUE=0x02.
Aynı yazma aynı hatayla düştü
Abort ile ikinci yazma bitişikti; 0x0020 imzası değişmedi.
Sınır daraldı, kapsam dışı kalanlar kayıtlı
F2 disable/enable ve block-size re-assert bu koşuda YOKTUR; ikisi sonraki revizyonların tek değişkenidir.
Doğru çalışanlar
imaj 670818f2326d84f7f50a1571bf466823abeb8cdd7badf0fb89ae81741e93bfdc
kanıt evidence/rpi5/radio/attempt-r130-f2-io-abort-uart-capture/
Sorulan: Function 2'nin enable/ready yaşam döngüsü tamamen kapatılıp (F1 korunarak) yeniden açılırsa, ikinci yazma kurtulur mu?
Cevap: Yaşam döngüsü tamamlandı ve kurtarmadı. WIFIF2REENABLE ATTEMPTED=1 BEFORE_ENABLE=Some(6) DISABLE_OK=1 READY_CLEAR=1 ENABLE_OK=1 READY_SET=1 FAILED=0 — her geçiş ilk bounded poll'da. Hemen ardından ikinci F2 yazması yine 0x0020 ile düştü. Yeni ayırt edici fark: CORE_OR=0x00000080 (R130'un aynı sınırında 0) — yaşam döngüsünün ürettiği post-lifecycle HOST_INT.
Yaşam döngüsü gerçekten tamamlandı
Enable biti gözlendi, temizlendi, hazır-biti düşüşü doğrulandı, geri açıldı, hazır-biti yükselişi doğrulandı — yalnızca register yazılmış sayılmadı.
Post-lifecycle HOST_INT=0x80
R130'un aynı sınırında CORE_OR=0 idi; R131 yaşam döngüsünden sonra 0x80. Pre-lifecycle INTSTATUS=0 olduğundan bu yeni kart durumu ayrıca sınanmalıdır — R132 tam bunu yapar.
Disable/enable test edilen tam formda elendi
Yeni kesmeyi servis etmeden yapılan kapat/aç ikinci yazmayı kurtarmadı; kesmeyi servis eden form R132'nin değişkenidir.
Doğru çalışanlar
imaj 877a1b96ba3df93034c31d93991986605c6447d38dfdd3076f39ecf0954f892f
kanıt evidence/rpi5/radio/attempt-r131-f2-reenable-uart-capture/
Sorulan: Yaşam döngüsünün ürettiği HOST_INT (0x80) yaz-bir-temizle ile ack edilip geri okuma sıfır okunursa, ikinci yazma kurtulur mu?
Cevap: Ack tamamlandı ve kurtarmadı. WIFIF2POSTIRQ ATTEMPTED=1 BEFORE=Some(128) MASKED=Some(128) ACK_ATTEMPTED=1 ACK_OK=1 AFTER=Some(0); ardından ikinci F2 yazması yine aynı 0x0020 ile düştü. Post-lifecycle HOST_INT açıklaması elendi.
0x80 gerçekten vardı
READY_SET sonrası core INTSTATUS 0x80 okudu; R131'deki gözlemin yalnız sonuç-sonrası gürültü olmadığı zaman olarak daraldı.
Ack sonrası çekirdek durumu sıfırdı
Write-one-to-clear tamamlandı, readback Some(0); trial boyunca core status sıfır kaldı — buna rağmen aynı yazma aynı veri CRC'siyle düştü.
Doğru çalışanlar
imaj 3fddd839a9e9f31830d62f17da1f1f3907fa6b6990c9c6c4911a656075ab2582
kanıt evidence/rpi5/radio/attempt-r132-post-lifecycle-host-int-uart-capture/
Sorulan: F2 block-size (0x210/0x211) 512 olarak yeniden yazılıp iki baytı geri okunursa, ikinci yazma kurtulur mu?
Cevap: Üçüncü boot değişkene ulaştı: block-size önce 0x00/0x02 idi, iki yazma ve iki geri okuma geçti, MATCH_512=1 FAILED=0. Bitişik ikinci F2 yazması yine 0x0020 ile düştü. İlk iki boot değişkene ulaşmadı (biri trial 0'ı ControlTimeout'tan önce F1 Read32 duvarında kesti, biri D11'de kırıldı). Block-size kaybı veya bayat programlama elendi.
Ulaşım üç boot aldı
İlk paket trial 0'ı ControlTimeout'tan önce F1 Read32 BusError ile kesti (WIFIRECOVER ATTEMPTED=0); ikinci paket D11'de kırıldı (plan satırı bile yok); üçüncü paket R129–R132 zincirinin tamamını geçip değişkeni icra etti.
MATCH_512=1
BEFORE_LOW/HIGH=Some(0)/Some(2), WRITE_LOW/HIGH_OK=1, READBACK 0x00/0x02 — blok boyutu zaten doğruydu ve yeniden yazılıp doğrulandı.
Block-size elendi
Aynı ikinci yazma aynı 0x0020; FIFO, kesme, enable/ready ve block-size durumlarının tümü tek tek sağlıklı doğrulandığı hâlde yazma düşüyor.
Doğru çalışanlar
imaj c58ee8c1fa30a776e1b67a4253353e6df1609cd8e020dd4d4cf58201c7509c37
kanıt evidence/rpi5/radio/attempt-r133-f2-block-size-uart-capture/ · attempt-r133-f2-block-size-repeat-uart-capture/ · attempt-r133-f2-block-size-repeat-2-uart-capture/
Sorulan: Send sınırında host-only SDHCI DATA reset (byte register 0x2f, mask 0x04) — idle doğrulamasıyla — ikinci yazmadan hemen önce uygulanırsa, ikinci yazma kurtulur mu?
Cevap: İlk boot eyleme ulaşamadı: TRIAL=0 sonrası kurtarma merdiveninde F1 Read32 (INTSTATUS) bus-ömründe-bir-kez reset kullanıldıktan sonra aynı adreste ikinci kez 0x0020 aldı, transport NOT_REARMABLE kapandı (WIFIHOSTDATA makbuzu yok). Tekrar koşu ulaştı ve ELEDİ: ATTEMPTED=1 MEASURED=1 APPLIED=1 CLEARED=1 READY=1 CONFIG_SAME=1 (2 poll, 10 µs), reset ile ikinci yazma arasında hiçbir SDIO makbuzu yok; ikinci yazma YİNE 0x0020 ile düştü. R24 (meşgul hatta), R116 (arıza sonrası kurtarma) ve R134 (send sınırı) ile host SDHCI DATA reset eylemi yerleşim-bağımsız elendi.
Eylem makbuzu tamam
PSTATE_B/A=0x017f0000, RESET_FIRST=0x04, 2 poll / 10 µs; SOFTWARE_RESET.DAT self-clear doğrulandı. Reset ile ikinci yazma arasına hiçbir SDIO işlemi girmedi.
Konfigürasyon korundu
CONFIG_SAME=1 — saat/timeout/kontrol/güç/blok/control2 konfigürasyonunun korunduğu kanıtlandı; bu kör bir reset değildi.
Yerleşim-bağımsız eleme
Profil sözleşmesi birebir işledi: APPLIED=1, READY=1 ve aynı 0x0020 tekrarı → ELEME. Reset eylemi hangi yerleşimde olursa olsun ikinci yazmanın 0x0020'sinin nedeni değil; kurtarma-yolu reset'i kodda kaldığı gibi durur.
İlk boot aynı F1 Read32 duvarını tekrarladı
Kurtarma INTSTATUS okuması, bus reset'inden sonra aynı adreste ikinci kez 0x0020 aldı; R133'ün ilk paketi ile ortak varışsızlık imzası. Süpürme motorunun bu kırılganlığı ayrı bir nottur.
Doğru çalışanlar
imaj b3910252804ba69fb8ed40c90f52abf4c886d9849c77ac64961f5efd059f1cf0
kanıt evidence/rpi5/radio/attempt-r134-host-data-reset-at-send-boundary-uart-capture/ · attempt-r134-host-data-reset-at-send-boundary-uart-capture-repeat/
Sorulan: Yeniden kurulan ikinci F2 yazması Linux'un kısa-yazma birimi olan 64 bayt byte-mode (16 sıfır dolgu) ile gönderilirse, R127'den beri düşen 0x0020 kurtulur mu? (R80 izi: Linux fn=2 adres=0x8000'e HİÇ 48 bayt yazmıyor; 64×1456 adet.)
Cevap: Üç boot gerekti ve üçüncüsü ELEDİ. İlk iki boot değişkene ulaşmadı: TRIAL=0 cevap bekleyişinde F1 Read32 (INTSTATUS) ile öldü — ilki AGE_MS=383'te error_status=0x0060, ikincisi AGE_MS=2133'te 0x0020; WIFIF2BLKSZ ATTEMPTED=0, ikinci yazma hiç denenmedi. Üçüncü boot ulaştı: plan arm oldu (WIFIF2WRITE64_PLAN ARMED=1 UNIT=64 PAD_ZERO=1 FIRST_WRITE_UNCHANGED=1 CARD_COMMANDS=0 HOST_RESET=0), TRIAL=0 tabanı korudu (48/48, ControlTimeout), kurtarma + R131/R132/R133 zinciri tam makbuzla geçti, WIFIHOSTDATA sıfır kez basıldı — ve 64 baytlık ikinci yazma YİNE aynı 0x0020 ile düştü: WIFIREAD OP=WriteFifo BYTES_READ=64 ERROR_STATUS=0x0020, STOP=NOT_REARMABLE TRIALS_RUN=1/11. Byte-count şekli elendi.
Değişken birebir icra edildi, profil sözleşmesi işledi
İkinci yazmanın teldeki bayt sayısı 64 oldu (WIFIREAD BYTES_READ=64, BusError bytes_read: 64); ilk yazma FRAMELEN=48 XFER=48 değişmedi; R134'ün elenen reset'i imajda yoktu (WIFIHOSTDATA makbuzu 0 adet, plan HOST_RESET=0).
R129–R133 zinciri bu boot'ta da tam geçti
WIFIRECOVER ATTEMPTED=1 INTSTATUS=Some(0) FIFO_OK=1 LENGTH=Some(0); F2REENABLE DISABLE_OK=1 READY_CLEAR=1 ENABLE_OK=1 READY_SET=1 FAILED=0; F2POSTIRQ BEFORE=Some(128) ACK_OK=1 AFTER=Some(0); F2BLKSZ MATCH_512=1 FAILED=0. Düşen tek işlem yine yeniden kurulan ikinci F2 yazmasıydı.
İki varışsızlık paketi ayrı mühürlendi
İlk boot 0x0060, ikinci boot 0x0020 F1 Read32 imzasıyla TRIAL=0'da öldü; ikisi de 'R135 sorusunu cevaplamaz' diye beyan edildi. Kart hiç yeniden yazılmadı — üç boot aynı db93f033… imajındaydı.
Sıradaki aday: re-arm→yazma zamanlaması (R26 emsali)
Kart tarafı (FIFO, kesme, enable/ready, block-size), host tarafı (DATA reset) ve teldeki byte sayısı elendi; MATCH_512 makbuzu ile ikinci yazma arasındaki ZAMAN hiç tek değişken olarak sınanmadı. R26 saf beklemenin yetmediğini, araya giren tek CMD52'nin senkronize ettiğini göstermişti. Önce masabaşı notu, sonra fiziksel koşu.
Doğru çalışanlar
imaj db93f033197a844046dda915ac79e1d23690e48a9cab867be0e77ec94999aa2d
kanıt evidence/rpi5/radio/attempt-r135-f2-write64-uart-capture/ · attempt-r135-f2-write64-uart-capture-repeat-01/ · attempt-r135-f2-write64-uart-capture-repeat-02/
Sorulan: Kontrol çerçevesi Linux'un aynı kartta ölçülen SDPCM glom biçimiyle (8 baytlık eklenti, BCDC dcmd 20. baytta) gönderilirse hem hat kabul eder hem firmware cevap verir mi?
Cevap: Tel biçimi duvarı KIRILDI, cevap gelmedi. Yeniden kurulan ikinci F2 yazması ilk kez kabul edildi: TRIAL=1 FRAMELEN=56 XFER=56 SENT=2 REPLIED=0 ERR=ControlTimeout — WriteFifo/0x0020 hatası YOK; süpürme TRIAL=2'ye ilerledi (TRIALS_RUN=2). Ancak her denemede REPLIED=0 CTRL_SEEN=0 FRAME_IND=0 HOST_INT=0 CORE_OR=0 kaldı: firmware çerçeveyi işlemiyor, terminal yine ControlTimeout.
Duvar taşımadan firmware mantığına kaydı
R127–R135 host tarafını (FIFO, kesme, yaşam döngüsü, block-size, DATA reset, byte-count) elemişti; R136 tel biçimini Linux'la eşitledi ve ikinci yazma kabul edildi. Artık sınır SDIO değil: firmware çerçeveyi yutuyor ve hiç kesme üretmiyor.
Kalan ölçülmüş farklar (R137 adayları)
Ölçülen Linux çerçeveleriyle (linux-r136-first-frame-v3) yapı birebir aynı; kalan farklar: SDPCM seq (bizde 255 taşıma başlangıcı, Linux'ta küçük ve artan), dcmd türü/id (bizde GET id=1, Linux ölçümünde SET id=4+), ve Linux'un preinit sırası (bus:txglomalign, ver, cur_etheraddr, mpc, bus:txglom, event_msgs, scan_ver).
Makbuz kusuru düzeltildi
R136 koşusunda WIFICTRLTX BCDCLEN=0 ve EXPECT_R80_* alanları eski yerleşimin ofsetlerini okuyordu; çerçevenin kendisi doğruydu (RAW satırında 14 00 00 00 = 20). Makbuz artık CONTROL_DATA_OFFSET+4'ten okuyor.
Doğru çalışanlar
imaj 940ff0ae798cca612f4481bf5b8b22c81c0ac5753b33d764ab5a11ce5c8fa246
kanıt evidence/rpi5/radio/attempt-r136-glom-control-frame-uart-capture/
Sorulan: Mailbox el sıkışması görünür kılınırsa: dongle protokol için hazır oluyor mu (FWREADY) ve tel biçimi dört çerçeve boyunca kararlı mı?
Cevap: Taşıma sağlam, dongle hazır değil. Dört deneme üst üste kabul edildi (TRIAL=0..3 FRAMELEN=56 XFER=56 BCDCLEN=20 SENT=1..4, seq 255→0→1→2→3; TRIALS_RUN=4/11) ve makbuz artık doğru BCDCLEN okuyor. Ancak yeni tanık 87 örnekte mailbox değerinin HİÇ değişmediğini ölçtü: LAST=0x00040002 = sürüm 4 + DEVREADY; FWREADY (0x0008, 'fw ready for protocol activity') hiç görünmedi ve kabul edilen çerçevelerin hiçbirine cevap gelmedi (REPLIED=0 FRAME_IND=0 HOST_INT=0).
Taşıma duvarı gerçekten aşıldı
R136'da iki denemeye çıkan süpürme R137'de dörde çıktı; her çerçeve kabul edildi ve düşen tek şey bilinen Read32(INTSTATUS) duvarı oldu. Tel biçimi (glom) ve makbuz alanları doğru.
Dongle protokol hazır bayrağını kaldırmıyor
ASELSAN/WIFIMBOXWATCH SAMPLES=87 CHANGES=0 LAST=0x00040002: DEVREADY var, FWREADY yok. brcmfmac'te FWREADY 'fw ready for protocol activity' demektir; bayrak kalkmadan kontrol isteklerinin cevaplanmaması beklenir.
Sıradaki aday: hostmail el sıkışmasının zamanlaması (R138)
Linux `brcmf_sdio_hostmail` her okumada SMB_INT_ACK yazar ve DEVREADY/FWREADY görünce sürümü yeniden yazar. Bizde ACK yalnız değer değiştiğinde, sürüm yalnız F2-hazır yolunda bir kez gidiyor; R138 yalnız bu iki yazmanın zamanlamasını değiştirir (docs/radio/R138-hostmail-ack-desk.md).
Doğru çalışanlar
imaj 68cad3b57b5c34bbe4a306d0314904e9241bcf9672111eb11901d88dc821ad76
kanıt evidence/rpi5/radio/attempt-r137-mailbox-handshake-uart-capture/
Sorulan: Host mailbox el sıkışması Linux'un brcmf_sdio_hostmail dizisiyle (her okumada SMB_INT_ACK + DEVREADY/FWREADY görülünce sürüm yazımı) tamamlanırsa dongle FWREADY'yi kaldırır ve çerçeveleri cevaplar mı?
Cevap: Hayır — hipotez ELENDİ. Üçüncü koşuda değişken tam icra edildi: 32 örnekte her okuma ACK'lendi (ACKS=32) ve her okumada protokol sürümü yeniden yazıldı (VERSION_WRITES=32); dongle yine FWREADY'yi kaldırmadı (FWREADY_SEEN=0, LAST=0x00040002 = sürüm 4 + DEVREADY) ve iki kusursuz glom çerçevesi cevapsız kaldı. Oturum host tarafında CommandDeadline(Mac) ile kapandı.
Değişken tam icra edildi
WIFIHOSTMAIL_PLAN ARMED=1 ACK_EVERY_READ=1 VERSION_REWRITE_ON_READY=1; WIFIMBOXWATCH SAMPLES=32 CHANGES=0 DEVREADY_SEEN=1 FWREADY_SEEN=0 VERSION=4 ACKS=32 VERSION_WRITES=32 LAST=0x00040002. R137'nin makbuz kusuru da düzeldi: bayraklar artık her örnekte değerlendiriliyor.
El sıkışma adayı elendi
Linux'un dizisi birebir uygulandı (her okumada ACK, hazır bayrağında sürüm yazımı); dongle yine 'protokol aktivitesi için hazır' demiyor. Duvar host el sıkışmasında değil.
Üç kanıt tek okumada birleşiyor
Dosya TCM'e doğrulanarak yükleniyor (FWSTAGE/NVRAM OK=1) ama CR4START makbuzları STARTED=0/EXECUTED=0; dongle DEVREADY diyor, FWREADY demiyor; host tarafı hâlâ kırılgan (F1 Read32/Write8 inhibit, CommandDeadline). Uygulama firmware'inin yürümediği okuması güçlendi — R139'un yönü bu.
Doğru çalışanlar
imaj e125208d4eb9d73bd0d7a71985766ce0fa172be9f4a2b975523bc80e57536b39
kanıt evidence/rpi5/radio/attempt-r138-hostmail-complete-uart-capture/ · attempt-r138-hostmail-complete-uart-capture-repeat-01/ · attempt-r138-hostmail-complete-uart-capture-repeat-02/
Sorulan: Reset vektörü Linux'un yaptığı gibi 4-baytlı bayraklı CMD53 ile backplane adres 0'a yazılırsa iner mi (R88'in 0x0060'ı R94 sonrası tekrarlar mı) ve CR4 yürütme tanıkları değişir mi?
Cevap: Taşıma KAPANDI, yürütme değişmedi. RSTVEC_C53=1 RSTVEC_B=4 RSTVEC_ERR=0x0000 RSTVEC_CMD52_FALLBACK=0 — 4-baytlı bayraklı CMD53 indi; R88'in veri CRC'si R94 sonrası tekrarlamadı ve CMD52 geri dönüşü hiç kullanılmadı. Buna rağmen CR4 tanıkları sıfır kaldı (EXECUTED=0 STARTED=0 MBOX=0 INTSTAT=0 SHARED_RAW=0; HT_REQ_AVAIL=1) ve dongle FWREADY demedi (SAMPLES=18 ACKS=18 VERSION_WRITES=17 FWREADY_SEEN=0).
Kritik yoldaki son bilinen yapısal fark kapandı
Linux'un CR4 başlatma değerleri R139 ölçümünde birebir çıkmıştı (ioctl 0x03/0x23/0x21/0x01, +0x800 1→0, rstvec 0xb83ef198, sürüm 0x00040000, hostintmask 0x200000f0, ACK 2). Bu koşu taşımayı da eşitledi: rstvec artık 4-baytlı bayraklı CMD53 ile iniyor.
CR4 yürütme hâlâ görünmüyor
Değerler ve taşıma Linux'la aynı olduğu hâlde paylaşımlı bellek boş (SHARED_RAW=0), mailbox ve intstatus sıfır. Yani eksik olan, yazdığımız değerler ya da bu yazmanın taşıması değil.
Kalan iki aday (R140)
(a) firmware staging taşıması — biz CMD52 ile yazıp geri okuyoruz, Linux CMD53 blok yazmalarıyla indiriyor; (b) F1 yazma güvenilirliği — bu koşu kendi el sıkışma yazmamızın tosbmailboxdata (0x18004048) Write32'sinde 0x0020 ile düştüğünü gösterdi.
Doğru çalışanlar
imaj a7d06727d947bdaa1aad452a83eb9ea21bff8156e35378ee4b65e9b8ed438eaa
kanıt evidence/rpi5/radio/attempt-r139-rstvec-cmd53-uart-capture/
Sorulan: "Host hazır" protokol sürümü yazması CR4 bırakılışından hemen sonra yapılırsa (Linux'un brcmf_sdio_firmware_callback konumu) dongle FWREADY'ye geçer mi?
Cevap: GEÇTİ — ilk kez. Yazma bırakılıştan 5 ms sonra indi (WRITE_OK=1, AFTER=0x00040000) ve dongle 30 ms içinde 0x00040008 (sürüm 4 + FWREADY) yazdı; intstatus 0x208000c0 (I_CHIPACTIVE|HMB_HOST_INT|HMB_FRAME_IND) kalktı. Pencere salt-okunur olduğu için el sıkışma cevaplanmadı ve protokol fazında posta kutusu DEVREADY'ye (0x00040002) geri düştü; koşu F1 Read32 0x18004020 veri CRC'siyle (0x0020) kapandı.
Duvar bir zamanlama duvarıymış
R136–R139 aynı değerleri yazıyordu ama bu yazma bırakılıştan saniyeler sonra gidiyordu; Linux'ta 74 µs sonra gidiyor. Yer değişince dongle aynı sırayla cevap verdi: 5 ms'de yazma, 30 ms'de FWREADY.
Cevapsız el sıkışma geri düşüyor
Salt-okunur pencere dongle'ı memnun etmiyor: FWREADY bir süre sonra DEVREADY'ye dönüyor ve denemeler yine hiç kesme görmüyor (CORE_OR=0x00000000). Linux aynı pencerede postayı ACK'liyor (0x18004040 ← 2) ve intstatus'ı write-1-to-clear ediyor.
Kalan duvar iki parçalı
(a) posta kesmesini erken pencerede cevaplamak (R141'in tek değişkeni), (b) F1 0x18004020 okumasındaki veri CRC'si — bu koşuda da koşuyu kapatan hata oldu.
Doğru çalışanlar
imaj 12595cd216f02de34ba7c320360d6abd39aed982c91f41173d46530287cf7471
kanıt evidence/rpi5/radio/attempt-r140-hostready-at-start-uart-capture/
Sorulan: R140'ın salt-okunur penceresinde gelen FWREADY ve host kesmesi Linux ISR'inin yaptığı gibi cevaplanırsa (tosbmailbox ← SMB_INT_ACK, intstatus write-1-to-clear) el sıkışma tamamlanır ve kalıcı olur mu?
Cevap: Cevap İNDİ (ACKS=7 INT_WRITES=2 INT_MASKED=0x200000c0 SETTLED=1 FWREADY_ACKED_MS=25) ama durum KALICI OLMADI: protokol fazında posta kutusu yine 0x00040002'ye düştü ve koşu TRIAL=0'da F1 Read32 0x18004020 veri CRC'siyle (0x0020) kapandı. Arıza makbuzu mekanizmayı gösterdi: HOST_CARD_INT=true (kart DAT1'i sürüyor) ve SDHCI_INT_SIGNAL_ENABLE=0 (kesme servis edilmiyor).
Cevap tasarlandığı gibi çalıştı
El sıkışma oturdu: FWREADY 25 ms'de onaylandı, intstatus 0x200000c0 write-1-to-clear edildi ve pencere erken kapandı (SETTLED=1). R140'ın salt-okunur penceresi artık cevap veriyor.
Dongle durumu yine korumadı
Protokol fazında posta kutusu 0x00040002 (yalnız DEVREADY) ve CHANGES=0; denemeler yine CORE_OR=0x00000000 gördü. Tek kesme onayı el sıkışmayı kalıcı kılmıyor.
Yeni ve doğrudan kanıt: kart DAT1'i sürüyor
SDHCI HOST_CARD_INT=true ve SDHCI_INT_SIGNAL_ENABLE=0; 4 baytlık CMD53 okumaları DAT1 sürülürken veri CRC'siyle düşüyor (0x0020/0x0060). Kartın bu izni bizden: F2 hazırlığında CCCR INT_ENABLE 0x03 → 0x07 yazılıyor, yani master+F1+F2 kesmeleri açık. Yoklamalı tasarımda DAT1'e ihtiyaç yok — R142'nin adayı bu.
Doğru çalışanlar
imaj 044266fbe0a4b9b616feca094abab47352bef9c6606e1a69a9e9a090dac5d765
kanıt evidence/rpi5/radio/attempt-r141-mailbox-answer-uart-capture/
Sorulan: Kartın DAT1 kesme hattını sürmesinin izni CCCR INT_ENABLE (F0 0x04) fonksiyon/master bitleri mi? Master biti temiz yazılırsa (0x03→0x02, 0x07→0x06) veri hattı CRC'leri biter mi?
Cevap: Yazma İNDİ (WIFIEN W1=Some(2) W2=Some(6) READBACK=Some(6)) ve koşu ilerledi (TRIALS_RUN=2), ama hipotez ELENDİ: kart DAT1'i yine sürdü (HOST_CARD_INT=true, SDHCI_INT_STATUS=0x101 bit 8) ve koşu yine F1 Read32 0x18004020 veri CRC'siyle kapandı (READ_FAILURES=5).
CCCR fonksiyon bitleri bu silikonda kapı değil
Master bit temizken de kart interrupt hattını sürüyor; SDHCI'nin card-interrupt durum biti (0x101) set kalıyor.
Tanık dinamik
Aynı koşuda HOST_CARD_INT önce false, sonra true okundu — latch'lenmiş bir kalıntı değil, kartın o an hattı sürdüğünü gösteriyor.
Kalan aday: SDIO çekirdeği host kesme maskesi
Bu sürücünün yazdığı tek diğer kesme etkinleştirmesi 0x18004024 (R121'den beri Linux'a benzemek için 0x200000f0). R143 tam onu sınadı.
Doğru çalışanlar
imaj 6de90c05876cf2fd28fa01781c53e96cecb2fde5392407cb10a31c7cee4edc11
kanıt evidence/rpi5/radio/attempt-r142-int-enable-off-uart-capture/
Sorulan: Kartın DAT1'i sürme izni SDIO çekirdeği host kesme maskesi mi? 0x18004024 ← 0x200000f0 yerine 0 yazılırsa hat susar ve F1 okumaları temiz kalır mı?
Cevap: Yazma İNDİ (hostintmask_written: Some(0)) ve koşu yine ilerledi (TRIALS_RUN=3), ama hipotez ELENDİ: maskeyle de kart DAT1'i sürüyor (HOST_CARD_INT=true ×4) ve koşu F1 Read32 0x18004020 veri CRC'siyle kapandı. Posta kutusu protokol fazında hâlâ 0x00040002, REPLIED=0.
Üç kesme-etkinleştirme hipotezi sırayla elendi
R141 posta cevabı (TRIALS_RUN=0), R142 CCCR master biti (2), R143 SDIO çekirdeği maskesi (3): hepsi indi, hiçbiri hattı kapatmadı, hepsi veri CRC'siyle bitti.
DAT1 tanığı dinamik — çakışma teşhisi ayakta
R142'de önce false sonra true okunması bitin latch olmadığını gösteriyor; dongle host cevap vermediği için hattı sürüyor ve 4-bit veri transferlerimizi aralıklı bozuyor.
Kurtarma yolu çalışıyor ama yoklamaya bağlı değil
WIFIREAD_RECOVERY PRIMARY_ERR=0x0020 → APPLIED=1 CLEARED=1 RECOVERY_OK=1 POST_READ_OK=1 POST_VALUE=Some(0): arıza temizlenebiliyor. R144 bu yolu yoklama döngüsüne bağlar; o zaman koşu protokol sorusuyla biter.
Doğru çalışanlar
imaj 79e05167ce0bf84fbc8d2fdaa2b207f1c08a9f6e6ecc31506be2b91127d2eb80
kanıt evidence/rpi5/radio/attempt-r143-hostintmask-off-uart-capture/
Sorulan: Yoklamadaki aralıklı veri CRC'si (R141–R143'ün üçünü de kapatan hata) turu düşürmesin: taşıma katmanının sınırlı kurtarmasından sonra okuma bir kez yinelenirse koşu protokol sorusuna ulaşır mı?
Cevap: ULAŞTI — bu hattın en ileri noktası. Protokol fazı İLK KEZ dongle'ın kesmelerini gördü (interrupt_status_or=0xc0, frame_ind_seen=1, host_int_seen=1, FRAME_IND=1 HOST_INT=1; R136–R143'te bu alan hep 0x00000000 idi) ve F2 çerçeve okumasını denedi. Yeni duvar F2 okuması: transfer zaman aşımı + veri CRC'si (error_status=0x20, transfer_complete=false, bytes_read=64).
Dongle'ın kesmesi ilk kez görüldü
WIFIFAIL interrupt_status_or=192 (0xc0) = I_HMB_HOST_INT | I_HMB_FRAME_IND ve FRAME_IND=1 HOST_INT=1: dongle veri göndermek istiyor. Bu alan R136–R143 boyunca hep sıfırdı.
F2 okuması denendi ve düştü
ReadFifo function=2 address=0x8000, 64 bayt: command_complete=true, buffer_ready=true, ama transfer_complete=false, bytes_read=64, error_status=0x20, timeout_transfer=true. Duvar artık F2 okuma yolu.
Yoklama hatası artık koşuyu düşürmüyor
WIFIPOLLRETRY RETRIES=0 RETRY_OK=0 RETRY_FAILED=0: bu koşuda R141–R143'ü kapatan hata hiç oluşmadı; koşu F2 okumasına kadar ilerledi.
Doğru çalışanlar
imaj 81323546eef41f6eff9437e597e5307dad8e8c547988675ef7941486dc09a2f3
kanıt evidence/rpi5/radio/attempt-r144-poll-retry-uart-capture-repeat-01/
Sorulan: R144'ün tek-yeniden-deneme kuralı F2 çerçeve okumalarına da uygulanırsa ilk kez dongle'dan gelen bir çerçeve okunur mu?
Cevap: KISMEN: taşıma artık koşuyu taşıyor (2. boot TRIALS_RUN=8/11, 9 kontrol çerçevesi) ama dongle denemeler boyunca hiç kesme kaldırmadı (CORE_OR=0x00000000, REPLIED=0) ve F2 okuma yoluna hiç çerçeve gelmedi. 1. boot ise F2 yoluna ulaşamadan yoklama okumasında düştü (RETRIES=1 RETRY_FAILED=1).
Taşıma katmanı artık taşıyor
8/11 deneme tamamlandı ve WIFIRECOVER dokuz kez FIFO_OK=1 döndü; R141–R143'te koşuyu kapatan hata artık ölçümü bloke etmiyor.
Dongle susuyor
Her denemede CORE_OR=0x00000000 ve posta kutusu 158 örnek boyunca 0x00040002 (DEVREADY): R140'ın 25 ms'de gördüğü FWREADY (0x00040008) kaybolmuş durumda, dongle bir daha sinyal vermiyor.
Boot'lar arası değişkenlik büyük
Aynı imajın 1. boot'u 1/11 denemede düştü, 2. boot'u 8/11'e çıktı; ölçüm için tek boot yeterli değil.
Doğru çalışanlar
imaj 167cb2334c20a188c9af717f19c96f3e3b5d235ad049dc7e48f2375f8d163739
kanıt evidence/rpi5/radio/attempt-r145-fifo-retry-uart-capture-repeat-01/
Sorulan: Dongle'ın kendi yayınladığı SDPCM paylaşım alanı (Linux'un brcmf_sdio_readshared yolu: RAM tepesi-4'teki işaretçi + yapının flags/trap/assert/konsol alanları) okunursa firmware'in durumu ne çıkar?
Cevap: Firmware CANLI ve SAĞLIKLI: paylaşım alanı yayınlanmış (PTR=0x00201cc0, PTR_PLAUSIBLE=1, STRUCT_OK=1), W0_FLAGS=0x00000001 (sürüm 1; ASSERT/TRAP/FAIL bitleri yok), konsol adresi W5_CONSOLE=0x0025debc, firmware kimliği W7/W10=0xb677b91b (FWID 01-b677b91b — bizim BRCMFW.BIN ile aynı). Chipid nöbetçisi okuma öncesi/sonrası 0x15264345: kararma yok.
Susma bir çökme değil
Flags alanında ASSERT/ASSERT_BUILT/TRAP/FAIL bitlerinin hiçbiri yok ve trap/assert alanları sıfır: firmware kendini sağlıklı bildiriyor. Paylaşım alanını yayınlaması, protokol katmanına geldiğini gösteriyor.
Firmware kimliği bizim dosyamızla aynı
W7 ve W10 = 0xb677b91b → FWID 01-b677b91b; BRCMFW.BIN'in kuyruğundaki kimlikle birebir. Yanlış blob kuşkusu da böylece kapandı.
Elimizde yeni bir kanal var: firmware konsolu
W5_CONSOLE=0x0025debc RAM aralığımızın içinde; firmware'in kendi log metni orada duruyor ve okunabilir. R147'nin tek işi bu.
Doğru çalışanlar
imaj 6b7e0c2116e8c6568b9f30b54f4451c125b58ca066141ec09bac8f2da0314b4e
kanıt evidence/rpi5/radio/attempt-r146-shared-witness-uart-capture/
Sorulan: R146'nın bulduğu konsol adresinden (0x0025debc) firmware'in kendi log metni okunabilir mi?
Cevap: OKUNDU. Yapı tutarlı: tampon 0x0025dab4, boy 0x400 (1024 — metnin '1024..' önekiyle birebir), yazma indeksi 0x177 (367 bayt). Metin firmware'in kendi damgalı log biçimini taşıyor ve ilk satırlar WLC başlatması: 'wl0: wlc_channels_commit: no valid channel for "#n" nbands 2 bandlocked 0', 'wl0: Broadcom BCM4345 80…'.
Konsol yapısı ölçüldü
W2=tampon, W3=boy, W4=yazma indeksi; metnin öneki '1024..' boyla birebir eşleşiyor. Ring tampon olduğu için satır sırası doğrusal değil.
Firmware WLAN yığınını kuruyor
'wl0:' satırları WLC attach ve kanal kararlarının çalıştığını gösteriyor; ilk 62 ms'de kanal uyarısı düşüyor.
239 bayt daha var
Bu koşuda ilk 128 bayt okundu; tamponda 367 bayt yazılı. R148 tam logu okuyacak.
Doğru çalışanlar
imaj 9a51d4a3b407a8272bc2a03a73218bf0f6c3fab871d00a6c28c4300ab7e0b147
kanıt evidence/rpi5/radio/attempt-r147-console-witness-uart-capture-repeat-01/
Sorulan: Tam konsol logu (1024 bayt) okunursa firmware çerçevelerimiz hakkında ne yazmış?
Cevap: NEDENİ YAZMIŞ: 'sdpcmd_dpc: Enable' (t=2.919 s) → 'sdpcmd_dpc: Disable' + 'sdpcmd_tx: device disabled' + 'sdpcmd_sendheader: tx submit failed!!' (t=6.022 s) → 'sdpcmd_dpc: Enable'. Yani kontrol çerçevemiz cihaz devre dışıyken gönderildi ve firmware onu düşürdü; cevap bu yüzden yok. Aynı logda 'wl0: wlc_stf_txcore_shmem_write: No clock' ve 'wlc_channels_commit: no valid channel for "#n"' satırları da var.
Dongle nedeni kendi yazdı
sdpcmd_sendheader: tx submit failed!! — çerçevemizin gönderimi tam o anda düştü. Bu, R136'dan beri aranan cevabın doğrudan kanıtı.
Firmware içinde saat yok
wl0: wlc_stf_txcore_shmem_write: No clock — PHY/TX çekirdeğine saat bulunamıyor. Linux bu yüzden CR4 bırakılışından hemen sonra CHIPCLKCSR'yi saveclk|FORCE_HT (0xd2) yapar; bizde 0xd0.
Kanal listesi boş
wlc_channels_commit: no valid channel for "#n" nbands 2 bandlocked 0 — regulatory/CLM yapılandırması boş; ayrıca 'Invalid antennas available in srom' ve 'TCAM: 256 used: 255' satırları var.
Doğru çalışanlar
imaj f5c772b4892b8da5060463a62786f0a1bcad397b7ecb552c22f95e602a108e69
kanıt evidence/rpi5/radio/attempt-r148-console-full-uart-capture/
Sorulan: Linux'un CR4 bırakılışından hemen sonra yazdığı FORCE_HT biti (CHIPCLKCSR 0xd2, bizde 0xd0) firmware'in R148'de kendi yazdığı 'No clock' şikâyetini giderir mi?
Cevap: HAYIR. Bit indi (BEFORE=0xd0 WROTE=0xd2 AFTER=0xd2, HT_CSR_FIN=0xd2) ve firmware bu boot'ta SDPCM veri yolunu kapatmadı (R148'in 'sdpcmd_dpc: Disable' + 'sdpcmd_sendheader: tx submit failed!!' satırları logda yok) — ama 'wl0: wlc_stf_txcore_shmem_write: No clock' satırı t=55 ms'de aynen duruyor: SDIO/backplane HT saatini zorlamak PHY/TX çekirdeğine saat vermiyor.
Bit indi, etkisi ölçüldü
WIFIFORCEHT BEFORE=0xd0 WROTE=0xd2 WRITE_OK=1 AFTER=0xd2 ve CR4START HT_CSR_FIN=0xd2. Yani Linux'un değeri artık bizde de yazılı.
Firmware'in saat şikâyeti sürüyor
Tam konsol logunda 'wl0: wlc_stf_txcore_shmem_write: No clock' (t=55 ms) değişmedi; buna karşılık bu boot'ta veri yolu kapanmadı (log 375 baytta 'sdpcmd_dpc: Enable' ile bitiyor).
Açıklama bizim dizimizde: D11 reset'te
CR4 başlatırken D11 (PHY/TX) çekirdeğini reset'te bırakıyoruz; R139'un Linux tel izinde D11 için hiç reset-ctl yazması yok, yalnız ioctl 0x07 var. Reset'teki çekirdeğin saati olmaz — R150'nin tek değişkeni bu.
Doğru çalışanlar
imaj 3e348bd06eaa86223c7df9470e531a45f1f803bb762c57b8d7705174cab46d27
kanıt evidence/rpi5/radio/attempt-r149-force-ht-uart-capture/
Sorulan: D11 (PHY/TX) çekirdeğinin reset'ini kaldırmak (Linux'ta D11 için reset-ctl yazması hiç yok) firmware'in 'No clock' şikâyetini giderir mi?
Cevap: GİDERDİ. WIFID11RELEASE RST_BEFORE=0x00000001 → RST_AFTER=0x00000000 RELEASED=1 ve tam konsol logunda 'wl0: wlc_stf_txcore_shmem_write: No clock' satırı artık YOK. Yani D11'i reset'te tutmak firmware'in çekirdek saatini gerçekten engelliyormuş. Kalan imza: ~2,97 s'de bir DPC kapanıyor ve çerçevemizin gönderimi düşüyor.
Firmware'in saat şikâyeti kapandı
R148 ve R149'da t=55 ms'de görünen 'No clock' satırı bu koşuda yok; D11 reset'inin kaldırılması firmware'in PHY/TX saatini bulmasını sağladı.
Yeni kalıp: veri yolu ~2,97 s'de bir kapanıyor
'sdpcmd_dpc: Disable' + 'sdpcmd_tx: device disabled' + 'sdpcmd_sendheader: tx submit failed!!' + 'sdpcmd_dpc: Enable' dört kez yinelendi (6.082, 9.048, 12.014, 14.979) ve TRIALS_RUN=4: çerçevemiz her seferinde kapalı pencerede gönderiliyor.
Zaman çizgileri hizalanmalı
Firmware logu kendi damgalarını taşıyor; host tarafı damgasız. R151 bu yüzden host tarafına monoton ms damgası ekler.
Doğru çalışanlar
imaj 7889fea1c1f8919182fcb96c0abbde04fdca7557ccfe10e391b65e8b406f541d
kanıt evidence/rpi5/radio/attempt-r150-d11-release-uart-capture/
Sorulan: Host olayları CR4 bırakılışına göre damgalanırsa firmware'in kendi damgalı Disable anlarıyla hizalanabilir mi?
Cevap: ALTYAPI KURULDU ama damgalar okunamadı: bütün T_MS alanları 0 çıktı, çünkü T0_MS=2018624513 ham sayacıydı (freq_cached() ilk çağrıda 0). Ölçüm bu yüzden hizalanamadı; R152 kaynağı düzeltti. Aynı koşuda 'No clock' satırı geri gelmişti ve 'tx submit failed' hiç yoktu.
Kaynak hatası makbuzda göründü
T0_MS ham sayac, sonraki çağrılar gerçek ms: saturating_sub her yerde 0 üretti. R152 host_now_ms()'i frekansı kendisi kaydettirecek şekilde düzeltti.
D11 etkisi kararsız
R150'de 'No clock' yoktu, R151'de geri geldi: D11 release'inin firmware'e saat vermesi boot'lar arasında değişiyor.
Veri yolu bu boot'ta kapanmadı
'tx submit failed' 0 kez; koşu yine Read32 0x18004020 ile kapandı (REPLIED=0).
Doğru çalışanlar
imaj b9b2560f26c6e1208b99a0de2f24c687822a5a2074ac0ef59d266fc2de7d2b27
kanıt evidence/rpi5/radio/attempt-r151-host-timeline-uart-capture/
Sorulan: ms kaynağı düzeltilince host zaman çizgisi firmware'in Disable damgalarıyla hizalanır mı?
Cevap: HİZALANDI ve tetikleyici ortaya çıktı: her 'Disable' + 'tx submit failed!!' olayı bizim bir kontrol çerçevesi gönderimimizden SABİT ~326 ms sonra geliyor (5752↔6095, 8736↔9062, 11703↔12029, 14669↔14996, 17636↔17963 ms). Yani dongle çerçevemizi alıyor, sonra cihaz devre dışı kalıyor ve gönderim düşüyor.
Tetikleyici bizim çerçevemiz
Sabit ~326 ms kayma, firmware saatimin bizim T0'ımıza göre kaymasıdır; her denemede bir Disable ve bir tx submit failed var — tesadüf değil, bizim gönderimimize bağlı.
Kalan çerçeve farkı ölçülü
R136 mühründe Linux'un ilk kontrol çerçevesi seq=0x02, bizimki 0xFF. R136 bunu kapanış notunda açık bırakmıştı; artık tek baytlık bir değişken olarak sınanabilir.
'No clock' bu boot'ta yok
R150 gibi; R151'de vardı. D11 release'inin firmware saatine etkisi boot'lar arasında değişken — kayda geçti.
Doğru çalışanlar
imaj 0d6349ce99ca3f35fb0ecbae3c774fb5aa7f0f88107cc07194e3e5ec42b4d7df
kanıt evidence/rpi5/radio/attempt-r152-timeline-fix-uart-capture/
Sorulan: İlk kontrol çerçevesinin SDPCM seq baytı 0xFF yerine Linux'un ölçülmüş değerine (küçük/artan; mühürlü decode'da 0x02) çevrilirse firmware'in 'tx submit failed' deseni kaybolur ve cevap gelir mi?
Cevap: HAYIR — hipotez elendi. seq=0 hatta çıktı (TRIAL=0 SEQ=0, TRIAL=1 SEQ=1) ama firmware yine veri yolunu kapatıp gönderimi düşürdü (t=6.106 s'de bir kez daha Disable + tx submit failed!!) ve REPLIED=0 kaldı; TRIALS_RUN=1/11.
Seq baytı tetikleyici değil
R136'dan beri kalan tek ölçülü çerçeve farkı buydu; değiştirildi ve desen sürdü. Böylece çerçevenin bu alanı da elendi.
Kalan aday kredi/pencere
Çerçevemiz TXWIN=21 ile gidiyor; bu bizim başlangıç varsayımımız ve dongle'ın kendi ilan ettiği pencereyi hiç görmedik. Linux'ta bus->tx_max dongle'ın çerçevelerinden öğrenilir.
'No clock' kararsızlığı dört koşuda iki-iki
R150 ve R152'de yok, R151 ve R153'te var. D11 release'inin firmware saatine etkisi boot'a bağlı; kayda geçti ve tek başına değişken yapılmadı.
Doğru çalışanlar
imaj c8a51ce7203b897e56b92e3b7ee0ddd04926da7e188152fcbd2ef83c7ee80b74
kanıt evidence/rpi5/radio/attempt-r153-seq-zero-uart-capture-repeat-01/
Sorulan: Oturumun ilk kontrol çerçevesi Linux'un ölçülmüş preinit çerçevesiyle (SET cur_etheraddr, cmd=263, id=4, len=20) değiştirilirse firmware'in veri yolunu kapatıp gönderimi düşürmesi durur ve cevap gelir mi?
Cevap: Desen DURDU, cevap gelmedi. WIFIPREINIT USED=1 (cmd=263, id=4, SET, 20 bayt) ve konsolda hiç 'Disable' / 'device disabled' / 'tx submit failed!!' satırı yok (R152'de 5, R153'te 1 kez vardı) — ilk olumlu sinyal. Ama REPLIED=0 ve koşu 1. denemede taşıma hatasıyla kapandı; karar için tekrar boot gerekir.
Ölçülen preinit çerçevesi hatta çıktı
WIFITRIAL_RESULT TRIAL=0 REQ_ID=4 CMD=263 FRAMELEN=56 BCDCLEN=20 SEQ=0 — Linux'un mühürlü preinit çerçevesi tel biçimi (R136 glom, dat_offset=20) korunarak gönderildi.
Veri yolu bu boot'ta kapanmadı
Konsolda Disable/tx-submit-failed yok. Bu, R152'de ölçülen 'bizim çerçevemiz veri yolunu kapatıyor' deseninin içerikle ilişkili olduğunu destekliyor.
Tek boot karar için yetmez
Koşu 1. denemede aralıklı Read32 hatasıyla kapandı ve 'No clock' yine var; imajın 2. ve 3. boot'u kuralla bekleniyor.
Doğru çalışanlar
imaj 0d930016cab64c745088291621e130fccd82665f6ca9c4915eeff9b78df98024
kanıt evidence/rpi5/radio/attempt-r154-preinit-first-uart-capture/ · attempt-r154-preinit-first-uart-capture-repeat-01/
Sorulan: Okuma-hatası kurtarmalarına (WIFIREAD_RECOVERY, SDHCI hat sıfırlaması içerir) zaman damgası eklenirse dongle'ın Disable'ını çerçeve mi yoksa kendi hat sıfırlamamız mı tetikliyor, ayırt edilebilir mi?
Cevap: Altyapı kuruldu (T_MS damgaları var) ama bu boot'ta Disable hiç olmadı: 'Disable' ve 'tx submit failed' 0, 'No clock' yok, TRIALS_RUN=4/11 ve REPLIED=0. İki kurtarma da CR4 bırakılışının hemen ardında (T_MS=1 ve 0) oluştu; deneme sırasında hiç kurtarma yok — yani soru bu boot'ta sınanamadı.
Damga çalışıyor
WIFIREAD_RECOVERY artık T_MS taşıyor; zaman çizgisi yardımcıları tüm imajlarda derleniyor, sıfır noktası yalnız ilgili özellik açıkken işaretleniyor.
Desen varyansı netleşti
Son beş koşuda Disable sayısı 5/1/0/1/0; 'No clock' varlığı bağımsız değişiyor (R152 ve R155'te yok, R153/R154'te var). İkisi arasında bağ görünmüyor.
Ortak gözlem: cevap yok
Her denemede CORE_OR=0x00000000 ve REPLIED=0 — dongle kontrol çerçevemize karşılık üretmiyor ya da ürettiğini göremiyoruz. Sıradaki adım: Disable'ın görüldüğü boot'larda kurtarma damgalarını hizalamak.
Doğru çalışanlar
imaj 4f7b59a7b91eae4b7d4a14e75c91c23e3fc52c3e79f9985473c26463aa8a7abe
kanıt evidence/rpi5/radio/attempt-r155-recovery-timeline-uart-capture/
Sorulan: Aynı R155 imajının tekrar boot'unda kurtarma T_MS'leri firmware'in Disable damgalarıyla hizalanırsa deseni çerçeve mi yoksa kendi hat sıfırlamamız mı tetikliyor, kesinleşir mi?
Cevap: Kesinleşti: deseni ÇERÇEVEMİZ tetikliyor. Kurtarmalar T_MS=0/1 (CR4 bırakılışının hemen ardı), çerçevemiz T_MS=5907 ve 'Disable' + 'tx submit failed!!' 6.239 s (≈ bizim 5913 ms'imiz) — yani olay çerçeveden ~6 ms sonra; kurtarma yolu olaydan ~5,9 s önce.
Kurtarma yolu elendi
SDHCI hat sıfırlaması içeren iki kurtarma da CR4 bırakılışının hemen ardında; Disable ile hiç çakışmıyor.
Tetikleyici çerçevenin kendisi
Disable, çerçevemizden ~6 ms sonra (bizim saatimizde) geliyor; bu, R152'de ölçülen sabit kaymayı koruyor ve içerik/seq denemelerinin (R153/R154) neden bir şeyi değiştirmediğini açıklıyor.
Yeni kanıt: glom pazarlığı
Linux'un preinit sırası glomsuz çerçevelerle başlıyor ve glom ikinci çerçevede (bus:rxglom=1) pazarlık ediliyor; bizim ilk çerçevemiz ise glomlu. R157 ölçülen sırayı ve her çerçevenin kendi ölçülen biçimini uygular.
Doğru çalışanlar
imaj 4f7b59a7b91eae4b7d4a14e75c91c23e3fc52c3e79f9985473c26463aa8a7abe
kanıt evidence/rpi5/radio/attempt-r155-recovery-timeline-uart-capture-repeat-01/
Sorulan: Oturumun ilk üç kontrol çerçevesi Linux'un ölçülmüş preinit sırası olursa (iki glomsuz çerçeveyle glom pazarlığı, sonra glomlu cur_etheraddr) dongle veri yolunu kapatmayı bırakır ve cevap gelir mi?
Cevap: Bu boot'ta sınanamadı: WIFIPREINITSEQ SENT=0 — çağrı "istek gönder" dalının içindeydi ve koşu ondan önce F2 yazma hatasıyla (WriteFifo, F2 0x8000, T_MS=3351) kapandı. Çağrı yoklamanın öncesine taşındı, imaj yeniden üretildi; tekrar boot bekliyor.
İlk RX başarısı
WIFIFAIL frames_received=2, frame_ind_seen=1, host_int_seen=1, fifo_reads=3 ve CORE_OR=0x000000c0: dongle host kesmesini kaldırdı ve iki çerçeve aldık — bu hatta ilk kez. Koşu F2 yazma hatasıyla erken kapandı.
Çağrı yeri düzeltildi
Preinit sırası artık taşıma hazır olur olmaz, yoklamanın ve F2 okuma yolunun öncesinde gönderiliyor (Linux'un gönderdiği yer).
Desen bu boot'ta yok
Konsolda Disable ve tx submit failed yok; No clock var. Erken kapanma yüzünden yorum yapılmıyor.
Doğru çalışanlar
imaj fccf3ee52e94038d6f521cbf9880f8e3e91425f2c5b0bba9c9f6795f751b408d (düzeltilmiş: 3b3f3a5ae2fa736ccc79f0c03527a447653580cc1d37eaf44820d2e0e2519af0)
kanıt evidence/rpi5/radio/attempt-r157-glom-negotiation-uart-capture/
'Özellik yok, risk de yok' satırları için: Bu bir güvenlik başarısı değildir. Bluetooth tarama/eşleşme yolu artık gerçek radyo verisi işlediği için onun saldırı yüzeyi açıkça kabul edilmiş risk olarak gösterilir; Wi-Fi veya kalıcı anahtar deposu gibi hâlâ eksik yetenekler ayrı tutulur. Gerçek güvenlik iddiası adversarial radyo ve parser testleriyle ayrıca kanıtlanmalıdır.
Tarama kapısı R211 ile geçti. R212 (planlı, tarama sonrası): R211 ham UART tekrarını mühürle; 16 kayıt sınırını ve sabit NVRAM MAC kimliğini ayrı ayrı doğrula. Bu adım mevcut R211 escan PASS'ını geri almaz; WPA/association ve Bluetooth ayrı kapılardır. bir tarama onarımı değil, kapsam ve kanıt kalitesi planıdır: R211 UART akışını bağımsız mühürle tekrar etmek, 16 kayıt sınırını ayrı test etmek ve sabit NVRAM MAC'in kart-özel kimlikle ilişkisini doğrulamak. WPA/association/ping ve Bluetooth keşfi ayrı iş paketleridir; hiçbiri R211 PASS'ından çıkarılamaz.