Wi-Fi ve Bluetooth

Sorduğu soru

Adres doğru mu?

Yaptığı

DTB'den türetilen sayfayı haritalar ve SDHCI denetleyicisinin kayıtlarını okur.

Reddettiği

Tek bir yazma yok, komut indeksi yok.

Kaynak / kanıt

kernel/src/driver/rpi5_sdio_wifi.rs
rpi5_radio_source

Cihazda ne oldu

R1: denetleyici sağlıklı okundu — VER=0x1002, CAPS=0x55eec832/0x8000a527, ölü pencere yok.

Sorduğu soru

Çip orada mı ve konuşuyor mu?

Yaptığı

Yazılım sıfırlaması, 3,3 V güç, ~400 kHz saat, CMD0 ve CMD5. CMD5'in cevabı çalışma gerilimi penceresini ve I/O fonksiyon sayısını taşır.

Reddettiği

Firmware yok, genişletilmiş I/O komutu yok, ağ adı yok.

Kaynak / kanıt

rpi5_sdio_wifi.rs · bring_up()
rpi5_radio_source · only_the_two_radio_buses_may_write…

Cihazda ne oldu

R1: CMD0 ve CMD5 tamamlandı ama cevap tamamen sıfırdı — OCR=0, FUNCS=0, READY=0. PSTATE=0x000f0000 sebebi verdi: kart takılı görünüyor ama DAT[3:0] ve CMD hatlarının hepsi düşük. Çip beslenmiyordu. Eksik olan WIFI-A2b idi. R2: güç verildikten sonra da OCR=0 ve READY=0. Sıradaki şüpheli pin mux.

Sorduğu soru

Pedler çevre birimlerine bağlanabilir mi?

Yaptığı

On pinin mux alanını yazar. Bu kart D0 (R14): gpio24–27 uart0'a fsel 4, gpio30–35 sd2'ye fsel 1 (PIN_PLAN_D0). C0 tablosundaki 3,4,4,4 / 4,4,4,3,4,3 değerleri bu silikonda kullanılmaz. Kelime 2'de ON nibble'ları (28/29) maskelenmez; kelime 4'e (D0 pad kaydı) yazılmaz. Her pin tek tek geri okunur.

Reddettiği

Yalnızca bu on pin. Boot SPI (1–4), PCIe I2C (14,15), güç düğmesi (20) ve ON hatları (28,29) asla yazılmaz. Referans pinler gpio okumazsa HİÇBİR ŞEY yazılmaz: yanlış yerleşimle yazmak hedef almadığımız pedleri başka çevre birimlerine bağlar.

Kaynak / kanıt

kernel/src/driver/rpi5_pinctrl.rs · apply_radio_mux_d0()
rpi5_radio_source · the_mux_write_touches_only_the_two_radio_pin_groups

Cihazda ne oldu

R14 silikonu D0 ölçtü; R4–R13 C0 tablosuyla yanlış kelimelere yazıyordu (R4: VERIFIED=8/10, CLK/CMD reddi; R7: RETRIED=2 OK=0; R7-staged: S1_HELD=0; R8: P30_HELD=0). R15 doğru tabloyla VERIFIED=10/10, ON_INTACT=1, W4_UNTOUCHED=1. C0 koşularındaki sayılar geçerli, pin adları değil.

Sorduğu soru

Wi-Fi yuvası besleniyor mu?

Yaptığı

brcmstb GPIO bankasının 28. hattını (WL_ON) çıkış yapıp yükseğe sürer, sonra DTB'nin kendi startup-delay-us değeri olan 150 ms beklenir. Makbuz kaç bitin değiştiğini ve BT_ON'a dokunulup dokunulmadığını ayrı bildirir.

Reddettiği

BT_ON'a asla dokunmaz. DATA tekdüze okunursa yazmayı reddeder.

Kaynak / kanıt

rpi5_sdio_wifi.rs · power_on()
rpi5_radio_source · the_wifi_chip_is_powered_before_it_is_asked_anything

Cihazda ne oldu

R2: çalıştı. ASSERTED=1, tam olarak bizim bitimiz uygulandı, BT_ON'a dokunulmadı. PSTATE'in DAT hatları 0000'dan 0110'a çıktı — WL_ON gerçekten besliyor.

Sorduğu soru

Pedler gerçekten çevre birimlerine bağlı mı?

Yaptığı

pinctrl@7d504100 bloğunu okur. D0 overlay bu blogu 0x20 bayta (sekiz kelime) indirir; C0 DTB 0x30 / on iki kelimedir. gpio24–27 (UART), gpio28/29 (ON hatları), gpio30–35 (SDIO) ham seçicileri radio_pins_d0 ile çözülür ve makbuz MAP=D0 basar. Grupların kendi içinde tutarlı olup olmadığını da söyler.

Reddettiği

Tek bir yazma yok — bir pin muxunu değiştirmek hata ayıklama UART'ini ya da boot SPI'yi koparabilir. Fonksiyon ADI da vermez: seçici kodlaması bilinmiyor ve 'bu 5 sd2 demek' yazmak ölçümü tahmine çevirirdi.

Kaynak / kanıt

