Seguridad Wireless - Wifi
Equipos y materiales => Puntos de acceso, routers, switchs y bridges => Openwrt & LEDE => Mensaje iniciado por: Noltari en 18-05-2017, 15:59 (Jueves)
-
Buenas!
Aunque hace bastante que no aparezco por el foro por tema de falta de tiempo libre quería compartir lo último que estoy haciendo relacionado con OpenWrt/LEDE.
Como hace poco tenía algo de tiempo decidí ponerme a investigar sobre si sería posible ejecutar U-Boot en routers BCM63xx. Después de varios intentos al final fui capaz de ejecutarlo y ahora mismo estoy portando drivers y haciéndolos compatibles con U-Boot.
Desde el principio he tenido como objetivo conseguir hacer upstreaming de todo lo que consiguiera hacer funcionar de forma estable, y como podréis ver ya han aceptado algunos de los parches que he enviado y también hay más en camino:
Git U-Boot Upstream (https://github.com/Noltari/u-boot/commits/master?author=noltari)
Git U-Boot MIPS (http://git.denx.de/?p=u-boot/u-boot-mips.git)
U-Boot Patchwork (http://patchwork.ozlabs.org/project/uboot/list/?submitter=64520&state=*&archive=both)
¿Por qué pegarse la currada de añadir soporte para BMIPS en U-Boot?
Pues porque como ya he dicho tenía algo de tiempo libre y me apetecía trastear un poco con U-Boot, y más ahora que están migrando todo a la filosofía DT (Device Tree).
También porque veo bastante factible utilizar U-Boot como Second Stage Bootloader en routers BCM63xx con NAND, que como ya sabréis a día de hoy siguen sin ser compatibles con OpenWrt/LEDE debido a la estructura que Broadcom ha decidido utilizar en la flash.
Upstream (http://git.denx.de/?p=u-boot.git;a=search;s=%C3%81lvaro+Fern%C3%A1ndez;st=author)
- Generalización de u-boot.elf (necesario para cargar U-Boot en RAM por TFTP desde CFE)
- Inicialización genérica para MIPS del debug uart (muy útil al añadir soporte para un nuevo SoC)
- Mejora del comando cpu (útil para mostrar información sobre las CPUs)
- Soporte para syscon-reboot (driver para reiniciar el dispositivo escribiendo una máscara en un registro)
- Soporte para brcm,bcm6345-uart (driver del puerto serie en los BCM63xx/BCM33xx)
- Driver para detectar la frecuencia y otros datos de las CPU en BMIPS
- Infraestructura inicial para BMIPS
- Soporte para BCM6358
- Soporte para Huawei HG556a (ver B)
- Soporte para BCM6328
- Soporte para Comtrend AR-5387un
- Soporte para BCM63268
- Soporte para Comtrend VR-3032u
- Soporte para BCM63268
- Soporte para brcm,bcm6345-gpio (driver de los gpios, para controlar LEDs/botones)
- Soporte para brcm,bcm6328-leds (driver de los LEDs en BCM6328+)
- Soporte para brcm,bcm6358-leds (driver de los LEDs en BCM6358+)
- Soporte para brcm,bcm6345-clk (driver que habilita/deshabilita los relojes de los periféricos)
- Soporte para brcm,bcm6345-reset (driver que resetea los controladores de los periféricos)
- Soporte para brcm,bcm6328-power-domain (driver que habilita el voltaje de los periféricos)
- Soporte para brcm,bcm6345-wdt (driver del Watchdog en BMIPS)
- Soporte para wdt-reboot (driver que permite reiniciar el dispositivo mediante el watchdog)
- Soporte para BCM6348
- Soporte para Comtrend CT-5361
- Soporte para BCM3380
- Soporte para Netgear CG3100d
- Soporte para BCM6338
- Soporte para Sagem F@ST1704
- Arreglos para el driver del uart
mips/next (http://git.denx.de/?p=u-boot/u-boot-mips.git;a=shortlog;h=refs/heads/next)
Roadmap
- SPI (v3 mandada):
- https://github.com/Noltari/u-boot/commits/bmips-spi-v3
- HSSPI (v2 mandada):
- https://github.com/Noltari/u-boot/commits/bmips-hsspi-v2
- BCM6368 (bastante fácil pero no me he puesto con ello aún)
- USBs (medio-funciona el EHCI y no funciona el OHCI):
- https://github.com/Noltari/u-boot/commits/bmips-usb-devel
- https://lists.denx.de/pipermail/u-boot/2017-May/292067.html
- NAND (habría que portar el driver de linux y lo ideal sería esperar a que se migraran los drivers de la NAND a DM...)
- DMA & Ethernet (esto requiere bastante curro en desarrollo y pruebas...)
- https://github.com/Noltari/u-boot/commits/bmips-eth-devel
- ¿Low Level Init? (con el fin de reemplazar completamente CFE. Requiere cógido propietario de Broadcom no disponible)
- BCM6345, BCM6318, BCM6362, BCM3368 (no tengo ningún dispositivo para desarrollo con estos SoCs).
Bugs/Issues
- loadb/loady no funciona en BCM3380 (fallo conocido, probablemente sea un tema de configuración del timeout en el driver del uart) -> He hablado con Florian y parece ser que los BCM3380 tienen un fallo en la inicialización que hace que sean bastante propensos al overflow...
¿Cómo compilar U-Boot?
- Os dejo unos tips sobre cómo compilar U-Boot utilizando el toolchain de LEDE, que es lo más rápido y fácil (Obviamente habría que sustituir el path de STAGING_DIR por el vuestro y huawei_hg556a_ram_defconfig por la config que queráis usar ;D):
export STAGING_DIR="/home/noltari/lede/lede-staging/staging_dir/"
export PATH="${STAGING_DIR}host/bin:$PATH:${STAGING_DIR}toolchain-mips_mips32_gcc-5.4.0_musl/bin"
make distclean
make huawei_hg556a_ram_defconfig
make ARCH=mips CROSS_COMPILE=mips-openwrt-linux-
- Por otro lado, si queréis cargarlo en un router que no permita cargar imágenes por TFTP (como el Sagem F@ST1704) podéis generar una imagen CFE para flashearlo:
dd if=/dev/zero of=rootfs.bin bs=2M count=1
rm -f u-boot.bin.* u-boot.img
$STAGING_DIR/host/bin/lzma e u-boot.bin -d22 -fb64 -a1 u-boot.bin.lzma
dd if=u-boot.bin.lzma of=u-boot.bin.lzma.cfe bs=5 count=1
dd if=u-boot.bin.lzma of=u-boot.bin.lzma.cfe ibs=13 obs=5 skip=1 seek=1 conv=notrunc
$STAGING_DIR/host/bin/imagetag -i u-boot.bin.lzma.cfe -f rootfs.bin --output u-boot.img --boardid "F@ST1704" --chipid 6338 --entry 0x80010000 --load-addr 0x80010000
- Y por último, para cargarlo en bootloaders HCS (BCM33xx) como initramfs:
$STAGING_DIR/host/bin/hcsmakeimage --magic_bytes=0xa0e7 --rev_maj=0003 --rev_min=0000 --input_file=u-boot.bin --output_file=/tftp/cg3100d --ldaddress=0x80010000
Si alguien se anima a hacer pruebas o a desarrollar algún driver bienvenido es :_).
P.D: sé perfectamente que conseguir reemplazar CFE en estos routers es difícil, pero soñar es gratis ;D.
Saludos!
-
Espero no hacer ninguna pregunta estupida, es posible traer este proyecto a otros broadcom como el BCM63168?
-
Espero no hacer ninguna pregunta estupida, es posible traer este proyecto a otros broadcom como el BCM63168?
Los BCM63168 y los BCM63268 son exactamente lo mismo (de hecho el VR-3032u lleva BCM63168), así que ya está hecho ;).
-
Como hace poco tenía algo de tiempo decidí ponerme a investigar sobre si sería posible ejecutar U-Boot en routers BCM63xx. Después de varios intentos al final fui capaz de ejecutarlo y ahora mismo estoy portando drivers y haciéndolos compatibles con U-Boot.
¡Flipante! >:( >:( >:( >:(
Tengo un par de AR-5381, así que este finde a probar.
-
Tengo un HG556a v. A... Necesitas que haga algo con él para ampliar el soporte? O tiras de Internet para estas cosas?
Por apoyar cuando tenga hueco libre.
Salu2
-
Buenas!
He solucionado un par de fallos en el driver del uart y ya he enviado los parches para el soporte del SPI.
Lo siguiente será probablemente el driver del HSSPI.
¡Flipante! >:( >:( >:( >:(
Tengo un par de AR-5381, así que este finde a probar.
Sabes que el feedback siempre será bienvenido :).
A ver si saco un rato este finde y puedo probar el driver del HSSPI y hacer que funcione :P
Tengo un HG556a v. A... Necesitas que haga algo con él para ampliar el soporte? O tiras de Internet para estas cosas?
Por apoyar cuando tenga hueco libre.
Salu2
No es necesario que pruebes nada en concreto porque en estos routers no tengo pensado reemplazar CFE con U-Boot, ya que va bastante bien y no hay ningún problema que haga U-Boot necesario.
Simplemente he añadido soporte para el HG556a por ver que funciona bien el BCM6358 y por tener una plataforma donde probar el driver SPI (gracias a la documentación de danitool empecé a probar el driver SPI en este router conectándolo a una flash externa).
Lo que sí que me gustaría es que la gente trasteara un poco y diese feedback de que los diferentes drivers y las funcionalidades de U-Boot van bien (ayer por ejemplo me di cuenta de que el driver del uart no iba bien con algunos baud rates).
Por otro lado, comentarte que tengas en cuenta que la ver A del HG556a no tiene los mismos LEDs que la ver C, por lo que si lo pruebas lo normal es que los LEDs no te coincidan :).
Saludos!
-
Buenas!
He solucionado un par de fallos en el driver del uart y ya he enviado los parches para el soporte del SPI.
Lo siguiente será probablemente el driver del HSSPI.
Tengo un HG556a v. A... Necesitas que haga algo con él para ampliar el soporte? O tiras de Internet para estas cosas?
Por apoyar cuando tenga hueco libre.
Salu2
No es necesario que pruebes nada en concreto porque en estos routers no tengo pensado reemplazar CFE con U-Boot, ya que va bastante bien y no hay ningún problema que haga U-Boot necesario.
Bueno, tengo un Vodafone Router Avanzado(SHG2500) (https://wiki.openwrt.org/inbox/vodafone/vodafone_station_revolution) por ahí que creo que no estaría mal para ir haciendo pruebas. Tiene flash NAND así que no me atreví a meterle la zarpa.
Ahora viene la segunda pregunta: ¿como se genera un firm que arranque desde uboot?
-
Bueno, tengo un Vodafone Router Avanzado(SHG2500) (https://wiki.openwrt.org/inbox/vodafone/vodafone_station_revolution) por ahí que creo que no estaría mal para ir haciendo pruebas. Tiene flash NAND así que no me atreví a meterle la zarpa.
Ahora viene la segunda pregunta: ¿como se genera un firm que arranque desde uboot?
Pues debería de ser bastante sencillo, y aunque no lo he probado bastaría con hacer lo siguiente:
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadataSimplemente habría que tener en cuenta que LEDE espera recibir "0x43464531" en el arg3 (registro a3) para que el arranque no sea detectado como RedBoot, sino como CFE.
Saludos!
-
Desaparezco unos días, y al volver me encuentro esto.
Noltari, ¡Eres un máquina!
>:( >:( >:(
-
Buenas,
Por fin he conseguido que funcione el driver del hsspi:
https://github.com/Noltari/u-boot/commits/bmips-hsspi
También he arreglado un fallo en el driver del uart que hacía que algunos baud rates no funcionaran bien y he conseguido averiguar por qué en el bcm3380 no funciona bien el uart:
- El periph-osc (o pll) que llevan los bcm3380 es de 48MHz, y no de 50MHz, lo que hacía que el baud rate no se calculara correctamente en el driver.
- Por lo que he podido observar, se producen muchos overflows cuando las luces de uplink y downlink están encendidas, lo que me hace pensar que habría que apagar (o al menos dormir) el core del HFC.
Según mis cálculos, estos son los baud rates que deberían soportar los routers con 48 vs 50 MHz:
(https://i.snag.gy/ves1nS.jpg) (https://snag.gy/ves1nS.jpg)
Saludos!
-
HOla master noltari!
Consulta: Existirá la posibilidad de cargar u-boot en un Technicolor TG789vn v3? Es posible cargar firmware generando un TFTP server en el pc cliente con una IP fija.
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
Según yo, llevar OpenWRT en dispositivos con memorias NAND y CPU Broadcom. Claro, se puede usar CFE, pero por temas legales CFE no puede ser incluido dentro de una imagen de firmware por problemas legales, y por el hecho de ser (en varios casos) codigo cerrado.
En mi caso, en el dispositivo que estoy consultando yo, Technicolor (o thomson) tiene un CFE custom, que no permite hacer partir OpenWRT ya que no se sabe hacia que sector de la memoria NAND apunta el CFE. Además, como es codigo cerrado, es dificil de modificar.
La idea seria compilar imagenes que ya vengan con el bootloader, y en este caso u-boot es codigo abierto. Ergo, sin problemas legales.
Eso me parece que es.
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
Según yo, llevar OpenWRT en dispositivos con memorias NAND y CPU Broadcom. Claro, se puede usar CFE, pero por temas legales CFE no puede ser incluido dentro de una imagen de firmware por problemas legales, y por el hecho de ser (en varios casos) codigo cerrado.
En mi caso, en el dispositivo que estoy consultando yo, Technicolor (o thomson) tiene un CFE custom, que no permite hacer partir OpenWRT ya que no se sabe hacia que sector de la memoria NAND apunta el CFE. Además, como es codigo cerrado, es dificil de modificar.
La idea seria compilar imagenes que ya vengan con el bootloader, y en este caso u-boot es codigo abierto. Ergo, sin problemas legales.
Eso me parece que es.
Osea que el tema de U-boot es todo por el tema legal?
Enviado desde mi Xperia M2 Aqua mediante Tapatalk
-
HOla master noltari!
Consulta: Existirá la posibilidad de cargar u-boot en un Technicolor TG789vn v3? Es posible cargar firmware generando un TFTP server en el pc cliente con una IP fija.
El bootloader de ese router creo que no es CFE, por lo que si como dices se pueden cargar binarios por TFTP entonces sí, se podría.
De todas formas ese dispositivo es un poco peculiar porque no hay muchos BCM6368 con NAND...
Saludos.
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
Según yo, llevar OpenWRT en dispositivos con memorias NAND y CPU Broadcom. Claro, se puede usar CFE, pero por temas legales CFE no puede ser incluido dentro de una imagen de firmware por problemas legales, y por el hecho de ser (en varios casos) codigo cerrado.
En mi caso, en el dispositivo que estoy consultando yo, Technicolor (o thomson) tiene un CFE custom, que no permite hacer partir OpenWRT ya que no se sabe hacia que sector de la memoria NAND apunta el CFE. Además, como es codigo cerrado, es dificil de modificar.
La idea seria compilar imagenes que ya vengan con el bootloader, y en este caso u-boot es codigo abierto. Ergo, sin problemas legales.
Eso me parece que es.
Voy a explicar un poco el principal problema de BCM63xx y la NAND (esta explicación es válida para los BCM63268, puesto que los BCM6328/BCM6368 suelen hacerlo de otras formas):
- El bootrom carga en memoria el primer bloque de la NAND (cferom) y lo ejecuta. Este cferom no es más que un SPL (Secondary Program Loader), que se encarga de decidir si se va a utilizar la primera o la segunda imagen de la NAND.
- El cferom abre el sistema de ficheros de la imagen escogida y carga en memoria el cferam.XXX ubicado en dicha partición, que sería la parte principal del CFE.
- cferam se ejecuta esperando una posible interrupción del usuario o bien carga el kernel almacenado en la partición y lo ejecuta.
Como habréis podido deducir, esto implica que para generar imágenes que se puedan almacenar en la NAND de estos dispositvos, necesitamos crear una imagen que consistiría en un sistema de ficheros JFFS2 que contenga el cferam.XXX único del dispositivo, el kernel y el propio sistema de ficheros.
El problema es que incluir el cferam.XXX en una imagen generada desde LEDE/OpenWrt suele conllevar problemas legales
Por otro lado, tendríamos que lidiar con el hecho de utilizar JFFS2 para la NAND, lo que no es nada adecuado ya que acabaría cargándose la NAND a largo plazo (lo recomendable es usar ubifs).
La idea es generar una imagen que únicamente flashearíamos una vez y que contenga únicamente el u-boot.bin camuflado como cferam.XXX, de forma que en lugar de arrancar el kernel de la misma imagen, podría hacerse desde otra partición que ya no tendría que ser JFFS2.
Por último, decir que u-boot también es útil para probar diferentes periféricos del router antes de añadir soporte en LEDE/OpenWrt para el mismo, puesto que se puede alterar fácilmente la memoria y, por tanto, facilitar diferentes procesos como encontrar los gpios del router, los LEDs...
Saludos!
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
Según yo, llevar OpenWRT en dispositivos con memorias NAND y CPU Broadcom. Claro, se puede usar CFE, pero por temas legales CFE no puede ser incluido dentro de una imagen de firmware por problemas legales, y por el hecho de ser (en varios casos) codigo cerrado.
En mi caso, en el dispositivo que estoy consultando yo, Technicolor (o thomson) tiene un CFE custom, que no permite hacer partir OpenWRT ya que no se sabe hacia que sector de la memoria NAND apunta el CFE. Además, como es codigo cerrado, es dificil de modificar.
La idea seria compilar imagenes que ya vengan con el bootloader, y en este caso u-boot es codigo abierto. Ergo, sin problemas legales.
Eso me parece que es.
Voy a explicar un poco el principal problema de BCM63xx y la NAND (esta explicación es válida para los BCM63268, puesto que los BCM6328/BCM6368 suelen hacerlo de otras formas):
- El bootrom carga en memoria el primer bloque de la NAND (cferom) y lo ejecuta. Este cferom no es más que un SPL (Secondary Program Loader), que se encarga de decidir si se va a utilizar la primera o la segunda imagen de la NAND.
- El cferom abre el sistema de ficheros de la imagen escogida y carga en memoria el cferam.XXX ubicado en dicha partición, que sería la parte principal del CFE.
- cferam se ejecuta esperando una posible interrupción del usuario o bien carga el kernel almacenado en la partición y lo ejecuta.
Como habréis podido deducir, esto implica que para generar imágenes que se puedan almacenar en la NAND de estos dispositvos, necesitamos crear una imagen que consistiría en un sistema de ficheros JFFS2 que contenga el cferam.XXX único del dispositivo, el kernel y el propio sistema de ficheros.
El problema es que incluir el cferam.XXX en una imagen generada desde LEDE/OpenWrt suele conllevar problemas legales
Por otro lado, tendríamos que lidiar con el hecho de utilizar JFFS2 para la NAND, lo que no es nada adecuado ya que acabaría cargándose la NAND a largo plazo (lo recomendable es usar ubifs).
La idea es generar una imagen que únicamente flashearíamos una vez y que contenga únicamente el u-boot.bin camuflado como cferam.XXX, de forma que en lugar de arrancar el kernel de la misma imagen, podría hacerse desde otra partición que ya no tendría que ser JFFS2.
Por último, decir que u-boot también es útil para probar diferentes periféricos del router antes de añadir soporte en LEDE/OpenWrt para el mismo, puesto que se puede alterar fácilmente la memoria y, por tanto, facilitar diferentes procesos como encontrar los gpios del router, los LEDs...
Saludos!
Gracias, saludos
Enviado desde mi Xperia M2 Aqua mediante Tapatalk
-
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?
Según yo, llevar OpenWRT en dispositivos con memorias NAND y CPU Broadcom. Claro, se puede usar CFE, pero por temas legales CFE no puede ser incluido dentro de una imagen de firmware por problemas legales, y por el hecho de ser (en varios casos) codigo cerrado.
En mi caso, en el dispositivo que estoy consultando yo, Technicolor (o thomson) tiene un CFE custom, que no permite hacer partir OpenWRT ya que no se sabe hacia que sector de la memoria NAND apunta el CFE. Además, como es codigo cerrado, es dificil de modificar.
La idea seria compilar imagenes que ya vengan con el bootloader, y en este caso u-boot es codigo abierto. Ergo, sin problemas legales.
Eso me parece que es.
Voy a explicar un poco el principal problema de BCM63xx y la NAND (esta explicación es válida para los BCM63268, puesto que los BCM6328/BCM6368 suelen hacerlo de otras formas):
- El bootrom carga en memoria el primer bloque de la NAND (cferom) y lo ejecuta. Este cferom no es más que un SPL (Secondary Program Loader), que se encarga de decidir si se va a utilizar la primera o la segunda imagen de la NAND.
- El cferom abre el sistema de ficheros de la imagen escogida y carga en memoria el cferam.XXX ubicado en dicha partición, que sería la parte principal del CFE.
- cferam se ejecuta esperando una posible interrupción del usuario o bien carga el kernel almacenado en la partición y lo ejecuta.
Como habréis podido deducir, esto implica que para generar imágenes que se puedan almacenar en la NAND de estos dispositvos, necesitamos crear una imagen que consistiría en un sistema de ficheros JFFS2 que contenga el cferam.XXX único del dispositivo, el kernel y el propio sistema de ficheros.
El problema es que incluir el cferam.XXX en una imagen generada desde LEDE/OpenWrt suele conllevar problemas legales
Por otro lado, tendríamos que lidiar con el hecho de utilizar JFFS2 para la NAND, lo que no es nada adecuado ya que acabaría cargándose la NAND a largo plazo (lo recomendable es usar ubifs).
La idea es generar una imagen que únicamente flashearíamos una vez y que contenga únicamente el u-boot.bin camuflado como cferam.XXX, de forma que en lugar de arrancar el kernel de la misma imagen, podría hacerse desde otra partición que ya no tendría que ser JFFS2.
Por último, decir que u-boot también es útil para probar diferentes periféricos del router antes de añadir soporte en LEDE/OpenWrt para el mismo, puesto que se puede alterar fácilmente la memoria y, por tanto, facilitar diferentes procesos como encontrar los gpios del router, los LEDs...
Saludos!
Gracias por la excelente explicacion! Lo del tema legal lo habia leido entrecruzando info entre DDWRT y OpenWRT.
Entonces, con u-boot se puede usar squashfs?...me respondo solo:
http://openwrtsummit.org/slides/openwrt-nand-ubi-2016.pdf (http://openwrtsummit.org/slides/openwrt-nand-ubi-2016.pdf)
Lectura corta pero se entiende todo el nuevo proceso que se viene.
-
Buenas,
He actualizado el post principal con el último merge de u-boot/mips al repo principal.
Los drivers del SPI y HSSPI ya están siendo revisados y supongo que no tardarán mucho en aceptarlos.
Por otro lado, supongo que lo siguiente que añadiré será el soporte para BCM6368, ya que es el único SoC que falta de los que tengo para desarrollo.
También estoy trabajando de forma paralela en el driver del ethernet (y DMA), pero no es que sea precisamente fácil y rápido ;)
https://github.com/Noltari/u-boot/commits/bmips-eth-devel
Con respecto al driver de la NAND he encontrado un parche que envió un desarrollador de Broadcom para Cygnus/Iproc, que puede servirme de base y facilitarme mucho el trabajo, pero prefiero esperar a que se añada soporte de verdad en DM para la NAND...
Saludos!
-
Buenas,
Por lo que os leo, router como el Vodafone Avanzado va a estar difícil que por el momento estén soportados por openwrt/lede. Dos preguntas
¿Hay algún router con wifi ac al que se le pueda cargar Openwrt?
En la página de donaciones no he visto nada al respecto, pero ¿Vendría bien para acelerar el desarrollo la donación de algún Vodafone Avanzado?
Un saludo!
-
Buenas,
Por lo que os leo, router como el Vodafone Avanzado va a estar difícil que por el momento estén soportados por openwrt/lede. Dos preguntas
¿Hay algún router con wifi ac al que se le pueda cargar Openwrt?
En la página de donaciones no he visto nada al respecto, pero ¿Vendría bien para acelerar el desarrollo la donación de algún Vodafone Avanzado?
Un saludo!
El router mini de xiaomi tiene wifi AC y funciona con LEDE.
Saludos.
-
Buenas,
Por lo que os leo, router como el Vodafone Avanzado va a estar difícil que por el momento estén soportados por openwrt/lede. Dos preguntas
¿Hay algún router con wifi ac al que se le pueda cargar Openwrt?
En la página de donaciones no he visto nada al respecto, pero ¿Vendría bien para acelerar el desarrollo la donación de algún Vodafone Avanzado?
Un saludo!
TP-Link C7 v2.0, TP-Link C5 v1.x, Sitecom WLR-8100, entre otros...
-
Gracias! Pensaba más bien en router proporcionados por operadoras.
Un saludo!
-
Retomo el tema porque he estado probando el u-boot que colgó Noltari y después de unas modificaciones he conseguido que funcione con un AD1018, reconozca la NAND y monte un UBIfs partiendo del defconfig de un ar-5387un.
Ahora voy a ver si consigo hacer un fichero de configuración por defecto para el AD1018 incluyendo las modificaciones del .config
Dejo aquí los comandos que hay que utilizar para montar un UBIfs en u-boot, por si le sirve a alguien:
CFE> r u-boot.elf
0x80010000/601731 Entry at 0x80010000
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
0 buffers found.
Closing DMA Channels.
Starting program at 0x80010000
U-Boot 2020.01-rc2 (Nov 14 2019 - 18:18:02 +0100)
CPU: BCM63283B0
Model: Comtrend AR-5387un
DRAM: 128 MiB
NAND: 128 MiB
In: serial@10000100
Out: serial@10000100
Err: serial@10000100
Model: Comtrend AR-5387un
Net:
Warning: ethernet@10e00000 (eth0) using random MAC address - da:db:3d:d3:c0:4a
eth0: ethernet@10e00000
AR-5387un # mtd list
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x20000 bytes
- min I/O: 0x800 bytes
- OOB size: 64 bytes
- OOB available: 51 bytes
- ECC strength: 15 bits
- ECC step size: 512 bytes
- bitflip threshold: 1 bits
- 0x000000000000-0x000008000000 : "nand0"
* nor0
- type: NOR flash
- block size: 0x10000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000001000000 : "nor0"
###Montar particion en NAND
AR-5387un # ubi part nand0
AR-5387un # ubi part
Device 0: ubi0, MTD partition nand0
AR-5387un # ubi info
UBI: MTD device name: "nand0"
UBI: MTD device size: 128 MiB
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: number of good PEBs: 1019
UBI: number of bad PEBs: 5
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 1019
UBI: number of PEBs reserved for bad PEB handling: 15
UBI: max/mean erase counter: 1/0
###Montar UBI filesystem
AR-5387un # ubifsmount ubi0:data
AR-5387un # ubifsls
619775 Wed Nov 13 18:11:45 2019 u-boot.bin
4616320 Wed Nov 13 18:14:22 2019 initramfs7.elf
56 Sun Nov 03 08:25:29 2019 hello.txt
25371 Sun Nov 03 08:05:20 2019 logread.txt
12936 Sun Nov 03 08:05:06 2019 dmesg.txt
AR-5387un # ubifsload 0x80060000 hello.txt
Loading file 'hello.txt' to addr 0x80060000...
Done
AR-5387un # md 0x80060000
80060000: 48656c6c 6f204e61 6e640a2e 2e2e0a2e Hello Nand......
80060010: 2e2e0a2e 2e2e0a2e 2e2e0a2e 2e2e0a42 ...............B
80060020: 79652c20 62796520 4e616e64 0a2e0a2e ye, bye Nand....
###Cargar binario en memoria y ejecutarlo
AR-5387un # ubifsload 0x80010000 u-boot.bin
Loading file 'u-boot.bin' to addr 0x80010000...
Done
###Ahora estamos en un u-boot distinto
AR-5387un # go 0x80010000
## Starting application at 0x80010000 ...
U-Boot 2020.01-rc2 (Nov 15 2019 - 08:38:08 +0100)
CPU: BCM63283B0
Model: Comtrend AR-5387un
DRAM: 128 MiB
NAND: 128 MiB
In: serial@10000100
Out: serial@10000100
Err: serial@10000100
Model: Comtrend AR-5387un
Net:
Warning: ethernet@10e00000 (eth0) using random MAC address - 86:5d:67:17:74:d9
eth0: ethernet@10e00000
###Desmontar UBI filesystem
AR-5387un # ubifsumount
Unmounting UBIFS volume data!
El volumen UBI ya lo tenía creado desde Openwrt de esta forma:
mtdinfo /dev/mtd0
ubiformat /dev/mtd0
ubiattach -p /dev/mtd0
ubimkvol /dev/ubi0 -N data -s 121MiB
mkdir /mnt/data_disk
mount -t ubifs ubi0:data /mnt/data_disk
echo "Hello Nand" > /mnt/data_disk/hello.txt
cat /mnt/data_disk/hello.txt
umount /mnt/data_disk
ubidetach -p /dev/mtd0
-
Ya tengo el u-boot arrancando desde la memoria nand de un ad1018 con SoC BCM6328.
El cferom.bin, de 16KB, lo he grabado en el bloque 0 de la nand y a un u-boot.bin renombrado como cferam.000 le he añadido 12 bytes de cabecera con la dirección de entrada de memoria.
Este cferam.000 se lo he pasado al mkfs.jffs2 para que creara una imagen JFFS2 y la he grabado en los bloques 1,2,3,4 y 5 (ocupa unos 600KB)
Vamos, lo que se hace con el cferam.bin lo he hecho con el u-boot.bin.
Al u-boot.bin le cambié en el make menuconfig la dirección de entrada (CONFIG_SYS_TEXT_BASE) de 0x80010000 a 0x80600000, porque la primera me machacaba los punteros debido a que un cferam es bastante más pequeño.
Pero no se cómo añadir al cferom.bin los datos por defecto de la NVRAM cuando compilo ¿Alguna idea?
Un saludo
HELO
CPUI
L1CI
DRAM
----
PHYS
ZQDN
PHYE
DINT
LSYN
USYN
MSYN
LMBE
PASS
----
ZBSS
CODE
DATA
L12F
MAIN
NAN0
NAN6
NAN7
BT00
NAN9
NAN3
RFS1
NAN5
U-Boot 2020.01-rc2 (Dec 01 2019 - 21:33:56 +0100)
CPU: BCM63283B0
Model: Comtrend AR-5387un
DRAM: 128 MiB
NAND: 128 MiB
In: serial@10000100
Out: serial@10000100
Err: serial@10000100
Model: Comtrend AR-5387un
Net:
Warning: ethernet@10e00000 (eth0) using random MAC address - 82:e0:24:1d:c2:50
eth0: ethernet@10e00000
AR-5387un # help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
chpart - change active partition
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
cpu - display information about CPUs
dm - Driver model low level access
echo - echo args to console
env - environment handling commands
exit - exit script
false - do nothing, unsuccessfully
fdt - flattened device tree utility commands
fstype - Look up a filesystem type
go - start application at address 'addr'
help - print command description/usage
iminfo - print header information for application image
itest - return true/false on integer compare
led - manage LEDs
license - print GPL license text
ln - Create a symbolic link
load - load binary file from a filesystem
loadb - load binary file over serial line (kermit mode)
loadx - load binary file over serial line (xmodem mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
meminfo - display memory information
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mtd - MTD utils
mtdparts - define flash/nand partitions
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
random - fill memory with random pattern
reset - Perform RESET of the CPU
run - run commands in an environment variable
save - save file to a filesystem
setenv - set environment variables
setexpr - set environment variable as the result of eval expression
sf - SPI flash sub-system
showvar - print local hushshell variables
size - determine a file's size
source - run script from memory
sspi - SPI utility command
test - minimal test like /bin/sh
tftpboot - boot image via network using TFTP protocol
true - do nothing, successfully
ubi - ubi commands
ubifsload - load file from an UBIFS filesystem
ubifsls - list files in a directory
ubifsmount- mount UBIFS volume
ubifsumount- unmount UBIFS volume
version - print monitor, compiler and linker version
AR-5387un # setenv ipaddr 192.168.3.130
AR-5387un # setenv serverip 192.168.3.40
AR-5387un # printenv
baudrate=115200
bootdelay=2
fdtcontroladdr=87d5b94c
ipaddr=192.168.3.130
serverip=192.168.3.40
stderr=serial@10000100
stdin=serial@10000100
stdout=serial@10000100
Environment size: 164/8188 bytes
AR-5387un # sspi
SF: Detected s25fl129p1 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
AR-5387un # mtd list
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x20000 bytes
- min I/O: 0x800 bytes
- OOB size: 64 bytes
- OOB available: 51 bytes
- ECC strength: 15 bits
- ECC step size: 512 bytes
- bitflip threshold: 1 bits
- 0x000000000000-0x000008000000 : "nand0"
* nor0
- type: NOR flash
- block size: 0x10000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000001000000 : "nor0"
AR-5387un # meminfo
DRAM: 128 MiB
AR-5387un # cpu list
0: cpu@0 BCM63283B0
1: cpu@1 BCM63283B0
AR-5387un # bdinfo
boot_params = 0x87d65d08
memstart = 0x80000000
memsize = 0x08000000
flashstart = 0x00000000
flashsize = 0x00000000
flashoffset = 0x00000000
ethaddr = (not set)
IP addr = 192.168.3.130
baudrate = 115200 bps
relocaddr = 0x87f60000
reloc off = 0x07960000
AR-5387un # coninfo
List of available devices:
serial@10000100 00000007 IO stdin stdout stderr
serial 00000003 IO
AR-5387un #