[Tutorial] Analizar y Resolver problemas RGH/Jtag

Al arrancar la consola ejecuta una pequeña porcion de codigo en la CPU de solo lectura el 1bl.bin (bootloader 1)

Este se encarga de ciertos procesos que ahora no es necesario entender (inicializar Hards ...) , lo importante es que se comienza la bootsequence cargando el siguente bootloader 2bl (CB) , desencriptandolo , comprobando que es original y ejecutandolo en caso de que lo sea.

Este mismo proceso se va repitiendo con los consecutivos bootloaders CD,CE,CF,CG,DASH.

Inicialmente este proceso por motivos debug utilizaba un puerto (postout) de 8 bits que nos iba diciendo en que punto exacto del bootsequence (secuencia de arranque ) se encontraba la consola.

En una de las ultimas actualizaciones de Dash se anulo el postout capando el RGH hasta la aparicion de los CBa Rip que permitio volver a usarlo.

Si nosotros modificamos (parcheamos) uno de esos bootloaders para que , por ejemplo, se salte ciertos checks, el bootloader (anterior en la secuencia ) al cargarlo comprobaria que el hash no coincide y al detectar que esta modificado provocaria un "panic" y no arrancaria la consola.

Gligli se puso manos a la obra y decidio un punto de esta secuencia para romper la comprobacion (hash) de un bootloader y asi poder parchear todo lo que queramos a partir de ese punto (bootloader, Kernel, Dash ...).

No voy a extenderme mucho en este proceso ya que hay mucha info al respecto. Solo decir que decidio desestabilizar la Cpu glitcheandolo ( nano reset de la CPU) en el momento exacto en el que realiza el check hash al cargar el bootloader parcheado.

CPURST:

Este es el punto usado para desestablizar la Cpu. Soldamos un cable del chip al Cpu para enviar un 0 logico provocando un reset en el momento exacto durante escasos nanosegundos.

La Cpu comprueba la integridad del bootloader calculando su Hash y enviandolo a un registro del CPU y comparandolo con el Hash correcto guardado en otro registro del CPU.

Si justo en el momento de realizar esta comparacion le pegamos un viaje (cpurst) y tenemos suerte respondera que "SI" aunque no lo sean y la secuencia de arranque continua.

Si no hacemos el cpurst en el momento justo de esta comparacion respondera que "No" son iguales y entrara en "panic" , si el cpurst es muy corto no sera suficiente para desestabilizar la Cpu, y si es demasiado largo dejaremos la CPU colgada , perdera algun registro vital y tendremos algun tipo de cuelgue en la secuencia de arranque, reiniciandose todo el proceso para reintentarlo.

El SMC original al quinto intento nos mostraria luces rojas. Al estar el SMC parcheado para reinicios infinitos el chip lo reintentará hasta que lo consiga.

POSTOUT:

El chip lo que hace es usar el puerto post out a traves de un cable soldado a uno de sus bits ya que Gligli observo que solo necesitaba debuguear uno de sus 8 bits para saber el momento deseado exacto en el cual pretendia desestabilizar la CPU.
Gracias a este punto el chip sabe exactamente cuando frenar (se enciende el Debug Led) el CPU , hacer el cpurst y volver al CPU a su velocidad normal (Apagado del Debug Led) .

Conozco sceners que estan desarrollando chips usando todos los bits del postout obteniendo muy buenos resultados al ser mas preciso el debug del proceso.

PLL/SDA&SDL:

La velocidad del chip utilizado en su momento era muy baja con respecto a la del Cpu con lo cual no era capaz de golpear en el momento exacto.

Pongamos un ejemplo para entender mejor el problema de las velocidades (MHZ)

Imaginemos dos vehiculos en una carretera avanzando en la misma direccion , si sale el coche A mas lento (chip) va a 30 Km/h y despues sale el coche B (CPU) mucho mas rapido 1000 km/h adelantara en un momento concreto al coche A.