kernel/src/driver/rpi5_pinctrl.rs
rpi5_radio_source · the_pin_mux_is_read_and_never_written

Cihazda ne oldu

R3: pencere canlı, sıfır yazma. gpio24–27 ve gpio30/31 fsel=0 (gpio) okudu — DTB uart0 ve sd2 istiyor. Sessizliğin sebebi bulundu. R3 C0 kelime haritasıyla etiketledi; R15 aynı kusuru yazma yolunda kapattı, envanter radio_pins_d0 + MAP=D0 ile taşındı.

Sorduğu soru

Çipin iç veri yoluna ulaşabiliyor muyuz? Firmware oraya yazılır.

Yaptığı

CMD3 (göreli adres) → CMD7 (seç) → CMD52 ile CCCR → fonksiyon 1'i etkinleştir ve HAZIR demesini bekle → 4 bit veri yolu → pencereyi ChipCommon'a (0x1800_0000) kaydır ve geri oku → chipid'i dört CMD52 ile topla.

Reddettiği

Yalnızca CMD52. CMD53 yok — chipid okumak onu gerektirmiyor.

Kaynak / kanıt

rpi5_sdio_wifi.rs · enumerate()
rpi5_radio_source · a_dead_backplane_can_never_be_reported_as_a_chip

Cihazda ne oldu

R31 itibarıyla geçti: CMD3/CMD7, CCCR, FN1 enable ve backplane penceresi çalışıyor; WIFIBP CHIPID=0x15264345, ID=0x4345 = BCM43455. R31 aynı kimliği CMD53 kapısında da MATCH52=1 ile doğruladı. Bu yalnızca firmware indirmenin ön koşuludur; tarama/SSID yok.

Sorduğu soru

Firmware pratik hızda TCM'e yazılabilir mi ve çipin ARM çekirdeği başlatılabilir mi?

Yaptığı

CMD53 okuma kapısını sınar, TCM'e yazma yollarını ayırır, firmware dosyasını microSD'den okur, cmd52 ile TCM staging yapar ve saat/bekleme darboğazını ölçer.

Reddettiği

Firmware+NVRAM TCM'e yüklenmiş olsa da bunu 'çalışan Wi-Fi' saymaz. Yeni FGC/saat/rstvec/D11 varyantı, CLM aktarımı, SDPCM/BCDC, tarama ve SSID yok. CMD53 blok yazma TCM'de kanıtlı düşüyor; firmware staging cmd52 + verify yolundadır.

Kaynak / kanıt

rpi5_sdio_wifi.rs · cmd53_read/write, stage_to_tcm(), clock_speed_probe()
rpi5_radio_source · cmd52_staging_writes_only_tcm_and_verifies_readback

Cihazda ne oldu

