GXY escribió:stargate escribió:creo que voy a recibir el rembolso y acabare comprando otra pero no de Ali , alguna recomendación ?
tendras que esperar por otro batch de mister pi de taki, lo digo porque comprarle a AV son qmtech tambien.
vaya putada.
si te dan el reembolso sin devolucion te podrias plantear localizar un taller de reparacion de electronica (uno de averias de consolas podria servir) porque si es un fallo del conector HDMI es bastante probable que soldando otro se arregle.
arreglarlo uno mismo yo no lo veo. si se tiene estacion de aire/gas, los materiales adecuados para soldadura SMD de precision, y bastante pericia, tal vez, pero con soldador normal y pericia nivel "he soldado algun cable de vez en cuando" lo normal es que el intento de arreglo empeore las cosas.
como sacaste los diagnosticos? supongo que hiciste SSH al linux pero estaria bien tener un "how to"
-----------------------------------------------------------
Copio y pego el resumen que me ha hecho Claude
Basicamente fui siguiendo punto por punto con su ayuda e íbamos descartando cosas
Cómo diagnostiqué por SSH un MiSTer que dejó de dar señal HDMI
Contexto: MiSTer sobre placa QMTECH (kit "QMTECH MiSTer FPGA SoC" con su I/O board y carcasa). De un día para otro dejó de dar imagen por HDMI. El aparato enciende, los LED internos funcionan. Probado con tres pantallas distintas y varios cables HDMI: nada.
Resumen de lo que hice, por si le sirve a alguien con el mismo síntoma.
1. Descartes físicos primero
Desconecté todos los periféricos USB (Pendrive, mandos, dongle Bluetooth, teclado) y arranqué solo con corriente y HDMI. Sin cambios.
Saqué y volví a meter la microSD. La tarjeta se lee perfectamente en el Mac.
Aviso: que la SD se lea en el ordenador no descarta corrupción. El sistema operativo ve solo la partición grande; el MiSTer arranca también desde una zona previa de la tarjeta que ni siquiera aparece.
2. Encontrar la IP
La documentación oficial no explica cómo localizar la IP: da por hecho que la miras en el router.
ping MiSTer.local no resuelve. El MiSTer no soporta mDNS/Bonjour.
En la lista de dispositivos del router aparece con el hostname MiSTer y la MAC , que lo identifica sin lugar a dudas.
Y esto ya es la primera información útil: si el aparato aparece en el router, el sistema arranca. Si no apareciera, el problema sería la SD o la alimentación, no el vídeo.
3. Entrar por SSH
ssh root@<IP>
Contraseña por defecto: 1
4. Comprobar que el sistema está entero
ls -la /media/fat/
ls /media/fat/*.rbf
ps | grep -i mister | grep -v mister
En mi caso: menu.rbf presente, binario MiSTer presente, proceso corriendo. Nada perdido.
(Detalle curioso: MiSTer.ini no existía. No es fatal — sin él se usan los valores por defecto — pero me hizo sospechar. Y las fechas mostraban que el binario MiSTer se había actualizado el día anterior al fallo.)
5. La comprobación que más aclara: ¿está configurado el FPGA?
cat /sys/class/fpga_manager/fpga0/state
Devolvió operating.
Eso significa que hay un core cargado y generando imagen. O sea: el problema no es que el MiSTer no arranque ni que no saque vídeo. Lo saca. Lo que falla es que esa señal salga por el conector.
6. Registro del kernel
dmesg | grep -iE "hdmi|adv7|i2c|fpga|edid"
Limpio. FPGA manager registrado, bus i2c-gpio inicializado, red a 1 Gbps. Ningún error.
El chip HDMI no aparece en dmesg porque no lo maneja el kernel: lo controla el propio programa MiSTer por I2C. Su ausencia ahí no significa nada.
7. Descartes por software
Forzar un modo de vídeo fijo, saltándose la negociación EDID:
printf '[MiSTer]\nvga_scaler=1\nvideo_mode=0\n' > /media/fat/MiSTer.ini
sync
reboot
Sin cambios.
Volver a la versión anterior del binario. Ojo con esto, porque el primer intento falla:
cp /media/fat/.MiSTer.old /media/fat/MiSTer
cp: cannot create regular file '/media/fat/MiSTer': Text file busy
No se puede sobrescribir un binario en ejecución. Hay que renombrarlo primero, que sí está permitido:
mv /media/fat/MiSTer /media/fat/MiSTer.new
cp /media/fat/.MiSTer.old /media/fat/MiSTer
sync
reboot
Tampoco cambió nada.
8. Preguntarle directamente al chip HDMI
El transmisor HDMI de estas placas es un ADV7513, colgado del bus I2C. Las herramientas están instaladas de serie:
ls /dev/i2c*
which i2cdetect i2cget i2cdump
Escaneo del rango donde vive:
for b in 0 1 2; do echo "=== bus $b ==="; i2cdetect -y -r $b 0x38 0x3f; done
Resultado: en el bus 1 responden 38 y 39 — las dos direcciones del ADV7513 (0x39 mapa principal, 0x38 lectura del EDID de la pantalla).
El chip está vivo. Descartado que esté muerto o sin alimentación.
9. El diagnóstico definitivo: dos registros
i2cget -y 1 0x39 0x41
i2cget -y 1 0x39 0x42
Resultado:
0x10
0x98
Según la guía de programación del ADV7513 (Analog Devices):
Registro 0x41, bit 6 = control de apagado. 0 = encendido. 0x10 → bit 6 a cero → el chip está encendido y operativo.
Registro 0x42, bit 6 = estado del Hot Plug Detect. Bit 5 = terminación de reloj HDMI detectada. 0x98 = 1001 1000 → bit 6 a cero y bit 5 a cero.
Es decir: el chip está alimentado y funcionando, pero no detecta ninguna pantalla conectada.
Repetí la lectura con una televisión ya encendida antes de conectar el cable: siguió dando 0x98.
10. Conclusión
El Hot Plug Detect es una línea física del conector: la placa da 5 V por el pin 18 y la pantalla responde levantando el pin 19. Ese registro refleja el estado eléctrico de un pin — ninguna configuración, imagen de SD ni versión de firmware puede alterarlo.
Con el FPGA en operating, el chip encendido, el dmesg limpio y el HPD en bajo con tres pantallas y varios cables, la conclusión es que hay una avería de hardware en el tramo entre el conector HDMI y la entrada HPD del chip: soldaduras del conector, el fusible o diodo de protección de los 5 V del puerto, una pista cortada, o el propio pin del chip dañado. Distinguir cuál requiere polímetro.
El aparato tenía dos meses. Acabé tramitando devolución y reembolso.
-------------------------------------------------------------