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

0 Usuarios y 1 Visitante están viendo este tema.

habiss

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #240 en: 14-04-2016, 09:12 (Jueves) »
Muchas gracias Dani, pero no hay forma. Con GPIO_ACTIVE_LOW, da un kernel panic. Con GPIOF_INIT_HIGH no lo da, pero no funciona el usb. Probados con compilación limpia.

Pongo las salidas en Chaos Calmer y en Barrier Breaker con el mismo pendrive pinchado por si alguien ve algo.

En Chaos Calmer:

dmesg
Código: [Seleccionar]
[    5.100000] usbcore: registered new interface driver usbfs
[    5.108000] usbcore: registered new interface driver hub
[    5.112000] usbcore: registered new device driver usb
[    5.188000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    5.196000] ehci-platform: EHCI generic platform driver
[    5.304000] ehci-platform ehci-platform: EHCI Host Controller
[    5.308000] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1
[    5.316000] ehci-platform ehci-platform: irq 15, io mem 0xb0001500
[    5.336000] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00, overcurrent ignored
[    5.356000] uhci_hcd: USB Universal Host Controller Interface driver
lsusb
Código: [Seleccionar]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
/sys/bus/usb/devices
Código: [Seleccionar]
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-0:1.0 -> ../../../devices/platform/ehci-platform/usb1/1-0:1.0
lrwxrwxrwx    1 root     root           0 Jan  1  1970 usb1 -> ../../../devices/platform/ehci-platform/usb1


y en Barrier Breaker, funcionando correctamente:
dmesg
Código: [Seleccionar]
[    4.564000] usbcore: registered new interface driver usbfs
[    4.572000] usbcore: registered new interface driver hub
[    4.576000] usbcore: registered new device driver usb
[    4.680000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.688000] ehci-platform: EHCI generic platform driver
[    4.800000] ehci-platform ehci-platform: EHCI Host Controller
[    4.804000] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1
[    4.812000] ehci-platform ehci-platform: irq 15, io mem 0xb0001500
[    4.832000] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00, overcurrent ignored
[    4.852000] uhci_hcd: USB Universal Host Controller Interface driver
[    4.868000] usbcore: registered new interface driver usb-storage
[    5.260000] usb 1-2: new high-speed USB device number 2 using ehci-platform
[    5.768000] usb 1-2.1: new high-speed USB device number 3 using ehci-platform
[    5.884000] usb-storage 1-2.1:1.0: USB Mass Storage device detected
[    5.892000] scsi0 : usb-storage 1-2.1:1.0

lsusb
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 001 Device 003: ID abcd:1234 Unknown

/sys/bus/usb/devices
Código: [Seleccionar]
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-0:1.0 -> ../../../devices/platform/ehci-platform/usb1/1-0:1.0
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-2 -> ../../../devices/platform/ehci-platform/usb1/1-2
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-2.1 -> ../../../devices/platform/ehci-platform/usb1/1-2/1-2.1
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-2.1:1.0 -> ../../../devices/platform/ehci-platform/usb1/1-2/1-2.1/1-2.1:1.0
lrwxrwxrwx    1 root     root           0 Jan  1  1970 1-2:1.0 -> ../../../devices/platform/ehci-platform/usb1/1-2/1-2:1.0
lrwxrwxrwx    1 root     root           0 Jan  1  1970 usb1 -> ../../../devices/platform/ehci-platform/usb1



habiss

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #241 en: 15-04-2016, 08:54 (Viernes) »
Sigo haciendo pruebas. Parece que el ephy-reset no logra poner el gpio en alto.

La salida de /sys/kernel/debug/gpio aparece como desplazados los gpio con un offset de 474:
Código: [Seleccionar]
GPIOs 474-505, platform/10000084.gpio-controller, bcm63xx-gpio.0:
 gpio-476 (VH4032N:blue:dsl    ) out hi   
 gpio-479 (VH4032N:red:dsl     ) out hi   
 gpio-485 (VH4032N:blue:hspa   ) out hi   
 gpio-486 (VH4032N:red:hspa    ) out hi   
 gpio-498 (VH4032N:red:power   ) out hi   
 gpio-499 (VH4032N:blue:voice  ) out hi   
 gpio-500 (VH4032N:red:voice   ) out hi   

