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

Ficht · « **Respuesta #260 en:** 23-04-2016, 19:19 (Sábado) »

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

Entonces, estos GPIO's ya no serán exportables como tal, tendrían que volverse a liberar en caso de querer usarlos verdad?

danitool · « **Respuesta #261 en:** 23-04-2016, 19:44 (Sábado) »

Cita de: Ficht en 23-04-2016, 19:19 (Sábado)

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

Entonces, estos GPIO's ya no serán exportables como tal, tendrían que volverse a liberar en caso de querer usarlos verdad?

Viendo que sí son exportables y controlables via software aun teniendo el pinmux activado por CFE, no sabría que decir. No sé que ocurre para que los leds dejen de funcionar mediante control por hardware.

Así que tal vez sí tal vez no

Tki2000 · « **Respuesta #262 en:** 23-04-2016, 21:33 (Sábado) »

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

He estado experimentando para ver qué es lo que influye en el estado del registro, y por ahora no le encuentro explicación:

No influye si lo ponemos o lo quitamos:

Código: [Seleccionar]

bcm_gpio_writel(val, GPIO_MODE_REG);
Si calculamos val y lo OReamos a GPIO_CTL_LO_REG, funciona, aunque el valor resultado sea el mismo leído:

Código: [Seleccionar]

bcm_gpio_writel(bcm_gpio_readl(GPIO_CTL_LO_REG) | val, GPIO_CTL_LO_REG);
Si leemos y escribimos el mismo valor en el registro GPIO_CTL_LO_REG, no funciona

Código: [Seleccionar]

bcm_gpio_writel(bcm_gpio_readl(GPIO_CTL_LO_REG), GPIO_CTL_LO_REG);
¿En qué puede influir que hagamos el OR con val, si el valor que escribimos es el mismo que leemos?
El valor de los registros siempre es el mismo, antes y después de la escritura...:

Código: [Seleccionar]

GPIO_MODE_REG = 0x3c0
GPIO_CTL_LO_REG = 0x34043e4

Expediente X

danitool · « **Respuesta #263 en:** 23-04-2016, 22:25 (Sábado) »

Expediente X total. No tengo ninguna placa bcm6368 con leds lan así que poco puedo decir. En las bcm6328 no ocurre esto, la activación de leds lan por hardware es totalmente sólida.

Podríamos usar devmem para experimentar un poco más. Es más inmediato a la hora de cambiar los registros a placer:

Primero leemos GPIO_MODE_REG:

Código: [Seleccionar]

devmem 0x10000092 32Elegimos nuevo valor desactivanto los bits 6 7 8 9 y lo escribimos

Código: [Seleccionar]

devmem 0x10000092 32 nuevovalor_hexVolvemos a escribir de nuevo el valor original

Código: [Seleccionar]

devmem 0x10000092 32 valororiginal_hex

Lo mismo podríamos hacer para GPIO_CTL_LO_REG

Código: [Seleccionar]

devmem 0x10000084 32cambiamos los bits de lo que nos ha devuelto

Código: [Seleccionar]

devmem 0x10000084 32 nuevovalor_hex

Para tener devmem en la rama trunk es necesario activarlo en el kernel, y habilitar la utilidad devmem en el busybox, lo primero en el menú del kernel (make kernel_menuconfig), lo segundo con el menuconfig habitual en las subopciones del busybox.

En Chaos calmer y versiones previas devmem viene operativo. Si alguien da con un comando que active los leds por hardware, no haría falta recompilar firmwares para activarlo (en versiones CC o anteriores obviamente). Serviría también para otros modelos de router supongo.

Tki2000 · « **Respuesta #264 en:** 25-04-2016, 14:43 (Lunes) »

Por ahora he conseguido que el USB funcione bien, pero estoy atascado con otro problema. No consigo que el switch de red funcione.
Aparentemente, detecta cuando se le enchufa/desenchufa una clavija de red, pero no levanta el switch, y si lo hago manualmente, pierde todos los paquetes, osea, que estoy incomunicado por RJ45...
He probado con y sin el parche de los LEDes...
¿Alguna idea?

Edito:

Parece que tiene que ver con esto: https://dev.openwrt.org/ticket/21843
El cambio se produjo en la revisión r47867 : https://dev.openwrt.org/changeset/47867

¿Alguien ha tenido problemas en las plataformas bcm63xx, después de esa revisión, para acceder al switch?
¿Estoy en un callejón sin salida?

Tki2000 · « **Respuesta #265 en:** 26-04-2016, 22:03 (Martes) »

Pego un log de arranque, por si alguien consigue discernir por qué no funciona el switch.
Me llama la atención el error ifconfig: SIOCGIFFLAGS: No such device, pero no consigo saber el por qué de este error.
Al final br-lan no se levanta.

