2 puntos por GN⁺ 2024-04-30 | 1 comentarios | Compartir por WhatsApp
  • Después de instalar NixOS en un Terramaster F2-221, un SSD USB externo se volvió un estorbo, así que se fabricó un backplane propio para agregar internamente un SSD de arranque NVMe
  • El backplane original del F2-221 estaba centrado en SATA y el circuito de alimentación, y al analizar fotos del F5-422 se confirmó cómo Terramaster expandía las bahías con 2 controladores SATA ASM1061
  • Se siguieron los pares diferenciales PCIe usando fotos del F5-422, la hoja de datos del ASM1061 y la ubicación de los capacitores de acoplamiento, pero algunos pines no pudieron confirmarse hasta el final y tampoco se verificó el pinout de PCIe2
  • La PCB prototipo conectó directamente una ranura M.2 NVMe a una línea PCIe x1 Gen 2; el BIOS mostró Patriot P300 128GB y los discos duros también funcionaron con normalidad
  • El F3 Backplane final se simplificó para usar directamente el riel de 3.3V y, tras varias semanas arrancando desde NVMe y ejecutando btrfs scrub sin errores, el proyecto de KiCad se publicó en GitHub

El punto de partida: eliminar el SSD USB externo

  • El Terramaster F2-221 es un NAS x86_64 estándar basado en Intel J3355, así que instalar NixOS en lugar del TOS original fue algo sencillo
  • Como los 2 conectores SATA ya estaban ocupados por discos duros de 4TB, hubo que conectar un SSD USB externo como dispositivo de almacenamiento del sistema operativo
  • Hacer espacio para el SSD externo detrás del estante, junto al NAS, y preocuparse por el cable cada vez que se movían cosas hizo necesaria una unidad interna
  • La placa madre tenía un conector USB interno para el bootstrap de TOS, pero al ser USB 2.0 no era adecuado para usarlo como SSD de arranque

Comparación entre los backplanes del F2-221 y del F5-422

  • La placa madre del F2-221 tenía un conector con forma de PCIe x4 donde se insertaba la PCB del backplane, pero el backplane original no tenía ningún IC de conversión PCIe a SATA
  • Los conectores SATA estaban cableados directamente al conector de borde PCIe, y la disposición real de pines era un pinout no estándar, no un PCIe estándar
  • El Intel J3355 ofrece 2 puertos SATA y 6 líneas PCIe Gen 2, así que existía la posibilidad de que los modelos Terramaster de 4 y 5 bahías ampliaran los puertos SATA usando líneas PCIe
  • En una foto de alta resolución del review del Terramaster F5-422 se identificaron 2 IC ASMedia ASM1061
    • El ASM1061 es un controlador SATA basado en PCIe Gen 2 x1 y ofrece 2 puertos SATA
    • En el F5-422, se determinó que el primer ASM1061 está conectado a los puertos 3 y 4 del backplane, y el segundo ASM1061 al puerto 5
  • En la parte trasera de la placa madre del F2-221 también se confirmó que los pines que parecían señales PCIe en el backplane del F5-422 realmente estaban cableados

Ingeniería inversa de las señales PCIe

  • Con base en las fotos del backplane del F5-422 y la hoja de datos del ASM1061, se siguieron las líneas PCIe, pero varios pares diferenciales pasaban por vías hacia capas internas, lo que dificultó distinguir entre TX, RX y REFCLK
  • Una de las pistas verificables era que uno de los pines del conector PCIe estaba conectado al PERST# del ASM1061
  • Se aprovechó el hecho de que en PCIe tradicionalmente se colocan capacitores de acoplamiento en el par diferencial de TX para distinguir la dirección de la señal
    • El par diferencial conectado al TX del ASM1061 debía tener capacitores de acoplamiento del lado del backplane
    • Desde la perspectiva de la CPU y la placa madre, ese par diferencial corresponde a RX
    • Se estimó que los pares diferenciales conectados al RX del ASM1061 podían identificarse por la ubicación de los capacitores de acoplamiento del lado de la placa madre
  • Se estimó que REFCLK era el par diferencial restante más cercano al TX y RX de cada interfaz PCIe x1
  • Se importaron las fotos del backplane del F5-422 en KiCad para seguir las trazas externas hasta las vías y comparar posibles rutas en capas internas, validando de forma aproximada el pinout de PCIe1
  • Algunos pines no estaban conectados en el backplane original del F2-221 o entraban a capas internas, por lo que no fue posible confirmar su función
  • El pinout de PCIe2 no se verificó