GPIOs 506-511, platform/10000080.gpio-controller, bcm63xx-gpio.1:

En Barrier Breaker si sale bien y se ve en /sys/kernel/debug/gpio el gpio-27 con nombre ephy-reset en high:

Código: [Seleccionar]
GPIOs 0-37, bcm63xx-gpio:
 gpio-2   (VH4032N:blue:dsl    ) out hi
 gpio-5   (VH4032N:red:dsl     ) out hi
 gpio-11  (VH4032N:blue:hspa   ) out hi
 gpio-12  (VH4032N:red:hspa    ) out hi
 gpio-24  (VH4032N:red:power   ) out hi
 gpio-25  (VH4032N:blue:voice  ) out lo
 gpio-26  (VH4032N:red:voice   ) out hi
 gpio-27  (ephy-reset          ) out hi
 gpio-34  (reset               ) in  hi
 gpio-35  (wps                 ) in  hi


si exporto el 501 (que se correspondería con el gpio 27) y lo pongo en salida alto:
Código: [Seleccionar]
echo 501 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio501/direction
echo 1 > /sys/class/gpio/gpio501/value
cambia el /sys/kernel/debug/gpio, pero sigue sin haber potencia en el usb:

Código: [Seleccionar]
GPIOs 474-505, platform/10000084.gpio-controller, bcm63xx-gpio.0:
 gpio-476 (VH4032N:blue:dsl    ) out hi   
 gpio-479 (VH4032N:red:dsl     ) out hi   
 gpio-485 (VH4032N:blue:hspa   ) out hi   
 gpio-486 (VH4032N:red:hspa    ) out hi   
 gpio-498 (VH4032N:red:power   ) out hi   
 gpio-499 (VH4032N:blue:voice  ) out hi   
 gpio-500 (VH4032N:red:voice   ) out hi   
 gpio-501 (sysfs               ) out hi   

GPIOs 506-511, platform/10000080.gpio-controller, bcm63xx-gpio.1:

alguién ve como solucionarlo?

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #242 en: 15-04-2016, 10:55 (Viernes) »
Sigo haciendo pruebas. Parece que el ephy-reset no logra poner el gpio en alto.

La salida de /sys/kernel/debug/gpio aparece como desplazados los gpio con un offset de 474:
Código: [Seleccionar]
GPIOs 474-505, platform/10000084.gpio-controller, bcm63xx-gpio.0:
 gpio-476 (VH4032N:blue:dsl    ) out hi   
 gpio-479 (VH4032N:red:dsl     ) out hi   
 gpio-485 (VH4032N:blue:hspa   ) out hi   
 gpio-486 (VH4032N:red:hspa    ) out hi   
 gpio-498 (VH4032N:red:power   ) out hi   
 gpio-499 (VH4032N:blue:voice  ) out hi   
 gpio-500 (VH4032N:red:voice   ) out hi   

GPIOs 506-511, platform/10000080.gpio-controller, bcm63xx-gpio.1:

En Barrier Breaker si sale bien y se ve en /sys/kernel/debug/gpio el gpio-27 con nombre ephy-reset en high:

Código: [Seleccionar]
GPIOs 0-37, bcm63xx-gpio:
 gpio-2   (VH4032N:blue:dsl    ) out hi
 gpio-5   (VH4032N:red:dsl     ) out hi
 gpio-11  (VH4032N:blue:hspa   ) out hi
 gpio-12  (VH4032N:red:hspa    ) out hi
 gpio-24  (VH4032N:red:power   ) out hi
 gpio-25  (VH4032N:blue:voice  ) out lo
 gpio-26  (VH4032N:red:voice   ) out hi
 gpio-27  (ephy-reset          ) out hi
 gpio-34  (reset               ) in  hi
 gpio-35  (wps                 ) in  hi