Código: [Seleccionar]

CFE version 1.0.37-102.15 for BCM96368 (32bit,SP,BE)
Build Date: Wed Feb 10 09:57:47 CST 2010 (link@hpnb)
Copyright (C) 2000-2009 Broadcom Corporation.

Parallel flash device: name AM29LV320MT, id 0x2201, size 32768KB
CPU type 0x2A031: 400MHz, Bus: 160MHz, Ref: 64MHz
CPU running TP0
Total memory: 134217728 bytes (128MB)
Boot Address 0xb8000000


Board IP address                  : 192.168.1.1:ffffff00
Host IP address                   : 192.168.1.100
Gateway IP address                :
Run from flash/host (f/h)         : f
Default host run file name        : vmlinux
Default host flash file name      : bcm963xx_fs_kernel
Boot delay (0-9 seconds)          : 3
Boot image (0=latest, 1=previous) : 0
Board Id (0-4)                    : 96368VVW
Number of MAC Addresses (1-32)    : 11
Base MAC Address                  : e4:xx:xx:xx:xx:xx
PSI Size (1-64) KBytes            : 64
Main Thread Number [0|1]          : 0
Serial Number (20)                : -----------
Vendor Specific 01 (40)           : ---------------
Vendor Specific 02 (40)           :
Vendor Specific 03 (40)           :

