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

habiss · « **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 · « **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?

Tki2000 · « **Respuesta #242 en:** 15-04-2016, 10:55 (Viernes) »

Cita de: habiss 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/valuecambia 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.

habiss · « **Respuesta #243 en:** 16-04-2016, 00:19 (Sábado) »

Cita de: Tki2000 en 15-04-2016, 10:55 (Viernes)

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.

Tki2000 · « **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

danto · « **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!

Tki2000 · « **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...

danitool · « **Respuesta #247 en:** 22-04-2016, 19:02 (Viernes) »

Cita de: Tki2000 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...

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.

Ficht · « **Respuesta #248 en:** 22-04-2016, 19:20 (Viernes) »

Cita de: Tki2000 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...

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.

Tki2000 · « **Respuesta #249 en:** 22-04-2016, 19:25 (Viernes) »

Cita de: danitool en 22-04-2016, 19:02 (Viernes)

Cita de: Tki2000 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...

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.

Ficht · « **Respuesta #250 en:** 22-04-2016, 19:31 (Viernes) »

Cita de: Tki2000 en 22-04-2016, 19:25 (Viernes)

Cita de: danitool en 22-04-2016, 19:02 (Viernes)
Cita de: Tki2000 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...

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!

Tki2000 · « **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?

danitool · « **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.

Tki2000 · « **Respuesta #253 en:** 22-04-2016, 20:18 (Viernes) »

Cita de: danitool 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.

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,

, lo tengo definido en el dts, pero no lo he pasado al parche, por eso no se ve). Voy a pasarlo al parche.

Tki2000 · « **Respuesta #254 en:** 22-04-2016, 20:50 (Viernes) »

Arreglado led azul de power.
Arregladas las particiones en el parche.

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.

Ficht · « **Respuesta #255 en:** 22-04-2016, 20:55 (Viernes) »

Cita de: danitool en 22-04-2016, 20:09 (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 · « **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.

Tki2000 · « **Respuesta #257 en:** 23-04-2016, 11:58 (Sábado) »

Cita de: danitool 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.

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

Tki2000 · « **Respuesta #258 en:** 23-04-2016, 14:02 (Sábado) »

Cita de: Tki2000 en 23-04-2016, 11:58 (Sábado)

Cita de: danitool 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.

¡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?

danitool · « **Respuesta #259 en:** 23-04-2016, 14:31 (Sábado) »

Genial

.

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.

Noticias:

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

habiss

habiss

habiss

danto

danitool

Ficht

Ficht

danitool

Ficht

danitool

danitool