Autor Tema: [Desarrollo] OpenWrt en ASTORIA ARV7519RW22 (Leído 513735 veces)

Tki2000 · « **Respuesta #760 en:** 22-11-2015, 20:31 (Domingo) »

Cita de: francisgambin en 22-11-2015, 18:51 (Domingo)

Cita de: medber en 21-11-2015, 21:03 (Sábado)
Hola a todos

He compilado OpenWrt 15.05 para el ARV7519RW22 y quería compartirla con ustedes.

Detalles:
Sincronizada con Chaos Calmer 15.05 Final (LuCI git-15.248.30277-3836b45)
Compilación estándar con LuCI y paquetes por defecto
incluido: el archivo de firmware vdsl.bin
incluido: clave opkg correcta
incluido: parches de @Noltari y @Blogic que arreglan problemas de: USB / VLANs Switch / Flash / Leds

Descargar:
OpenWrt 15.05 Chaos Calmer para ARV7519RW22 https://drive.google.com/file/d/0BzBSJsSR-T9iRzJQbEVfazJPTHM/view?usp=sharing

Nota:
Por defecto esta versión está habilitada para el apoyo VDSL. Por habilitar el apoyo ADSL, cambie esta opción de
Código: [Seleccionar]
option xfer_mode 'ptm'a esta
Código: [Seleccionar]
option xfer_mode 'atm'en el archivo /etc/config/network

.

Muy buenas tardes, estoy probando tu compilación pero me encuentro con el siguiente problema de dependencias en kernel para kmod-fs-ext4

Installing kmod-fs-ext4 (3.18.20-1) to root...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/lantiq/xrx200/packages/base/kmod-fs-ext4_3.18.20-1_lantiq.ipk.

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-ext4:
* kernel (= 3.18.20-1-21cf68ce9862224207b8806e4c272ef6) * kernel (= 3.18.20-1-21cf68ce9862224207b8806e4c272ef6) *
* opkg_install_cmd: Cannot install package kmod-fs-ext4.

Saludos

Date una vueltecita por las >>>Preguntas más comunes<<<

medber · « **Respuesta #761 en:** 22-11-2015, 21:46 (Domingo) »