R31: CMD53 okuma Gate1 geçti. R40/R41: TCM cmd52 ile okunuyor/yazılıyor, CMD53 TCM'de 0x0060 ile düşüyor. R42/R43: toplu cmd52 yazma ve karttan BRCMFW.BIN okuma geçti. R48: 64 KB doğrulandı ama tam indirme yavaştı. R53: saat-süpürme — yavaş saat yardımcı değil, süre timeout-spin kaynaklı. R54: issue() bekleme sınırı faza göre 2K'ya çekildi (/256 gate1/erom'da 50K korunur), /16'da 4976→109 ms/sektör (~45×). R55 PASS: 609 KB firmware TAM ve DOĞRULANMIŞ indirildi (OK=1, ~2–3 dk). R56/R57: firmware şanssız /16 boot'larında abort — kök neden retry değil, doğrulamanın R5-temiz beklemesi. R58 PASS ×2: DATA-tabanlı doğrulama (completion/R5 yoksay, gerçek veri oku) ile gürültülü boot'ta bile firmware OK=1 (RETRIES=0) VE NVRAM ilk kez yüklendi (OK=1, FW_INTACT=1). R58'den R93'e firmware+NVRAM 30 mühürlü koşuda PASS oldu. R59–R93 (30 deneme): CR4 çekirdeğini başlatmak hâlâ AÇIK. Çekirdek release dizisinin denenen hiçbir varyantında (saat temizle/tut, FGC var/yok, PMU reload, KSO, CARDCTRL, wrapper 4-bayt bayrağı) host-görünür yürütme sinyali üretmiyor — doğru always-on gösterge (SDIO çekirdeği 0x18004000 mailbox/intstatus + PMU) ile ölçüldü: MBOX=0, INTSTAT=0, RES_PEND=0, HAVEHT=0. Yanlış çıkan iki yorum düzeltildi (EXT_LPO_AVAIL=0 normaldir; FGC belirleyici değil). Kaynak-teyitli elemeler: rstvec→backplane-adres-0 CR4 için DOĞRU (R74), D11-disable uygulandı ama yürütme gelmedi (R74). R75 Linux kontrolünden sonra çalışma R76–R93 ile sürdü ve ilk anlamlı fark küçük-CMD53 yazma transportuna daraldı (henüz hipotez, cihazda sınanmadı). Kalan olasılık uzayının tamamı bu sayfada tek tek listelidir. SDPCM/escan bu duvarın ötesinde.

Sorduğu soru

Ortamdaki ağlar listelenebilir mi?

Yaptığı

Henüz hiçbir şey. Bu, brcmfmac'in yaptığı işin yeniden yazılmasıdır.

Reddettiği

Ekranda ağ listesi YOK; uydurma SSID çekirdekte hiç geçmiyor.

Kaynak / kanıt

—
—

Sorduğu soru

Bir ağa katılınabilir mi?

Yaptığı

Henüz hiçbir şey. PBKDF2-SHA1, HMAC-SHA1 PRF, 4-yollu el sıkışma, CCMP/AES gerekir.

Reddettiği

Arayüzde 'Bağlan' YOK. Kayıtlı ağ deposunda parola alanı bile yok.

Kaynak / kanıt

—
—

Sorduğu soru

UART adresi doğru mu?

Yaptığı

UARTA sayfasını haritalar ve sekiz kelime okur.

Reddettiği

HCI yok, yazma yok, shutdown GPIO'ya dokunulmuyor.

Kaynak / kanıt

kernel/src/driver/rpi5_bt_uart.rs
rpi5_radio_source

Cihazda ne oldu

R1: UART penceresi canlı — DEAD_WINDOW=0, LSR=0x60 (THR boş + verici boş).

Sorduğu soru

Denetleyici orada mı ve HCI konuşuyor mu?

Yaptığı

BT_ON hattını sürer (GPIO bank 0 bit 29), UARTA'yı 115200 8N1 programlar, tek bir HCI Reset (0x0C03) gönderir ve Command Complete olayını çözer.

Reddettiği

.hcd yaması yok, 3 Mbit/s'e geçilmiyor, Inquiry ve LE tarama gönderilmiyor, cihaz listesi yok.

Kaynak / kanıt

rpi5_bt_uart.rs · bring_up()
rpi5_radio_source · the_bt_on_line_is_one_named_bit…

Cihazda ne oldu

R1: BT_ON sürülemedi ve suç bizimdi. Canlılık kapısı IODIR=0xffffffff okuyup pencereyi ölü saydı; oysa IODIR bir YÖN kaydıdır ve hepsi bir olması 'hepsi giriş' demektir. Çip beslenmediği için HCI Reset gönderilmedi (TX=0, ANSWERED=0). Kapı düzeltildi. R2: BT_ON sürüldü, UART programlandı ve dört bayt gerçekten gönderildi (TX=4), ama 500 ms boyunca tek bayt dönmedi. R15–R93: pinler doğru D0 kelimede. BT bring-up her radyo boot'unda koşuyor (main.rs:3111, koşulsuz); R93 makbuzu dahil aynı sonuç: APPLIED=1, DIV=52, LSR=0x60, TX=4, RXTO=1, ANSWERED=0 — Bluetooth cevap vermedi. R75 Linux kontrolü aynı çipi BCM4345C0 diye tanıdı ve brcm/BCM4345C0.raspberrypi,5-model-b.hcd yamasını yükledi; bu yama dosyası AselsanOS'ta YOKTUR ve depoda pinli değildir — cevapsızlığın en güçlü adayı budur.

Sorduğu soru

—

Yaptığı

RP1 GEM yalnızca adlandırıldı. CPU adresi BAR'a bağlı olduğu için sabit değildir ve haritalanmaz.

Reddettiği

MMIO yok, MAC yok, PHY yok, paket yok.

Kaynak / kanıt

kernel/src/driver/rpi5_eth.rs
rpi5_radio_source

CR4 TCM boyutu çipten ölçülüyor

Değişen tek şey: 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

Staging optimizasyonu cr4_start'tan önce geri alınır

Değişen tek şey: 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=

Tanık nöbetçisi: TCM okuması döngüden sonraya alınır

Değişen tek şey: 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

Çekirdek bırakıldıktan sonra HT istenir

Değişen tek şey: 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

HT isteği öncesi ve sonrası PMU kaynakları okunur

Değişen tek şey: 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

SDHCI clock register genişliği düzeltilir

Değişen tek şey: 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

İlk D11 wrapper yazması issue ediliyor mu?

Değişen tek şey: 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

Host DATA kurtarma + wrapper + HT sonrası runtime sınırı

Değişen tek şey: 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

CMD53 sonucu kendi işlemiyle sahiplenilir

Değişen tek şey: 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))

Boş Event/Data zarfları tanılanır

Değişen tek şey: 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

BCDC GET_VAR çerçeve uzunluğu düzeltilir

Değişen tek şey: İ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

RX başlığı doğrulanır, INTSTATUS Read32 sınırı ayrılır

Değişen tek şey: 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

R107 fiziksel açılışı ve Read32 sınırı

Değişen tek şey: 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

UART ön-arm ile INTSTATUS CMD53 Read32 sahipliği ayrıştırılır

Değişen tek şey: 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

Read32 data-CRC/end-bit sonucu ayrıştırılır

Değişen tek şey: 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

D11 başlangıç yazmasının transport sahipliği

Değişen tek şey: 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

D11 retry sonrası SDPCM kontrol timeout'u

Değişen tek şey: 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

