CodingBox Q&A Ask question

Programlayıcı SFP+ FTLX8571D3BCV-IT'yi okuyor, ama yazmaya No Acknowledge ile cevap veriyor

Asked Active Viewed 110 AI translation from Русский
6

Şehre yayılmış node'ları olan küçük bir modül değişim fonu tutuyorum, neredeyse her yabancı switch için bir SFP'yi yeniden kodlamak gerekiyor. Gigabit modüllerde şema çoktan oturdu, onluğa gelince takıldım.

Masada olan:

  • SFP/SFP+ kafesli, 3.3 V beslemeli bir programlayıcı
  • Finisar FTLX8571D3BCV-IT ve FTLX1471D3BCV-IT, ikisi de okunuyor
  • eski stoktan bir Cisco GLC-LH-SM
  • HP J4858B ve J4859C

Okuma stabil ve tekrarlanabilir şekilde alınıyor, her iki bank da tam olarak. Yazma hiçbir varyantta gitmiyor:

read  A0 0x00-0xFF ... OK
read  A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledge

Şimdiye kadar kontrol ettiğim:

  • sıradan gigabit SFP'lerde aynı işlemler aynı programlayıcıyla geçiyor, yani devre ve besleme canlı;
  • ikinci bir FTLX8571D3BCV-IT örneği aldım, davranış byte byte aynı;
  • GLC-LH-SM'de No Acknowledge, vendor alanlarına dokunmayı denemeden önce, hemen geliyor.

Yani mesele belirli bir örnekte değil. Bu modülün kendisindeki donanımsal bir yazma koruması mı, yoksa SFP+'ta bellek artık çıplak bir EEPROM değil ve I2C üzerinden sıradan bir yazmayla oraya hiç girilemiyor mu? Ayrıca özellikle HP J4858B/J4859C ilgimi çekiyor: onları sıradan bir programlayıcıyla yazan oluyor mu, yoksa bu baştan çıkmaz sokak mı?

Comments 6

Accepted answer

Burada iki farklı mekanizma birbirine karışmış, ikisi de farklı şekilde çözülüyor.

Birincisi - donanımsal yazma korumalı sıradan bir EEPROM. Bellek çipinin bir write protect ucu var, o çekiliyken okuma gidiyor, yazma ise düşüyor. Bu işle yakından uğraşan insanların önerdiği yöntem: firmware süresince bu ucu toprağa oturtmak. Gigabit modüllerin bir kısmında bu yeterli.

İkincisi - senin onlukta karşılaştığın şey. SFP+'ta veri sık sık ayrı bir EEPROM'da değil, modülün mikrokontrolcüsünün arkasında duruyor: A0 ve A2'yi okumaya kendisi veriyor ve yazmayı sadece kendi komut dizisiyle kabul ediyor. Standart bir programlayıcı böyle bir diziyi bilmiyor ve hangi alanı hedeflediğine bakmaksızın her denemede No Acknowledge alıyor. Orada toprağa oturtacak bir şey yok.

Kafesi gerçekten aşmaya yardımcı olan: programlayıcının konnektörünü atlayarak, modülün 4 ve 7 numaralı bacaklarına, yani I2C hattına, doğrudan tellerle lehimlemek. Geri bildirimlere göre, bundan sonra kafeste sessiz kalan modüllerin bir kısmı yazılıyor. Yöntem kaba, eller düzgün olmalı ve bundan sonra modül senin sorumluluğunda yaşıyor.

HP ayrı bir hikaye. Standart programlayıcılar onları almıyor, orada kendine özgü bir işlem gerekiyor, sıradan bir devreyle J4858B/J4859C'de başarı beklemezdim. Görev sadece yabancı bir switch'te çalışan bir modül elde etmekse, HP ile uğraşmaktan daha ucuzu, dürüst bir belleği olan bir modül alıp içine vendor imajını baştan sona akıtmak: 256 baytlık dump'ın ilk 128'i anlamlı, gerisi üreticinin rezervi.

Hiçbir vendor böyle bir yeniden kodlamayı elbette desteklemiyor: yeniden flash'lanmış bir modülle desteğe gidecek bir şeyin yok.

3 Russialambdaops44RU Show original (Русский) AI translation