si exporto el 501 (que se correspondería con el gpio 27) y lo pongo en salida alto:
Código: [Seleccionar]
echo 501 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio501/direction
echo 1 > /sys/class/gpio/gpio501/value
cambia el /sys/kernel/debug/gpio, pero sigue sin haber potencia en el usb:

Código: [Seleccionar]
GPIOs 474-505, platform/10000084.gpio-controller, bcm63xx-gpio.0:
 gpio-476 (VH4032N:blue:dsl    ) out hi   
 gpio-479 (VH4032N:red:dsl     ) out hi   
 gpio-485 (VH4032N:blue:hspa   ) out hi   
 gpio-486 (VH4032N:red:hspa    ) out hi   
 gpio-498 (VH4032N:red:power   ) out hi   
 gpio-499 (VH4032N:blue:voice  ) out hi   
 gpio-500 (VH4032N:red:voice   ) out hi   
 gpio-501 (sysfs               ) out hi   

GPIOs 506-511, platform/10000080.gpio-controller, bcm63xx-gpio.1:

alguién ve como solucionarlo?


Para darle el reset, tienes que ponerlo a alto, y luego ponerlo a bajo. Hace el reset, al quitar la señal, después de habérsela dado.
Lo que no sé, es si hace reset después de haberse comunicado con el driver. El reset debería ser anterior a la carga del driver.
En última instancia, prueba a descargar el driver y volverlo a cargar después de hacer el reset.
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

habiss

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #243 en: 16-04-2016, 00:19 (Sábado) »
Para darle el reset, tienes que ponerlo a alto, y luego ponerlo a bajo. Hace el reset, al quitar la señal, después de habérsela dado.
Lo que no sé, es si hace reset después de haberse comunicado con el driver. El reset debería ser anterior a la carga del driver.
En última instancia, prueba a descargar el driver y volverlo a cargar después de hacer el reset.

Gracias Tki2000 y Dani por responder. No sirve. Haciendo el reset manual a través de sysfs sigue sin funcionar.
Total ya lo dejo, porque con mis escasos conocimientos el tema me viene muy grande, aunque algo he aprendido. Vuelvo a Barrier Breaker. Gracias.

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #244 en: 19-04-2016, 17:17 (Martes) »
He actualizado el post con la imagen Barrier Breaker 14.04 para el VH4032N : https://foro.seguridadwireless.net/openwrt/(desarrollo)-observa-telecom-vh4032n/msg310444/#msg310444

Actualización -> Repositorio completo r40396 Barrier Breaker 14.04 (640MB) : VH4032N-WRT-Repository-3.10.34-1.zip
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

danto

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #245 en: 21-04-2016, 20:30 (Jueves) »
Hola,

Gracias a toda la info que hay en este hilo he podido replicar lo que hizo gmtii y añadir soporte a la ultima versión (y supongo que) estable de barrier breaker 14.07 que hay en el git de openwrt-es.

Por si hay algún interesado, el binario que he usado es este: http://www.mediafire.com/download/puj33iacxopyxrt/openwrt-VH4032N-squashfs-cfe.bin

He puesto que utilice el driver privativo de broadcom (kmod-brcm-wl), compatibilidad con algunos usb-serie chinos como el ch431, el python y algun modulo diferente de luci. Quiero darle una segunda vida al router y usarlo como servidor de impresion 3d con octoprint.

Un saludo!

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #246 en: 22-04-2016, 18:49 (Viernes) »
He conseguido compilar un trunk r49199 con USB funcional.
Todavía estoy haciendo pruebas, y hasta que no consiga compilar todo el repositorio no colgaré la imagen, así que paciencia.

Por si hay alguien que esté impaciente, aquí dejo los parches que he hecho para el trunk r41999: VH4032N trunk Patches. Funcionarán durante un tiempo, mientras no metan las "zarpas" a los ficheros que modifica el parche.

Están tanto los parches para "poner" activo el VH4032N en la compilación, como los parches para revertir los cambios (los ficheros que tienen sufijo _revert).

Para aplicarlos, utilizar la fórmula
Código: [Seleccionar]
patch -p0 < patch-openwrt.patch
patch -p0 < patch-kernel.patch