SDPCM FIFO drain sıralaması

Değişen tek şey: İ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

D11 CRC/timeout retry kapısı ve ilk BCDC sınırı

Değişen tek şey: 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

İlk BCDC control-response receive/interrupt sahipliği

Değişen tek şey: 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

F1 Read32 fallback sonrası host-data idle kapısı

Değişen tek şey: 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

Tek exact runtime SDHCI DATA recovery

Değişen tek şey: 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

Arıza anında salt-okuma matrisi

Değişen tek şey: 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

Bayraklı/bayraksız backplane okuma karşılaştırması

Değişen tek şey: 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

Sahiplenilmiş DATA reset kapısı veri-hatası sınıfının tamamına açılır

Değişen tek şey: 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

Bluetooth bring-up izolasyonu

Değişen tek şey: 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

F2 watermark 0x60 → 0x08

Değişen tek şey: 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ı

SDIO taşıma sayımı

Değişen tek şey: 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

CCCR INT_ENABLE 0x03 → 0x07

Değişen tek şey: 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

CCCR INT_ENABLE, R124 imajı tekrar

Değişen tek şey: 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

fn1 WAKEUPCTRL = 0x02 — icra edildi ve ELENDİ

Değişen tek şey: 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)

Tek boot, on iki deneme — motor çalıştı, iki denemede durdu

Değişen tek şey: 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)

Sıralanmış matris — R127'nin adayı ÇÜRÜDÜ

Değişen tek şey: 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)

Denemeler arası kurtarma — tek değişken

Değişen tek şey: 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

Fonksiyon-2 IO_ABORT — ikinci yazmadan hemen önce

Değişen tek şey: 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

Fonksiyon-2 kapat/aç — hazır bitleriyle doğrulanan yaşam döngüsü

Değişen tek şey: 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

F2 yaşam döngüsü sonrası HOST_INT örnekle/ack — ikinci yazmadan hemen önce

Değişen tek şey: 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

Fonksiyon-2 block-size 512 re-assert — geri okumayla

Değişen tek şey: 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

İkinci F2 yazması öncesi host-only SDHCI DATA reset

Değişen tek şey: 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

İkinci F2 yazması 64 bayt byte-mode — ELENDİ

Değişen tek şey: 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)

SDPCM glom biçimi — SDIO duvarı KIRILDI, cevap yok

Değişen tek şey: 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)

Mailbox el sıkışması tanığı — taşıma sağlam, FWREADY YOK

Değişen tek şey: 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)

Hostmail el sıkışması — ELENDİ: dongle yine hazır olmadı

Değişen tek şey: 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)

Reset vektörü Linux taşımasıyla — TAŞIMA KAPANDI, yürütme yok

Değişen tek şey: 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)

"Host hazır" yazmasının yeri — DUVAR KIRILDI: dongle 30 ms'de FWREADY dedi

Değişen tek şey: 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)

Posta cevabı indi ve el sıkışma oturdu — ama duvar artık DAT1 hattı

Değişen tek şey: 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)

CCCR master biti temiz — kart DAT1'i yine sürdü (hipotez elendi)

Değişen tek şey: 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)

Host kesme maskesi de kapı değil — DAT1 dinamik, koşu 3 denemeye ilerledi

Değişen tek şey: 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)

Yoklama hatasına tek yeniden deneme — dongle'ın kesmesi İLK KEZ görüldü

Değişen tek şey: 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)

Aynı kural F2 okumasına — taşıma 8 denemeye çıktı, dongle sustu

Değişen tek şey: 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)

Dongle kendi beyanını verdi: firmware canlı, sağlıklı, konsolu yayında

Değişen tek şey: 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)

Konsol okundu: firmware WLAN yığınını kuruyor (salt-okunur)

Değişen tek şey: 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)

Tam log: 'sdpcmd_sendheader: tx submit failed!!' — neden yazılı

Değişen tek şey: 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)

FORCE_HT indi ama firmware'in 'No clock'u sürüyor

Değişen tek şey: 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)

D11 reset'i kaldırıldı — firmware'in 'No clock'u KAYBOLDU

Değişen tek şey: 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)

Host zaman çizgisi kuruldu ama damgalar 0 (kaynak hatası)

Değişen tek şey: Ö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)

Zaman çizgileri hizalandı — Disable'ı BİZİM çerçevemiz tetikliyor

Değişen tek şey: Ö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)

Seq baytı Linux'un değerine çevrildi — desen sürdü (hipotez elendi)

Değişen tek şey: 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)

Ölçülen preinit çerçevesi: 'tx submit failed' deseni KAYBOLDU (karar için tekrar boot)

Değişen tek şey: 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)

Kurtarma damgaları kuruldu; bu boot'ta Disable hiç olmadı

Değişen tek şey: Ö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)

Hizalama kapandı: Disable'ı ÇERÇEVEMİZ tetikliyor; glom pazarlığı yapılmamış

Değişen tek şey: 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)

Düzeltilmiş glom pazarlığı: preinit sırası yoklamanın öncesinde (temiz güç döngüsü bekliyor)

Değişen tek şey: 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)

