rodries escribió:Es que yo pienso que el reset se debe hacer en caso de error solamente, y de hecho cuando un comando me devuelve error yo sigo intentando el siguiente paso, a veces el test_ready me da error pero lo ignoro y al llegar al capacity me devuelve el tamaño por lo que el montaje es correcto. Gracias a esto hay un monton de devices que funcionan aunque alguno de los pasos reporte error, lo único que hay que tener cuidado en usar el disable_hard_reset cuando tires un reset para intentar levantar un dispositivo no vayas a entrar en un bucle infinito. También hay un par de devices que me han reportado un error en el sense devolviendo unit not ready pero todos los pasos continuan y al leer el primer sector devuelve error y hace falta hacer un hard reset para que se levante la unidad. La verdad es que los dispositivos baratos no siguen ninguna norma, lo que hacen los chinos es implementarlos a ojo y ver si en windows funcionan. Me he encontrado un device que ni siquiera funciona en linux pero si en windows y en el nuevo driver usb2 de la wii, así que la mayoría de los errores son por implementaciones chapuzeras del protocolo.
El Reset Bulk se debería poder hacer siempre. Si no está soportado, entonces se podría esquivar. Si miras en usbstorage.c en libogc, verás que se comprueba si despues del reset, se reporta error -7004 (que debe ser timeout) y se permiten los USB_ClearHalt para poder continuar (eso es lo que hago en mi ultima modificación).
Sobre los otros comandos que mencionas, en los fuentes que me enviaste, veo que empleas un timeout de 200ms, mientras que yo empleo mínimo 1s y en el test_ready 5s, con lo cual a mi no me reportan timeout salvo que de verdad haya un problema (que entonces se repetiría el proceso, pero nunca le falta tiempo para que un comando eche a andar)
Además, tu handshake() no gestiona los flags de estado de forma adecuada: así por ejemplo, en mi caso si se produce un error a medio camino, cancelo y limpio los flags, evitando que se tenga que cumplir todo el tiempo de timeout y eso me permite meter unos tiempos mucho mayores (y así si un device tarda 3 segundos en estar listo, no me va a dar error, ni me tengo que saltar nada)
Por otro lado, en mi caso no se entra en procesos de bucle infinito en reset, ni hay problemas de recursividad, ya.
rodries escribió:Hay algunos dispositivos que están diseñados para inicializarse sólamente al pincharlos ya que se supone que un SO no se suele reiniciar y en tal caso se reinicia el pc al complento por lo que si no los sacas y los vuelves a pinchar no se inicializan, por eso hay algunos que tienes que sacarlos y volverlos a pinchar para que se inicializen y si no haces esto no hay forma de inicializarlos una vez inicializados por el hbc y en cambio hay otros que sólo funcionan si los pinchas antes de encender la wii.
Si, eso ya lo se. Incluso puede ocurrir que un dispositivo de un error interno y no responda a ningún comando y la única forma de hacerlo, es desenchufar/enchufar. Pero eso no quita a que en la mayoría de las ocasiones, si se pueda inicializar o limpiar la condición de error, sin necesidad de desenchufarlos o que a buenas malas, un device trabado, pueda volver a funcionar porque el driver se queda esperando a que hagas eso, sin provocar muerte ruidosa, ni quedarse flipado de forma irrecuperable porque se ha detenido en un punto inadecuado.
Es lo malo de que la Wii no permita controlar el power del puerto
rodries escribió:La verdad es que es un coñazo hacer que funcionen todos los devices y a no ser que me encuentre algún dispositivo que me interese reparar voy a pasar un poco ya de seguir mejorando la compatibilidad del driver, además nadie está usando tu driver excepto yo.
Aunque supongo que waninkoko estará copiando tus mejoras en su cios, que para mí es un atraso al no usar el mload que es lo que le da mucho juego a tu cios y una potencia bestial de cambiar cosas en runtime.
Hombre, yo creo que nadie nos pide que arreglemos todos los devices y sinceramente, no es algo que me preocupe demasiado: mi objetivo es que al menos, los que funcionen, lo hagan bien y sin problemas raros.
Luego hay otros que me han reportado -1204 y se ha demostrado que es del Reset Bulk y es lo que estoy mirando, si hay alguna forma de permitir dicho comando sin que suponga un problema para ésta gente.
Sobre eso de que nadie está usando mi driver... te referirás a programadores homebrew porque creo que hay mucha gente que lo está usando a diario bajo uLoader al menos y es de lo que se trata: de que la gente pueda utilizar en lo posible sus dispositivos-
Lo demás no me preocupa en absoluto: si usan o no mload, si usan o no el módulo ehci, etc, no me va a quitar el sueño
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
.![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
)![[mad]](/images/smilies/nuevos/miedo.gif "loco")
no puedo hacer funcionar el metal slug con uloader 2.7 o mas bien no entiendo bien como...me encuentra 2 dol ms6.dol y emu.dol pero cuando intento cargar el ms6 con cualquiera de los 2 me reinicia la consola.... ![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
¿alguien que me pueda orientar?... ![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
No he tenido ningun problema con la version 2.7,solo lo de el metal sulg 6 que encuentra 2 dol alternativos y ninguno carga el ms6(pido ayuda en eso)pero por lo demas ningun problema probe 10 juegos aprox. y a pesar de los problemas que comentan aqui no he tenido ninguno con la rev 14 de cIOS y probando entre otros con red steel y obviamente con metal slug anthology....repito ningun problema de reconocimiento de discos ni nada,pido ayuda con el metal slug. 
), pero tambien creo que tu pregunta no esta hubicada en el lugar correcto, creo que le pega más el foro de "parcher y grabación".... ¿no crees?.![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