*** Press any key to stop auto run (3 seconds) ***
Auto run second count down: 0
Booting from latest image (0xb8020000) ...
Code Address: 0x80A00000, Entry Address: 0x80a00000
LZMA: Prossible old LZMA format, trying to decompress..
Decompression OK!
Entry at 0x80a00000
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
21 buffers found.
Closing DMA Channels.
Starting program at 0x80a00000
[    0.000000] Linux version 4.1.20 (tki2k@Ubuntu) (gcc version 5.3.0 (OpenWrt G
CC 5.3.0 r49199) ) #3 SMP Tue Apr 26 19:33:03 UTC 2016
[    0.000000] Detected Broadcom 0x6368 CPU revision b2
[    0.000000] CPU frequency is 400 MHz
[    0.000000] 128MB of RAM installed
[    0.000000] board_bcm963xx: Boot address 0xb8000000
[    0.000000] board_bcm963xx: CFE version: 1.0.37-102.15
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0002a031 (Broadcom BMIPS4350)
[    0.000000] board: board name: VH4032N
[    0.000000] MIPS: machine is Observa VH4032N
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 08000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 16 bytes.
[    0.000000] Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 16 bytes
[    0.000000] PERCPU: Embedded 10 pages/cpu @81106000 s10048 r8192 d22720 u40960
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line:  root=/dev/mtdblock2 rootfstype=squashfs,jffs2
 noinitrd console=ttyS0,115200
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 124180K/131072K available (3175K kernel code, 139K rwdata,
 732K rodata, 1320K init, 203K bss, 6892K reserved, 0K cma-reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:256
[    0.000000] clocksource MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns
[    0.000016] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns
[    0.008675] Calibrating delay loop... 397.82 BogoMIPS (lpj=795648)
[    0.046960] pid_max: default: 32768 minimum: 301
[    0.052387] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.059170] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.072782] SMP: Booting CPU1...
[   10.814423] Primary instruction cache 64kB, VIPT, 4-way, linesize 16 bytes.
[   10.814438] Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 16 bytes
[   10.814746] CPU1 revision is: 0002a031 (Broadcom BMIPS4350)
[    0.124962] Synchronize counters for CPU 1:
[    0.124964] SMP: CPU1 is running
[    0.124982] done.
[    0.125174] Brought up 2 CPUs
[    0.144032] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.155442] NET: Registered protocol family 16
[    0.165572] registering PCI controller with io_map_base unset
[    0.196014] PCI host bridge to bus 0000:00
[    0.200311] pci_bus 0000:00: root bus resource [mem 0x30000000-0x37ffffff]
[    0.207383] pci_bus 0000:00: root bus resource [io  0x8000000-0x800ffff]
[    0.214273] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[    0.221267] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    0.237321] pci 0000:00:01.0: BAR 0: assigned [mem 0x30000000-0x30003fff]
[    0.247307] Switched to clocksource MIPS
[    0.254300] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[    0.280339] ssb: Found chip with id 0xA8D6, rev 0x00 and package 0x08
[    0.323983] ssb: WARNING: Using fallback SPROM failed (err -2)
[    0.329942] ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
[    0.335678] ssb: Unsupported SPROM revision 255 detected. Will extract v1
[    0.365498] ssb: Sonics Silicon Backplane found on PCI device 0000:00:01.0
[    0.373456] NET: Registered protocol family 2
[    0.379642] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    0.386868] TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
[    0.393420] TCP: Hash tables configured (established 1024 bind 1024)
[    0.400139] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.406172] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.413145] NET: Registered protocol family 1
[    0.420109] futex hash table entries: 512 (order: 1, 8192 bytes)
[    0.427827] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.433845] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.446992] io scheduler noop registered
[    0.451054] io scheduler deadline registered (default)
[    0.458468] bcm63xx_uart.0: ttyS0 at MMIO 0xb0000100 (irq = 10, base_baud = 1562500) is a bcm63xx_uart
[    0.468101] console [ttyS0] enabled
[    0.475240] bootconsole [early0] disabled
[    0.484449] bcm63xx-rng bcm63xx-rng: registered RNG driver
[    0.491860] 18000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufact
urer ID 0x000001 Chip ID 0x002201
[    0.502177] Amd/Fujitsu Extended Query Table at 0x0040
[    0.507447]   Amd/Fujitsu Extended Query version 1.3.
[    0.512626] number of CFI chips: 1
[    0.516453] bcm63xxpart: CFE boot tag found with version 6 and board type 96368VVW
[    0.524356] 5 bcm63xxpart partitions found on MTD device 18000000.nor
[    0.531001] Creating 5 MTD partitions on "18000000.nor":
[    0.536468] 0x000000000000-0x000000020000 : "CFE"
[    0.543381] 0x000000020100-0x00000016a53c : "kernel"
[    0.550368] 0x00000016a53c-0x000001fe0000 : "rootfs"
[    0.557371] mtd: device 2 (rootfs) set to be root filesystem
[    0.563279] 1 squashfs-split partitions found on MTD device rootfs
[    0.569619] 0x0000003c0000-0x000001fe0000 : "rootfs_data"
[    0.577135] 0x000000020000-0x000001fe0000 : "linux"
[    0.584305] 0x000001fe0000-0x000002000000 : "nvram"
[    0.592939] bcm63xx-spi bcm63xx-spi: at 0xb0000800 (irq 9, FIFOs size 542)
[    0.640872] b53_common: found switch: BCM63xx, rev 0
[    0.646637] bcm63xx-wdt bcm63xx-wdt:  started, timer margin: 30 sec
[    0.657667] NET: Registered protocol family 10
[    0.664904] NET: Registered protocol family 17
[    0.669611] bridge: automatic filtering via arp/ip/ip6tables has been depreca
ted. Update your scripts to load br_netfilter if you need this.
[    0.682629] 8021q: 802.1Q VLAN Support v1.8
[    0.696536] VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
[    0.718630] Freeing unused kernel memory: 1320K (80406000 - 80550000)
[    2.198913] init: Console is alive
[    2.202769] init: - watchdog -
[    3.581280] usbcore: registered new interface driver usbfs
[    3.587104] usbcore: registered new interface driver hub
[    3.592735] usbcore: registered new device driver usb
[    3.605214] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.613446] ehci-platform: EHCI generic platform driver
[    3.719318] ehci-platform ehci-platform: EHCI Host Controller
[    3.725260] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1
[    3.733630] ehci-platform ehci-platform: irq 15, io mem 0xb0001500
[    3.751284] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00, overcurrent ignored
[    3.761047] hub 1-0:1.0: USB hub found
[    3.764995] hub 1-0:1.0: 2 ports detected
[    3.773899] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.781858] ohci-platform: OHCI generic platform driver
[    3.787464] ohci-platform ohci-platform: Generic Platform OHCI controller
[    3.794488] ohci-platform ohci-platform: new USB bus registered, assigned bus number 2
[    3.802771] ohci-platform ohci-platform: irq 13, io mem 0xb0001600
[    3.869174] hub 2-0:1.0: USB hub found
[    3.873131] hub 2-0:1.0: 2 ports detected
[    3.884587] init: - preinit -
[    4.211345] usb 1-2: new high-speed USB device number 2 using ehci-platform
[    4.349350] hub 1-2:1.0: USB hub found
[    4.353735] hub 1-2:1.0: 2 ports detected
[    4.399076] random: procd urandom read with 57 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[    7.861928] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40000: 0x3600 instead
[    7.871710] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40004: 0x4272 instead
[    7.881470] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40008: 0x6463 instead
[    7.891308] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c4000c: 0x2043 instead
[    7.901055] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40010: 0x706f instead
[    7.910828] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40014: 0x7469 instead
[    7.920582] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40018: 0x7665 instead
[    7.930348] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c4001c: 0x2032 instead
[    7.940112] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c40028: 0x3638 instead
[    7.949880] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00c4002c: 0x3936 instead
[    7.959643] jffs2: Further such events for this erase block will not be printed
[    8.063069] jffs2: notice: (273) jffs2_build_xattr_subsystem: complete building 
xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[    8.080940] mount_root: switching to jffs2 overlay
ifconfig: SIOCGIFFLAGS: No such device
[    8.117117] procd: - early -
[    8.120213] procd: - watchdog -
[    8.905892] procd: - ubus -
[    8.961908] procd: - init -
Please press Enter to activate this console.
[    9.680128] random: nonblocking pool is initialized
[   10.532011] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   10.555014] Loading modules backported from Linux version v4.4-rc5-1913-gc8fdf68
[   10.562685] Backport generated by backports.git backports-20151218-0-g2f58d9d
[   10.575091] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.593738] nf_conntrack version 0.5.0 (1960 buckets, 7840 max)
[   10.680036] xt_time: kernel timezone is -0000
[   10.769111] PPP generic driver version 2.4.2
[   10.776177] NET: Registered protocol family 24
[   10.800210] b43-phy0: Broadcom 43222 WLAN found (core revision 16)
[   10.839287] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 6
[   10.845713] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 6, Version 0
[   10.865269] Broadcom 43xx driver loaded [ Features: PNL ]
[   18.803906] bcm63xx_enetsw bcm63xx_enetsw.0: link UP on port4, 100Mbps, full-duplex
[   18.822646] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready

He probado esta misma compilación en un HG622 (compilado para él), y no hay ningún problema en el switch.

danitool · « **Respuesta #266 en:** 26-04-2016, 23:01 (Martes) »

No tengo respuesta a lo del fallo del ethernet.

Sin embargo veo que hay errores la leer la flash. Aunque pueda que esté equivocado, esta flash no tiene un tamaño de bloque de 128k? y por tanto habría que añadir a la generación de la imagen el parámetro

Código: [Seleccionar]

--block-size 0x20000Lo del tamaño de bloque intuyo que es 128 por ser una flash "gigante" para ser una NOR paralelo.

Ficht · « **Respuesta #267 en:** 26-04-2016, 23:51 (Martes) »

Cita de: Tki2000 en 26-04-2016, 22:03 (Martes)

Pego un log de arranque, por si alguien consigue discernir por qué no funciona el switch.
Me llama la atención el error ifconfig: SIOCGIFFLAGS: No such device, pero no consigo saber el por qué de este error.
Al final br-lan no se levanta.

Código: [Seleccionar]
CFE version 1.0.37-102.15 for BCM96368 (32bit,SP,BE) Build Date: Wed Feb 10 09:57:47 CST 2010 (link@hpnb) Copyright (C) 2000-2009 Broadcom Corporation. Parallel flash device: name AM29LV320MT, id 0x2201, size 32768KB CPU type 0x2A031: 400MHz, Bus: 160MHz, Ref: 64MHz ............................... [ 10.776177] NET: Registered protocol family 24 [ 10.800210] b43-phy0: Broadcom 43222 WLAN found (core revision 16) [ 10.839287] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 6 [ 10.845713] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 6, Version 0 [ 10.865269] Broadcom 43xx driver loaded [ Features: PNL ] [ 18.803906] bcm63xx_enetsw bcm63xx_enetsw.0: link UP on port4, 100Mbps, full-duplex [ 18.822646] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
He probado esta misma compilación en un HG622 (compilado para él), y no hay ningún problema en el switch.

Hola.... no he podido aguantarme y me he liao (justo cuando peor voy de tiempo y cabeza)
Estoy compilando con el parche y estoy exactamente como tu...

Pero, lo que me da la sensación de que openwrt no acaba de iniciar ..... puede ser? o son ideas mías?
El mensaje final de la carga del sistema no lo da ("init complete" o algo parecido), por otro lado con htop, se ve que no es un sistema completo en marcha, hay varias tareas que no se están ejecutando.... a lo mejor los tiros no van al ethernet, si no a otro lado... la wifi, pasa lo mismo, la detectas, la lees, la activas..... pero no arranca.

Tki2000 · « **Respuesta #268 en:** 27-04-2016, 08:40 (Miércoles) »

Cita de: danitool en 26-04-2016, 23:01 (Martes)

No tengo respuesta a lo del fallo del ethernet.

Sin embargo veo que hay errores la leer la flash. Aunque pueda que esté equivocado, esta flash no tiene un tamaño de bloque de 128k? y por tanto habría que añadir a la generación de la imagen el parámetro
Código: [Seleccionar]
--block-size 0x20000Lo del tamaño de bloque intuyo que es 128 por ser una flash "gigante" para ser una NOR paralelo.

