[Investigación] PsGroove en PSP

Cerrado
1…24, 25, 26, 27, 28…30
Saludos wuepe, no sé si ya tendrás por ahi este header y quizás de ahi supiste que era por fifo, acá te dejo extractos por si acaso:

#define SCE_USBPSPCM_DEVNAME         "usbpspcm:" /*E Device file name */
#define SCE_USBPSPCM_DEVNAME_LENGTH  16 /*E Maximum length of device file name */

#define SCE_USBPSPCM_RDWR_MODE       0x03416102
#define SCE_USBPSPCM_RDWR_NORMAL     0x00U
#define SCE_USBPSPCM_RDWR_RD_SEQ     0x01U
#define SCE_USBPSPCM_RDWR_WR_SEQ     0x02U

#define SCE_USBPSPCM_HOST_ADDR       0xFF


Por lo que parece haber una especie de sistema de archivos usbpspcm:/, ya tenemos por donde empezar a buscar.

Edito: Añado un pdf de "a saber donde", por ahi se ve como usa iodevctl para mandar paketetes.
http://www.delcom-eng.com/downloads/USBPRGMNL.pdf
(si bien no es psp, se puede estudiar igualmente)
Aquí hablan sobre la Redirección de USB

http://www.psp-programming.com/forums/i ... 4.msg18012

Aquí tienes detalles en español con ejemplos comentados debidamente sobre // _____ PSP USB & USB STOR ______ // y hace mención del requerimiento de "-lpspusb -lpspusbstor" en el makefile para poder compilar sin error.

http://psp.scenebeta.com/tutorial/tema- ... as-1-parte

De encontrar mas información la comparto lo antes posible =) , espero que esto les sirva de referencia, yo por mi parte hare un par de pruebas mas tarde para ver que descubro.

Saludos DeViaNTe y Wuepe.
Añado, parece ser que el problema viene por esta estructura:
   const unsigned short HUB_Hub_Descriptor[] = {
   0x09, 0x29, 0x06, 0xa9, 0x00, 0x32, 0x64, 0x00,
   0xff,
  };


Que en realidad, el nº de puertos en la psp, lo toma del 2º atributo, no del 3º, y mandaba que tenia 0x29 puertos(41 decimal), en vez de 6.

Cambiando el 0x29 por 0x06, ya funciona, pero claro los demás datos pueden no coincidir. Así que he usado la structura de DeViaNTe.

Asi que se añade este descriptor.

struct HubDescriptor {
    unsigned char bLength;
    unsigned char bDescriptorType;
    unsigned char bNumberOfPorts;
    unsigned short wHubCharacteristics;
    unsigned char bPowerOnToPowerGood; /* Port settling time, in 2ms */
    unsigned char bHubControlCurrent;
    unsigned char bRemoveAndPowerMask[64];
} __attribute__((packed));


#define USB_DT_HUB_SIZE                                 9

/* Descriptor del HUB */
static struct HubDescriptor hubdesc =  {   
    .bLength                = USB_DT_HUB_SIZE,      // Tamaño del descriptor del tipo "hub"
    .bDescriptorType        = USB_DT_HUB_DESCRIPTOR,            // Tipo: HUB
    .bNumberOfPorts         = 6,                            // 6 puertos
    .wHubCharacteristics    = 0x00A9,                       // Modo de alimentación de los puertos.
    .bPowerOnToPowerGood    = 50,                           // Corriente requerida para estar estable: 50x2 = 100 mA
    .bHubControlCurrent     = 100,                          // Corriente requerida para el control: 100mA
    .bRemoveAndPowerMask    = { 0x00, 0xFF },       // Máscaras de eventos.
};

y se cambia el envio del descriptor en el callback

/* Device request */
int usb_request(int arg1, int arg2, struct DeviceRequest *req)

Modificando esta linea
//usb_send_request((void *)HUB_Hub_Descriptor, sizeof(HUB_Hub_Descriptor),0); // endpoint 0 control
por
usb_send_request((const unsigned char *)&hubdesc, sizeof(hubdesc),0); // endpoint 0 control



ahora ya recibe correctamente que tiene 6 puertos, por lo que queda libre ese callback, parece ser que el comando de cambiar puerto, que se usaba, si funciona y ahora empieza a pedir Get_Port_Status, aunque el que pide es el de hub y luego el del Set_Port_Feature, asi que ahora falta, que mande el RESET_PORT

Dejo esto aqui, para que sigais avanzando, pero esta tomando pies esto.
wuepe escribió:Añado, parece ser que el problema viene por esta estructura:
const unsigned short HUB_Hub_Descriptor[] = {
0x09, 0x29, 0x06, 0xa9, 0x00, 0x32, 0x64, 0x00,
0xff,
};

Que en realidad, el nº de puertos en la psp, lo toma del 2º atributo, no del 3º, y mandaba que tenia 0x29 puertos(41 decimal), en vez de 6.

Cambiando el 0x29 por 0x06, ya funciona, pero claro los demás datos pueden no coincidir. Así que he usado la structura de DeViaNTe.

Asi que se añade este descriptor.

/* Descriptor del HUB */
static struct HubDescriptor hubdesc = {
.bLength = USB_DT_HUB_SIZE, // Tamaño del descriptor del tipo "hub"
.bDescriptorType = USB_DT_HUB_DESCRIPTOR, // Tipo: HUB
.bNumberOfPorts = 6, // 6 puertos
.wHubCharacteristics = 0x00A9, // Modo de alimentación de los puertos.
.bPowerOnToPowerGood = 50, // Corriente requerida para estar estable: 50x2 = 100 mA
.bHubControlCurrent = 100, // Corriente requerida para el control: 100mA
.bRemoveAndPowerMask = { 0x00, 0xFF }, // Máscaras de eventos.
};

y se cambia el envio del descriptor en el callback