Para quitarlos,
Código: [Seleccionar]
patch -p0 < patch-openwrt_revert.patch
patch -p0 < patch-kernel_revert.patch

¡Hala!. ¡A Compilar con ganas...!  ;) , o a esperar a que suba mi compilación cuando esté terminada...  >:D
« Última modificación: 22-04-2016, 19:20 (Viernes) por Tki2000 »
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

danitool

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #247 en: 22-04-2016, 19:02 (Viernes) »
He conseguido compilar un trunk r49199 con USB funcional.
Todavía estoy haciendo pruebas, y hasta que no consiga compilar todo el repositorio no colgaré la imagen, así que paciencia.

Por si hay alguien que esté impaciente, aquí dejo los parches que he hecho para el trunk r41999: VH4032N trunk Patches. Funcionarán durante un tiempo, mientras no metan las "zarpas" a los ficheros que modifica el parche.

Están tanto los parches para "poner" activo el VH4032N en la compilación, como los parches para revertir los cambios (los ficheros que tienen sufijo _revert).

Para aplicarlos, utilizar la fórmula
Código: [Seleccionar]
patch -p0 < patch-openwrt.patch
patch -p0 < patch-kernel.patch

Para quitarlos,
Código: [Seleccionar]
patch -p0 < patch-openwrt_revert.patch
patch -p0 < patch-kernel_revert.patch

¡Hala!. ¡A Compilar con ganas...!  ;) , o a esperar a que suba mi compilación cuando esté terminada...  >:D

Le he echado un ojo..
Código: [Seleccionar]
+               reset {
+                       label = "reset";
+                       gpios = <&gpio0 34 1>;
+                       linux,code = <KEY_RESTART>;
+               };
+               wps {
+                       label = "wps";
+                       gpios = <&gpio0 35 1>;
+                       linux,code = <KEY_WPS_BUTTON>;
+               };
esto no puede estar bien, lo máximo admisible es 31 para el controlador gpio, si el número de gpio es mayor que 31 hay que saltar al siguiente chip (gpio1) y seguir contando desde 0.
« Última modificación: 22-04-2016, 19:05 (Viernes) por danitool »

Ficht

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #248 en: 22-04-2016, 19:20 (Viernes) »
He conseguido compilar un trunk r49199 con USB funcional.
Todavía estoy haciendo pruebas, y hasta que no consiga compilar todo el repositorio no colgaré la imagen, así que paciencia.

Por si hay alguien que esté impaciente, aquí dejo los parches que he hecho para el trunk r41999: VH4032N trunk Patches. Funcionarán durante un tiempo, mientras no metan las "zarpas" a los ficheros que modifica el parche.

Están tanto los parches para "poner" activo el VH4032N en la compilación, como los parches para revertir los cambios (los ficheros que tienen sufijo _revert).

Para aplicarlos, utilizar la fórmula
Código: [Seleccionar]
patch -p0 < patch-openwrt.patch
patch -p0 < patch-kernel.patch

Para quitarlos,
Código: [Seleccionar]
patch -p0 < patch-openwrt_revert.patch
patch -p0 < patch-kernel_revert.patch