"Önce boşalt, sonra yaz" indi: F2 kapısına rağmen ilk yazma yine düştü

Değişen tek şey: 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)

64 baytlık yazma birimi de duvarı açmadı; işaret denetleyici durumuna kaydı

Değişen tek şey: 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)

Duvar bizim kabul kuralımızdı: ölçülen preinit sırası ilk kez tamamen çıktı

Değişen tek şey: 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)

Yol açıldı: 3 deneme koştu; firmware her çerçevemizi `device disabled` ile reddediyor

Değişen tek şey: 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)

Kimlik devam ettirildi (id 5→14, tekrar yok); süpürme 9/11'e ilerledi, duvar aynı

Değişen tek şey: 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)

Duvar toggle'dı: dongle artık SDPCM TX'ini kapatmıyor; kalan duvar F1 okuması

Değişen tek şey: 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)

Netboot hattı çalıştı: payload ağdan indi, radyo zinciri SD ile aynı noktaya geldi

Değişen tek şey: 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)

Radyo hattı: F1 okuma yolu (INTSTATUS okuması kart meşgulken düşüyor)

Değişen tek şey: Planlı tek değişken (radyo): SDIO çekirdeği INTSTATUS okuması (F1 CMD53, 0x18004020) için sınırlı okuma kurtarması — R144/R145'in F2 FIFO'suna uyguladığı kuralın aynısı (taşıma katmanının zaten yaptığı sınırlı kurtarmadan sonra BİR yineleme; ikinci hata fatal; sayaçlar makbuza). Çerçeve baytları, geometri, kabul kuralı ve kimlik devamlılığı değişmez.

Neden bu sırada: R163 koşusu burada kapandı: `WIFIREAD OP=Read32 FN=1 ADDR=0x18004020 REASON=Transfer PRESENT_STATE=0x01ff0206` (DAT_INHIBIT|DAT_LINE_ACTIVE) ve `WIFITRIALEND TRIALS_RUN=1/11`. Okuma kurtarması bugüne kadar yalnız F2 FIFO'suna uygulandı (`WIFIFIFORETRY`); INTSTATUS okumasına hiç uygulanmadı. R164 altyapı işi (netboot payload) bu basamağı geciktirdi, değiştirmedi.

Planlı — R164 koşusundan ölçülen taban: `WIFITRIAL_RESULT TRIAL=1 … ERR=Session(CommandDeadline(Mac)) T_MS=9008` (ve R163'te `WIFIREAD OP=Read32 FN=1 ADDR=0x18004020 PRESENT_STATE=0x01ff0206`). Beklenen: yeni makbuz `WIFIINTREADRETRY`/zaman bütçesi; süpürme TRIALS_RUN>1'e ilerler ya da yeni hata adı tek değişkeni belirler.

Planlı — R164 koşusundan sonra imaj üretilecek

Bluetooth patchram (.hcd) hattı

Değişen tek şey: 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=

CR4 TCM'i (0x0025FFFC) okumak SDIO bağlantısını düşürüyor

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.

cr4_start'tan sonra SD hattı ÖLÜ — R70'ten beri bütün tanıklar ölü hatta okundu

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.

CR4 RAM'inin tepesi 160 KiB yanlış: TCM_RAMSIZE tahmin, ölçüm değil

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ı.

ramsize silikondan hiç okunmuyor: ARMCR4 CAP + 8× BANKIDX/BANKINFO taraması yok

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.

Yürütme tanığı yanlış adresten okunuyor: 0x237FFC yerine 0x25FFFC

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.

CR4 bırakıldıktan sonra HT hiç istenmiyor; üstelik FORCE_ALP tutuluyor

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.

Wrapper yazması: 4-bayt bayrağı set ama taşıma 4 ayrı 1-baytlık CMD52

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.

TCM'e yazılan her kelime 4B bayrağı OLMADAN gidiyor; Linux blok-kipi bayraklı CMD53 kullanıyor

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.

Tek oracle'ımız Linux'un hiç kullanmadığı göstergedir

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.

tosbmailboxdata + F2 enable 'post-MBOX' değil — firmware-hazırdan ÖNCE gelir

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.

PMU RES_RELOAD 'elendi' değil — üç koşunun ÜÇÜNDE de cihazda hiç latch etmedi

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.

halt_cr4 / CR4 set_passive, düşen CMD53 yazmaları yüzünden dışarıda bırakıldı

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.

NVRAM biçim adayı kendi aynasına karşı kapatıldı, Linux'a karşı değil

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.

Staging için daraltılan komut-bekleme bütçesi ve /16 saati hiç geri alınmıyor

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.

PMU serbest-koşan zamanlayıcısı 13 mühürlü koşuda hiç ilerlemedi

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.

FWSTAGE yazma sayacı ile doğrulama sayacı 28 koşuda tutmuyor

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.

cmd52 okuma yolu tamamlanma durumunu tamamen yok sayıyor

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.

Linux kartı 1,8 V UHS-I DDR50'ye alıyor; AselsanOS 3,3 V'ta kalı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.

Düşen bir CMD53 anındaki host register durumu hiçbir makbuzda yok

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.

Bluetooth ayrı bir hat: .hcd patchram deposunda yok

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.

0x0060 bir DATA CRC değil, 'veri fazı hiç olmadı' imzası

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).