He actualizado la version (Revision #02)

@howl
esta nueva revision tiene todos los parches disponibles para arreglar la problemas del module dwc2.

@francisgambin
esta nueva revision tiene Ext4.
.

howl · « **Respuesta #762 en:** 22-11-2015, 21:56 (Domingo) »

Cita de: crislgga en 22-11-2015, 18:16 (Domingo)

Cita de: howl en 22-11-2015, 17:40 (Domingo)
El problema lo estás teniendo en el protocolo de envío, tienes que enviarlo en vez de en xmodem en ASCII. En linux por ejemplo yo lo hago con cat archivo.asc > /dev/ttyUSB0.

En Windows si usas putty o alguno similar tienes que indicarle en vez de xmodem, texto plano.

En cuanto empiece a enviarse verás que el router te empieza a devolver todo el rato '*' y te llenará un línea de ellos.

En ese momento solo queda esperar y cuando acabe verás que se encienden los dos típicos leds que tiene estas compilaciones de uboot puestas para encender (el primero verde y el último azul).

Si sigues con problemas tranquilo, comenta sin problemas que no es molestia.

Gracias howl
¿Mas o menos cuanto suele tardar en enviarlo?, lleva 10 mins desde hyperterminal y aun sigue, eso si, envio y hago el corto de r155 un segundo, y quito el corto de r155, sigue los asteriscos, entonces de ahi mi duda del envio de todo

Quita el corto de r155 antes de enviar, te sale CFG 04 UART y quitas corto. Luego ya envías. Tarda un tanto pero no debería de llegar a más de 3 o 4 minutos. Haz como te comento.

medber le daré una prueba, muchas gracias, si puedes compartir los parches te lo agradecería mucho, he probado trunk y no se si es por el cambio a de uclibc a musl pero reacciona mucho mejor luci a la hora de aplicar cambios de configuración, mucho más fluido.

Añado, además me gustaría empezar a usar OpenWrt a partir de la dirección 0xB00A000 en vez de 0xB008000 para poder meter uboot 2014.07, aunque de momento estoy esperando a ver si consigo otra placa porque la que tengo el UART es prácticamente imposible ya y si compilo un arranque malo lo brikeo. Así puedo ir compilando con ese cambio a esperas de ver si se acepta en OpenWrt.

medber · « **Respuesta #763 en:** 22-11-2015, 22:06 (Domingo) »

Cita de: howl en 22-11-2015, 21:56 (Domingo)

medber le daré una prueba, muchas gracias, si puedes compartir los parches te lo agradecería mucho, he probado trunk y no se si es por el cambio a de uclibc a musl pero reacciona mucho mejor luci a la hora de aplicar cambios de configuración, mucho más fluido.

Añado, además me gustaría empezar a usar OpenWrt a partir de la dirección 0xB00A000 en vez de 0xB008000 para poder meter uboot 2014.07, aunque de momento estoy esperando a ver si consigo otra placa porque la que tengo el UART es prácticamente imposible ya y si compilo un arranque malo lo brikeo. Así puedo ir compilando con ese cambio a esperas de ver si se acepta en OpenWrt.

Aquí estan:

Código: [Seleccionar]


	Changeset 46913
	lantiq: Initialize USB on AR9 platform
	https://dev.openwrt.org/changeset/46913

	Changeset 46914
	lantiq: Introduce DWC2 compatible DTS definitions for AR9 USB
	https://dev.openwrt.org/changeset/46914

	Changeset 47129
	lantiq: fix ath_pci_fixup hang on bridged devices
	https://dev.openwrt.org/changeset/47129

	Changeset 47190
	lantiq: several ARV7519RW22 fixes
	https://dev.openwrt.org/changeset/47190

	Changeset 47208
	lantiq: Fixed reading the number of RX FIFOs in the SPI driver
	https://dev.openwrt.org/changeset/47208

	Changeset 47209
	lantiq: Print the status register whenever an error occurs
	https://dev.openwrt.org/changeset/47209

	Changeset 47563
	lantiq: tweak DWC2 default parameters
	https://dev.openwrt.org/changeset/47563

	Changeset 47566
	lantiq: add phy led config support over devicetree bindings
	https://dev.openwrt.org/changeset/47566

	Bug 95241 - null pointer assignment in dwc2 driver
	https://bugzilla.kernel.org/show_bug.cgi?id=95241

por el 'OpenWrt a partir de la dirección 0xB00A000 en vez de 0xB008000' voy a ver si puedo prepararla.

howl · « **Respuesta #764 en:** 22-11-2015, 22:51 (Domingo) »

El de
Bug 95241 - null pointer assignment in dwc2 driver
https://bugzilla.kernel.org/show_bug.cgi?id=95241
realmente no arregla nada y hay posibilidades de que introduzca otros errores.

Pruebo y te comento si continúa pero es bastante probable que hasta la 4.4 no es algo que esté resuelto. Hay parches que reescriben por completo grandes partes de ese módulo, uno incluso reescribe por completo el hcd de dwc2 de forma que hace exactamente lo mismo pero el código es mucho más limpio y claro, pero tienen que revisarlo bien antes de meterlo.

Si no entran para la 4.4 final actualmente en rc1 ya sería en la 4.5.

howl · « **Respuesta #765 en:** 22-11-2015, 23:18 (Domingo) »

medber, funciona correctamente, revisando los parches intuyo que la solución al problema es este parche reciente de blogic https://dev.openwrt.org/changeset/47563. Si vas a hacer en algún momento una tercera revisión con el desplazamiento a 0xB00A0000 (que ojo es una idea de momento mía que no ha sido aceptada todavía upstream) te recomendaría quitar el parche de Bug 95241 - null pointer assignment in dwc2 driver.

medber · « **Respuesta #766 en:** 22-11-2015, 23:21 (Domingo) »

@howl
He copiado un archivo (2.2GB) desde una memoria USB conectada al puerto usb número 1 a otra memoria USB conectada al segundo puerto usb. (formateada con NTFS).

nada paso. excepto ntfs-3g consume 75% del tiempo de CPU

luego. conecte un disco duro externo USB (formateado con Ext4) y una memoria USB en un concentrador USB en el puerto usb 1. y un usb wifi (rt2800usb) en el puerto usb número 2. Entonces empecé a copiar archivos de gran tamaño (~ 5 GB) durante la descarga a través de ADSL con velocidad máxima. Menos de 10 minutos tuve un kernel oops.

=> el problema del module dwc2 todavía persiste.

medber · « **Respuesta #767 en:** 22-11-2015, 23:25 (Domingo) »

Cita de: howl en 22-11-2015, 23:18 (Domingo)

medber, funciona correctamente, revisando los parches intuyo que la solución al problema es este parche reciente de blogic https://dev.openwrt.org/changeset/47563. Si vas a hacer en algún momento una tercera revisión con el desplazamiento a 0xB00A0000 (que ojo es una idea de momento mía que no ha sido aceptada todavía upstream) te recomendaría quitar el parche de Bug 95241 - null pointer assignment in dwc2 driver.

vale. voy a quitar el parche de Bug 95241 y probare una nueva revision.

También, voy a leer sus posts sobre el desplazamiento a 0xB00A0000 para regenerar une nueva imagen para ti.

howl · « **Respuesta #768 en:** 22-11-2015, 23:44 (Domingo) »

Te resumo ese tema de desplazar un sector de memoria el firmware.

Actualmente en OpenWrt está el uboot 2013.10 para lantiq. Hay gits en github con la versión 2014.01, 2014.04 y 2014.07. He ido adaptando los cambios de esta placa para ver si sería posible ir actualizando el uboot de openwrt hasta la última versión de uboot.

El problema está en que la 2014.07 tiene muchos cambios en la parte de manejo de la memoria en vrx200 y hace que el ejecutable ocupe algo más, incluyendo ambos firmwares para las dos versiones de la 1.1 y 1.2 hace que ubott pase de ocupar los 2 primeros sectores a ocupar los 3 primeros. Actualmente eso supone comerse el tercer sector que es el usado para uboot-env. Si se desplaza el firmware de 0xB0080000 a 0xB00A000 se puede meter uboot en los 3 sectores primeros y uboot-env en el cuarto 0xB008000-0xB00A0000. Además así coincide con la imagen de linux en el firmware original ya que analizándolo está en 0xB00A0000.

El cambio es sencillo y es solo cambiar los valores del dts así que siendo solo para mi creo que mejor deja dicho cambio ya que supone modificar la el run write-openwrt y demás. Mejor igual esperar a si se acuerda ponerlo en 0xB00A0000 de forma general.

Yo sigo funcionando bien sin problemas con el router usando tu imagen, si puedes volver a provocar el fallo pega lo que te salta por el puerto UART justo cuando va a proceder a reinciarse para ver si es otro problema distinto.

medber · « **Respuesta #769 en:** 22-11-2015, 23:58 (Domingo) »

@howl

aquí tiens los datos del archivo arv7519rw22.dts

Código: [Seleccionar]

			nor-boot@0 {
				compatible = "lantiq,nor";
				bank-width = <2>;
				reg = <0 0x0 0x2000000>;
				#address-cells = <1>;
				#size-cells = <1>;

				partition@0 {
					label = "uboot";
					reg = <0x0 0x60000>;
					read-only;
				};

				partition@60000 {
					label = "uboot-env";
					reg = <0x60000 0x20000>;
					read-only;
				};

				partition@80000 {
					label = "firmware";
					reg = <0x80000 0x1e00000>;
				};

				partition@1e80000 {
					label = "dsl_fw";
					reg = <0x1e80000 0x100000>;
				};

				boardconfig: partition@1f80000 {
					label = "boardconfig";
					reg = <0x1f80000 0x80000>;
					read-only;
				};
			};

haga la modification que quieres y escribí un nuevo mensaje

howl · « **Respuesta #770 en:** 23-11-2015, 00:09 (Lunes) »

Con lo comentado quedaría así:

Código: [Seleccionar]

			nor-boot@0 {
				compatible = "lantiq,nor";
				bank-width = <2>;
				reg = <0 0x0 0x2000000>;
				#address-cells = <1>;
				#size-cells = <1>;

				partition@0 {
					label = "uboot";
					reg = <0x0 0x80000>;
					read-only;
				};

				partition@80000 {
					label = "uboot-env";
					reg = <0x80000 0x20000>;
					read-only;
				};

				partition@a0000 {
					label = "firmware";
					reg = <0xa0000 0x1e00000>;
				};

				partition@1e80000 {
					label = "dsl_fw";
					reg = <0x1e80000 0x100000>;
				};

				boardconfig: partition@1f80000 {
					label = "boardconfig";
					reg = <0x1f80000 0x80000>;
					read-only;
				};
			};

Una cosa, de momento me salen unos mensajes que conseguí ver antes sin usar los usbs:
[ 1283.292000] dwc2 1e101000.ifxhcd: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason is unknown [ 1283.292000] dwc2 1e101000.ifxhcd: hcint 0x00000002, intsts 0x04400029 [ 2086.572000] dwc2 1e101000.ifxhcd: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but reason is unknown [ 2086.572000] dwc2 1e101000.ifxhcd: hcint 0x00000002, intsts 0x04400029

Creo que cuando salen se bloquea la transmisión de datos durante unos instantes pero tengo que comprobarlo mejor porque igual es que el pincho wifi pilla poca señal.

medber · « **Respuesta #771 en:** 23-11-2015, 00:27 (Lunes) »

únicamente par @howl

!! La imagen siguiente ha sido generada para probar una structura de particiones / memoria diferente de la structura estándar del ARV7519rw22 !! NADIE LA FLASHEE !!

aquí la tienes con desplazamiento a 0xB00A0000 y con el parche de Bug 95241 quitado
https://drive.google.com/file/d/0BzBSJsSR-T9iWU1jTkptMGhWLXc/view?usp=sharing

.

howl · « **Respuesta #772 en:** 23-11-2015, 00:36 (Lunes) »

La probaré mañana he movido el router para descartar tema de señal del usb wifi y para poner bien esa imagen tengo que editar las variables de uboot. (Ponle alguna edición post en rojo y mayúsculas indicando que no flashee nadie esa imagen para evitar que alguien la meta sin cambiar el write-openwrt de uboot.)

Creo que si hay algún tipo de problema en el usb, pero por las cosas que hace creo que eso ya si será con los parches que van llegando upstream al kernel de linux.

Además de acercar el router a donde se lo tengo conectado por wifi he puesto dns de google para descartar otros fallos pero da toda la sensación de que a veces se bloquea el flujo de datos del usb.

crislgga · « **Respuesta #773 en:** 23-11-2015, 01:37 (Lunes) »

Cita de: howl en 22-11-2015, 21:56 (Domingo)

Cita de: crislgga en 22-11-2015, 18:16 (Domingo)
Cita de: howl en 22-11-2015, 17:40 (Domingo)
El problema lo estás teniendo en el protocolo de envío, tienes que enviarlo en vez de en xmodem en ASCII. En linux por ejemplo yo lo hago con cat archivo.asc > /dev/ttyUSB0.

En Windows si usas putty o alguno similar tienes que indicarle en vez de xmodem, texto plano.

En cuanto empiece a enviarse verás que el router te empieza a devolver todo el rato '*' y te llenará un línea de ellos.

En ese momento solo queda esperar y cuando acabe verás que se encienden los dos típicos leds que tiene estas compilaciones de uboot puestas para encender (el primero verde y el último azul).

Si sigues con problemas tranquilo, comenta sin problemas que no es molestia.

Gracias howl
¿Mas o menos cuanto suele tardar en enviarlo?, lleva 10 mins desde hyperterminal y aun sigue, eso si, envio y hago el corto de r155 un segundo, y quito el corto de r155, sigue los asteriscos, entonces de ahi mi duda del envio de todo

Quita el corto de r155 antes de enviar, te sale CFG 04 UART y quitas corto. Luego ya envías. Tarda un tanto pero no debería de llegar a más de 3 o 4 minutos. Haz como te comento.

Bueno, conseguido y cargado, cargar el uboot asc, 12minutos, gracias
Ahora a instalar una imagen de las que esta en el repositorio oficial,actualizando desde el uboot, ya que habia visto esta tarde la imagen ultima del compañero, pero al leer ahora los comentarios, esperaré que refinais y retoqueis esa imagen con las variables ya cambiadas, que esto de las zonas de memoria hexadecimales son un puto coñazo, lo sé
saludos

medber · « **Respuesta #774 en:** 23-11-2015, 10:20 (Lunes) »

Me di cuenta de algo interesante

1. He utilizado una llave usb wifi diferente (Sagem XG-76NA 802.11bg) y repite la misma prueba de esfuerzo (copiar de una unidad flash USB a un disco duro usb mientras estoy descargando a velocidad máxima a través de tarjeta wifi usb, al mismo tiempo)

Sagem XG-76NA 802.11bg conectado al puerto USB 1, y el disco duro + unidad flash USB conectados al puerto USB 2 a través de un concentrador USB externo (D-Link DUB-H4 USB 2.0)

=> No pasó nada.

2. Cuando repito la misma prueba con Ralink RT5370 usb wifi, me sale un kernel oops en cuestión de segundos.

Ralink RT5370 conectado al puerto USB 1, y el disco duro + unidad flash USB conectados al puerto USB 2 a través de un concentrador USB externo (D-Link DUB-H4 USB 2.0)

3. Sin embargo, cuando conecto Ralink RT5370 usb wifi en el concentrador USB externo (D-Link DUB-H4 USB 2.0) y repito la misma prueba de esfuerzo, no pasa nada.

Disco duro conectado al puerto USB 1, y Ralink RT5370 usb wifi + unidad flash USB conectados al puerto USB 2 a través de un concentrador USB externo (D-Link DUB-H4 USB 2.0)

=> Por estas pruebas asumo que:

Driver rt2x00usb probablemente no es la causa principal.
No es problema el consumo de energía, ya sea desde Sagem XG-76NA 802.11bg (zd1211rw) consume 500 mA mientras Ralink RT5370 consume 450mA.
No es cuestión de modo Wifi de rt2x00usb porque el modo N con un solo canal (20Mhz) y modo G tanto causó un kernel oops cuando Ralink RT5370 estaba conectada al puerto USB 1

Voy a compilar una nueva versión de OpenWrt desde el Stable Branch (15.05) para ver si la cosas van bien.

.

howl · « **Respuesta #775 en:** 23-11-2015, 15:42 (Lunes) »

medber con la imagen desplazada a 0xB00A0000 en el primer reinicio después de dejar que se genere completamente el sistema jffs2 en el primer arranque salta lo siguiente. Borrando por completo rootfs_data y que regenere de nuevo no sirve de nada ya que vuelve a hacerlo.

[ 22.912000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002063c: 0x0101 instead [ 22.928000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020644: 0x0001 instead [ 22.944000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002079c: 0x244e instead [ 22.968000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000207a0: 0x4946 instead [ 22.992000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000207dc: 0x2450 instead [ 23.016000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000207e0: 0x5859 instead [ 23.040000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020820: 0x68b8 instead [ 23.064000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020824: 0x13c4 instead [ 23.088000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000208ac: 0x7369 instead [ 23.112000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000208b0: 0x6f72 instead [ 23.120000] jffs2: Further such events for this erase block will not be printed [ 23.424000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055268: 0x0100 instead [ 23.440000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005526c: 0x0100 instead [ 23.456000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055678: 0x0001 instead [ 23.472000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055688: 0x6f72 instead [ 23.484000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005568c: 0x6765 instead [ 23.500000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055690: 0x6572 instead [ 23.516000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005570c: 0x6f72 instead [ 23.532000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055710: 0x6765 instead [ 23.548000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055714: 0x6572 instead [ 23.632000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00055718: 0x3300 instead [ 23.640000] jffs2: Further such events for this erase block will not be printed [ 23.672000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00061354: 0x0100 instead [ 23.688000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006179c: 0x745f instead [ 23.704000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617a0: 0x5637 instead [ 23.720000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617a4: 0x3952 instead [ 23.736000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617a8: 0x3200 instead [ 23.752000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617c0: 0x3334 instead [ 23.768000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617c4: 0xfa33 instead [ 23.784000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617c8: 0x5774 instead [ 23.800000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617cc: 0xa04b instead [ 23.816000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000617d0: 0xf481 instead [ 23.824000] jffs2: Further such events for this erase block will not be printed [ 23.844000] jffs2: Old JFFS2 bitmask found at 0x000634d4 [ 23.848000] jffs2: You cannot use older JFFS2 filesystems with newer kernels [ 23.968000] jffs2: notice: (1039) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xre.

Supongo que habrá que hacer algún cambio más por ahí así que ya revisaré a ver.

Si puedes haz una imagen a 0xB008000 sin el parche null pointer de dwc2 para probar y ver si va más fluido sin ese cambio.

Por cierto, muchas gracias por fijarte en los nuevos parches para dwc2, yo ya estaba obcecado mirando solo a ver cuando metían el kernel 4.3 para lantiq y ni me habría dado cuenta de ese parche.

howl · « **Respuesta #776 en:** 23-11-2015, 18:39 (Lunes) »

Vale lo del problema con el root fs y el desplazamiento ha sido por fallo mio en los cambios del archivo de dts, me deje un cambio y eso hizo que la partición firmware se solapara 1 página encima de la de dsl_fw.

medber este sería el archivo correcto:

Código: [Seleccionar]

			nor-boot@0 {
				compatible = "lantiq,nor";
				bank-width = <2>;
				reg = <0 0x0 0x2000000>;
				#address-cells = <1>;
				#size-cells = <1>;

				partition@0 {
					label = "uboot";
					reg = <0x0 0x80000>;
					read-only;
				};

				partition@80000 {
					label = "uboot-env";
					reg = <0x80000 0x20000>;
					read-only;
				};

				partition@a0000 {
					label = "firmware";
					reg = <0xa0000 0x1de0000>;
				};

				partition@1e80000 {
					label = "dsl_fw";
					reg = <0x1e80000 0x100000>;
				};

				boardconfig: partition@1f80000 {
					label = "boardconfig";
					reg = <0x1f80000 0x80000>;
					read-only;
				};
			};

Como ves fue el valor de longitud de firmware ponerla de 1e00000 a 1de0000.

Si me hace una con ello y sin el parche null pointer te lo agradezco porque yo ahora mismo tendría que liberar un tanto de espacio para poder compilar OpenWrt.

Altair64 · « **Respuesta #777 en:** 23-11-2015, 19:51 (Lunes) »

Una preguntita así un poco de noobis pero es que no encuentro indicativos de si esto es o no es así

Ya tengo el ttl-usb y soldados los cablecitos para conectarlo al router, pero eso que sale en la wiki de wrt de hacer un corto en los huecos de 2 resistencias, hay que hacerlo para el ttl-usb? (leo que es para usar el "modo UART" pero no tengo claro si este modo es el que se usa con el ttl-usb o es otra cosa

Salud y gracias!

medber · « **Respuesta #778 en:** 23-11-2015, 20:43 (Lunes) »

Cita de: howl en 23-11-2015, 18:39 (Lunes)

Vale lo del problema con el root fs y el desplazamiento ha sido por fallo mio en los cambios del archivo de dts, me deje un cambio y eso hizo que la partición firmware se solapara 1 página encima de la de dsl_fw.

medber este sería el archivo correcto:
Código: [Seleccionar]
nor-boot@0 { compatible = "lantiq,nor"; bank-width = <2>; reg = <0 0x0 0x2000000>; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "uboot"; reg = <0x0 0x80000>; read-only; }; partition@80000 { label = "uboot-env"; reg = <0x80000 0x20000>; read-only; }; partition@a0000 { label = "firmware"; reg = <0xa0000 0x1de0000>; }; partition@1e80000 { label = "dsl_fw"; reg = <0x1e80000 0x100000>; }; boardconfig: partition@1f80000 { label = "boardconfig"; reg = <0x1f80000 0x80000>; read-only; }; };
Como ves fue el valor de longitud de firmware ponerla de 1e00000 a 1de0000.

Si me hace una con ello y sin el parche null pointer te lo agradezco porque yo ahora mismo tendría que liberar un tanto de espacio para poder compilar OpenWrt.

únicamente par @howl

!! La imagen siguiente ha sido generada para probar una structura de particiones / memoria diferente de la structura estándar del ARV7519rw22 !! NADIE LA FLASHEE !!

Aquí la tienes con el nuevo ARV7519RW22.dts y sin el parche null pointer (Bug 95241)
https://drive.google.com/file/d/0BzBSJsSR-T9iWXExaUZ2Vk1GZG8/view?usp=sharing

.

howl · « **Respuesta #779 en:** 23-11-2015, 20:57 (Lunes) »

Cita de: noentiendero en 23-11-2015, 19:51 (Lunes)

Una preguntita así un poco de noobis pero es que no encuentro indicativos de si esto es o no es así

Ya tengo el ttl-usb y soldados los cablecitos para conectarlo al router, pero eso que sale en la wiki de wrt de hacer un corto en los huecos de 2 resistencias, hay que hacerlo para el ttl-usb? (leo que es para usar el "modo UART" pero no tengo claro si este modo es el que se usa con el ttl-usb o es otra cosa

Salud y gracias!

Quiero de aquí a unos días rehacer el procedimiento para flashear ya en vistas a algo final y explicar cosas como la que comentas que sin tener ciertas nociones previas resultan lioso al verlas por primera vez.

Tu lo que comentas que has hecho es soldar el puerto UART que te va a escupir datos y tu vas a poder mandarle datos por el para interactuar. A día de hoy gracias a que se dispone del pass del bootloader que lleva original es lo único necesario a hacer físicamente para poder tratar con este router. Según lo tienes ahora simplemente enciéndelo y de seguido según lo enciendes pulsa 3 veces barra de espacio, pega el pass y continua los pasos del post inicial para conseguir flashear U-Boot y OpenWrt.

Ahora bien entonces, ¿qué es eso de los dos cortos para UART? Pues esos dos cortos lo que hacen es poner al procesador en un modo de arranque distinto, que en vez de acceder a la primera posición de la memoria flash y cargar lo que se encuentra, se queda esperando a que por el puerto UART le mandes el programa que va a ejecutar. Ese es el misterio, uno es el puerto UART en sí y lo otro es el método de arranque del procesador para cargarle lo que va a ejecutar incialmente a través del puerto UART.

Noticias:

Autor Tema: [Desarrollo] OpenWrt en ASTORIA ARV7519RW22 (Leído 513735 veces)

medber

howl

medber

howl

howl

medber

medber

howl

medber

howl

medber

howl

crislgga

medber

howl

howl

Altair64

medber

howl