Pues bien un valiente quiere saltar del techo del coche A al coche B justo al adelantarlo, al ser tantisima la diferencia de velocidad es casi imposible acertar el momento exacto de saltar, o saltara antes de tiempo o saltara despues y ostia al canto!.

Si justo antes de adelantar el coche B al A frenamos el coche B (CPU) a 100 Km/h seguira siendo dificil el momento exacto pero habra muchas mas probabilidades de exito y una vez el valiente haya saltado con exito dejar de frenarlo para que continue a su ritmo.

Esta fue la idea y gligli busco una forma para frenar la CPU en las Fat y descubrio el punto PLL en la placa, con un cable de este punto al chip enviando un 0 logico consiguió su objetivo. En las slim con dual CB no era valido este metodo y tuvo que optar por enviar un comando a traves del puerto SPI que tambien conseguia frenar la CPU aunque no tanto como el PLL de las Fat Rgh1 y por eso era algo mas dificil glitchearlas. Mas tarde en las Fat RGH1 a traves de una actualizacion pasaron a ser dual CB (Rgh2) anulando la posibilidad de usar el PLL y tuvieron que pasar al sistema de frenado del CPU de las Slim siendo aun mas inestables.


CLK:

Este punto es el que marca la velocidad de nuestro chip. Hay chips que usan uno de los CLK de la placa soldando un cable al chip y otros chips como el Squirt al llevar su propio CLK no necesitan este punto. Las placas coronas eliminaron el CLK usado por los chips clasicos con lo cual obligaban a usar chips con CLK interno. Squirt fue una vez mas el pionero.

Cuanto mas rapido sea el CLK usado por el chip mejor sera la relacion de velocidad que explicaba antes entre chip y CPU aumentando la probabilidad de exito y la estabilidad del mismo.

Se rumorea que Squirt esta desarrollando una version de su magnifico Bga 1.2 con cristal de 100MHZ que promete aportar estabilidad en consolas problematicas.

VCC/GND:

Estos ultimos puntos no necesitan de mucha explicacion, simplemente alimentan el chip, cada modelo trabaja a un determinado voltaje , la mayoria usan 3,3v pero otros como el DGX usa 5V.


Si entendemos todo este rollo nos sera mas facil entender cierto problemas.

CPURST:

* Este cable es el mas delicado ya que el pulso que envia debe ser increiblemente preciso y puede verse afectado por interferencias provocadas por los propios componentes de la placa (bobinas ...) , el ventilador , la chapa, etc. Incluso el numero de dispositivos USB (mandos, hdd...) enchufados en la consola , el tipo de alimentador de la consola, el grosor o largo de los cables etc son suficientes para que el pulso no llegue en su momento o duracion adecuada.

El famoso largo del Cpurst es importante por el simple hecho de que una señal logica no es mas que una corriente electrica. Si un punto tiene 0V se considera un 0 logico y un 1 logico sera si ese punto tiene un voltaje suficiente segun cada caso.

Esta corriente va a traves de un cable y segun su largo a nivel de nanosegundos puede verse afectado tanto en el momento que tarda en llegar a la CPU como a la intensidad y largo del pulso enviado.

De modo que si este cable esta mal instalado provocara:
- Si no esta conectado no enviara el pulso, la consola entrara en bucle o glitcheo infinito.
- Si el largo , posicion ... no es el exacto el glitcheo sera inestable o incluso infinito.

POSTOUT:

* Si este punto falla el chip no conseguira saber con exactitud el momento de frenar y hacer el cpurst.
- No se enciende el DebugLed ( cable desconectado o mal soldado)
- Se enciende de forma inestable
- O simplemente no acierta y glitcheo infinito.

PLL/SDA&SDL:

* Si estos puntos no estan correctamente instalados no frenara adecuadamente la CPU y no acertara en el momento exacto:
- El Debugled se enciende mas rapido de lo normal
- El Debugled se mantiene encendido inestablemente, glitchs cortos y largos aleatorios.
- Si no puenteamos correctamente las resistencias ausentes en el SPI de las coronas sin postout provocara inestabilidad al no frenar correctamente la CPU. A veces es conveniente usar resistencias o cables largos para hacer estos puentes.

CLK:

* Si este punto falla o el reloj interno falla al estar el chip programado para actuar en ciertos instantes si su reloj esta mal no acertara en el momento de actuar.
- Si no se conecta bien el chip no arrancará.
- Si falla la velocidad de proceso del chip sera inestable.
- Si el clk es lento con respecto al Cpu aleatoriamente al chip puede no darle tiempo a hacer el proceso glitch y el CPU se le pasara de largo. Posible causa por la que algunos chips clasicos con clk 48mhz no consiguen glitchear establemente algunos nuevos modelos (corona con nand Toshiba Ntsc)

VCC/GND:

* Si estos cables fallan ni siquiera se encendera el chip. Si usamos cables inadecuados puede provocar inestabilidad en el resto de lso puntos del chip y al propio funcionamiento del chip.Se suelene usar cables mas gordos en estos puntos para ayudar en la estabilidad.

- Si falla el VCC/GND No se enciende el led de encendido.
- Cables inadecuados provocará inestabilidad general del chip.

OTROS:

Algunas veces el chip inestabiliza los voltajes de la consola y se producen cuelgues aleatorios. Editando ciertos parametros relacionados con los voltajes en el SMC_config solventa estos problemas. (Power Mode, Ana Fuse ...)

Muchos se preguntan que diferencia hay en los timmings como los del RGH2_A,RGH2_B... o incluso entre Modelos Falcon, Jasper ...

Pues bien , los timming o .svf de un mismo chip solo varian entre un modelo y otro de consola en los pulsos de reloj que sirven de contador para calcular el momento y longitud del nanopulso.

Los bootloaders son diferentes en cada modelo y por tanto tienen una cantidad de instrucciones diferente, esto hace que el momento en el tiempo en el que debemos hacer el cpurst logicamente no coincide.

Ejemplo Rgh1
constant WIDTH_RESET_START : integer := 1603; -- zephyr: 1723, falcon: 1603, jasper: 1628
constant WIDTH_RESET_END : integer := 5;
constant WIDTH_BYPASS_END : integer := 48000;

Logicamente tambien varia si hay o no dual CB.

Rgh1
constant POST_37 : integer := 13;
constant POST_39 : integer := 14;
constant POST_3B : integer := 15;

Rgh2
constant POST_B8 : integer := 12;
constant POST_BA : integer := 13;
constant POST_BB : integer := 14;

El tema de los codigos vhd de Xilinx daría para mucho pero no me voy a extender ahora para no complicaros.

Quizas cree un nuevo Tutorial explicando paso a paso el codigo vhd de los chips.

Como vemos es un proceso que requiere una maxima precision y estabilidad a la maxima velocidad posible. Cuanto mas rapido (mhz) sea el chip y fiable sea el fabricante (Team) mejores resultados tendremos a corto,medio y largo plazo.

Por supuesto una mala instalacion , un corto ... pueden dañar la consola.Pero es importante recordar que dias o meses despues de una instalacion por deterioro del chip si se unen ciertas circunstancias en el proceso de glitcheo podemos dañar irreversiblemente la CPU (0022...).

Si por ejemplo el chip falla al frenar la CPU y realiza el cpurst cuando el la CPU esta a una alta velocidad puede dañarlo.

Si por ejemplo el chip es inestable y una vez arrancada la consola a pleno rendimiento se despierta erroneamente y realiza un cpurst tambien podria dañar la CPU.

Por eso si quieres asegurarte un glitcheo estable y por mucho tiempo personalmente recomiendo chips fabricados por Teams que se juegan su reputacion y por lo tanto usaran componentes de calidad , estabilidad y durabilidad.