¡Hala!. ¡A Compilar con ganas...!  ;) , o a esperar a que suba mi compilación cuando esté terminada...  >:D

 >:(  >:(  >:(

Hombre @Tki2000 buen trabajo!!
No has intentado definir los led's que le faltaban? (power azul, y los 4 de Lan)
En cuanto me libere un poco de cosas, me pondré a probar. (había probado 500 veces, pero no me salia)

Saludos.

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #249 en: 22-04-2016, 19:25 (Viernes) »
He conseguido compilar un trunk r49199 con USB funcional.
Todavía estoy haciendo pruebas, y hasta que no consiga compilar todo el repositorio no colgaré la imagen, así que paciencia.

Por si hay alguien que esté impaciente, aquí dejo los parches que he hecho para el trunk r41999: VH4032N trunk Patches. Funcionarán durante un tiempo, mientras no metan las "zarpas" a los ficheros que modifica el parche.

Están tanto los parches para "poner" activo el VH4032N en la compilación, como los parches para revertir los cambios (los ficheros que tienen sufijo _revert).

Para aplicarlos, utilizar la fórmula
Código: [Seleccionar]
patch -p0 < patch-openwrt.patch
patch -p0 < patch-kernel.patch

Para quitarlos,
Código: [Seleccionar]
patch -p0 < patch-openwrt_revert.patch
patch -p0 < patch-kernel_revert.patch

¡Hala!. ¡A Compilar con ganas...!  ;) , o a esperar a que suba mi compilación cuando esté terminada...  >:D

Le he echado un ojo..
Código: [Seleccionar]
+               reset {
+                       label = "reset";
+                       gpios = <&gpio0 34 1>;
+                       linux,code = <KEY_RESTART>;
+               };
+               wps {
+                       label = "wps";
+                       gpios = <&gpio0 35 1>;
+                       linux,code = <KEY_WPS_BUTTON>;
+               };
esto no puede estar bien, lo máximo admisible es 31 para el controlador gpio, si el número de gpio es mayor que 31 hay que saltar al siguiente chip (gpio1) y seguir contando desde 0.

¡¡¡Actualizado!!! Gracias por el apunte, danitool

Ficht, no he actualizado eso. Como ya he dicho, estoy en pruebas. Pero si alguien sabe qué gpios son, puedo actualizar el parche.
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

Ficht

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #250 en: 22-04-2016, 19:31 (Viernes) »
He conseguido compilar un trunk r49199 con USB funcional.
Todavía estoy haciendo pruebas, y hasta que no consiga compilar todo el repositorio no colgaré la imagen, así que paciencia.

Por si hay alguien que esté impaciente, aquí dejo los parches que he hecho para el trunk r41999: VH4032N trunk Patches. Funcionarán durante un tiempo, mientras no metan las "zarpas" a los ficheros que modifica el parche.

Están tanto los parches para "poner" activo el VH4032N en la compilación, como los parches para revertir los cambios (los ficheros que tienen sufijo _revert).

Para aplicarlos, utilizar la fórmula
Código: [Seleccionar]
patch -p0 < patch-openwrt.patch
patch -p0 < patch-kernel.patch

Para quitarlos,
Código: [Seleccionar]
patch -p0 < patch-openwrt_revert.patch
patch -p0 < patch-kernel_revert.patch

¡Hala!. ¡A Compilar con ganas...!  ;) , o a esperar a que suba mi compilación cuando esté terminada...  >:D

Le he echado un ojo..
Código: [Seleccionar]
+               reset {
+                       label = "reset";
+                       gpios = <&gpio0 34 1>;
+                       linux,code = <KEY_RESTART>;
+               };
+               wps {
+                       label = "wps";
+                       gpios = <&gpio0 35 1>;
+                       linux,code = <KEY_WPS_BUTTON>;
+               };
esto no puede estar bien, lo máximo admisible es 31 para el controlador gpio, si el número de gpio es mayor que 31 hay que saltar al siguiente chip (gpio1) y seguir contando desde 0.

¡¡¡Actualizado!!! Gracias por el apunte, danitool

Ficht, no he actualizado eso. Como ya he dicho, estoy en pruebas. Pero si alguien sabe qué gpios son, puedo actualizar el parche.

Aquí están en este hilo de GPIO's

Esto de GPIO0 es una de la cosas que hacia mal... jejeje ¡como se aprende en este foro!

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #251 en: 22-04-2016, 19:45 (Viernes) »
Gracias Fitch, le echaré un ojo.

Una de las cosas que he notado es que no salen bien las particiones, con respecto a la memoria flash del router.
Las particiones en BB, ocupaban las 32MB de flash completamente.
En trunk, aunque las particiones se las he definido en el dts, al arrancar, sólo detecta 16MB de flash.

En BB:
Código: [Seleccionar]
[    0.540000] Creating 5 MTD partitions on "physmap-flash.0":
[    0.548000] 0x000000000000-0x000000020000 : "CFE"
[    0.556000] 0x000000020100-0x000000140000 : "kernel"
[    0.560000] mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    0.576000] 0x000000140000-0x000001fe0000 : "rootfs"
[    0.584000] mtd: device 2 (rootfs) set to be root filesystem
[    0.588000] mtd: partition "rootfs_data" created automatically, ofs=0x720000, len=0x18c0000
[    0.596000] 0x000000720000-0x000001fe0000 : "rootfs_data"
[    0.604000] 0x000001fe0000-0x000002000000 : "nvram"
[    0.612000] 0x000000020000-0x000001fe0000 : "linux"

