Noticias

Mar 15, 2024

DisplayPort: tocando el modo alternativo

Realmente, la implementación más moderna de DisplayPort es el modo alternativo USB-C DisplayPort, sinónimo de “vídeo a través de USB-C”, y nos lo perderíamos si lo omitiera. Por cierto, nuestros dos últimos artículos

Realmente, la implementación más moderna de DisplayPort es el modo alternativo USB-C DisplayPort, sinónimo de “vídeo a través de USB-C”, y nos lo perderíamos si lo omitiera. Por cierto, nuestros dos últimos artículos sobre cómo hablar de USB-PD le han dado a algunas personas un juguete nuevo e interesante con el que jugar: la gente ha comentado los artículos, se ha puesto en contacto conmigo para pedirme ayuda con la depuración e incluso he visto a personas integrar el FUSB302B en sus proyectos! Pisándole los talones a ese logro, vayamos más allá y conquistemos una característica más del USB-C, una que aún no está abiertamente disponible para que la pirateemos, aunque lo merece.

Para nuestros lectores veteranos, no sorprende ver que se les niegan capacidades mundanas a los piratas informáticos. A estas alturas, todos sabemos que muchas computadoras portátiles y teléfonos le permiten obtener una conexión DisplayPort a través de un puerto USB-C. Dado que las especificaciones USB-C están disponibles abiertamente y previamente implementamos un disipador PD usando esas especificaciones, es de esperar que podamos hacer DisplayPort con la misma facilidad. Sin embargo, la especificación del modo alternativo DisplayPort está detrás de un muro de pago de membresía VESA, con un precio elevado, una práctica suya que ha sido ampliamente criticada, contraria a su propósito como organización de estándares y que ha resultado en que algunos de sus estándares fallen.

Sin embargo, no se preocupe: podemos encontrar fácilmente una variedad de archivos PDF que brindan una descripción general de alto nivel y algunos detalles del modo alternativo DisplayPort, ¡y aquí está mi favorito! También tengo un dispositivo que ejecuta MicroPython con un chip FUSB302 conectado y algunos dispositivos míos de modo alternativo DisplayPort que puedo desmontar. ¡Resulta que esto es más que suficiente para que podamos aplicar ingeniería inversa a una biblioteca de modo alternativo DisplayPort de código abierto!

El puerto USB-C tiene cuatro pares de alta velocidad y un par auxiliar de baja velocidad (SBU). Esto se adapta perfectamente a los requisitos de DisplayPort, con hasta cuatro pares de transferencia de datos de alta velocidad y un canal de configuración AUX. Una pequeña peculiaridad: no hay ningún pin para la señal HPD; en cambio, su estado se reenvía dentro de los mensajes de modo alternativo de DisplayPort a través del canal PD. Como resultado, puede conectar su dispositivo a un USB-C compatible con DisplayPort, escribir algunas palabras mágicas a través de PD y obtener una señal DisplayPort en los pines TX/RX del USB-C. No es necesario profundizar en los aspectos internos de DisplayPort; Lo máximo que necesitará es reenviar HPD como un mensaje PD, y si su dispositivo usa una toma USB-C, haga que un mux económico cambie las señales de acuerdo con la forma en que esté enchufado su cable USB-C.

Además de DisplayPort, también obtienes USB 2.0 en los viejos pines USB2, perfectos para conectar un teclado y un mouse junto a tu monitor. Sin embargo, eso no es todo lo que puede extraer: si está satisfecho con DisplayPort de dos carriles, puede pedirle al dispositivo ascendente que le proporcione dos carriles de DisplayPort en un par de pines y un puerto USB3 en otro. Así es como funcionan la mayoría de las bases USB-C económicas: tienen dos carriles de DisplayPort que se usan para VGA o HDMI, USB3 para un puerto de alta velocidad o algunos periféricos y USB2 para muchas otras cosas, manejando su energía. entrada en el lateral.

A juzgar por el PDF que tenemos de ST, hay siete tipos de mensajes PD que debemos responder si queremos construir un dispositivo DisplayPort; el diagrama de la página 13 los muestra todos. En el artículo "Todo sobre USB-C: Responder a PD de bajo nivel", aprendimos dos tipos de mensajes: Source_Capabilities, que es un anuncio del perfil de energía de la PSU USB-C, y el mensaje de Solicitud, que hemos creado para obtener uno de esos perfiles de energía y obtenga un voltaje más alto de un puerto USB-C. De dos a siete: ¡esto está a nuestro alcance!