/* Device request */
int usb_request(int arg1, int arg2, struct DeviceRequest *req)

Modificando esta linea
//usb_send_request((void *)HUB_Hub_Descriptor, sizeof(HUB_Hub_Descriptor),0); // endpoint 0 control
por
usb_send_request((const unsigned char *)&hubdesc, sizeof(hubdesc),0); // endpoint 0 control

ahora ya recibe correctamente que tiene 6 puertos, por lo que queda libre ese callback, parece ser que el comando de cambiar puerto, que se usaba, si funciona y ahora empieza a pedir Get_Port_Status, aunque el que pide es el de hub y luego el del Set_Port_Feature, asi que ahora falta, que mande el RESET_PORT

Dejo esto aqui, para que sigais avanzando, pero esta tomando pies esto.



Bolas esto es animador grax por su chambas [sonrisa]
wuepe escribió:Añado, parece ser que el problema viene por esta estructura:
   const unsigned short HUB_Hub_Descriptor[] = {
   0x09, 0x29, 0x06, 0xa9, 0x00, 0x32, 0x64, 0x00,
   0xff,
  };


Que en realidad, el nº de puertos en la psp, lo toma del 2º atributo, no del 3º, y mandaba que tenia 0x29 puertos(41 decimal), en vez de 6.

Cambiando el 0x29 por 0x06, ya funciona, pero claro los demás datos pueden no coincidir. Así que he usado la structura de DeViaNTe.

Asi que se añade este descriptor.

struct HubDescriptor {
    unsigned char bLength;
    unsigned char bDescriptorType;
    unsigned char bNumberOfPorts;
    unsigned short wHubCharacteristics;
    unsigned char bPowerOnToPowerGood; /* Port settling time, in 2ms */
    unsigned char bHubControlCurrent;
    unsigned char bRemoveAndPowerMask[64];
} __attribute__((packed));


#define USB_DT_HUB_SIZE                                 9

/* Descriptor del HUB */
static struct HubDescriptor hubdesc =  {   
    .bLength                = USB_DT_HUB_SIZE,      // Tamaño del descriptor del tipo "hub"
    .bDescriptorType        = USB_DT_HUB_DESCRIPTOR,            // Tipo: HUB
    .bNumberOfPorts         = 6,                            // 6 puertos
    .wHubCharacteristics    = 0x00A9,                       // Modo de alimentación de los puertos.
    .bPowerOnToPowerGood    = 50,                           // Corriente requerida para estar estable: 50x2 = 100 mA
    .bHubControlCurrent     = 100,                          // Corriente requerida para el control: 100mA
    .bRemoveAndPowerMask    = { 0x00, 0xFF },       // Máscaras de eventos.
};

y se cambia el envio del descriptor en el callback

/* Device request */
int usb_request(int arg1, int arg2, struct DeviceRequest *req)

Modificando esta linea
//usb_send_request((void *)HUB_Hub_Descriptor, sizeof(HUB_Hub_Descriptor),0); // endpoint 0 control
por
usb_send_request((const unsigned char *)&hubdesc, sizeof(hubdesc),0); // endpoint 0 control



ahora ya recibe correctamente que tiene 6 puertos, por lo que queda libre ese callback, parece ser que el comando de cambiar puerto, que se usaba, si funciona y ahora empieza a pedir Get_Port_Status, aunque el que pide es el de hub y luego el del Set_Port_Feature, asi que ahora falta, que mande el RESET_PORT

Dejo esto aqui, para que sigais avanzando, pero esta tomando pies esto.


VAMOS A POR EL CUERPO!!! XD GRAN TRABAJO.
wuepe escribió:
Añado, parece ser que el problema viene por esta estructura:
   const unsigned short HUB_Hub_Descriptor[] = {
   0x09, 0x29, 0x06, 0xa9, 0x00, 0x32, 0x64, 0x00,
   0xff,
  };


Que en realidad, el nº de puertos en la psp, lo toma del 2º atributo, no del 3º, y mandaba que tenia 0x29 puertos(41 decimal), en vez de 6.

Cambiando el 0x29 por 0x06, ya funciona, pero claro los demás datos pueden no coincidir. Así que he usado la structura de DeViaNTe.

Asi que se añade este descriptor.

struct HubDescriptor {
    unsigned char bLength;
    unsigned char bDescriptorType;
    unsigned char bNumberOfPorts;
    unsigned short wHubCharacteristics;
    unsigned char bPowerOnToPowerGood; /* Port settling time, in 2ms */
    unsigned char bHubControlCurrent;
    unsigned char bRemoveAndPowerMask[64];
} __attribute__((packed));


#define USB_DT_HUB_SIZE                                 9

/* Descriptor del HUB */
static struct HubDescriptor hubdesc =  {   
    .bLength                = USB_DT_HUB_SIZE,      // Tamaño del descriptor del tipo "hub"
    .bDescriptorType        = USB_DT_HUB_DESCRIPTOR,            // Tipo: HUB
    .bNumberOfPorts         = 6,                            // 6 puertos
    .wHubCharacteristics    = 0x00A9,                       // Modo de alimentación de los puertos.
    .bPowerOnToPowerGood    = 50,                           // Corriente requerida para estar estable: 50x2 = 100 mA
    .bHubControlCurrent     = 100,                          // Corriente requerida para el control: 100mA
    .bRemoveAndPowerMask    = { 0x00, 0xFF },       // Máscaras de eventos.
};

y se cambia el envio del descriptor en el callback

/* Device request */
int usb_request(int arg1, int arg2, struct DeviceRequest *req)

Modificando esta linea
//usb_send_request((void *)HUB_Hub_Descriptor, sizeof(HUB_Hub_Descriptor),0); // endpoint 0 control
por
usb_send_request((const unsigned char *)&hubdesc, sizeof(hubdesc),0); // endpoint 0 control



