Drew Fustini: entrevista exclusiva para AT

Nueva entrevista exclusiva para el blog AT con Drew Fustini. Un embajador del proyecto RISC-V, diseñador de hardware de código abierto en OSHPark, y desarrollador de sistemas embebidos Linux. Además es miembro de la dirección de BeagleBoard.org Foundation. Y si quieres conocer más sobre él, te invito a seguir leyendo la entrevista…

Architecnología: Siempre suelo comenzar con esta pregunta: ¿Quién es Drew Fustini? (Descríbete, por favor)

Drew Fustini: Soy diseñador de hardware y desarrollador de Linux embebido, soy de Chicago (EE.UU.), pero  vivo en Berlín. Diseño proyectos de hardware de código abierto para OSH Park (un servicio de fabricación de PCB) y mantengo las bibliotecas Adafruit Python para el BeagleBone. También soy voluntario en la junta directiva de la Asociación de Hardware de Código Abierto (OSHWA) y la Fundación BeagleBoard.org. Organizo la reunión de Embedded Linux de Berlín (¡esperamos que podamos empezar a reunirnos de nuevo en 2021!) y me convertí en embajador de la Fundación RISC-V a principios de este año.

AT: ¿Cómo y cuándo te empezó a apasionar la tecnología?

DF: Recuerdo que siempre me interesó cómo funcionaba la tecnología, especialmente los ordenadores y la electrónica. Tuve el privilegio de tener un PC en casa desde una edad temprana ya que mi padre era ingeniero en los laboratorios Bell (la división de I+D de AT&T). Principalmente jugaba a juegos como Centipede pero me familiaricé con el uso del DOS. Empecé a programar cuando conseguí una calculadora gráfica en la escuela secundaria que podía ejecutar programas BASIC. Empecé a hacer juegos para mi calculadora. Mi escuela tenía Macs y aprendimos Hypercard que era una mezcla de hacer un sitio web fuera de línea y una presentación de PowerPoint. Pero lo más emocionante era que podías programar la interfaz de usuario como botones y animaciones usando HyperScript. Después de unos años, decidí diversificarme en C y C++. En el camino, tuve la suerte de tener un vecino con acceso a Internet que me dijo que debía hacer un sitio web y me dio un libro sobre HTML. Eso me llevó a aprender Perl, que era la forma en que la mayoría de la gente construía aplicaciones web en ese entonces.

AT: ¿Tienes algún referente? ¿Alguien que te haya inspirado?

DF: Tuve la suerte de tener ordenadores tanto en casa como en la escuela desde muy joven. No teníamos muchas clases de computación pero tenía acceso a estos sistemas caros. Una figura importante en mi viaje tecnológico fue mi vecino de al lado que era programador y también tenía su propio negocio de construcción de PCs. Esto me metió en el desarrollo de webs y me permitió empezar a ganar dinero haciendo eso mientras estaba en la escuela secundaria, y me consiguió un puesto de verano en un proveedor de servicios de Internet en Chicago.

AT: ¿Cómo comenzó tu papel como embajador de RISC-V?

DF: Estuve en la feria Embedded World en Alemania en febrero por BeagleBoard.org (poco sabíamos que sería el último evento de este año). Nuestro stand estaba cerca del pabellón RISC-V y pasé mucho tiempo hablando con gente de las compañías miembros de RISC-V y también con Calista Redmond, CEO de la Fundación RISC-V (ahora RISC-V International). Ella me dijo que estaban a punto de comenzar un programa de embajadores para los apasionados del RISC-V. Mi interés en RISC-V viene de mi pasión por el hardware de código abierto. Me encantaría ver más código abierto a nivel de chip. RISC-V es un conjunto de instrucciones abiertas estándar (ISA) que permite implementaciones de código abierto. No puede haber una implementación de código abierto de un ISA propietario como ARM o x86. Por lo tanto, es posible diseñar un microprocesador RISC-V que sea completamente de código abierto.

AT: ¿Cómo comenzaste como hacker del kernel Linux?

DF: He estado interesado en los sistemas operativos desde que estaba en el instituto. En aquel entonces hacía programación de sistemas Windows por diversión (Win16 API). Más tarde descubrí Linux y desde entonces lo he estado usando para mis sistemas personales como el portátil y el de escritorio. También me interesé mucho por el funcionamiento de Linux y empecé a leer libros como «Understanding the Linux Kernel«. No hice ninguna programación del kernel pero continué leyendo otro excelente libro sobre programación de sistemas llamado Advanced Programming for the Unix Environment from front to back. Fue una gran manera de entender la API de POSIX, que es esencialmente cómo el espacio de usuario (por ejemplo, las aplicaciones) interactúan con el kernel. Fue un conjunto de habilidades vitales para ser un buen administrador de sistemas Linux y desarrollador de aplicaciones.