Reconfiguración del circuito de alimentación

  • Un lado del backplane del F2-221 no tenía IC para señales PCIe, pero sí mucho circuito de alimentación centrado en MOSFET, diodos, resistencias y capacitores
  • Con fotos en primer plano se revisaron los componentes y las trazas, y se redibujó el esquema en KiCad
  • Se determinó que el circuito tenía una estructura de load switch con arranque suave para cada riel de alimentación de los puertos SATA
    • El F2-221 tiene 4 en total: 2 puertos SATA × 2 rieles de alimentación
    • El F5-422 tiene 10 en total, uno por cada combinación de sus 5 bahías
  • Uno de los pines de tierra del conector SATA, P4, era llevado a tierra al conectar un disco duro y se usaba como si fuera el pin de enable del load switch
  • Esta estructura parecía estar pensada para reducir las chispas entre el conector y la unidad causadas por la alta corriente de irrupción inicial al conectar discos duros en hot-plug
  • Para evitar soldar muchos componentes discretos, se eligió el IC de load switch integrado con arranque suave incorporado onsemi NCP45521-L

Por qué se eligió NVMe en lugar de SATA SSD

  • Al principio se consideró agregar puertos SATA con un ASM1061 y fijar un SSD SATA dentro del gabinete
  • Había espacio para un conector M.2 entre los rieles de montaje del backplane, y aunque quedaba muy ajustado, con menos de 1 mm libres a cada lado, sí era posible instalarlo
  • Para usar un SSD M.2 SATA hacía falta un controlador que convirtiera PCIe a SATA
    • Era posible usar un ASM1061 como en el F5-422
    • Pero era difícil comprar el IC ASM1061 suelto, así que habría que retirarlo de una tarjeta PCIe que lo incluyera
  • Como NVMe es PCIe por naturaleza, se podían conectar directamente las líneas PCIe a una ranura M-key M.2 sin controlador adicional
  • Los SSD NVMe normalmente usan 4 líneas PCIe Gen 3 o superiores, pero en este diseño solo se usa 1 línea PCIe Gen 2, así que no se esperaba que la velocidad superara a SATA
  • Aun así, como no hacía falta controlador, el ruteo era más simple y había más opciones de SSD NVMe, NVMe resultó más adecuado para este uso
  • El SSD usado fue un Patriot P300 128GB, comprado localmente por €14.90
  • Como no estaba claro si el BIOS arrancaría directamente desde NVMe, también se contempló como plan de contingencia poner la partición de arranque en una memoria USB 2.0 interna

Fabricación y pruebas de la PCB prototipo

  • La nueva PCB tenía que encajar con la estructura de montaje del backplane dentro del gabinete, así que la posición del conector de borde PCIe y de los orificios para tornillos debía ser exacta
  • Como también había que considerar el tamaño de la PCB y las restricciones del flujo de aire, el prototipo era importante no solo para validar lo eléctrico sino también el ajuste mecánico
  • Se midió la PCB original con regla y calibrador, se redujo la distorsión de lente en una foto frontal y luego se importó en KiCad para alinear conectores, orificios de tornillos y contorno
  • En el prototipo se dejaron los pines no identificados como puntos de prueba, y como el riel de 3.3V se descubrió tarde, se añadió un convertidor buck para bajar de 5V a 3.3V
  • Se pidió una PCB de 4 capas a JLCPCB y llegó unas semanas después
  • Era la primera vez soldando un encapsulado DFN y los componentes eran muy pequeños, pero se comprobó que no hubiera cortos entre alimentación y tierra y se revisó la soldadura con acercamientos de un smartphone
  • Al conectarlo al NAS y arrancar, Patriot P300 128GB apareció en la lista de opciones de arranque del BIOS, por lo que fue posible arrancar directamente desde NVMe
  • No se encontró la línea CLKREQ, que era motivo de preocupación, pero parecía estar permanentemente forzada a nivel bajo en algún lugar de la placa madre y REFCLK sí funcionaba
    • CLKREQ suele usarse para que el SSD solicite el reloj de referencia cuando lo necesita
    • En este diseño ASPM no funciona, pero como se trata de la unidad de arranque de un servidor que siempre está encendido, no parecía un problema importante
  • Los discos duros también funcionaron con normalidad después de conectarlos
  • Como el prototipo creado para pruebas y depuración funcionó correctamente tal cual, el propósito de los pines no identificados dejó de ser importante