Birkaç şeyi netleştir, yoksa falcılık olur. No Acknowledge cihaz adresinin kendisinde mi geliyor, yoksa ilk veri byte'ından sonra mı? Programlayıcının log'unda bu genelde görülür. Bir de senin programlayıcın ne - hazır bir cihaz mı, yoksa kendi devresi üzerinde bir ev yapımı mı? Kafesteki 3.3 V'tan genel olarak ne beklenmesi gerektiği buna bağlı.

Bir de besleme verilirken davranış ilginç: modül takıldıktan hemen sonra ve birkaç dakika beslemede kaldıktan sonra ret aynı mı? Ve dört tip de aynı mı davranıyor, yoksa Finisar ile HP farklı mı: HP'nin genelde kendi ret sebepleri olur, onları hemen ayırmak daha iyi.

3 RussiadwdmmonkRU Show original (Русский) AI translation

Sonuç hakkında rapor veriyorum. Kafesi atlayarak I2C hattına doğrudan 4 ve 7 numaralı bacaklardan lehimledim. Finisar'lar gitti: FTLX8571D3BCV-IT yazıldı ve geri okumayla doğrulandı, FTLX1471D3BCV-IT de öyle. GLC-LH-SM No Acknowledge vermeyi bıraktı ve normal yazılıyor.

HP teslim olmadı. J4858B yazmayı formal olarak kabul ediyor, ama düzenlemeden sonra modül switch tarafından reddediliyor, J4859C de aynı şekilde davranıyor. Yani benim için soru yarı yarıya kapandı: Finisar ve Cisco'yu artık yazıyorum, HP'yi daha iyi zamanlara kadar bir kenara bıraktım.

1 KazakhstanlinkguruKZ Show original (Русский) AI translation

HP'de tuzak yazma korumasından daha derin, o yüzden senin sonucun beklenen bir şey. J4858B'de byte 68-83'ü, yani seri numarasını, düzenlerken byte 124-127'deki checksum değişiyor ve modül bundan sonra reddediliyor. Bu MSA'nın CC_BASE ve CC_EXT'i değil, onları hesaplamak sorun değil, A0'ın son dört byte'ında ayrı bir vendor checksum'ı. Algoritma ne kadar eşelenirse eşelensin kamuya açık olarak hiç çözülmedi.

J9150A da aynı hikayeden. Daha yeni HP ve Aruba modüllerinde ise statik checksum'dan tamamen bir istek-cevap şemasına, HPIDv2'ye geçilmiş, orada programlayıcı prensip olarak işe yaramıyor. Yani "yazılıyor ama kabul edilmiyor" tam olarak çıkması gereken sonuç.

1 Kazakhstanlambdaowl20KZ Show original (Русский) AI translation

Madem senin elinde bir tane değil bir filo var, aletten bahsedeyim. Huawei S5731 ve S6730 ile HP 6120XG için yeniden kodlamaya Ubiquiti'nin UACC-SFP-WIZARD'ını uyarladım - ucuz bir programlayıcı olarak gayet canlı. Sadece Ubiquiti modüllerinin kendisi için 0x00001011, SFPX, QSFP türünden parola listeleri dolaşıyor, onlar olmadan bazı modüller yazmaya açılmıyor. İmajlardan bende dolaşımda olanlar FTLX8571D3BCV ve FTLX8574D3BCV, daha nadiren SNR-SFP+W73-3 ve W37-3.

3 Russiaportrunner91RU Show original (Русский) AI translation

Yukarıdaki genellemeyi düzelteyim, kimse vaktinden önce lehim aletine sarılmasın: her SFP+'ta bellek mikrokontrolcünün arkasına saklanmıyor. Bende FTLX8574D3BCV ve bir çift SNR-SFP+W73-3, hiç lehim yapmadan kafeste sıradan bir programlayıcıyla yazıldı. Yani önce belirli örneği kontrol etmekte fayda var, ancak sonra araya girmeye kalkmalı.

Write protect ucunu toprağa oturtmak da, bu arada, evrensel bir reçete değil: mikrokontrolcülü bir modülde bu hiçbir şey vermiyor, oradaki ret bellekten değil, kontrolcünün firmware'inden geliyor. Bu işlemin bir anlamı sadece dürüst, ayrı bir EEPROM'un olduğu yerde var, bunu da modül güçsüzken yapmak gerekiyor, yoksa modül yerine kolayca bir tuğla elde edersin.

2 UkrainecoremonkUA Show original (Русский) AI translation
Log in to comment. Log in