En trunk:
Código: [Seleccionar]
[    0.454787] Creating 6 MTD partitions on "18000000.nor":
[    0.460244] 0x000000000000-0x000000020000 : "CFE"
[    0.466467] 0x000000020100-0x000000158a04 : "kernel"
[    0.472870] 0x000000158a04-0x000000fa0000 : "rootfs"
[    0.479219] mtd: device 2 (rootfs) set to be root filesystem
[    0.485058] 1 squashfs-split partitions found on MTD device rootfs
[    0.491389] 0x000000340000-0x000000fa0000 : "rootfs_data"
[    0.498238] 0x000000020000-0x000000fa0000 : "linux"
[    0.504555] 0x000000fa0000-0x000000fc0000 : "cal_data"
[    0.511219] 0x000000fe0000-0x000001000000 : "nvram"

¿Algo hago mal?  ???
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

danitool

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #252 en: 22-04-2016, 20:09 (Viernes) »
Tienes que hacer un poco de números para definir las particiones.

32MB es 0x2000000 en hexadecimal, restando lo que ocupa la nvram tendríamos
0x2000000 - 0x020000 = 0x1FE0000
por tanto la última partición debería ser

Código: [Seleccionar]
+ nvram@fe0000 {
+ label = "nvram";
+ reg = <0x1FE0000 0x020000>;
+ };

La partición cal_data sobra ya que sino me equivoco el chip es un bcm4322, y broadcom no necesita particiones de calibración, si acaso una "sprom fixup" lo cual es un código totalmente diferente que no afecta a las particiones.

El resto de particiones tendrás que acomodarlas al espacio de 32 MB haciendo cuentas.

Lo de los leds LAN ... deberían ir controlados por hardware. Igual se puede hacer algún apaño para que se active esa función en el SoC. Lo que no sé es por qué no es capaz de hacerlo el propio bootloader. Tal vez si soy capaz de averiguar como va el tema, puedo proponer algún comando experimental a ver si alguien se anima y es capaz de activar los leds para que funcionen de forma autónoma.
« Última modificación: 22-04-2016, 20:09 (Viernes) por danitool »

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #253 en: 22-04-2016, 20:18 (Viernes) »
Tienes que hacer un poco de números para definir las particiones.

32MB es 0x2000000 en hexadecimal, restando lo que ocupa la nvram tendríamos
0x2000000 - 0x020000 = 0x1FE0000
por tanto la última partición debería ser

Código: [Seleccionar]
+ nvram@fe0000 {
+ label = "nvram";
+ reg = <0x1FE0000 0x020000>;
+ };

La partición cal_data sobra ya que sino me equivoco el chip es un bcm4322, y broadcom no necesita particiones de calibración, si acaso una "sprom fixup" lo cual es un código totalmente diferente que no afecta a las particiones.

El resto de particiones tendrás que acomodarlas al espacio de 32 MB haciendo cuentas.

Lo de los leds LAN ... deberían ir controlados por hardware. Igual se puede hacer algún apaño para que se active esa función en el SoC. Lo que no sé es por qué no es capaz de hacerlo el propio bootloader. Tal vez si soy capaz de averiguar como va el tema, puedo proponer algún comando experimental a ver si alguien se anima y es capaz de activar los leds para que funcionen de forma autónoma.


Así es como lo tengo definido:

Código: [Seleccionar]
&pflash {
status = "ok";

linux,part-probe = "bcm63xxpart";

cfe@0 {
label = "CFE";
reg = <0x0000000 0x0020000>;
read-only;
};

linux@20000 {
label = "linux";
reg = <0x0020000 0x1fc0000>;
};

nvram@1fe0000 {
label = "nvram";
reg = <0x1fe0000 0x020000>;
};
};