Según el datasheet de AM29LV320M, que es lo que detecta, el bloque es de 64KB. Según el datasheet de S29GL256P10, que es lo que lleva, el bloque es de 128KB. Probaré a cambiarle el bloque en la generación de la imagen.
De todas formas, creo que el error tiene más que ver con el "corte" que le pego al router cuando está flasheando la imagen en 0xb9000000. Al dejar un sector a medias, en la generación del sistema jffs2, se encuentra con el flasheado anterior, y da el error. Estoy haciendo suposiciones, y no sé si me estaré equivocando... me suele pasar cuando pienso en voz alta...
De todas formas, antes terminaba de generar el sistema jffs2 en un par de minutos, y ahora no lo veo terminar...

Cita de: Ficht en 26-04-2016, 23:51 (Martes)

Cita de: Tki2000 en 26-04-2016, 22:03 (Martes)
Pego un log de arranque, por si alguien consigue discernir por qué no funciona el switch.
Me llama la atención el error ifconfig: SIOCGIFFLAGS: No such device, pero no consigo saber el por qué de este error.
Al final br-lan no se levanta.

Código: [Seleccionar]
CFE version 1.0.37-102.15 for BCM96368 (32bit,SP,BE) Build Date: Wed Feb 10 09:57:47 CST 2010 (link@hpnb) Copyright (C) 2000-2009 Broadcom Corporation. Parallel flash device: name AM29LV320MT, id 0x2201, size 32768KB CPU type 0x2A031: 400MHz, Bus: 160MHz, Ref: 64MHz ............................... [ 10.776177] NET: Registered protocol family 24 [ 10.800210] b43-phy0: Broadcom 43222 WLAN found (core revision 16) [ 10.839287] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 6 [ 10.845713] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 6, Version 0 [ 10.865269] Broadcom 43xx driver loaded [ Features: PNL ] [ 18.803906] bcm63xx_enetsw bcm63xx_enetsw.0: link UP on port4, 100Mbps, full-duplex [ 18.822646] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
He probado esta misma compilación en un HG622 (compilado para él), y no hay ningún problema en el switch.

Hola.... no he podido aguantarme y me he liao (justo cuando peor voy de tiempo y cabeza)
Estoy compilando con el parche y estoy exactamente como tu...

Pero, lo que me da la sensación de que openwrt no acaba de iniciar ..... puede ser? o son ideas mías?
El mensaje final de la carga del sistema no lo da ("init complete" o algo parecido), por otro lado con htop, se ve que no es un sistema completo en marcha, hay varias tareas que no se están ejecutando.... a lo mejor los tiros no van al ethernet, si no a otro lado... la wifi, pasa lo mismo, la detectas, la lees, la activas..... pero no arranca.

Yo tampoco sé lo que pasa. La wifi no se levanta nunca. Si levanto eth1 manualmente, haciendo ifconfig, se ve que la IP de eth1 es 192.168.1.1, pero no me es posible comunicarme de ninguna manera...

Voy a probar lo del bloque de flash, que comenta danitool, porque puede ser que al no escribir correctamente en la flash, las cosas se queden a medias...
Voy a probar también a desvincular la wifi del switch, a ver si el switch está funcionando, pero por el tema de estar ligado a la wifi en br-lan, no lo está haciendo bien.

Ficht · « **Respuesta #269 en:** 27-04-2016, 08:49 (Miércoles) »

Cita de: Tki2000 en 27-04-2016, 08:40 (Miércoles)

Cita de: danitool en 26-04-2016, 23:01 (Martes)

No tengo respuesta a lo del fallo del ethernet.

he probado con dnsmasq-full
y el logread si que me da info de equipos de mi red...

Código: [Seleccionar]