Comencé a hacer programación del kernel por medio de un desafío que aprendí mientras asistía a LinuxCon 2015 en Chicago (¡mi ciudad natal!). Conocí a muchos de la comunidad del núcleo de Linux como Linus Torvalds y Gerg KH. Era demasiado tímido para hablar con ellos, pero mi amigo más extrovertido Renault me dijo que no debíamos perder la oportunidad de decir Hola 🙂 Los dos fueron muy simpáticos. Linus me dijo que una cosa que podemos hacer para ayudar es ejecutar las versiones candidatas de Linux y reportar problemas (Linux responde a miles de personas que lo prueban en todo tipo de configuraciones de hardware). Greg KH nos habló del Eudyptula Challenge dirigido por el misterioso «Little Penguin». Al enviar un correo electrónico a «Little Penguin», uno recibiría una tarea de programación del núcleo para completar. Comenzaron con algo tan simple como escribir un módulo del núcleo para imprimir «hola mundo» en el registro del núcleo e ir desarrollando habilidades. En total había 20 tareas y me tomó casi 2 años para completarlas. En gran parte esto se debe a que a menudo había retrasos de semanas para obtener una respuesta. Esta es una buena simulación de cómo son las listas de correo del núcleo – uno tiene que aprender a tener paciencia y persistencia cuando pide a otros que revisen sus parches del núcleo y trabajar a través de su retroalimentación. Al final, acepté un simple parche para el kernel que reestructuraba algo de código en un controlador para ajustarse mejor a los estándares de codificación del kernel. Aunque era pequeño, me dio confianza y me hizo participar mucho más en la lectura de las listas de correo del núcleo de Linux y comencé a asistir a conferencias centradas en el núcleo como la Linux Plumbers Conference.

AT: ¿Cuál es exactamente tu trabajo dentro del kernel? ¿Sólo trabajas en el código de soporte de las tablas de Beagle o haces otras contribuciones? ¿Algo sobre el código dependiente de la arquitetura RISC-V?

DF: No tengo un trabajo en sí mismo trabajando en el kernel. Pero como miembro voluntario de la junta de la Fundación BeagleBoard.org, estoy enfocado en mejorar la experiencia de la gente que usa las placas de desarrollo del BeagleBone, así como en reducir la carga de mantenimiento del software en nuestro pequeño equipo de voluntarios. La mejor manera de hacer esto es asegurándose de que todo lo que se necesita para el BeagleBone está en el núcleo de Linux (esto también se refiere a «mainline», es el repositorio del núcleo Linux de Linus Torvald). El Texas Instruments SoC (System-on-Chip) utilizado en el BeagleBone está bien soportado en Linux ya que ha sido una parte muy exitosa utilizada en muchos proyectos comerciales, desde impresoras 3D, hasta robots autónomos, o unidades de navegación GPS. Sin embargo, hay personalizaciones del núcleo de Linux (por ejemplo, los módulos del núcleo) que fueron creados para nuestra experiencia de desarrollador «out-of-the-box» que se centra en la creación rápida de prototipos. Hemos estado manteniendo estos como una serie de parches de flujo descendente durante años después de que los mantenedores relevantes del núcleo de Linux indicaran que nuestra solución no era aceptable para el núcleo upstream. Esto a menudo significa que o bien estamos sentando un mal precedente o no encontramos una solución suficientemente genérica. Esto es importante porque Linux soporta miles de tipos diferentes de hardware y depende en gran medida de abstracciones bien diseñadas.

