?>/script>'; } ?> [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx) Widgets Magazine

Autor Tema: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)  (Leído 27785 veces)

0 Usuarios y 2 Visitantes están viendo este tema.

Noltari

  • Visitante
[Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« 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
Git U-Boot MIPS
U-Boot Patchwork

¿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
  • 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
  • N/A

Roadmap

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):
Código: [Seleccionar]
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:
Código: [Seleccionar]
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:
Código: [Seleccionar]
$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!
« Última modificación: 03-06-2017, 12:29 (Sábado) por Noltari »

mega-samu

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #1 en: 18-05-2017, 18:26 (Jueves) »
Espero no hacer ninguna pregunta estupida, es posible traer este proyecto a otros broadcom como el BCM63168?

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #2 en: 18-05-2017, 18:42 (Jueves) »
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 ;).

Pteridium

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #3 en: 18-05-2017, 20:08 (Jueves) »
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.

vk496

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #4 en: 18-05-2017, 22:59 (Jueves) »
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

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #5 en: 19-05-2017, 08:02 (Viernes) »
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!
« Última modificación: 19-05-2017, 08:05 (Viernes) por Noltari »

Pteridium

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #6 en: 19-05-2017, 12:05 (Viernes) »
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) 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?

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #7 en: 20-05-2017, 10:15 (Sábado) »
Bueno, tengo un Vodafone Router Avanzado(SHG2500) 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:
Código: [Seleccionar]
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata
Simplemente 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!
« Última modificación: 20-05-2017, 10:15 (Sábado) por Noltari »

Desconectado Tki2000

  • Moderador
  • *
  • Mensajes: 2247
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #8 en: 21-05-2017, 09:26 (Domingo) »
Desaparezco unos días, y al volver me encuentro esto.
Noltari, ¡Eres un máquina!
 >:( >:( >:(

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #9 en: 23-05-2017, 19:35 (Martes) »
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:


Saludos!
« Última modificación: 24-05-2017, 10:00 (Miércoles) por Noltari »

BernoO

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #10 en: 28-05-2017, 16:53 (Domingo) »
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.

WiFlash

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #11 en: 29-05-2017, 21:01 (Lunes) »
Me gustaría hacer una pregunta, un poco estúpida, pero me inquieta.
¿Qué posibilidades nos da U-boot en los routers?

BernoO

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #12 en: 29-05-2017, 22:27 (Lunes) »
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.
« Última modificación: 29-05-2017, 22:33 (Lunes) por BernoO »

WiFlash

  • Visitante
Re: Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #13 en: 30-05-2017, 19:45 (Martes) »
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


Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #14 en: 31-05-2017, 11:23 (Miércoles) »
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.

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #15 en: 31-05-2017, 12:01 (Miércoles) »
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!
« Última modificación: 31-05-2017, 12:03 (Miércoles) por Noltari »

WiFlash

  • Visitante
Re: Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #16 en: 31-05-2017, 15:19 (Miércoles) »
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


BernoO

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #17 en: 31-05-2017, 15:42 (Miércoles) »
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

Lectura corta pero se entiende todo el nuevo proceso que se viene.
« Última modificación: 31-05-2017, 16:49 (Miércoles) por BernoO »

Noltari

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #18 en: 02-06-2017, 08:43 (Viernes) »
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!

ifsnop

  • Visitante
Re: [Proyecto] U-Boot para BMIPS (BCM63xx, BCM33xx)
« Respuesta #19 en: 31-08-2017, 10:39 (Jueves) »
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!