ahora ya recibe correctamente que tiene 6 puertos, por lo que queda libre ese callback, parece ser que el comando de cambiar puerto, que se usaba, si funciona y ahora empieza a pedir Get_Port_Status, aunque el que pide es el de hub y luego el del Set_Port_Feature, asi que ahora falta, que mande el RESET_PORT

Dejo esto aqui, para que sigais avanzando, pero esta tomando pies esto.


Vaya, que interesante lo que has encontrado sobre los puertos, yo por mi parte andaba rompiéndome la cabeza editando el código en varias partes probando cosas xD, me había retirado a dormir y regrese a codificar algo que se me ocurrió pero al fin y al cabo no funciono jaja!.

Por lo menos con este progreso me voy a dormir un rato que aquí son las 5:00AM (Eastern Time), pero luego regreso a ver como van y si puedo ayudar en algo.

Saludos Wuepe y animo!.

PD: GRACIAS A LOS USUARIOS QUE NOS HAN DEJADO EL MENSAJE DE INVESTIGACIÓN BASTANTE LIMPIO DE UN TIEMPO PARA ACÁ, POR FAVOR SIGAN ASÍ, GRACIAS!. CUALQUIER COMENTARIO DIRIGIRLO AL HILO DE DEBATE COMO YA LO ESTÁN HACIENDO ^^.
Wuepe ahora que lo veo tienes toda la razon sobre lo de la estructura y nosotros comiendonos la olla con el bucle del request del USB que no paraba nunca xD vueno ahora solo falta el resert_port.
Minami escribió:Wupe ahora que lo veo tienes toda la razon sobre lo de la estructura y nosotros comiendonos la olla con el bucle del request del USB que no paraba nunca xD vueno ahora solo falta el resert_port.


resert_port y a volar?? :O
pupila1992 escribió:
Minami escribió:Wupe ahora que lo veo tienes toda la razon sobre lo de la estructura y nosotros comiendonos la olla con el bucle del request del USB que no paraba nunca xD vueno ahora solo falta el resert_port.


resert_port y a volar?? :O


No, no es tan facil, pero mas cerca si que estamos ;)
playstation_9999 está baneado por "usar clon para saltarse baneo temporal"
Hola pueden subir los compilados eboot y prx ultimos para testearlos animo
Comento, para testeo de desarrolladores, usamos el eboot para kernel 1.5 que muestra los comentarios(printf) para depurar el código, puede usarse un eboot para 3.xx pero este no sirve para testeo de desarrolladores, puesto que si funciona, pero no muestra los datos del prx en pantalla, es el propio eboot quien puede pintar.

Por ello, si es para testeo de desarrolladores bien, si es para de usuarios en particula, que solo testeen, no es necesario que bajeis de versión a 1.5, ni 5.00m33(o inferior m33/oe) con addon kernel 1.5(en caso de eo lleva kernel 1.5 de base) ni useis el timemachine para iniciar en hibrido 1.5/3.40 en caso de slim.

Por ello pongo incapie, en que una vez que este desarrollado, tendría que funcionar ya para las demás consolas, sin tener que usar kernel 1.5

Por ahora, es mejor que se pongan fuentes, y si quieren testear algo, que tengan 1.5 para que vean hace su proceso, para kernel 1.5 podeis usar el primer eboot para 5.00 creado.
Mu Bien, ahora solo faltan las fuentes [360º] wuepe si necesitas ayuda con las depuraciones o algo avisa que te ayudo ;)
Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/

Edito, subo a megaupload.
Código Fuente:
driver rv33

Compilado:
eboot kernel 1.5 bin
driver rv33 prx

Repito, necesario kernel 1.5, puesto que es para testeos de desarrolladores, en kernel 3.xx se puede usar el eboot 5.xx pero este no muestra los datos del driver para su testeo
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/


wuepe despues de este gran avance cuando crees tu que prodremos , hacer el ps groove a traves de nuestras psp¿?¿
ante todo enhorabuena por el progreso
samtr escribió:
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/


wuepe despues de este gran avance cuando crees tu que prodremos , hacer el ps groove a traves de nuestras psp¿?¿
ante todo enhorabuena por el progreso


si no lo creyese dudo que siguiese
juanlu16 escribió:
samtr escribió:
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/


wuepe despues de este gran avance cuando crees tu que prodremos , hacer el ps groove a traves de nuestras psp¿?¿
ante todo enhorabuena por el progreso


si no lo creyese dudo que siguiese


Lee bn juan y dejad este hilo para los desarrolladores!
Un saludo.
aerox150 está baneado por "utilizar clones para saltarse baneo temporal"
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


weepe acabo de probar el compilado en psp fat 5.50 gen-de con kernel 1.50 y no va

e provado en psp/game150 con kernel 1.50 y 5.xx y no va
e provado en psp7game con kernel 1.50 y 5.xx y tampoco va

lo has provado tu?

el de deviante si va lo acabo de provar

el prx en la raiz claro
Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/

Edito, subo a megaupload.
Código Fuente:
driver rv33

Compilado:
eboot kernel 1.5 bin
driver rv33 prx

Repito, necesario kernel 1.5, puesto que es para testeos de desarrolladores, en kernel 3.xx se puede usar el eboot 5.xx pero este no muestra los datos del driver para su testeo
aerox150 escribió:
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


weepe acabo de probar el compilado en psp fat 5.50 gen-de con kernel 1.50 y no va

e provado en psp/game150 con kernel 1.50 y 5.xx y no va
e provado en psp7game con kernel 1.50 y 5.xx y tampoco va

lo has provado tu?

el de deviante si va lo acabo de provar

el prx en la raiz claro
Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/

Edito, subo a megaupload.
Código Fuente:
driver rv33

Compilado:
eboot kernel 1.5 bin
driver rv33 prx

Repito, necesario kernel 1.5, puesto que es para testeos de desarrolladores, en kernel 3.xx se puede usar el eboot 5.xx pero este no muestra los datos del driver para su testeo