Mon Apr 25 15:55:51 2016 kern.info kernel: [   27.169360] bcm63xx_enetsw bcm63xx_enetsw.0: link UP on port1, 100Mbps, full-duplex
Mon Apr 25 15:55:51 2016 kern.info kernel: [   27.177599] bcm63xx_enetsw bcm63xx_enetsw.0: link UP on port3, 100Mbps, full-duplex
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan' is enabled
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan6' is enabled
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Network device 'lo' link is up
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'loopback' has link connectivity 
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Network device 'eth0' link is up
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan' has link connectivity 
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan' is setting up now
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan6' has link connectivity 
Mon Apr 25 15:55:51 2016 daemon.notice netifd: Interface 'wan6' is setting up now
Mon Apr 25 15:55:51 2016 daemon.notice netifd: wan (1125): udhcpc (v1.24.2) started
Mon Apr 25 15:55:51 2016 daemon.notice netifd: wan (1125): Sending discover...
Mon Apr 25 15:55:51 2016 daemon.notice netifd: wan (1125): Sending select for 192.168.2.5...
Mon Apr 25 15:55:51 2016 daemon.notice netifd: wan (1125): Lease of 192.168.2.5 obtained, lease time 268435455
Mon Apr 25 15:55:52 2016 daemon.notice netifd: Interface 'wan' is now up
Mon Apr 25 15:55:53 2016 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: started, version 2.75 cachesize 150
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: DNS service limited to local subnets
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: using local addresses only for domain lan
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: reading /tmp/resolv.conf.auto
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: using local addresses only for domain lan
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: using nameserver 192.168.2.1#53
Mon Apr 25 15:55:53 2016 daemon.info dnsmasq[1178]: read /etc/hosts - 4 addresses
Mon Apr 25 15:55:56 2016 kern.notice kernel: [   32.596873] random: nonblocking pool is initialized
Mon Apr 25 15:55:57 2016 daemon.notice netifd: Interface 'wan6' is now up
Mon Apr 25 15:55:57 2016 daemon.info dnsmasq[1178]: reading /tmp/resolv.conf.auto
Mon Apr 25 15:55:57 2016 daemon.info dnsmasq[1178]: using local addresses only for domain lan
Mon Apr 25 15:55:57 2016 daemon.info dnsmasq[1178]: using nameserver 192.168.2.1#53
Mon Apr 25 15:55:57 2016 daemon.info dnsmasq[1178]: using nameserver fd6e:376b:623d::1#53
Wed Apr 27 06:28:59 2016 user.notice firewall: Reloading firewall due to ifup of wan6 (eth0)

sigo mirando....

Tki2000 · « **Respuesta #270 en:** 27-04-2016, 11:45 (Miércoles) »

He conseguido que el switch funcione, poniendo manualmente la configuración.
Lo que no sé es, por qué la configuración no se genera en la generación de la imagen.

Código: [Seleccionar]

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd8d:63b5:e452::/48'

config interface 'lan'
        option ifname 'eth0.1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 8t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 8t'

La wifi la detecta, pero no he probado a levantarla todavía. Tengo que hacer otras cosas a lo largo de la mañana. Luego sigo probando...

danitool · « **Respuesta #271 en:** 27-04-2016, 11:46 (Miércoles) »

Cita de: Tki2000 en 27-04-2016, 08:40 (Miércoles)

Según el datasheet de AM29LV320M, que es lo que detecta, el bloque es de 64KB. Según el datasheet de S29GL256P10, que es lo que lleva, el bloque es de 128KB. Probaré a cambiarle el bloque en la generación de la imagen.
De todas formas, creo que el error tiene más que ver con el "corte" que le pego al router cuando está flasheando la imagen en 0xb9000000. Al dejar un sector a medias, en la generación del sistema jffs2, se encuentra con el flasheado anterior, y da el error. Estoy haciendo suposiciones, y no sé si me estaré equivocando... me suele pasar cuando pienso en voz alta...
De todas formas, antes terminaba de generar el sistema jffs2 en un par de minutos, y ahora no lo veo terminar...

El datasheet no suele mentir. Tal vez el driver tenga un bug y detecte 64KB de tamaño de bloque.

Para flashear evitando la doble imagen no te funciona aumentar el tamaño del firmware hasta 1/2 de la flash como en otros routers?

En este caso sería añadir el parámetro

Código: [Seleccionar]

--pad 16Tardaría bastante en flashear, pero se evitaría cortar la corriente al router. Si es que funcionase.

Tki2000 · « **Respuesta #272 en:** 27-04-2016, 11:52 (Miércoles) »

Cita de: danitool en 27-04-2016, 11:46 (Miércoles)

Cita de: Tki2000 en 27-04-2016, 08:40 (Miércoles)
Según el datasheet de AM29LV320M, que es lo que detecta, el bloque es de 64KB. Según el datasheet de S29GL256P10, que es lo que lleva, el bloque es de 128KB. Probaré a cambiarle el bloque en la generación de la imagen.
De todas formas, creo que el error tiene más que ver con el "corte" que le pego al router cuando está flasheando la imagen en 0xb9000000. Al dejar un sector a medias, en la generación del sistema jffs2, se encuentra con el flasheado anterior, y da el error. Estoy haciendo suposiciones, y no sé si me estaré equivocando... me suele pasar cuando pienso en voz alta...
De todas formas, antes terminaba de generar el sistema jffs2 en un par de minutos, y ahora no lo veo terminar...

El datasheet no suele mentir. Tal vez el driver tenga un bug y detecte 64KB de tamaño de bloque.