A lo largo del último año (desde Linux Plumbers 2019), he estado trabajando con los mantenedores y desarrolladores de los subsistemas gpio y pinctrl para conseguir la funcionalidad que BeagleBoard.org necesita en el kernel upstream. El proceso suele ser que intentaré obtener una nueva funcionalidad para un controlador que esté trabajando en mi BeagleBone y luego compartiré el código en la lista de correo en lo que se llama un RFC (solicitud de comentarios). Esta es una forma de solicitar comentarios de otros con más experiencia y pensar sobre cómo podría ser una solución correcta. Después de esa retroalimentación inicial, la puliré más hasta el punto de poder publicar un PATCH en la lista de correo con el código que estoy pidiendo que se añada al núcleo. El mantenedor podría responder rápidamente diciendo que aplicaron el parche a su árbol e irá a Linus Torvalds para la próxima versión. Sin embargo, es normal que la retroalimentación resulte en que yo envíe una segunda revisión. Este ciclo puede continuar durante muchos ciclos. Creo que el más alto al que he llegado es PATCH v5. Sin embargo, para tareas de desarrollo más complejas, como añadir un nuevo controlador a Linux, un desarrollador puede terminar haciendo más de 20 revisiones al parche.

AT: ¿Crees que RISC-V algún día conquistará la informática doméstica? ¿Qué hay de la HPC? ¿Podría la compra de Arm por NVIDIA ayudar a impulsar RISC-V?

DF: Creo que pasará mucho tiempo antes de que algo interrumpa a x86 (AMD e Intel) para la informática doméstica. Los consumidores esperan un alto nivel de rendimiento a un precio bajo y, al mismo tiempo, compatibilidad con software que podría tener décadas de antigüedad. Veo que un conjunto de instrucciones abiertas (ISA) como el RISC-V es muy útil cuando las empresas quieren tener un mayor control sobre el diseño de microarquitecturas y al mismo tiempo poder colaborar con otras organizaciones en las implementaciones de código abierto. La computación móvil es un objetivo más probable para RISC-V en un futuro próximo. Creo que dentro de 2 años tendremos dispositivos móviles como los teléfonos que tengan procesadores RISC-V en el mercado. Puede que no sean los dispositivos de mayor rendimiento, pero hay miles de millones de teléfonos y no todos necesitan el mayor rendimiento.

Y aún mejor para RISC-V son los controladores integrados. Empresas como Nvidia tenían su propia arquitectura interna para los controladores de gestión del sistema en sus GPU. Decidieron adoptar RISC-V para no tener que hacer todo el diseño del procesador y el soporte de la cadena de herramientas de software por su cuenta desde cero. Del mismo modo, Western Digital se ha comprometido a utilizar RISC-V para todos los controladores de sus productos de almacenamiento. RISC-V les permite aprovechar un ecosistema de software en crecimiento, mientras que también tienen la libertad de innovar en la microarquitectura.

Para HPC, el Barcelona Supercomputing Center ha estado muy involucrado en RISC-V, tanto en términos de ingeniería de hardware como de software. La adopción de RISC-V también debería beneficiarse de EPI.

En términos de Nvidia, creo que podemos ver a los licenciatarios de ARM que son competidores de Nvidia empezar a trabajar en los diseños de RISC-V como una forma de mitigar el riesgo. Pero muchas compañías en China ya estaban bien avanzadas en la transición de ARM a RISC-V debido a las payasadas políticas del gobierno de EE.UU. y potencialmente del gobierno británico también. En general, RISC-V es una forma de que las naciones tengan más control soberano sobre la tecnología de los procesadores.

AT: Tengo que confesar que no conocía OSHPARK. Pero encuentro muy interesante poder enviar tus diseños para hacerlos realidad. En el pasado me interesé por los servicios de MPW, y esto es fantástico también para los PCBs. ¿Puedes contar una historia divertida, o algún proyecto loco que alguien haya enviado?

DF: Una cosa que la gente suele preguntar sobre OSH Park, y yo, es ¿por qué tanto morado?! Nuestro fundador Laen comenzó el servicio para un grupo de aficionados a la electrónica de Portland llamado Dorkbot PDX hace unos diez años. Se dieron cuenta de que podían ahorrar dinero combinando todos sus diseños de placas individuales en un gran panel de PCB. En el camino, alguien trajo una placa de circuito púrpura una vez a una reunión de Dorkbot. Laen pensó que se veía muy bien y comenzó a experimentar con los colores de la máscara de soldadura (la pintura que se pone en la parte superior de una placa de circuito, típicamente verde). Después de unos pocos intentos (que resultaron ser marrones), se decidió por nuestro clásico tono púrpura. Los tableros de circuitos púrpura son todavía muy raros en la industria, así que es muy divertido que cuando vemos un proyecto con tableros púrpura en línea o en persona, como es probable que lo hayamos fabricado 🙂 El púrpura ha sido totalmente aceptado por nuestro equipo, desde las versiones púrpuras de cada posible pieza de equipo de oficina hasta mis uñas 🙂

