Autor Tema: [Desarrollo] OpenWrt en Observa Telecom VH4032N (Leído 234052 veces)

gmtii · « **en:** 05-02-2014, 00:27 (Miércoles) »

ACTUALIZACIÓN A 21/11/2019

Este router ya tiene soporte completo en OpenWRT así que se puede bajar el firmware desde sus servidores.
Y en la wiki, se explica un modo sencillo de instalación: https://openwrt.org/toh/observatelecom/vh4032n#oem_easy_install

Hilo para el soporte del nuevo router de Vodafone VH4032N:

CPU 6368
RAM 128 MB
FLASH 32 MB
WIFI 2.4 y 5 GHz Broadcom 43222
3 puertos USB 2.0
Switch 10/100 :-(

Git temporal del router hasta integración en Openwrt-es:

https://bitbucket.org/gmtii/barrier-breaker-openwrt-vh4032n/branch/barrier-breaker_14.04

Tutorial para Instalación

jar229 · « **Respuesta #1 en:** 05-02-2014, 08:31 (Miércoles) »

El router tiene bastante buena pinta

Lástima que no tenga ethernet gigabit

Tki2000 · « **Respuesta #2 en:** 05-02-2014, 10:12 (Miércoles) »

Parece que el responsable de dar la alimentación a los puertos USB es el chip que hay a la derecha del NEC.

Debiera ser del tipo MIC2526 o similar. En la foto no lo distingo.
Si es del tipo MIC2526, ¿tienes posibilidad de medir el voltaje en las patillas 1, 4 y 7 con el firmware original y con el openwrt puesto? Al menos la patilla 7 debiera de tener alimentación. Las patillas 1 y 4 depende de si el chip detecta niveles altos o bajos debieran tener 0 o 1 lógicos para que se activen las salidas de voltaje a los puertos USB.

El datasheet se puede ver aquí.

danitool · « **Respuesta #3 en:** 05-02-2014, 12:44 (Miércoles) »

Cambiaste la board ID a 96368MVWG?, uhm creo que ese no es el camino correcto. Y podría ser que por elegir esa board ID el chip que mencionas dejase de funcionar, tal vez sea CFE quien lo activa al arrancar el sistema.

Edito: o bien algún led definido para 96368MVWG, se corresponde con el gpio que activa ese chip, aunque supongo que ya lo habrás comprobado.

¿Cual era la board ID original?. Aunque a veces no hay ninguna diferencia poniendo una u otra board ID, mejor siempre trabajar con la que hay por defecto.

sanson · « **Respuesta #4 en:** 05-02-2014, 12:51 (Miércoles) »

hola

@Gmtii

te e editado la segunda fotografia, para que no se vea, ya que salen datos que no estan permitidos en el foto. tapa parte tapa la mac, la clave etc

saludos

Noltari · « **Respuesta #5 en:** 05-02-2014, 13:26 (Miércoles) »

Cita de: danitool en 05-02-2014, 12:44 (Miércoles)

Cambiaste la board ID a 96368MVWG?, uhm creo que ese no es el camino correcto. Y podría ser que por elegir esa board ID el chip que mencionas dejase de funcionar, tal vez sea CFE quien lo activa al arrancar el sistema.

Edito: o bien algún led definido para 96368MVWG, se corresponde con el gpio que activa ese chip, aunque supongo que ya lo habrás comprobado.

¿Cual era la board ID original?. Aunque a veces no hay ninguna diferencia poniendo una u otra board ID, mejor siempre trabajar con la que hay por defecto.

+1
Eso es trampa

.
Si nos dices el ID original podemos crear una definición nueva para ese router. La 96368MVWG está demasiado sobrecargada ya con dispositivos copy & pasteados del de referencia a los que los fabricantes no cambiaron el identificador.

Saludos!

gmtii · « **Respuesta #6 en:** 05-02-2014, 13:46 (Miércoles) »

exacto; es un AP1212 L

https://www.dropbox.com/s/tgnojcqg2ca53ws/IMG_20140205_121706.jpg

http://www.diodes.com/datasheets/AP1212.pdf

ahora mido tocando gpios y pongo resultados...

la definición de placa original es la 0, 96368VVW.

Saludos.

Cita de: Tki2000 en 05-02-2014, 10:12 (Miércoles)

Parece que el responsable de dar la alimentación a los puertos USB es el chip que hay a la derecha del NEC.

Debiera ser del tipo MIC2526 o similar. En la foto no lo distingo.
Si es del tipo MIC2526, ¿tienes posibilidad de medir el voltaje en las patillas 1, 4 y 7 con el firmware original y con el openwrt puesto? Al menos la patilla 7 debiera de tener alimentación. Las patillas 1 y 4 depende de si el chip detecta niveles altos o bajos debieran tener 0 o 1 lógicos para que se activen las salidas de voltaje a los puertos USB.

El datasheet se puede ver aquí.

gmtii · « **Respuesta #7 en:** 05-02-2014, 13:47 (Miércoles) »

cada día estoy más vago

Cita de: Noltari en 05-02-2014, 13:26 (Miércoles)

Cita de: danitool en 05-02-2014, 12:44 (Miércoles)
Cambiaste la board ID a 96368MVWG?, uhm creo que ese no es el camino correcto. Y podría ser que por elegir esa board ID el chip que mencionas dejase de funcionar, tal vez sea CFE quien lo activa al arrancar el sistema.

Edito: o bien algún led definido para 96368MVWG, se corresponde con el gpio que activa ese chip, aunque supongo que ya lo habrás comprobado.

¿Cual era la board ID original?. Aunque a veces no hay ninguna diferencia poniendo una u otra board ID, mejor siempre trabajar con la que hay por defecto.
+1
Eso es trampa .
Si nos dices el ID original podemos crear una definición nueva para ese router. La 96368MVWG está demasiado sobrecargada ya con dispositivos copy & pasteados del de referencia a los que los fabricantes no cambiaron el identificador.

Saludos!

Noltari · « **Respuesta #8 en:** 05-02-2014, 14:27 (Miércoles) »

Cita de: gmtii en 05-02-2014, 13:46 (Miércoles)

exacto; es un AP1212 L

https://www.dropbox.com/s/tgnojcqg2ca53ws/IMG_20140205_121706.jpg

http://www.diodes.com/datasheets/AP1212.pdf

ahora mido tocando gpios y pongo resultados...

la definición de placa original es la 0, 96368VVW.

Saludos.

Cita de: Tki2000 en 05-02-2014, 10:12 (Miércoles)
Parece que el responsable de dar la alimentación a los puertos USB es el chip que hay a la derecha del NEC.

Debiera ser del tipo MIC2526 o similar. En la foto no lo distingo.
Si es del tipo MIC2526, ¿tienes posibilidad de medir el voltaje en las patillas 1, 4 y 7 con el firmware original y con el openwrt puesto? Al menos la patilla 7 debiera de tener alimentación. Las patillas 1 y 4 depende de si el chip detecta niveles altos o bajos debieran tener 0 o 1 lógicos para que se activen las salidas de voltaje a los puertos USB.

El datasheet se puede ver aquí.

Perfecto, el mismo ID que el Zyxel P870HW-51a v2...
Otro caso de fabricantes vagos xD.
https://github.com/openwrt-es/barrier-breaker-openwrt/commit/81577a0c34136266b827b2b007498cf03f750f5a
Saludos!

Tki2000 · « **Respuesta #9 en:** 05-02-2014, 15:18 (Miércoles) »

A la izquierda del chip NEC parece que hay otro chip de alimentación USB sin soldar. El USB por cable va conectado directamente al NEC, prescindiendo del limitador de 500mA. A lo mejor se pueden medir en las pistas del socket las señales mejor que en las patillas del otro chip, si se han molestado en implementar la señalización, aunque no hayan puesto el chip.

gmtii · « **Respuesta #10 en:** 05-02-2014, 20:31 (Miércoles) »

buenas,

el ap1212 que falta efectivamente controlaría el puerto que va con el cable a la placa y donde se pincha el 3g; tiene VCC fijo donde iría la salida del IC.

Respecto al otro; he probado a compilar con la definición de placa original sin ningún LED definido, y el CFE parece que no hace ninguna inicialización previa dado que no cambia...

El revisado el conexionado y está tal cual el datasheet, es decir, el 720114 controla directamente al ap1212 mediante los pines EN1 y EN2 para cada puerto USB; un detalle es que, el mismo hub no aparece en la salida del lsusb de tal modo que hay algo que lo tiene desactivado...

El único GPIO que he encontrado que llega al 720114 es el 27, que corresponde con el pin SYSRSTB. Por defecto está a uno de tal modo on está en reset.

Saludos

Tki2000 · « **Respuesta #11 en:** 06-02-2014, 09:04 (Jueves) »

Pues creo que ahí está la clave.

Según he estado viendo, el que los puertos PPB del NEC se comporten como activadores del AP1212 depende del estado que el chip haya leído cuando se le hace un reset (en el datasheet está en la página 18). Es decir estos pins se comportan como entrada en el momento del reset. Supongo que dichos pins estarán ligados por resistencias "pull-up" directamente a la alimentación ya que me dices que no ves más pines que lleguen a la CPU. Existe la posibilidad de que si cuando se inicia el router se le da la orden de resetear el NEC poniendo a 0 el GPIO que me comentas y luego a 1, puede que el chip arranque correctamente. (el pin de reset está activo en 0 según el datasheet).

Otra posibilidad de ver esto sería poner el firmware original y con un analizador lógico ver si se resetea el chip en algún momento con el GPIO que me comentas, aunque creo que lleva menos lío probar primero a resetear el chip y ver si "sale andando".

Esto lo he encontrado en otro datasheet del NEC:

Código: [Seleccionar]

STATUS BEFORE INITIALIZATION: Power-on does not necessarily define the initial status of a MOS device. 
Immediately after the power source is turned ON, devices with reset functions have not yet been initialized. 
Hence, power-on does not guarantee output pin levels, I/O settings or contents of registers. A device is not 
initialized until the reset signal is received. A reset operation must be executed immediately after power-on 
for devices with reset functions.

danitool · « **Respuesta #12 en:** 06-02-2014, 12:47 (Jueves) »

Si es el caso de que efectivamente necesita un reset o un cambio de high a low, o viceversa antes de en un momento determinado, podría arreglarse fácilmente.

Por ejemplo para poner en HIGH/LOW antes de que se inicialice el USB este código podría valer, por ejemplo poniéndolo en el archivo board_bcm963xx.c. Antes de que se registren los USBs.

Código: [Seleccionar]

	if ((board.has_ohci0 || board.has_ehci0)) {
	  	printk(KERN_INFO PFX "resetting gpio27 for usbHUB...\n");
		gpio_request(27, "USB_rst");
		gpio_direction_output(27, 0);
		gpio_set_value(27, 1);
		
		usbh_ports = board.num_usbh_ports;

		if (!usbh_ports || WARN_ON(usbh_ports > 1 && board.has_usbd))
			usbh_ports = 1;
	}

Puede que si lo que necesita es un reset necesitemos una línea más:

Código: [Seleccionar]

gpio_set_value(27, 0);
Aunque tal vez board_register_devices podría no ser la función correcta para hacer el cambio de high a low o viceversa sino en la función prom_init, de forma parecida a lo que hay para el bcm6318 y el gpio-pinmux para usb. Todo es cuestión de probar.

Noltari · « **Respuesta #13 en:** 06-02-2014, 13:05 (Jueves) »

Cita de: danitool en 06-02-2014, 12:47 (Jueves)

Si es el caso de que efectivamente necesita un reset o un cambio de high a low, o viceversa antes de en un momento determinado, podría arreglarse fácilmente.

Por ejemplo para poner en HIGH/LOW antes de que se inicialice el USB este código podría valer, por ejemplo poniéndolo en el archivo board_bcm963xx.c. Antes de que se registren los USBs.
Código: [Seleccionar]
if ((board.has_ohci0 || board.has_ehci0)) { printk(KERN_INFO PFX "resetting gpio27 for usbHUB...\n"); gpio_request(27, "USB_rst"); gpio_direction_output(27, 0); gpio_set_value(27, 1); usbh_ports = board.num_usbh_ports; if (!usbh_ports || WARN_ON(usbh_ports > 1 && board.has_usbd)) usbh_ports = 1; }Puede que si lo que necesita es un reset necesitemos una línea más:
Código: [Seleccionar]
gpio_set_value(27, 0);
Aunque tal vez board_register_devices podría no ser la función correcta para hacer el cambio de high a low o viceversa sino en la función prom_init, de forma parecida a lo que hay para el bcm6318 y el gpio-pinmux para usb. Todo es cuestión de probar.

Totalmente de acuerdo con danitool.

De todas formas, encontrar el GPIO no debería ser difícil, ¿no?

Saludos.

gmtii · « **Respuesta #14 en:** 06-02-2014, 20:41 (Jueves) »

bingo! tal cual interpretó Tki2000, el datasheet obliga a ese reset tras aplicar alimentación... y con la solución de danitool aplicada antes de la inicialización de usb, hub vivito y coleando.. buen trabajo !

Código: [Seleccionar]

Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

al final quedó como sigue (no entendí qué hacen el resto de líneas y daba error al compilar) sobre la variable inexistente en el struct de board:

Código: [Seleccionar]

	if ((board.has_ohci0 || board.has_ehci0)) {
	  	printk(KERN_INFO PFX "LOG: resetting gpio27 for usbHUB...\n");
		gpio_request(27, "USB_rst");
		gpio_direction_output(27, 0);
		gpio_set_value(27, 1);
		gpio_set_value(27, 0);
	  	printk(KERN_INFO PFX "LOG: done reset gpio27 ...\n");    // mínimo 5us en reset
		gpio_set_value(27, 1);
		
	}

ya puestos y abusando de Vds. : estoy bloqueado con el uboot del lantiq vr9 livebox 2.1... la inicialización de puertos hace que los ping una vez arrancado Openwrt, con menos de 15 bytes de payload funcionen, pero más fallan... ping -s 14 192.168.1.100 responde, pero ping 192.168.1.100 no...

les suena de algo???

saludos!

Cita de: danitool en 06-02-2014, 12:47 (Jueves)

Si es el caso de que efectivamente necesita un reset o un cambio de high a low, o viceversa antes de en un momento determinado, podría arreglarse fácilmente.

Por ejemplo para poner en HIGH/LOW antes de que se inicialice el USB este código podría valer, por ejemplo poniéndolo en el archivo board_bcm963xx.c. Antes de que se registren los USBs.
Código: [Seleccionar]
if ((board.has_ohci0 || board.has_ehci0)) { printk(KERN_INFO PFX "resetting gpio27 for usbHUB...\n"); gpio_request(27, "USB_rst"); gpio_direction_output(27, 0); gpio_set_value(27, 1); usbh_ports = board.num_usbh_ports; if (!usbh_ports || WARN_ON(usbh_ports > 1 && board.has_usbd)) usbh_ports = 1; }Puede que si lo que necesita es un reset necesitemos una línea más:
Código: [Seleccionar]
gpio_set_value(27, 0);
Aunque tal vez board_register_devices podría no ser la función correcta para hacer el cambio de high a low o viceversa sino en la función prom_init, de forma parecida a lo que hay para el bcm6318 y el gpio-pinmux para usb. Todo es cuestión de probar.

Tki2000 · « **Respuesta #15 en:** 06-02-2014, 21:16 (Jueves) »

¡¡¡Chachi!!!

Otro router rulando....

gmtii · « **Respuesta #16 en:** 07-02-2014, 00:12 (Viernes) »

si alguien consigue uno y quiere probar, ahí va un firmware (poniendo la definición de placa según dice el primer post)

https://www.dropbox.com/s/if7727rq1g46391/openwrt-96368MVWG-generic-squashfs-cfe.bin.gz

Creo que funciona todo.

Saludos.

Tki2000 · « **Respuesta #17 en:** 07-02-2014, 09:33 (Viernes) »

No pillé uno hace un par de días porque no había soporte y ahora fíjate.... ¡Qué rápido cambia la vida!...

A ver si consigo alguno y pruebo.

cvc90 · « **Respuesta #18 en:** 10-02-2014, 21:27 (Lunes) »

Buenas este router dispone de driver xDSL en openwrt??? Podrías dar mas detalles de como cambiar el nombre de placa, ya que dispongo uno de estos y me gustaría probar, gracias.

gmtii · « **Respuesta #19 en:** 10-02-2014, 21:59 (Lunes) »

no hay soporte de ADSL.

Sobre cambiar el nombre de la placa: debemos conectarnos por puerto serial al router vía conversor USB-TTL. De hecho pulsando el botón no entra en modo recovery así que igual es necesario sí o sí.

Pulsamos una tecla para interrumpir la cuenta atrás y ahí con la tecla b, accedemos al menu de cambio de nombre de placa.

De todos modos cuando el soporte este implantado no hará falta.

Saludos.

Noticias:

Autor Tema: [Desarrollo] OpenWrt en Observa Telecom VH4032N (Leído 234052 veces)

gmtii

danitool

Noltari

gmtii

gmtii

Noltari

gmtii

danitool

Noltari

gmtii

gmtii

cvc90

gmtii