Versión final: F3 Backplane

  • El prototipo funcionaba bien, pero tenía puntos de prueba sobrantes y quedaba un poco torcido dentro del gabinete, así que se volvió a fabricar la versión final V1.0
  • En la versión final se eliminó el convertidor buck y se conectó el conector M.2 directamente al riel de 3.3V del conector PCIe
  • Se ajustó ligeramente la posición para reducir la inclinación del prototipo, se quitaron los puntos de prueba y se añadió un logo
  • Se le dio el nombre de F3 Backplane, en el sentido de haberle sumado uno al F2
  • La PCB final, vuelta a pedir a JLCPCB, también funcionó correctamente igual que el prototipo
  • Se ejecutó un btrfs scrub completo sobre los discos duros y no aparecieron errores
  • El sistema se ha ejecutado durante varias semanas desde el SSD NVMe sin ningún hiccup
  • Soldar los conectores SATA fue difícil y quedó algo tosco porque no se añadió thermal relief al plano de tierra interno, pero ese problema ya fue corregido en el repositorio de GitHub

Rendimiento y materiales publicados

  • El resultado de hdparm para el SSD NVMe es el siguiente
/dev/nvme0n1:
 Timing cached reads:   4554 MB in  2.00 seconds = 2279.68 MB/sec
 Timing buffered disk reads: 1222 MB in  3.00 seconds = 407.22 MB/sec
  • No es una velocidad especialmente alta para un SSD NVMe, pero era el resultado esperado al usar solo 1 línea PCIe Gen 2
  • Como unidad de arranque, el rendimiento es más que suficiente
  • El proyecto de KiCad está publicado en GitHub