¿Qué debemos hacer para aplicarle ingeniería inversa, como mínimo? Yo diría que el PDF parece contener información más que suficiente por sí solo: allí se describen el flujo de comunicación, diferentes códigos de comando y contenidos. Sin embargo, ¡será mucho más cómodo si tenemos capturas de paquetes como referencia!

El rastreo de comunicaciones USB-C es un campo poco explorado, especialmente si se trata de señales de alta velocidad. Para eso, necesita una placa intermediaria que preserve la integridad de la señal y al mismo tiempo le permita acceder a los pines CC, y esos no son ni un centavo la docena. Cuando se trata de herramientas comerciales para detectar USB-C, siento que la mayoría de ellas tienen un precio que explica el hecho de que muchas personas no entienden USB-C. Sin embargo, ciertamente hay formas de evitarlo: en la sección de comentarios del primer artículo de PD, [WF] nos señaló una forma de detectar paquetes USB-C arbitrarios con un analizador lógico y un circuito adicional simple, con la ayuda de sigrok y Vista de pulso! Estamos creando un dispositivo que puede hablar en modo alternativo DisplayPort, no solo olerlo, pero si desea acceder a uno de sus dispositivos mientras sigue este artículo, esto debería ser suficiente.

Dicho esto, podría haber una solución aún más simple; si la ha seguido, es posible que tenga un FUSB302B, que es un USB-C PHY IC. Desde que se publicó el artículo “Responder a PD”, he estado desarrollando poco a poco las capacidades de mi “pila” USB-PD MicroPython personal: una variedad de funciones y códigos de PD, más bien, pero la llamaré pila hasta que se conozca más. se encuentra el nombre adecuado. Primero, agregué capacidad de escucha de paquetes: cambié el FUSB302 al modo de solo recepción, leí su entrada FIFO lo más rápido posible y analicé los datos sobre la marcha. También agregué análisis de información de paquetes, para que pueda ver las comunicaciones USB-C en la consola serie, sin tener que leerlas primero.

Hay una advertencia, por supuesto: no puedo realizar fácilmente la captura de paso de paquetes USB-C, ya que no quería diseñar una placa de paso de código abierto con capacidad de derivación CC, y estas placas no están disponibles. Dicho esto, alguien debería hacerlo; ¡es una lástima que el dispositivo USB-C-Thru nunca haya recibido financiación! En lugar de eso, comencé desmontando los dispositivos de cable cautivo que poseo y luego conecté el pin CC, ya que, con un dispositivo de cable cautivo, solo hay un pin CC posible. Esto significa que no necesito detectar automáticamente la rotación, lo cual es bueno porque, dado el tiempo que mi código MicroPython podría tomar para determinar la rotación, la conversación USB-PD podría haber terminado en ese momento. Entonces, el CC1 de mi placa está conectado a uno de los pines CC de mi base USB, el CC1 está codificado para ser el pin de escucha, ¿qué más?

Querrá desactivar los pullups de FUSB; serán contraproducentes aquí, ya que estamos aprovechando una disposición pullup/pulldown existente, e introducir un pulldown más resultará en que VBUS se apague. También querrás desactivar las respuestas GoodCRC: FUSB302 las hace automáticamente, lo que ayuda cuando lo usamos como receptor, pero aquí entrarán en conflicto con las respuestas GoodCRC de ambos lados de la conversación USB-C; desactivar el transmisor es aún mejor. También habilité la recepción de paquetes SOP'/”: estos paquetes se usan para marcadores electrónicos y, aunque normalmente no necesitamos recibirlos, poder detectarlos ahora es bueno.

¡Ahora estamos listos! Eso sí, las comunicaciones USB-C se realizan muy rápido. Mi código MicroPython tampoco es rápido: uso MicroPython porque prefiero la capacidad de pirateo a la velocidad de ejecución. Sin embargo, como consecuencia, no puedo analizar los paquetes a medida que llegan; me perderé partes de la conversación USB-C si lo hago, ya que, recuerde, incluso imprimir declaraciones lleva un poco de tiempo. En cambio, leo el contenido FIFO de entrada lo más rápido posible, almaceno los paquetes en la RAM y luego los analizo. Por el lado positivo, tener capturas de paquetes en la RAM también significa que termino con grabaciones de conversaciones PD que puedo almacenar y reproducir fácilmente más tarde, ¡y tú también obtienes algunas de estas capturas!