Siento entrometerme, pero ejecuto el eboot en kernel 1.5, con el psgroove.prx en la raíz, y en la carpeta del eboot por si acaso y me salta el típico error de "The game could not ve started. (80020148), alomejor es error mio, pero, ¿puede ser que este mal compilado o algo?

Por cierto, a mi tambien me funcionaba el de Deviante, SUERTE! :)
aerox150 está baneado por "utilizar clones para saltarse baneo temporal"
creo que habran tenido algun fallo a la hora de compilarlo porque no rurla

pro cierto en el hilo de debate creo que han malinterpretado la noticia porque creen que ya funciona y andan como locos pbuscando los archivos del jailbreak para meterlos en la psp jajajaja

pero aunque fuera asi, donde los van a meter jajaja

por cierto weepe, miralo de nuevo porque no va
a mi me va perfectamente i tambien se instala bien
moha99 escribió:a mi me va perfectamente i tambien se instala bien

Podrias decirnos que firmware, si tenias plugins puestos, fat, slim, todo eso? Esto es muy raro :-?

Porcierto, a que te refieres con lo de "también se instala bien"? xd
A mi me funciona perfectamente tengo el 5.00 m33 -6 con el prometheus y el kernel 1.50 no tengo ningun plugin instalado.
Instalado en game150 y el prx en la raíz por si teneis dudas.
moha99 escribió:a mi me va perfectamente i tambien se instala bien

Explica donde has puesto los archivos, en que ruta, el modelo de psp que tienes y la version. Saludss
Chicos, las pruebas van en el hilo de debate y pruebas. Por favor haced las cosas bien y dejad este hilo libre para los investigadores!
¿Cuantas veces hay que pedirlo?

hilo_debate-y-testers-psgroove-en-psp_1480315_s1000#p1721657805

Gracias por la colaboración!
aerox150 está baneado por "utilizar clones para saltarse baneo temporal"
pues algo hay mal, ya que no da soporte para la 5.50gen.d3

solo para inferiores

ya que el compilado no va en ninguna variacion del kernel ni de carpeta ya sea game, game150, game5xx

asi que es una lastima

sin en cambio el de deviante por ahora si carga, solo lo digo para añadir informacion por si el de deviante tiene algo en el compilado que se pueda añadir a este para que de soporte a los gen-d
aerox150 escribió:pues algo hay mal, ya que no da soporte para la 5.50gen.d3

solo para inferiores

ya que el compilado no va en ninguna variacion del kernel ni de carpeta ya sea game, game150, game5xx

asi que es una lastima

sin en cambio el de deviante por ahora si carga, solo lo digo para añadir informacion por si el de deviante tiene algo en el compilado que se pueda añadir a este para que de soporte a los gen-d


Ya a mi tampoco me funciona pero estoy downgradeando ahora mismo jaja
-Zaka- escribió:
aerox150 escribió:pues algo hay mal, ya que no da soporte para la 5.50gen.d3

solo para inferiores

ya que el compilado no va en ninguna variacion del kernel ni de carpeta ya sea game, game150, game5xx

asi que es una lastima

sin en cambio el de deviante por ahora si carga, solo lo digo para añadir informacion por si el de deviante tiene algo en el compilado que se pueda añadir a este para que de soporte a los gen-d


Ya a mi tampoco me funciona pero estoy downgradeando ahora mismo jaja


Chicos, intentemos no ansuciar más el hilo, ¡Se tiene que instalar el kernel addon 1.5! http://psp.scenebeta.com/tutorial/como-cargar-homebrew-kernel-1-50-y-3-xx-en-psp-y-pspslim

Tenia el mismo problema y ahora esta solucionado, si teneis otra duda por favor informad en el hilo de DEBATE Y TESTERS, ya que así no molestamos.

Saludos! [bye]
-Zaka- escribió:
aerox150 escribió:pues algo hay mal, ya que no da soporte para la 5.50gen.d3

solo para inferiores

ya que el compilado no va en ninguna variacion del kernel ni de carpeta ya sea game, game150, game5xx

asi que es una lastima

sin en cambio el de deviante por ahora si carga, solo lo digo para añadir informacion por si el de deviante tiene algo en el compilado que se pueda añadir a este para que de soporte a los gen-d


Ya a mi tampoco me funciona pero estoy downgradeando ahora mismo jaja


Haber no tiene soporte para superiores ya que es un testeo de desarrolladores, con lo cual es SIMPLE y se ejecuta en la BASE que es 1.50 cuando ya este todo listo y testeado se pasara a versiones mas comerciales ;)

A por cierto yo haria caso a se20 xD
by_kas_ escribió:
moha99 escribió:a mi me va perfectamente i tambien se instala bien

Podrias decirnos que firmware, si tenias plugins puestos, fat, slim, todo eso? Esto es muy raro :-?

Porcierto, a que te refieres con lo de "también se instala bien"? xd


lo tengo en game150 i el .prx en la raiz tengo psp fat 5.00 m33-6

i se instala bien en el pc windows 7
Testeado en PSP FAT 5.00 M33-6 con Kernel 1.50

No se si alguien más lo ha notado, pero al iniciar la PS3 puedo apreciar que tarda unos segundo más cuando tiene el PSPGroove conectado.

Buen curro chicos ;)
Kravenbcn escribió:Testeado en PSP FAT 5.00 M33-6 con Kernel 1.50

No se si alguien más lo ha notado, pero al iniciar la PS3 puedo apreciar que tarda unos segundo más cuando tiene el PSPGroove conectado.

Buen curro chicos ;)


¿Pero la has enchufado normal,o POWER+EJECT?
Porque si es Power+Eject,es normal que tarde más,todas lo hacen,tenga o no algo conectado.
Kravenbcn escribió:Testeado en PSP FAT 5.00 M33-6 con Kernel 1.50