1 comentarios

 
GN⁺ 2024-04-30
Opiniones de Hacker News
  • Como método para soldar un encapsulado DFN, roza lo completamente descabellado, pero se ve divertido.
    Puede que funcione de alguna manera, pero sería difícil esperar una confiabilidad consistente; parece suficiente solo para un proyecto puntual.

    • En realidad salió bien las 8 veces.
      Por suerte, el pad inferior del encapsulado DFN llegaba hasta ambos bordes, así que fue posible; no creo que este método funcione con QFN.
    • No sé por qué haría falta “demasiada” pasta de soldadura.
      He hecho trabajos similares varias veces con soldadura normal, y basta con poner un poco de más en cada pad, evitando llegar al punto de causar cortos.
      Se aplica flux, idealmente flux de resina que aguante bastante durante la siguiente etapa de calentamiento, se calienta toda la huella con una pistola de aire caliente y luego se coloca suavemente el IC encima.
      Así no hace falta dirigir aire caliente al IC durante mucho tiempo para calentar todo el conjunto.
    • Me parece un método totalmente válido.
      Si siempre pones algunas vías en el pad térmico y dejas expuesto el cobre del otro lado, las vías no quedan tapadas por la máscara de soldadura y absorben el exceso de estaño.
      En trabajos SMD de muy bajo presupuesto, también puedes calentar el pad térmico desde el otro lado con un cautín.
      Está bien presionar el chip, pero hay que tener cuidado con la alineación respecto de los pads.
      En QFN, casi nunca he visto puentes de soldadura, salvo grandes gotas de estaño en el borde exterior.
      Hoy en día, las aleaciones de soldadura y la máscara de soldadura evitan bastante bien los puentes, y la soldadura tiende mucho más a adherirse al metal que a quedarse entre el cuerpo del encapsulado y la máscara de soldadura.
    • Si extiendes más los pads desde debajo del chip hacia afuera, la soldadura manual se vuelve mucho más fácil cuando hace falta.
  • Me gustaría que hubiera más estandarización en los builds de NAS de consumo.
    Llevo años preguntándole a ASUSTOR si no piensa hacer un backplane o adaptador compatible con Mini ITX.
    Sería bueno poder cambiar solo el backplane unos años después, o poder colocar una SBC en un formato tipo Pico ITX.
    No me gusta que después de 5 o 10 años sea difícil actualizar correctamente un NAS.
    Si se pudiera cambiar solo la placa madre, muchos NAS de 1 Gbps podrían subirse a 2.5 Gbps o 10 Gbps, y el chasis podría usarse por más tiempo en vez de terminar en un relleno sanitario.

    • Me gustaría que Framework entrara en este campo.
      Es un desperdicio enorme desechar también el chasis del NAS y el backplane cuando lo único que quedó viejo es la parte de cómputo.
      También podría haber sinergia con la placa madre de la Laptop 13, con TDP de nivel portátil e incluso la posibilidad de ARM.
      Aun así, el mercado de appliances NAS no parece tan grande, más bien de “prosumidores” y pequeñas empresas, y la diferenciación está más en el software que en el hardware.
      La gente compra Synology no por el hardware, sino por DSM.
      Me da pena, porque creo haber leído en algún lado que Framework no tiene planes de integración vertical.
      Sería bueno que hubiera un sistema operativo compatible con Framework en el que cosas como el ahorro de energía o la sensación del touchpad funcionen bien desde el inicio.
    • Ojalá el FLASHSTOR de ASUSTOR fuera una tarjeta de expansión NVMe de 6/12 bahías, en vez de una placa madre integrada + switch PCIe + CPU soldada + RAM soldada.
      Quisiera poder conectar algo así directamente en una PC común, pero los productos que encontré son de 4 puertos o demasiado caros.
    • Puedes comprar una placa Supermicro, hacer el backplane tú mismo o usar uno ya hecho, y agregar tarjetas de expansión según lo que soporte la placa madre.
    • Pero entonces la empresa no podría vender por 500 dólares un chasis y una placa madre de 100 dólares.
      Tú mismo ya diste la respuesta.
  • Siempre me impresiona la profundidad y el esfuerzo que la gente está dispuesta a dedicarle a estas cosas.
    Más aún cuando se trata de trabajos en los que, si algo sale mal, pierdes dinero real, como modificar guitarras o hardware.
    Siento que antes de meterme de lleno en un proyecto así tendría que ganar experiencia con el cautín o con herramientas de carpintería en otros lados.
    También me pregunto por qué no es más grande el mercado de cajitas pequeñas amigables para hackear, donde sea más fácil meter mano en el hardware o el software.
    Me gustaría que existiera un NAS de precio de consumo al que se le pudiera quitar el sistema operativo y reemplazarlo por un OS o kernel normal.
    Tal vez simplemente me da demasiado miedo modificar objetos físicos reales.

    • Armé mi propio NAS por un total de £1000.
      Tiene 24 TB de discos físicos, 16 TB de capacidad utilizable (Raid Z2), corre Ubuntu LTS Server y levanto los contenedores que necesito en Docker con Portainer.
      No es una GUI de clics fácil para cualquiera, y cosas como los montajes SMB hay que crearlas a mano desde la terminal, pero es lo bastante fácil de mantener.
      El hardware es una motherboard Asrock Rack C246 WSI Mini ITX, 32 GB de RAM ECC, un Intel i3-9100T, seis discos IronWolf NAS de 4 TB, un chasis rackmount 2U de poca profundidad y un Samsung 850 Evo de 1 TB como unidad de arranque.
      En reposo consume 23 W, que es suficientemente bajo, y bajo carga sube hasta 65 W.
      Hago que los discos bajen de vueltas después de 10 minutos de inactividad y aun así tienen alrededor de 10 mil ciclos de carga/descarga al año, así que está bien frente a su especificación de 600 mil.
    • Quizá no sea exactamente de precio para consumidor común, pero Supermicro fabrica hardware bastante bueno para NAS.
      Puedes ponerle tus propios discos e instalar el OS que quieras.
      Tengo un equipo con una configuración de 183 TB corriendo TrueNAS (ZFS) y va muy bien.
      Básicamente es una caja x86 estándar con muchas bahías para discos, backplane, puertos SAS/SATA y capacidad de controladora.
      El mercado de segunda mano también es bastante activo.
      Eso sí, está pensado para gente que quiere meter 10 discos o más en un solo chasis, así que llamarlo de consumo queda medio raro.
    • Me pregunto si hoy hay buenas opciones.
      Sigo pensando en comprar un NAS, pero no quiero usar un OS propietario del proveedor que quizá escanee mis datos por integraciones en la nube inútiles u hostiles.
      Tampoco me gusta la posibilidad de que siga existiendo una puerta trasera con contraseña hardcodeada.
    • Hay barebones NAS que soportan dos discos duros de 3.5 pulgadas, dos M.2 NVMe y dos LAN 2.5GbE.
      No sé qué tal sea la calidad del BIOS, y no trae RAM, pero se puede expandir hasta 32 GB y tú pones el OS.
      El modelo Intel Alder Lake N100 cuesta $189: https://aoostar.com/products/aoostar-r1-2bay-nas-intel-n100-...
      El modelo Ryzen 5700 cuesta $299: https://aoostar.com/products/aoostar-r7-2-bay-nas-amd-ryzen-...
    • Si estás dispuesto a meterle mano, hay bastantes opciones.
      Hay gente que usa una Raspberry Pi como NAS; es lenta, pero sirve para backups locales baratos.
      También se pueden rootear NAS integrados antiguos como el DNS-320 y correr una variante relativamente reciente de Debian que aún recibe parches de seguridad.
      Eso sí, las especificaciones de CPU y RAM son muy bajas, así que hay que sentirse cómodo con la línea de comandos.
      Otra opción es comprar un servidor HP Proliant viejo (más o menos gen8), ponerle cuatro discos duros de 16 TB y arrancar desde una quinta unidad.
  • Me da curiosidad la parte que dice: “Este header USB es solo USB 2.0, así que no es una opción para este propósito”.
    No pongo en duda que sea un gran proyecto, pero quisiera saber por qué USB 2.0 no sirve para el OS en un NAS.
    ¿Hace algo más que leer durante el arranque y escribir un poco de datos de vez en cuando?

    • Estoy corriendo un NAS desde un disco de arranque USB 2.0, y el único problema es que systemd-journald no fue diseñado pensando en discos lentos.
      Si hago operaciones con journalctl sobre archivos de logs de 6 meses, toma 1 o 2 minutos por el patrón de acceso a archivos poco óptimo de journalctl.
    • No lo mencioné en el artículo, pero en esta máquina también corro algunas tareas ligeras de servidor, y con una memoria USB 2.0 era desesperantemente lento.
      Claro, no voy a negar que la verdadera razón por la que hice esto fue simplemente porque era divertido trastear.
  • Parece que soy un mal hacker.
    Tuve el mismo problema de tener que conectar un disco externo al NAS, y simplemente lo pegué encima del NAS con velcro.

    • Para este tipo de uso, nada se siente tan práctico como una pistola de silicón.
  • Se ve mucho más genial que el gabinete “custom” que hice con Lego para meter mi NAS casero.
    Conecté cuatro discos duros USB a un hub, y ese hub a una Nvidia Jetson.
    Quería que quedara como una sola pieza, y como los Lego de imitación son tan baratos, fue fácil experimentar.
    También fue divertido, pero esto se ve mucho más profesional y me da un poco de envidia.

  • Sorprendente y elegante.
    Es impresionante que haya llegado tan lejos solo con conjeturas, algo de prueba y error, comprobaciones de continuidad del circuito y una forma bastante ligera de reemplazar el IC de switch de carga.

    • Reuní una cantidad enorme de información de varios foros y de Stack Exchange, y algunas cosas tuve que aceptarlas como hechos a regañadientes.
      Aun así, al final funcionó bien.
  • Es una solución realmente genial.
    Uso el modelo de 5 bahías del mismo NAS, y conecté una memoria USB Samsung al USB interno para instalar TrueNAS Scale.
    Elegí un modelo muy usado para las dashcams de Tesla, así que asumí que al menos tendría cierta durabilidad.
    Hasta ahora estoy satisfecho, pero el rendimiento del CPU sigue quedándose muy corto, así que planeo actualizar a algo más potente.

    • Lo de que el rendimiento del CPU se queda corto es totalmente cierto.
      También pensé en cambiar la motherboard por una carrier custom para módulos de cómputo ARM o por la nueva Lattepanda mu, pero por ahora creo que primero tengo que usar este nuevo proyecto al que le dediqué tanto esfuerzo.
  • Está muy bien hecho, y me gustan este tipo de proyectos en los que la gente toma el control directo de su propio hardware
    También merece otro reconocimiento que lo hayan documentado públicamente
    Aunque me pregunto si habrá problemas con el flujo de aire
    Tanto el PCB original como el modificado tienen un agujero grande en el centro, que supongo sirve para hacer pasar aire sobre los discos
    Pero el disco NVMe lo tapa
    Probablemente se filtre suficiente aire alrededor de los bordes del NVMe como para enfriar bien los discos normales y, de paso, quizá termine teniendo el NVMe mejor enfriado del mundo
    Aun así, el espacio se ve muy ajustado

    • Esa parte también me preocupaba
      No es que sepa mucho de aerodinámica, así que no puedo asegurarlo, pero creo que algo de aire va a pasar por el agujero
      También empujé los separadores roscados para el SSD hasta el extremo izquierdo del PCB con la intención de que pasara más aire por la derecha
      Al menos hasta ahora no he notado que el rendimiento de enfriamiento haya empeorado
  • No es algo que vaya a usar directamente, pero igual me entusiasma
    Ver a alguien meterse tan a fondo, aprender y compartir lo aprendido de verdad me gusta y me resulta inspirador