Para flashear evitando la doble imagen no te funciona aumentar el tamaño del firmware hasta 1/2 de la flash como en otros routers?

En este caso sería añadir el parámetro
Código: [Seleccionar]
--pad 16Tardaría bastante en flashear, pero se evitaría cortar la corriente al router. Si es que funcionase.

Ya lo utilicé en su momento, y no funciona. El flasheo por TFTP tiene un tamaño máximo, y no llega a 16MB.
https://foro.seguridadwireless.net/openwrt/(desarrollo)-observa-telecom-vh4032n/msg314349/#msg314349

danitool · « **Respuesta #273 en:** 27-04-2016, 11:59 (Miércoles) »

Vale, por TFTP en el HG556a pasa algo parecido si se quieren flashear imágenes cuyo tamaño ronda 1/2 de la flash, pero por la interfaz web de CFE sí que deja.

En el vh4032n no deja ni via TFTP ni interfaz web-CFE?

Tki2000 · « **Respuesta #274 en:** 27-04-2016, 12:07 (Miércoles) »

Cita de: danitool en 27-04-2016, 11:59 (Miércoles)

Vale, por TFTP en el HG556a pasa algo parecido si se quieren flashear imágenes cuyo tamaño ronda 1/2 de la flash, pero por la interfaz web de CFE sí que deja.

En el vh4032n no deja ni via TFTP ni interfaz web-CFE?

Luego pruebo con una imagen paddeada a 16MB por la interfaz web del CFE.
Supongo que también tendré que utilizar un --image-offset, como en el HG622, ya que desde openwrt tenía el problema de que no flasheaba bien desde luci. Luego pruebo esto también, y ya comento resultados.

Tki2000 · « **Respuesta #275 en:** 27-04-2016, 19:51 (Miércoles) »

Resultados de pruebas con el VH4032N.
Aunque he hecho más pruebas, sólo comentaré las significativas.

1.- Quemado de imagen con --pad 16.
   El quemado por CFE lo hace siempre en la zona 0xb8020000
   El primer arranque lo hace bien.
   Al reiniciar (reboot) se corrompe y nos quedamos sin openwrt

   Ni con --image-offset 0x20000 --block-size 0x20000 conseguimos nada más.

2.- Quemado de imagen con --block-size 0x20000
   Por TFTP o CFE el quemado lo hace las zonas alternas 0xb8020000 y 0xb9000000. Sólo podemos verlo por el puerto serie.
   El primer arranque lo hace bien.
   Al reiniciar (reboot), se reinicia bien.
   Al quemar la imagen de openwrt por openwrt (sysupgrade o luci), la imagen se corrompe.

3.- Quemado de imagen con --image-offset 0x20000 --block-size 0x20000
   Por TFTP o CFE el quemado lo hace las zonas alternas 0xb8020000 y 0xb9000000. Sólo podemos verlo por el puerto serie.
   El primer arranque lo hace bien.
   Al reiniciar (reboot), se reinicia bien.
   Al quemar la imagen de openwrt por openwrt (sysupgrade o luci), la imagen se quema bien.

A partir de aquí, podemos quemar las subsiguientes imágenes de openwrt desde luci.

Actualizados los parches, con lo que llevo hasta ahora realizado: https://foro.seguridadwireless.net/openwrt/(desarrollo)-observa-telecom-vh4032n/msg344567/#msg344567

danitool · « **Respuesta #276 en:** 27-04-2016, 20:20 (Miércoles) »

para la corrupción después del primer flasheo tal vez necesites añadir ~~la board id~~ el alias de la placa al fichero

target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc

Si el --pad 16 funcionase, creo que sería bueno producir dos imágenes, una con este parámetro y otra sin él, ya que en Openwrt no es necesario, y flashear 16 megas debe tardar bastante. Aunque no estoy seguro si luego en el primer arranque el consumo de tiempo de borrar rootfs_data para formatear esa partición nos dejaría en el mismo tiempo total para tener Openwrt operativo.

Tki2000 · « **Respuesta #277 en:** 27-04-2016, 20:27 (Miércoles) »

Cita de: danitool en 27-04-2016, 20:20 (Miércoles)

para la corrupción después del primer flasheo tal vez necesites añadir ~~la board id~~ el alias de la placa al fichero

target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc

Si el --pad 16 funcionase, creo que sería bueno producir dos imágenes, una con este parámetro y otra sin él, ya que en Openwrt no es necesario, y flashear 16 megas debe tardar bastante. Aunque no estoy seguro si luego en el primer arranque el consumo de tiempo de borrar rootfs_data para formatear esa partición nos dejaría en el mismo tiempo total para tener Openwrt operativo.