P.D.: (Soy borrico, ;D , lo tengo definido en el dts, pero no lo he pasado al parche, por eso no se ve). Voy a pasarlo al parche.
« Última modificación: 22-04-2016, 20:23 (Viernes) por Tki2000 »
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #254 en: 22-04-2016, 20:50 (Viernes) »
Arreglado led azul de power.
Arregladas las particiones en el parche.  :-X
Actualizado el contenido del parche en el enlace de descarga.

Como nota curiosa, pongo que las luces de lan, en el CFE parpadean perfectamente al cargar datos, pero al arrancar openwrt, dejan de funcionar.

No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

Ficht

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #255 en: 22-04-2016, 20:55 (Viernes) »

Lo de los leds LAN ... deberían ir controlados por hardware. Igual se puede hacer algún apaño para que se active esa función en el SoC. Lo que no sé es por qué no es capaz de hacerlo el propio bootloader. Tal vez si soy capaz de averiguar como va el tema, puedo proponer algún comando experimental a ver si alguien se anima y es capaz de activar los leds para que funcionen de forma autónoma.


Si al encender el router hay algo conectado a lan, entonces el led correspondiente se enciende, parece ser detectado..... pero ya; una vez que ha empezado linux, ya se queda dicho's led's congelados, los gpio's descritos, si que los hacen trabajar (active low)

danitool

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #256 en: 22-04-2016, 22:59 (Viernes) »
Si podeis probad este parche para el tema de los leds de lan
Código: [Seleccionar]
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
@@ -80,6 +80,19 @@
  * inside arch_initcall */
  val = 0;
 