rstvec'in backplane adres 0'a 4-bayt bayrağı olmadan yazılması

Karar: KAPALI — hem bayraklı hem bayraksız varyant ölçüldü, ikisi de CR4'ü başlatmadı.

Wrapper adresleri ve reset dizisinin sırası yanlış olabilir

Karar: KAPALI. Bu alanda yeni varyant denemek yasaktır — 'tekrar edilmeyecekler' listesindedir.

fw[0] giriş vektörü ve rambase yanlış olabilir

Karar: KAPALI. Sapan tek şey rambase değil, ramsize (C01).

NVRAM firmware'i eziyor olabilir

Karar: KAPALI. C01'in etkisi 'ezme' değil, 'firmware'in baktığı yerde hiçbir şey olmaması'dır.

CLM yüklenmediği için CR4 başlamıyor olabilir

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.)

Firmware imajının sonunda doğrulanmayan bir uzunluk/CRC alanı var

Karar: KAPALI — doğrulanacak bir trailer mevcut değil.

NVRAM token/dolgu biçimi yanlış

Karar: KAPALI — biçim doğru. R92'nin bu maddesi kapatılabilir; sapan şey adres (C01).

Firmware 512'ye yuvarlanarak 609.792 bayt yazılıyor (Linux 609.312)

Karar: KAPALI — ayırt edici gücü yok.

KSO ve CARDCTRL hem probe'da hem cr4_start'ta tekrarlanıyor

Karar: KAPALI.

D11'e cr4_start içinde dokunulması zararlı

Karar: KAPALI — olgular doğru, mekanizma değil.

Düşen CMD53'ten sonra kurtarma yok (IO_ABORT ölü sabit)

Karar: KAPALI kök neden olarak. Kod eksikliği gerçek ama CR4'ün başlamamasını açıklamıyor.

PMU kaynak maskesi / LPO 'donanım duvarı' teşhisi

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ı.

Yanlış silikon varsayımı (D0 / C0)

Karar: KAPALI.

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.

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.

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.

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ı.

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ı.

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.

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ı.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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ü.

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ı.

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ı.

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.

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.

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ı.

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.

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.

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).

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ü.)

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ı.

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.

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.

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.

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.

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.

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ı.

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.

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.

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.

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ı.

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.

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.

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.

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.

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ı.

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ı.

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.

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ı.

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.

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ı.

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.

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).

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).

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.

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.

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ü.

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.

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.

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.

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.

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.

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ı.

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ı.

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ı.

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.

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ı.

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.

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.

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ı.

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ı.

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ı.

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ı.

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ı.

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.

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ü).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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ı.

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ü.

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ı.

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ı.

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.

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ı.

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.

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.

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.

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.

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.

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ı.

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ü.

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.

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ı.

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.

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ı.

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.

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.

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.

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.

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ı.

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.

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.

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.

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.

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.

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.

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.

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.

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ı.

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.

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ü.

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.

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.

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.

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.

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.

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.

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.

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).

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ı.

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).

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ı.

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).

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).

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.

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).

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).

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.

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…'.

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.

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.

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.

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.

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.

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.

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.

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ı.

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.

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.

imaj fccf3ee52e94038d6f521cbf9880f8e3e91425f2c5b0bba9c9f6795f751b408d (düzeltilmiş: 3b3f3a5ae2fa736ccc79f0c03527a447653580cc1d37eaf44820d2e0e2519af0)
kanıt evidence/rpi5/radio/attempt-r157-glom-negotiation-uart-capture/

Tehdit

609 KB'lık kapalı bir ikiliyi çekirdek imajına gömmek, denetlenemeyen kodu güvenilir imajın içine taşır ve imaj imzasını anlamsızlaştırır.

Bulgu

Kurulan her radyo imajında firmware imzası (bcm94345wlpagb) sıfır kez geçer; make verify-rpi5-wifi-firmware bunu her kurulumda tarar. Bayt sayısı her derlemede değişir, kimlik kanıtı o sayı değil.

Yöntem

Kurulan .img üzerinde dize taraması, artı sürücü kaynağında include_bytes! yasağı.

Kapı

make verify-rpi5-wifi-firmware · rpi5_radio_source

Tehdit

Teslimat yolu SD kart olduğu için kartı eline geçiren biri firmware'i değiştirebilir. Değiştirilmiş firmware ayrı bir işlemcide, bizim denetlemediğimiz kodu çalıştırır.

Bulgu

Üç dosyanın da SHA256'sı depoda pinli; make copy-rpi5-wifi-firmware kopyaladıktan sonra karttaki BRCMFW.BIN'in imzasını yeniden doğruluyor. DİKKAT — bu savunma yalnızca geliştirici makinesindedir: cihaz üstünde bütünlük ya da boyut kontrolü YOKTUR. firmware_size_expected() saf bir const fn'dir ve tek çağıranı bir makbuz alanıdır (main.rs:2962 → ASELSAN/FWREAD EXPECTED=); hiçbir dallanma ona bakmaz, yani karttaki dosya kaç bayt olursa olsun TCM'e yazılır.

