Recodificar QSFP28 y QSFP-DD: dónde vive el bloque de identificación al salir de SFF-8472 A0h/A2h
Hago lotes pequeños de recodificación de módulos para integradores, y hasta ahora todo lo que ha pasado por mi banco tenía forma de SFP: leer los 256 bytes en A0h con el ID de serie en la primera mitad, leer A2h para el diagnóstico y los umbrales, escribir el bloque de identificación, listo. Ahora un cliente ha llegado con piezas de 100G y 400G y mi equipo claramente se quedó corto.
- módulos a recodificar: una bandeja de QSFP28, algunos QSFP-DD y una muestra de OSFP
- programador actual: I2C plano, lee y escribe A0h y A2h, sin selección de página en absoluto
- los hosts del otro lado verifican nombre del vendedor, número de parte y serie antes de encender el puerto
Mis notas de trabajo sobre cómo está organizada la memoria, que es en realidad lo que quiero que se revise:
SFP/SFP+/SFP28 (SFF-8472): A0h 256B, ID de serie en los primeros 128B; A2h 256B diagnóstico + umbrales, páginas opcionales de 128B
QSFP+/QSFP28 (SFF-8636): A0h único, páginas de 128B seleccionadas por el byte 7Fh, página 00h obligatoria
XFP (INF-8077i): el byte 7Fh elige la tabla activa, con el ID de serie en la tabla 01h y EEPROM de usuario en la 02h
OSFP/QSFP-DD/SFP-DD (CMIS 5.x): 128B inferiores fijos, memoria superior por banco y página vía 7Eh y 7FhLo que he probado:
- volcar un QSFP28 con mi perfil de SFP, lo cual me entrega la mitad inferior más la página que estuviera seleccionada en ese momento
- tomar dos volcados del mismo módulo seguidos para ver qué bytes cambian por sí solos
¿Es correcto ese mapa, y qué campos tengo que escribir en realidad para la codificación de vendedor una vez que la memoria está paginada y bancada?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
El mapa es correcto en esencia. Lo que le falta a tu equipo es que en SFF-8636 solo hay una dirección y los 128 bytes superiores son una ventana: escribes el número de página en el byte 7Fh, luego lees la mitad superior y obtienes esa página. La página 00h es la obligatoria y contiene el bloque de identificación, así que para codificar rara vez necesitas ir a otro lado. CMIS añade un banco encima de eso - 7Eh selecciona el banco, 7Fh la página, y los 128 bytes inferiores se mantienen fijos y siempre legibles. Sin selección de página tu herramienta sigue entregándote la página en la que quedó el módulo, que es exactamente el comportamiento que describes.
Los campos que importan para la codificación de vendedor son los mismos en todos lados: nombre del vendedor, número de parte, revisión, número de serie, el OUI y los checksums. Si te equivocas en un checksum, un host exigente descarta el módulo aunque cada cadena se vea perfecta en un volcado hexadecimal. Otra cosa para la que hay que estar preparado: algunos módulos protegen las funciones de vendedor detrás de contraseñas de fabricante y de host mientras las lecturas simples quedan abiertas, así que puedes volcar tranquilamente una pieza que no puedes escribir.
Los checksums son justo lo que me mordió en el primer intento - las cadenas coincidían byte a byte con un módulo conocido y bueno y el host igual rechazaba la pieza. Bueno saber que la página 00h basta para el bloque de identificación, eso mantiene pequeño el alcance del trabajo.
El resumen honesto entonces es que mi programador no puede hacer esto en absoluto, porque no tiene forma de escribir el byte 7Fh antes de una lectura. Prefiero comprar una placa antes que ponerle selección de página a un equipo casero para un solo pedido. ¿Hay algo en el mercado que maneje bien los bancos CMIS, o eso es más bien una característica de hoja de datos?
Las placas comerciales sí lo anuncian - SFPTotal Plus X, el equipo de Reveltronics (REVELPROG-IS), los programadores EDGE y Flexoptix ponen todos QSFP-DD y OSFP en la lista de características, y encima incluyen una base de datos de códigos de vendedor. SFPTotal reclama más de 25.000 códigos, incluyendo Cisco, Huawei y HPE.
Cuánto de eso coincide con las piezas específicas de tu banco es otra pregunta, y yo tampoco me fiaría solo de mi palabra. Si puedes, pon una muestra del QSFP-DD del cliente frente a la placa antes de comprometerte con la compra. Que un formato esté en una hoja de datos no es lo mismo que soportar el módulo particular que tienes en la mano, y las piezas bancadas es donde se nota esa diferencia.
Para contraste, el trabajo simple de SFP sigue siendo tan crudo como siempre: solo los primeros 128 bytes del volcado de 256 bytes importan de verdad, el resto está reservado para el fabricante, y lleva años escribiéndose imágenes GLC-LX o GLC-BX-D/GLC-BX-U en piezas CWDM genéricas para que las acepte un Catalyst 3560, un HP J8692A o un EX4200-24F. Se compartieron esquemas de programadores caseros para eso, siendo serp-0.3 el que yo construí, y los volcados de un Finisar FCMJ-8521-3, un HP J4858C o J4859C, o un D-Link DEM-310GT eran los puntos de referencia habituales.
Animal distinto, pero vale la pena saberlo por si te llegan sticks GPON al banco: ahí no se codifica desde fuera en absoluto. En un FS GPON-ONU-34-20BI, pariente del Nokia G-010S-A, tienes una shell en el propio stick - con la fibra conectada responde en 192.168.1.10 como ONTUSER - se fija el serial y la MAC con uci, y se reescriben las cadenas de vendedor de la EEPROM desde dentro con sfp_i2c.
QDD y OSFP tienen estructura CMIS y contienen solo un byte de checksum en la Page 0.