+ if (board.has_enetsw) {
+ if (BCMCPU_IS_6368()) {
+ printk("Testing: code for enabling HW controled leds\n");
+ printk("GPIO_MODE_REG = 0x%x \n", bcm_gpio_readl(GPIO_MODE_REG));
+ bcm_gpio_writel(val, GPIO_MODE_REG);
+ val |= GPIO_MODE_6368_EPHY0_LED |
+ GPIO_MODE_6368_EPHY1_LED |
+ GPIO_MODE_6368_EPHY2_LED |
+ GPIO_MODE_6368_EPHY3_LED;
+ bcm_gpio_writel(bcm_gpio_readl(GPIO_CTL_LO_REG) | val, GPIO_CTL_LO_REG);
+ }
+ }
+
 #ifdef CONFIG_PCI
  if (board.has_pci) {
  bcm63xx_pci_enabled = 1;

Funcione o no me interesa saber que devuelve la línea del log del kernel:

GPIO_MODE_REG =

Lo del comando en consola sería con devmem, pero como devmem fue deshabilitado en las últimas versiones de kernel, considero que esto es menos lioso que volverlo a habilitar en la rama trunk.

Edit: el parche mejor probarlo sin los leds de lan definidos en el archivo dts, o en el kernel en caso de usar Barrier Breaker.
« Última modificación: 22-04-2016, 23:03 (Viernes) por danitool »

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #257 en: 23-04-2016, 11:58 (Sábado) »
Si podeis probad este parche para el tema de los leds de lan
Código: [Seleccionar]
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
@@ -80,6 +80,19 @@
  * inside arch_initcall */
  val = 0;
 
+ if (board.has_enetsw) {
+ if (BCMCPU_IS_6368()) {
+ printk("Testing: code for enabling HW controled leds\n");
+ printk("GPIO_MODE_REG = 0x%x \n", bcm_gpio_readl(GPIO_MODE_REG));
+ bcm_gpio_writel(val, GPIO_MODE_REG);
+ val |= GPIO_MODE_6368_EPHY0_LED |
+ GPIO_MODE_6368_EPHY1_LED |
+ GPIO_MODE_6368_EPHY2_LED |
+ GPIO_MODE_6368_EPHY3_LED;
+ bcm_gpio_writel(bcm_gpio_readl(GPIO_CTL_LO_REG) | val, GPIO_CTL_LO_REG);
+ }
+ }
+
 #ifdef CONFIG_PCI
  if (board.has_pci) {
  bcm63xx_pci_enabled = 1;

Funcione o no me interesa saber que devuelve la línea del log del kernel:

GPIO_MODE_REG =

Lo del comando en consola sería con devmem, pero como devmem fue deshabilitado en las últimas versiones de kernel, considero que esto es menos lioso que volverlo a habilitar en la rama trunk.

Edit: el parche mejor probarlo sin los leds de lan definidos en el archivo dts, o en el kernel en caso de usar Barrier Breaker.

¡Oído cocina!
Lo pruebo y te digo...
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 1940
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #258 en: 23-04-2016, 14:02 (Sábado) »
Si podeis probad este parche para el tema de los leds de lan
Código: [Seleccionar]
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
@@ -80,6 +80,19 @@
  * inside arch_initcall */
  val = 0;
 
+ if (board.has_enetsw) {
+ if (BCMCPU_IS_6368()) {
+ printk("Testing: code for enabling HW controled leds\n");
+ printk("GPIO_MODE_REG = 0x%x \n", bcm_gpio_readl(GPIO_MODE_REG));
+ bcm_gpio_writel(val, GPIO_MODE_REG);
+ val |= GPIO_MODE_6368_EPHY0_LED |
+ GPIO_MODE_6368_EPHY1_LED |
+ GPIO_MODE_6368_EPHY2_LED |
+ GPIO_MODE_6368_EPHY3_LED;
+ bcm_gpio_writel(bcm_gpio_readl(GPIO_CTL_LO_REG) | val, GPIO_CTL_LO_REG);
+ }
+ }
+
 #ifdef CONFIG_PCI
  if (board.has_pci) {
  bcm63xx_pci_enabled = 1;

Funcione o no me interesa saber que devuelve la línea del log del kernel:

GPIO_MODE_REG =

Lo del comando en consola sería con devmem, pero como devmem fue deshabilitado en las últimas versiones de kernel, considero que esto es menos lioso que volverlo a habilitar en la rama trunk.

Edit: el parche mejor probarlo sin los leds de lan definidos en el archivo dts, o en el kernel en caso de usar Barrier Breaker.

¡Oído cocina!
Lo pruebo y te digo...

¡¡¡Éxito total!!!
Los LEDes ya parpadean con la actividad.
Ésto es lo que sale con las líneas de antes:

Código: [Seleccionar]
[    0.000000] Testing: code for enabling HW controled leds
[    0.000000] GPIO_MODE_REG = 0x3c0

danitool
La lectura de GPIO_MODE_REG, es el mismo valor que luego le das a val, y que combinas con GPIO_CTL_LO_REG.
Entiendo que con el reseteo de GPIO_MODE_REG, le quitas el control al controlador de GPIO, y con la segunda escritura, le das el control a la controladora hardware, ¿por decirlo en plan coloquial?
« Última modificación: 23-04-2016, 14:29 (Sábado) por Tki2000 »
No habrás entendido algo, hasta que seas capaz de explicárselo a tu abuela...
Hacemos pantallas con píxeles casi invisibles, para luego ampliar la letra porque no la vemos... Bonita paradoja...
Creamos analfabetos tecnológicos con una velocidad pasmosa. Todo el mundo "maneja" tecnología, casi nadie sabe lo que tiene entre las manos, pero todo el mundo opina.
El analfabetismo, antes, pasaba desapercibido. Ahora, se transmite por Internet y las redes sociales.
Solo a un mandril epiléptico se le podría haber ocurrido diseñar la cinta de menú de M$.

danitool

  • Visitante
Re: [Desarrollo] OpenWrt en Observa Telecom VH4032N
« Respuesta #259 en: 23-04-2016, 14:31 (Sábado) »
Genial  :D.

Lo que no entiendo es por qué no funcionaban antes, ya que el registro del pinmux para esos leds de hardware parece que ya estaba activado. A menos que se borrase la configuración como "output" en esos gpios.

O tal vez necesite un "reset" del pinmux, o una puesta a 0 como hace el código propuesto.

En todo caso un pequeño avance más.