No se si alguien más lo ha notado, pero al iniciar la PS3 puedo apreciar que tarda unos segundo más cuando tiene el PSPGroove conectado.

Buen curro chicos ;)


Claro, cuando haces esa combinacion de teclas, la ps3 solicita la entrada a los USB eso conlleva un tiempo ;)
Minami escribió:
Kravenbcn escribió:Testeado en PSP FAT 5.00 M33-6 con Kernel 1.50

No se si alguien más lo ha notado, pero al iniciar la PS3 puedo apreciar que tarda unos segundo más cuando tiene el PSPGroove conectado.

Buen curro chicos ;)


Claro, cuando haces esa combinacion de teclas, la ps3 solicita la entrada a los USB eso conlleva un tiempo ;)


¿ Y te entra la ps3 en modo debug ? Esque no me e atrevido a probarlo XD
sergipiza escribió:
Minami escribió:
Kravenbcn escribió:Testeado en PSP FAT 5.00 M33-6 con Kernel 1.50

No se si alguien más lo ha notado, pero al iniciar la PS3 puedo apreciar que tarda unos segundo más cuando tiene el PSPGroove conectado.

Buen curro chicos ;)


Claro, cuando haces esa combinacion de teclas, la ps3 solicita la entrada a los USB eso conlleva un tiempo ;)


¿ Y te entra la ps3 en modo debug ? Esque no me e atrevido a probarlo XD


Dudo bastante que le entre la PS3 en modo debug,ya que esto aún no hace nada...pero bueno,vosotros seguid con lo vuestro,que después de 130 páginas aún no os habéis enterado de que están en ello.
Minami escribió:Claro, cuando haces esa combinacion de teclas, la ps3 solicita la entrada a los USB eso conlleva un tiempo ;)

Cierto, mea culpa, no me habia dado por iniciar con la combinación sin el PSPGroove [ayay]

Todavia no entra en modo debug, paciencia y dejadles que trabajen tranquilos ;)

Saludos.
Joder Tios a platicar aqui hilo_debate-y-testers-psgroove-en-psp_1480315_s1090#p1721658972 dejad trabajar alos cracks!!! de aqui [+furioso] [+furioso] y aprovechando sigan asi tios son la pura Ostia ahora si Ya les falta muy pocooooooo!!!!! [Ooooo] [Ooooo]
ellidr escribió:Joder Tios a platicar aqui hilo_debate-y-testers-psgroove-en-psp_1480315_s1090#p1721658972 dejad trabajar alos cracks!!! de aqui [+furioso] [+furioso] y aprovechando sigan asi tios son la pura Ostia ahora si Ya les falta muy pocooooooo!!!!! [Ooooo] [Ooooo]


Eso queria yo pero al ver que el hilo DEBATE Y TESTER se ponen a hablar de nombres como si lo estuvieran haciendo ellos ...
sergipiza escribió:
ellidr escribió:Joder Tios a platicar aqui hilo_debate-y-testers-psgroove-en-psp_1480315_s1090#p1721658972 dejad trabajar alos cracks!!! de aqui [+furioso] [+furioso] y aprovechando sigan asi tios son la pura Ostia ahora si Ya les falta muy pocooooooo!!!!! [Ooooo] [Ooooo]


Eso queria yo pero al ver que el hilo DEBATE Y TESTER se ponen a hablar de nombres como si lo estuvieran haciendo ellos ...


Tranquilo, digan lo que digan los nombres lo deciden los sceners, TODOS los sceners que han participado ;)
Minami escribió:
sergipiza escribió:
ellidr escribió:Joder Tios a platicar aqui hilo_debate-y-testers-psgroove-en-psp_1480315_s1090#p1721658972 dejad trabajar alos cracks!!! de aqui [+furioso] [+furioso] y aprovechando sigan asi tios son la pura Ostia ahora si Ya les falta muy pocooooooo!!!!! [Ooooo] [Ooooo]


Eso queria yo pero al ver que el hilo DEBATE Y TESTER se ponen a hablar de nombres como si lo estuvieran haciendo ellos ...


Tranquilo, digan lo que digan los nombres lo deciden los sceners, TODOS los sceners que han participado ;)


Vamos a ver, que parecemos niños chicos. Aqui nadie ha dicho que lo hayamos hecho nosotros. Haced el favor de leer y no ensuciar. Estamos dando ideas, no vamos a imponer nada. Y no habría puesto la votación si pensara que a los sceners le molesta y se que no les molesta por que mientras estamos discutiendo de eso estamos dejando este hilo libre. Asi que por favor dejad de escribir en este hilo y de pensar tonterias que no se han dicho e informarse más antes de hablar estupideces.

Gracias!
he probado el ultimo eboot compilado(que se ha dicho que no va) y funciona,

una vez hecho el proceso de arranque la psp dice...

USB_REQ_CLEAR_FEATURE USB_RECIP_OTHER value: 1 junto a una nota musical
(mensaje borrado)
aerox150 está baneado por "utilizar clones para saltarse baneo temporal"
wuepe escribió:Cambios realizados en la rev. 33
Arreglado bug del descriptor del hub, que no le mandaba correctamente que tiene 6 puertos.
Quitada función que no se utilizaba psplinkSetK1
Añadido un envio de Request Auxiliar
Comentado o quitado algunas funciones que no se utilizan.
Cambiado la forma de enviar el dato en hub_connect_port
Creado código para el envio de GET_STATUS del hub, aunque hay que revisarlo.
Añadidos algunos TODO: para implementar


Estado actual, hay que enviar correctamente, los valores 0x0000 para el estatus y 0x0000 para el change al preguntarnos por el STATUS del HUB.

Actualizada la svn.
http://code.google.com/p/eol-psgroove/

Edito, subo a megaupload.
Código Fuente:
driver rv33