Yöntem

SHA256SUMS + kopyalama sonrası yeniden doğrulama (host tarafı). firmware_size_expected() yalnızca raporlar, engellemez.

Kapı

make copy-rpi5-wifi-firmware · rpi5_radio_source

Tehdit

Blob 609 KB kapalı kaynaktır. Kendi ARM çekirdeğinde koşar, kendi RAM'ine sahiptir ve SDIO üzerinden ana işlemciyle konuşur. Sistemdeki en büyük güvenilmeyen bileşen budur ve kaynak incelemesi mümkün değildir.

Bulgu

Risk kaldırılamaz, yalnızca sınırlanabilir. R58 itibarıyla firmware ve NVRAM TCM'e yüklendi ama çip ÇALIŞTIRILMADI; CLM aktarılmadı ve çipin ARM çekirdeği başlatılmadı. Çalıştırıldığında da ana işlemcinin belleğine doğrudan erişimi olmayacak — SDIO bir mesaj arayüzüdür, paylaşımlı bellek değildir.

Yöntem

Statik gerçek: dosya kapalı kaynaktır. Azaltma, ne zaman ve neyle konuştuğunun sınırlanmasıdır.

Kapı

Kabul edilmiş, belgelenmiş risk. firmware/wifi/README.md

Tehdit

Wi-Fi parolaları klasik bir sızıntı hedefidir: düz metin saklanır, belleğe düşer, çekirdek dökümünde görünür.

Bulgu

Kayıtlı ağ deposunda parola alanı YOK. SavedNetwork yalnızca ad, güvenlik tipi ve otomatik-katıl bayrağı tutuyor. Sızacak kimlik bilgisi bulunmuyor çünkü hiç girilmiyor.

Yöntem

kernel/src/ui/ios_home.rs · SavedNetwork alan listesi.

Kapı

rpi5_ios_home

Tehdit

Bir SDIO sürücüsünün gönderebileceği her komut bir yetenektir. Sessizce eklenen bir komut indeksi, sözleşmeyi kimse fark etmeden genişletir.

Bulgu

Gönderilen indeksler tam olarak 0, 3, 5, 7, 52 ve 53. CMD53 okuma R16'da açıldı; CMD53 YAZMA yolu Kapı 2a'da BİLEREK açıldı. cmd53_write'in yedi çağrı sitesi ve altı sahibi var: write_probe (iki atıl CR4 RAM dönüş yazması), write_diag, backplane_write32_cmd53, WifiSdioBus::write32, WifiSdioBus::write_fifo ve pmu_res_reload. write_probe/write_diag atıl CR4 RAM'ine (0x199000) yazar; pmu_res_reload ChipCommon PMUControl'e (0x1800_0600) yazar ve R86'da C53_ERR=0x0020 ile düştü. Wrapper/FIFO sahipleri kaynakta mevcut olsa da çalıştırma kanıtı ayrı tutulur. Firmware staging yolu R41/R42 sonrası cmd52 + verify ile yalnızca TCM'e yazar. Firmware imaja gömülü DEĞİLDİR; ama R55'ten beri tam 609 KB TCM'e yazılıp doğrulanıyor (SECTORS_DONE=1191, WORDS_V=152448, OK=1) ve R58'den beri NVRAM de yükleniyor — 42 mühürlü paket. Çalıştırılmadı: CR4 EXECUTED=0.

Yöntem