Otra pregunta común es: ¡¿Por qué ese nombre tan raro?! Significa «Parque de Hardware de Código Abierto» y viene de la capacidad de nuestros clientes de elegir compartir sus proyectos en nuestro sitio web para que otros los usen. Durante los primeros años del servicio, sólo se llamaba Dorkbot PDX PCB order. Sin embargo, se hizo más y más popular y Laen, un administrador de sistemas a tiempo completo, pasaba toda la noche manejando los pedidos y tenía que tomar la decisión de convertirlo en un negocio completo o dejar de hacerlo. Afortunadamente, eligió dejar su trabajo de día y comenzar el OSH Park.

AT: ¿Cuál es su trabajo dentro de la Fundación BeagleBoard?

DF: Hablé de esto un poco antes al describir el desarrollo del núcleo que estoy haciendo. Más allá de la codificación, estoy involucrado semanalmente con los otros miembros de la junta para discutir soluciones a los problemas técnicos que se han planteado en nuestra comunidad y también discutir la estrategia para futuros diseños. También asisto a menudo a eventos para representar a BeagleBoard.org y dar charlas en conferencias, aunque eso ha cambiado un poco durante la pandemia.

AT: Sería genial tener una SBC basada en RISC-V. ¿Habrá alguna junta de Beagle en el futuro?

DF: Sí. Queremos construir una placa de desarrollo de hardware de código abierto compatible con Linux RISC-V (esencialmente un BeagleBone RISC-V). El mayor reto ahora mismo es encontrar un System-on-Chip (SoC) que podamos usar y que esté disponible en la distribución y que sea lo suficientemente barato como para hacer una placa de 100 dólares o menos. Nos hemos reunido con varias compañías y hay algunas soluciones prometedoras en el horizonte. El año 2020 no ha sido amable con los plazos de nadie, pero esperamos que esto sea algo que podamos llevar al mercado en 2021. Creo que la disponibilidad de un ordenador monoplaca RISC-V de bajo costo realmente aumentará la adopción, similar a lo que el BeagleBoard original hizo para ARM en 2008.

AT: RISC-V es todavía muy joven. Compite con ISAs veteranas como POWER, ARM, SPARC, etc. ¿Qué destacarías del RISC-V que otros no tengan (además de la licencia)? ¿Y algo que pienses que que todavía necesita ser trabajada para mejorar?

DF: Creo que RISC-V ayudará a que la IP de código abierto sea más una norma en la industria de los chips. RISC-V en sí mismo es sólo un estándar abierto, pero muchas empresas que implementan el conjunto de instrucciones de RISC-V están colaborando de una manera que creo que es nueva para la industria. Producir chips de silicio (por ejemplo, «taping out») es una propuesta costosa, por lo que es importante tener confianza en el diseño. Tradicionalmente, esto significa que las empresas conceden licencias de bloques de propiedad intelectual (por ejemplo, implementaciones de hardware a nivel de chip) a empresas que garantizan su corrección. Organizaciones como OpenHW y CHIPS Alliance se están centrando en cómo la industria puede integrar con confianza núcleos de RISC-V de código abierto en los productos. Todavía es pronto, pero creo que es una buena tendencia del hardware hacia donde está el software hoy en día: los bloques de construcción de los productos son de código abierto y no se reimplantan una y otra vez por cada proveedor.

AT: ¿Qué piensas del acelerador del proyecto EPI o de la CPU Shakti? ¿Algún proyecto basado en RISC-V que te entusiasme especialmente?

DF: Creo que EPI es positivo para tener más diversidad de diseño en la industria del hardware. Creo que la UE quiere fomentar la innovación soberana en lugar de depender de las empresas como Intel. Esta es una buena oportunidad para que las empresas y organizaciones encuentren financiación para probar enfoques innovadores. Shakti de la India es muy emocionante, ya que muestra lo que se puede lograr cuando una nación decide invertir en tecnología de producción propia en lugar de depender de los proveedores de propiedad existentes.

Una laguna que veo ahora mismo es que hay opciones muy limitadas cuando se trata de un RISC-V SoC que es capaz de ejecutar Linux de manera eficaz. Me emocionó ver a los laboratorios RIOS anunciar en la reciente RISC-V Global Summit que están trabajando en un SoC RV64 de bajo costo que esperan tener disponible a principios del próximo año.