Compilado:
eboot kernel 1.5 bin
driver rv33 prx

Repito, necesario kernel 1.5, puesto que es para testeos de desarrolladores, en kernel 3.xx se puede usar el eboot 5.xx pero este no muestra los datos del driver para su testeo


Oye Wuepe aqui hay informacion sobre el evento de reset, es de LUFA pero tal vez sirve de referencia, no se si tiene que ver con los eventos que estas trabajando ahora mismo o este es diferente:

http://www.fourwalledcubicle.com/files/ ... d7bf9a3881

void EVENT_USB_Device_Reset ( void )

Event for USB interface reset. This event fires when the USB interface is in device mode, and a the USB host requests that the device reset its interface. This event fires after the control endpoint has been automatically configured by the library.

This event is time-critical; exceeding OS-specific delays within this event handler (typically of around two seconds) will prevent the device from enumerating correctly.


EDIT: Encontre algo mas relevante a lo que se necesita, creo. Dale un vistazo a la siguiente documentación, se parece mucho a las estructuras que usa PSP PSGroove.

http://www.beck-ipc.com/files/api/scxxx/usbstruc.htm



typedef enum
{
USB_EVENT_RECEIVED = 0,
USB_EVENT_SENT = 1,
USB_EVENT_RESET = 2,
USB_EVENT_SETUP = 3,
USB_EVENT_SUSPEND = 4,
USB_EVENT_RESUME = 5,
USB_EVENT_SOF = 13,
USB_EVENT_ATTACH = 14,
USB_EVENT_DETACH = 15,
USB_EVENT_RELEASE = 16,
USB_EVENT_ERROR_BIT_STUFF = 6,
USB_EVENT_ERROR_DMA = 7,
USB_EVENT_ERROR_TURNAROUND = 8,
USB_EVENT_ERROR_DATA_FIELD = 9,
USB_EVENT_ERROR_CRC16 = 10,
USB_EVENT_ERROR_CRC5 = 11,
USB_EVENT_ERROR_PID = 12,
USB_EVENT_NAK = 17,
USB_EVENT_STALL = 18,
USB_EVENT_ERROR_DATA_OVERRUN = 25,
USB_EVENT_ERROR_DATA_TOGGLE = 19,
USB_EVENT_ERROR_SOF_LOST = 20,
USB_EVENT_ERROR_SOF_BANDWIDTH = 21,
USB_EVENT_ERROR_ATTACH = 22,
USB_EVENT_ERROR_LOST_EVENT = 23,
USB_EVENT_ERROR_BANDWIDTH = 24,
USB_EVENT_INVALID = -1
} UsbEventStatus;


Saludos.
A ver, tengo que pedir por favor que para dudas o preguntas sobre como usar este software, estando aún en fase de pruebas, debería dirigirse a este hilo: hilo_debate-y-testers-psgroove-en-psp_1480315

Este hilo es tan solo para aportar granitos de arena en la tarea de programar el PsGroove en PSP, y con granitos de arena no me refiero a animos, sino a referencias, posibles soluciones a los problemas actuales...

Y no estoy intentando moderar este hilo, ni me creo moderador, pero ya ha pasado [erick] por aqui a hacer limpieza un par de veces y parece que ya se ha cansado de pasarse media hora borrando posts.

Así que hagamos un favor a la comunidad y ahorremos tiempo a los moderadores, no ensuciemos mas este hilo.

Dicho esto, decir que el camino a seguir sería el parcheo del Kernel de la PSP, concretamente la parte de gestión del bus de usb (usb.prx sceUsbBus_driver)
Actualizado SVN a la rev 35

Cambios
Añadida Nuevas Funciones, para pasar de long a strrhex, y otra para pasar de
strhex a dos long, ambas se usan para mandar el estado al requery GET STATUS.
Conseguido Conectar con el Requery Connection Port.
Añadido nuevo hilo, para reenviar, o hacer un envio de datos esperando este a
que no haya nada aun en envio, utilizado para enviar el GET STATUS.


Hay que seguir trabajando, para mirar por que se queda en connection, y no manda solo el reset, pero bueno, los desarrolladores, teneis algo mas para seguir avanzando.

Edito:
Subo fuente driver rv35 megaupload: http://www.megaupload.com/?d=AX1S8JAI
Excelente trabajo Wuepe, me he pasado el día ajustándome al código y probando diferentes cosas.

Algo que me tiene en duda es la implementación del handler del USB Request, en el mismo, solo se esta condicionando "req->bRequest" en un switch y en el código de PSGroove original que tengo aquí, utilizan IF para condicionar varios eventos.

Por ejemplo mira este pedazo de código de PSGroove (psgroove.c):

if (port_cur == 0 &&
USB_ControlRequest.bmRequestType == 0x23 &&
USB_ControlRequest.bRequest == 0x03 && // SET_FEATURE
USB_ControlRequest.wLength == 0x00) {
uint8_t p = USB_ControlRequest.wIndex;
if (p < 1 || p > 6) return;

Endpoint_ClearSETUP();
Endpoint_ClearIN();
Endpoint_ClearStatusStage();

switch(USB_ControlRequest.wValue) {
case 0x0008: // PORT_POWER
if (p == 6 && state == init) {
/* after the 6th port is powered, wait a bit and continue */
state = hub_ready;
expire = 15;
}
break;
case 0x0004: // PORT_RESET
hub_int_response = (1 << p);
port_change[p - 1] |= C_PORT_RESET;
break;
}
return;
}


En el switch que utilizamos ahora no tomamos en consideracion los demas miembros de la estructura "DeviceRequest", solo "req->bRequest".

http://github.com/psgroove/psgroove/blo ... psgroove.c

Lo que propongo es utilizar la misma forma de evaluar cada evento en vez de utilizar un case para todo, tal vez ahí se pueda hacer todo correctamente.