Kaynak testi: cmd53_arg(true) yalnızca cmd53_write_inner gövdesinde (R123 sarmalayıcısı inner'a taşır; cmd53_write yalnız sayar), veri portuna (0x20) yazma yalnızca cmd53_write_inner içinde, write_probe'un hedefi CR4_RAM_BASE bölgesi ve asla ChipCommon değil; stage_to_tcm yalnızca rambase/TCM'e yazar ve verify-readback ister. include_bytes! ve download_firmware hâlâ yok. NOT: mevcut kapı testi write_probe'u pinliyor, cmd53_write'in çağıran KÜMESİNİ değil — pmu_res_reload bu yüzden kapının dışında kaldı.

Kapı

rpi5_radio_source · the_write_probe_targets_only_inert_ram_never_chipcommon

Tehdit

Bluetooth'u besleyen GPIO bankası aynı zamanda 2712_BOOT_CS_N, PCIE_SDA/SCL, PWR_GPIO, WL_ON ve WiFi SDIO hatlarını taşır. Oku-değiştir-yaz sırasında çöp bir okuma geri yazılırsa bankadaki HER hat yeniden programlanır.

Bulgu

Sürücü tekdüze DATA desenlerinde (0x00000000 ya da 0xFFFFFFFF) yazmayı tamamen reddediyor. Makbuz kaç bitin değiştiğini ve komşu ON hattına dokunulup dokunulmadığını ayrı ayrı bildiriyor. R1 koşusu kapının İLK HALİNİN fazla katı olduğunu gösterdi: IODIR=0xffffffff'i ölü pencere sayıp meşru bir işlemi engelledi ve Bluetooth çipi hiç beslenmedi. Kapı, canlılığı yalnızca DATA'dan okuyacak şekilde düzeltildi ve cihazdan okunan gerçek çiftin kabul edilmesi gerektiğini pinleyen bir regresyon testi eklendi.

Yöntem

gpio_write_allowed() kapısı; kaynak testi kapının ilk store'dan ÖNCE geldiğini kanıtlıyor. R1 regresyonu ayrıca pinli.

Kapı

rpi5_radio_source · the_bt_on_line_is_one_named_bit…

Tehdit

Radyo sayfaları üretim imajında haritalıysa, radyo koduna hiç niyet edilmeden ulaşılabilir.

Bulgu

rpi5-ios-home-demo profilinde wifi_claim() ve bluetooth_claim() NeverMapped döner. Radyo sayfaları yalnızca opt-in rpi5-radio-inventory profilinde haritalanır.

Yöntem

Derleme zamanı özellik kapısı + kaynak testi.

Kapı

rpi5_radio_source · default_images_never_map_the_radios

Tehdit

Bir akış açma isteği sessizce başarılı olursa, üst katmanlar var olmayan bir ağa güvenir.

Bulgu

open_flow() her radyo türü için hata döner: Wi-Fi ve Bluetooth RadioSilent, Ethernet BarUnmapped, hücresel CellularAbsent. Trafik sayacı sıfır.

Yöntem

kernel/src/driver/rpi5_radio.rs; her dönüş yolu testte sabitlenmiş.

Kapı

rpi5_radio_source · the_broker_is_silent_and_traffic_is_zero

Tehdit

CLM blob'u çipin hangi kanallarda ve hangi güçte YAYIN yapabileceğini söyler. Yanlış ya da eksik CLM ile çalışan bir radyo, bulunduğu ülkede yasa dışı kanallarda yayın yapabilir.

Bulgu

Bugün hiçbir yayın yok — ama gerekçe dar bir marja dayanıyor. Tam firmware ve NVRAM CR4 TCM'e YÜKLÜ ve doğrulanmış (R58'den beri 30 mühürlü koşu). CR4 start her radyo boot'unda DENENİYOR (main.rs:2894 cr4_start) ve yazmalar iniyor (RSTVEC_OK=1, WRITE_OK=1). Yayın olmamasının tek fiili nedeni çekirdeğin YÜRÜTMEMESİ (MBOX=0, EXECUTED=0). Gerçekten yüklenmeyen tek şey CLM'dir: dosya kartta duruyor, TCM'e hiç aktarılmıyor. Yayın kapısı açılmadan önce CLM'in yüklendiğinin doğrulanması bir ÖN KOŞUL olarak kaydedildi ve CR4 yürütmeye başladığı an bu satır YENİDEN YAZILMALIDIR.

Yöntem

R89–R93 cihaz koşuları + kaynak sözleşmeleri; yükleme var, yürütme yok, CLM aktarımı hiç yok.

Kapı

WIFI-A3 açık · CLM aktarımı yok · CR4 EXECUTED=0

Tehdit

Eşleşmiş cihazlar ve bağlantı anahtarları (link key) kalıcı sırlardır; sızarlarsa saldırgan güvenilir bir cihaz gibi davranabilir.

Bulgu

Eşleşme hiç uygulanmadı. Sürücüde LinkKey, BdAddr ve eşleşme fonksiyonu adı bile geçmiyor — kaynak testi bu adları yasaklıyor. Gönderilen tek HCI komutu Reset.

Yöntem

Kaynak testinde yasaklı belirteç listesi.

Kapı

rpi5_radio_source · only_the_two_radio_buses_may_write…

Tehdit

Ekranda gerçek görünen sahte veri, en sinsi güvenlik hatasıdır: kullanıcı var olmayan bir ağa bağlandığını sanır ve güvenlik kararlarını ona göre verir.

Bulgu

Çekirdek kaynağında tek bir uydurma SSID yok. local://wifi sayfası ölçülmemişken 'ölçülmedi' yazıyor ve 0x4345 ya da BCM43455 üretmiyor; ölçüldüğünde gerçek makbuzu basıyor.

Yöntem

Test önce makbuzu siliyor ve sayfanın kimlik uydurmadığını kanıtlıyor, sonra ölçüm yayınlayıp gerçek değerleri gösterdiğini doğruluyor.

Kapı

rpi5_ios_home_browser · local_wifi_page_is_measured_facts_not_invented

Tehdit

Çalışan bir Wi-Fi/Bluetooth yığını, kimlik doğrulamasından önce paket ayrıştıran kodla saldırıya açıktır: yönetim çerçeveleri, beacon'lar, HCI olayları.

Bulgu

Radyoların ikisi de çalışma durumuna hiç geçmiyor. Wi-Fi firmware'siz yayın yapamaz ve alamaz; Bluetooth yalnızca tek bir Reset gönderip cevabını okuyor. Ayrıştırılan tek hava verisi YOK.

Yöntem

Statik: alma yolu yok. Bu, güvenlik mühendisliği değil, özelliğin yokluğudur ve öyle sayılmalıdır.

Kapı

WIFI-A4 ve BT keşif kapısı açık