Por supuesto, hay desventajas en el uso de este método de captura de paquetes: es posible que todavía no pueda capturar comunicaciones que ocurren demasiado rápido, solo capturo paquetes con CRC válido y me perderé cualquier paquete confuso, y no tengo marcas de tiempo. por los paquetes recibidos; usar un analizador lógico anularía todos estos. Sin embargo, para nuestros propósitos de DisplayPort RE, es más que suficiente y cualquier código de análisis que escriba será muy útil al crear una biblioteca. Pin CC conectado, código ejecutándose y listo, ¡vamos!

Aquí puede ver una negociación de perfil de energía: Source_Capabilities, Request, Accept y PS_RDY, cosas que ya hemos hecho antes. Estos son necesarios si vas a hablar sobre PD por cualquier motivo, por lo que no es una gran sorpresa. Sin embargo, también hay una gran cantidad de mensajes Vendor_Defined, y estos pueden ponerlo nervioso. Sin embargo, no tenga miedo: agradezca el estándar USB-C, porque, con la forma en que les indica a los proveedores que implementen comunicaciones específicas del proveedor, ¡estos mensajes están mejor documentados de lo que cabría esperar!

Los VDM, o mensajes definidos por el proveedor, son responsables de cualquier invocación de modo alternativo que vaya más allá de los elementos habituales “USB3, USB2 y PD” que puede obtener; puede usar VDM para cualquier cosa que quede fuera del estándar, desde modos alternativos personalizados hasta actualizaciones de firmware. Puede tenerlos estructurados o no estructurados: los mensajes no estructurados son básicamente de formato libre, mientras que los mensajes estructurados son una especie de plantilla para una conversación típica que un proveedor podría querer implementar. La negociación DisplayPort utiliza mensajes estructurados, y de los siete comandos involucrados en la configuración del modo alternativo DisplayPort, ¡cinco de ellos son comandos ya definidos en el estándar USB-C! En cuanto a los dos restantes, el PDF que tenemos menciona de manera muy útil sus códigos en la página 8 y los describe con más detalle en las páginas 10-12.

Estos comandos son un poco especiales: no es sólo que se requiera una respuesta GoodCRC, el FUSB302B se encargará de ello por nosotros de todos modos. ¡También es que cada comando puede ser una solicitud o una respuesta, y cualquiera de las instrucciones puede transportar datos adicionales, dependiendo del comando específico que se utilice! Afortunadamente, todos estos datos opcionales se describen en el PDF, lo que resulta cada vez más útil a medida que profundizamos.

En definitiva, no necesitaremos tanta ingeniería inversa, específicamente: el principal problema, en mi opinión, serían los campos de bits. Además, dado que no tenemos las especificaciones completas, podríamos cometer uno o dos errores cruciales; por ejemplo, no sabemos qué tan rápido debemos responder a estos comandos o los detalles específicos del manejo adecuado de la señal DisplayPort HPD. Sin embargo, podemos resolverlos, ¡y tengo una gran variedad de dispositivos USB-C DisplayPort para obtener capturas de paquetes!

Bueno, ahora tenemos comandos de conversación DisplayPort, capturados desde un dispositivo de la vida real; si quisiéramos crear un sumidero DisplayPort ahora mismo, podemos simplemente reproducirlos, ¡solo ajustando cosas pequeñas como la identificación del mensaje! De hecho, aquí hay un fragmento de código que hace precisamente eso: envía de vuelta los comandos que capturamos y logré que invocara con éxito el modo alternativo DisplayPort en mi propia computadora portátil. Ahora, no verifiqué la salida DisplayPort de alta velocidad, pero obtuve voltaje en los pines SBU, lo que significa que el par de diferencias AUX se ha conectado a ellos, algo que solo sucede después de que el modo altmode DisplayPort se haya convocado con éxito.

La parte fundamental del código de reproducción es el bucle de solicitud-respuesta, que depende de nuestro código de análisis para responder los mensajes entrantes. Esto es genial para nosotros: necesitaremos exactamente este tipo de bucle una vez que podamos construir nuestras propias respuestas, solo que necesitaremos uno un poco más sofisticado. Hasta entonces, esto es suficiente para salir adelante en lo que respecta a mi proyecto personal.

¡Las próximas tareas son darle sentido a estos comandos e implementar una biblioteca DisplayPort significativa! Revisaremos los siete comandos necesarios, explicaremos cada uno de ellos, analizaremos los que recibiremos e implementaremos los que tendremos que enviar de vuelta. Luego, los uniremos todos en el bucle ya existente, descubriremos el manejo de rotación de carriles de alta velocidad del USB-C y estaremos listos para construir dispositivos de manejo DisplayPort de código abierto para cualquier puerto USB-C capaz a la vista. . Después de todo, hoy en día, ¡incluso un PinePhone puede utilizar DisplayPort!