Voy a tratar de cambiar el código lo mas posible en ese handler para ver si me da alguna señal positiva. Tal vez me encuentre con alguna sección que no conozca bien ya que cada port del exploit usa diferentes nombres para las estructuras, variables y demás.

Saludos.
emm, yo lo tengo asi para que reciba el port reset. Lo he adaptado a vuestro code, solo cambiar el case xxx por este otro:

case USB_REQ_GET_STATUS:
      if ((req->bmRequestType & USB_TYPE_CLASS) == USB_TYPE_CLASS) {
         u16 status = 0;
         u16 change = 0;
         value = 2 * sizeof (u16);
         switch (req->bmRequestType & USB_RECIP_MASK) {
               case USB_RECIP_DEVICE:
                  /* HUB STATUS */
                  status = 0;
                  change = 0;
                  break;
               case USB_RECIP_OTHER:
                  /* PORT STATUS */
                  if (req->wIndex == 0 || req->wIndex > 6) {
                     //error en el numero del puerto...
                     break;
                  }
                  // Puerto correcto... (Por hacer...)
                  status = port_status[req->wIndex-1]; // poner el status
                  change = port_change[req->wIndex-1]; // y el cambio ..
                  break;
               default:
                  break;
         }
         if (value > 0) {
            if (!g_reportrequest.unused) {
               Kprintf("enviando estado puerto... %d\n",req->wIndex);
               g_reportrequest.data = (const unsigned char *)&status;
               g_reportrequest.size = sizeof(status);
               memcpy(g_reportrequest.data + g_reportrequest.size,(const unsigned char *)&change,sizeof(change));
               g_reportrequest.size += sizeof(change);
               g_reportrequest.endpoint = &endp[0];
               g_reportrequest.isControlRequest = 0;
               g_reportrequest.onComplete = &complete_request;
               g_reportrequest.transmitted = 0;
               g_reportrequest.returnCode = 0;
               g_reportrequest.unused = &g_reportrequest;
               g_reportrequest.next = NULL;
               g_reportrequest.physicalAddress = NULL;   
               int res = sceUsbbdReqSend (&g_reportrequest);
            }
            else {
               Kprintf("inused g_reportrequest");
               return -1;
            }
         }
      }
      
      break;
   


Edito:

Vale a ver, he buscado otro to-do y me encontrao este...
case 4: //* PORT_RESET *  // TODO:
                 printf("USB_REQ_SET_FEATURE->USB_RECIP_OTHER->SetPortFeature PORT_RESET called\n");
                 port_change[req->wIndex - 1] |= C_PORT_RESET;
                 hub_port_changed();
                 value = 0;                 
                 break;


Asi deberia kedar, con esto introducimos un par de funciones portadas de psgroove.
static void hub_interrupt_transmit () {
  u8 data = 0;
  int i;

  for (i = 0; i < 6; i++) {
    if (port_change[i] != 0)
        data |= 1 << (i+1);
  }

  if (data != 0) {
    int err = 0;

    // Mantener una cola?
    //if (hub_interrupt_queued) {
    //  ERROR(dev, "hub_interrupt_transmit: Already queued a request\n");
    //  return;
    ///}

    /* Only queue one interrupt, and send it only once... If we don't do that
       then it will confuse the ps3, which will try to reset our device a few
       times and it will make it take over 15 seconds to get to plugging the JIG
       which will not work since it must be plugged in during boot in less
       than 5 seconds */
    // vale, si, hay que mantener cola...
   
    // En el on complete, deberiamos hacer dequeue.
    usb_recv_request((const unsigned char *)&data, sizeof(data),0); //endpoint 0.
   
    //hub_interrupt_queued = 1; - la cola!
   
    }
    else {
        Kprintf("Nothing to report, freeing request, NAK-ing interrupt\n");
    }

    // y más dequeue.
    //if (hub_interrupt_queued)
    //  usb_ep_dequeue(ep, req);
   
    //hub_interrupt_queued = 0;
}

static void hub_port_changed ()
{
  hub_interrupt_transmit();
}