Cierto.
Voy a hacer otras cuantas pruebas.

Edito:

Sigue pasando lo mismo. Al segundo reboot, tenemos esto:

Código: [Seleccionar]

Booting from only image (0xb8020000) ...
Code Address: 0x80A00000, Entry Address: 0x80a00000
Linux file system CRC error.  Corrupted image?

danitool · « **Respuesta #278 en:** 27-04-2016, 22:33 (Miércoles) »

Has probado haciendo el arreglo de CRC manualmente?

Código: [Seleccionar]

mtd fixtrx linux
O después del primer boot re-formatear la partición rootfs_data

Código: [Seleccionar]

mtd erase rootfs_data
No le veo mucho sentido que con imágenes pequeñas no dé el error y con las grandes sí, teniendo en cuenta que ambas las flashea perfectamente, y el resultado en flash debería ser idéntico después de generar rootfs_data

Tki2000 · « **Respuesta #279 en:** 28-04-2016, 08:13 (Jueves) »

Cita de: danitool en 27-04-2016, 22:33 (Miércoles)

Has probado haciendo el arreglo de CRC manualmente?

Código: [Seleccionar]
mtd fixtrx linux
O después del primer boot re-formatear la partición rootfs_data
Código: [Seleccionar]
mtd erase rootfs_data
No le veo mucho sentido que con imágenes pequeñas no dé el error y con las grandes sí, teniendo en cuenta que ambas las flashea perfectamente, y el resultado en flash debería ser idéntico después de generar rootfs_data

Ya, yo tampoco le encuentro sentido. Además el fallo se produce en el segundo reboot.
Como comentario añado, que la pausa que se aprecia tras las líneas:

Código: [Seleccionar]

Booting from only image (0xb8020000) ...
Code Address: 0x80A00000, Entry Address: 0x80a00000

es muy acentuada. Tarda mucho en pasar de esa línea, al quemar la imagen de 16MB. Es como si estuviera comprobando la imagen al completo, incluídos los espacios en blanco. Con una imagen más pequeña, la pausa apenas es apreciable.
~~¿Existirá algún límite en la comprobación y no irá más allá de los 16MB? Es lo primero que se me viene a la cabeza...~~

Edito:

Haciendo manualmente

Código: [Seleccionar]

mtd fixtrx linuxel segundo reboot lo hace correctamente y la pausa al reiniciar no se realiza, así que algo hemos ganado...

Si al incorporar al código target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc, no lo hace, y el problema del switch es que target/linux/brcm63xx/base-files/etc/board.d/02_network no se aplica, entonces ¿el problema puede estar en que las base-files no se aplican? ¿Por qué?
En /build_dir/target-mips_mips32_musl-1.1.14/linux-brcm63xx_smp/base-files/ipkg-brcm63xx/base-files/etc/board.d y
build_dir/target-mips_mips32_musl-1.1.14/linux-brcm63xx_smp/base-files/ipkg-brcm63xx/base-files/etc/uci-defaults aparecen los ficheros correctamente, así que presupongo que la imagen está bien generada... ¿Es a la hora del arranque cuando los valores no se escriben?

Al arrancar el router, /etc/uci-defaults aparece vacío, y /etc/board.d contiene tres ficheros:

Código: [Seleccionar]

01_leds
02_network
99-default_network

¿Es esto lo correcto?
Perdona que sea tan pesado, pero no tengo clara la secuenciación de arranque, y generación de datos, con todos los cambios que ha habido...

Edito 2:

Creo que ya sé por dónde van los tiros.
/tmp/sysinfo/board_name contiene unknown
/tmp/sysinfo/model contiene Observa VH4032N
Si el board_name no es correcto, la configuración no se aplica, ¿verdad?
Ahora la pregunta es, ¿dónde defino ese board_name? Creí que estaba reflejado en los parches que he hecho...

Edito 3:

¡¡¡HECHO!!!
Ya arranca toda la configuración y el switch es reconocido. La definición de la placa no es "Observa VH4032N reference board", es "Observa VH4032N".
Ahora lo que no consigo es que se levante la wifi con el driver b43, pero eso ya me importa menos...

Edito 4:

Actualizados los parches, con lo que llevo hasta ahora realizado: https://foro.seguridadwireless.net/openwrt/(desarrollo)-observa-telecom-vh4032n/msg344567/#msg344567

Se generan dos imágenes, una de 16MB para quemar a través del CFE del router, y otra (sysupgrade) con tamaño normal, para quemar a través de luci.

Noticias:

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

Ficht

danitool

danitool

danitool

Ficht

Ficht

danitool

danitool

danitool

danitool