Vale, añadiendo eso ya se hace bien el handle del port reset, y tal y tal.
Y del code, yo kitaría el HUB_READY de donde lo teneis! Pq causa conflicto! (Yo lo he dejado comentado...
case 8: //* PORT_POWER *                     
                 printf ("port %d, ",req->wIndex);
                 if (status == INIT && req->wIndex == 6)
                 {                                 
                   
                   printf(" OK\n\nHUB Completado\n ");
                   //status = HUB_READY;
                   //time_delay_status = 150;//ms
                   //sceKernelWakeupThread(g_thid_status);
                 }       

Y lo pasaría a cuando ya hemos enviado la info de todos los ports, desconectados, entonces ahi ya activarlo, en mi psp con este code completo, se conecta, manda la info y estados de todos los ports, recibe el reset de todos, y lo procesa bien, y se keda el hub en espera, y correctamente instalado en pc ( supongo en ps3 tambien ), a partir de ahi insertar el retraso de 15ms y estado hub_ready , y conectar el puerto 1, que como se puede ver, se puede mandar por usb_recv_...

Y ara piro pal sobre k ya son horas...
Saludos!

Y por si keda mas claro en source.. pos entero:
http://www.megaupload.com/?d=M6XFHFTV

(por cierto, añadirme a los creditos, k dejo el mio para apuntarme a este ( si kereis... ))

(y lo de la to-do me va bastante bien, asi meto un ctrl+f, "to-do" y ahi meto lo k falta xD)
Animo chavales ke la cosa va a mas y cada vez keda meno, salu2 a todos.
DeViaNTe escribió:
emm, yo lo tengo asi para que reciba el port reset. Lo he adaptado a vuestro code, solo cambiar el case xxx por este otro:

case USB_REQ_GET_STATUS:
      if ((req->bmRequestType & USB_TYPE_CLASS) == USB_TYPE_CLASS) {
         u16 status = 0;
         u16 change = 0;
         value = 2 * sizeof (u16);
         switch (req->bmRequestType & USB_RECIP_MASK) {
               case USB_RECIP_DEVICE:
                  /* HUB STATUS */
                  status = 0;
                  change = 0;
                  break;
               case USB_RECIP_OTHER:
                  /* PORT STATUS */
                  if (req->wIndex == 0 || req->wIndex > 6) {
                     //error en el numero del puerto...
                     break;
                  }
                  // Puerto correcto... (Por hacer...)
                  status = port_status[req->wIndex-1]; // poner el status
                  change = port_change[req->wIndex-1]; // y el cambio ..
                  break;
               default:
                  break;
         }
         if (value > 0) {
            if (!g_reportrequest.unused) {
               Kprintf("enviando estado puerto... %d\n",req->wIndex);
               g_reportrequest.data = (const unsigned char *)&status;
               g_reportrequest.size = sizeof(status);
               memcpy(g_reportrequest.data + g_reportrequest.size,(const unsigned char *)&change,sizeof(change));
               g_reportrequest.size += sizeof(change);
               g_reportrequest.endpoint = &endp[0];
               g_reportrequest.isControlRequest = 0;
               g_reportrequest.onComplete = &complete_request;
               g_reportrequest.transmitted = 0;
               g_reportrequest.returnCode = 0;
               g_reportrequest.unused = &g_reportrequest;
               g_reportrequest.next = NULL;
               g_reportrequest.physicalAddress = NULL;   
               int res = sceUsbbdReqSend (&g_reportrequest);
            }
            else {
               Kprintf("inused g_reportrequest");
               return -1;
            }
         }
      }
      
      break;
   


Edito:

Vale a ver, he buscado otro to-do y me encontrao este...
case 4: //* PORT_RESET *  // TODO:
                 printf("USB_REQ_SET_FEATURE->USB_RECIP_OTHER->SetPortFeature PORT_RESET called\n");
                 port_change[req->wIndex - 1] |= C_PORT_RESET;
                 hub_port_changed();
                 value = 0;                 
                 break;


Asi deberia kedar, con esto introducimos un par de funciones portadas de psgroove.
static void hub_interrupt_transmit () {
  u8 data = 0;
  int i;

  for (i = 0; i < 6; i++) {
    if (port_change[i] != 0)
        data |= 1 << (i+1);
  }

  if (data != 0) {
    int err = 0;

    // Mantener una cola?
    //if (hub_interrupt_queued) {
    //  ERROR(dev, "hub_interrupt_transmit: Already queued a request\n");
    //  return;
    ///}

    /* Only queue one interrupt, and send it only once... If we don't do that
       then it will confuse the ps3, which will try to reset our device a few
       times and it will make it take over 15 seconds to get to plugging the JIG
       which will not work since it must be plugged in during boot in less
       than 5 seconds */
    // vale, si, hay que mantener cola...
   
    // En el on complete, deberiamos hacer dequeue.
    usb_recv_request((const unsigned char *)&data, sizeof(data),0); //endpoint 0.
   
    //hub_interrupt_queued = 1; - la cola!
   
    }
    else {
        Kprintf("Nothing to report, freeing request, NAK-ing interrupt\n");
    }

    // y más dequeue.
    //if (hub_interrupt_queued)
    //  usb_ep_dequeue(ep, req);
   
    //hub_interrupt_queued = 0;
}

static void hub_port_changed ()
{
  hub_interrupt_transmit();
}


Vale, añadiendo eso ya se hace bien el handle del port reset, y tal y tal.
Y del code, yo kitaría el HUB_READY de donde lo teneis! Pq causa conflicto! (Yo lo he dejado comentado...
case 8: //* PORT_POWER *                     
                 printf ("port %d, ",req->wIndex);
                 if (status == INIT && req->wIndex == 6)
                 {                                 
                   
                   printf(" OK\n\nHUB Completado\n ");
                   //status = HUB_READY;
                   //time_delay_status = 150;//ms
                   //sceKernelWakeupThread(g_thid_status);
                 }       

Y lo pasaría a cuando ya hemos enviado la info de todos los ports, desconectados, entonces ahi ya activarlo, en mi psp con este code completo, se conecta, manda la info y estados de todos los ports, recibe el reset de todos, y lo procesa bien, y se keda el hub en espera, y correctamente instalado en pc ( supongo en ps3 tambien ), a partir de ahi insertar el retraso de 15ms y estado hub_ready , y conectar el puerto 1, que como se puede ver, se puede mandar por usb_recv_...

Y ara piro pal sobre k ya son horas...
Saludos!

Y por si keda mas claro en source.. pos entero:
http://www.megaupload.com/?d=M6XFHFTV

(por cierto, añadirme a los creditos, k dejo el mio para apuntarme a este ( si kereis... ))

(y lo de la to-do me va bastante bien, asi meto un ctrl+f, "to-do" y ahi meto lo k falta xD)


Vaya Deviante!! Gracias! ^^ Lo he probado y me resulta como has comentado!, me parece fantástico que te unas al grupo de PSPGroove, estoy seguro que cuando Wuepe vea este progreso le va a encantar. Por lo de los créditos, tienes mi respeto =), como todo el que ha contribuido mereces el crédito.

Ahora tengo entendido que entre las demás cosas por realizar, habría que hacer el proceso de enviar los descriptores y el "jig_response[64]", ¿cierto?

Saludos!, yo me retiro a descansar pero volveré pronto a ver como va todo y si puedo ayudar en algo.
vaya menuda sorpresa Deviante!!! mandame un privado y te pongo como commiter en el google code (si quieres claro [carcajad] )
creo que en el tercer descriptor es un poco largo miralo me da error
1482 respuestas
Cerrado
1…24, 25, 26, 27, 28…30
Volver a Modchips y Softmods