Backport de Backfire

[Álvaro Fernández Rojas]

Buenas chicos,

Sé que últimamente no estoy muy activo, pero es que ando liadillo con la universidad.

Hace algún tiempo le comenté a jar229 la posibilidad de hacer un backport de las novedades de las últimas versiones de OpenWrt a Backfire. La idea es tener una versión de OpenWrt con un kernel estable (2.6.32 es LTS) a la que se pueda añadir soporte para cualquier dispositivo de brcm63xx (luego, si va bien, podemos ampliar a más plataformas).

Pues bien, más o menos ya tengo algo encarrilado, aunque la verdad es que queda bastante por hacer :).

Esto son los repositorios con los que estoy trabajando:

backfire-openwrt

backfire-openwrt-luci

backfire-openwrt-packages

backfire-openwrt-xwrt

Os comento un poco lo que he hecho hasta el momento (branch next):

• Importar los repositorios de svn a git y crear los repos en Github.
• Crear subtargets para cada SOC. Es decir, dividir el soporte para cada uno de los SOCs, de forma que el kernel sea algo más reducido, incluyendo sólo lo que es necesario para cada uno (por ejemplo SSB vs BCMA, SPI vs HSSPI vs ninguno de los dos...).
• Minimizar el soporte de las placas que hay definidas para que me sea más fácil trabajar con el kernel y la generación de imágenes hasta conseguir integrar todas las novedades (momento en el cual me centraré en volver a añadir las definiciones de las placas).
• Añadir soporte para el HG520v (es el que estoy usando en un primer momento para probar las cosas que voy integrando). El problema es que hay un bug y el kernel se queda colgado al inicializar el switch, así que de momento me estoy apañando con el wifi xD.
• Actualizar el watchdog.
• Añadir soporte para el driver SPI (backfire no tiene driver SPI, y es necesario para las flashes en algunos modelos nuevos, para switches, etc).
• Mejoras varias en la inicialización de board_bcm963xx.c.
• Alguna cosilla más que se me ha olvidado.

Y lo que quedaría:

• Añadir las mejoras de la rama trunk en orden más o menos cronológico, descartando las que no sean necesarias.
• Añadir soporte para brcm-wl.
• Añadir soporte para las nuevas CPUs (6368, 6328, etc.).
• Y más cosillas que se me olvidan.

Intentaré tener soporte para BCM6368 antes de que acabe la semana.

Se aceptan dudas, comentarios varios del estilo "¿pero tú estás loco o qué killoh?", etc. ;D

Saludos!

[dgcbueu]

Me parece interesante para dispositivos con pocos recursos, los BCM6348, en estos lo que falta y sería estupendo tener son los drivers brcm-wl, en mi opinión este sería el mayor aporte.

Sobre los drivers SPI, la verdad también vendría bien, no solo para que tienen con flash SPI o switch controlado por SPI, sino en general, los pines están en el SoC y teóricamente se podrían usar para otros menesteres cableando y demás.

Para SoCs más actuales como BCM6328 ó 6368 poco puedo opinar, ya que no llegué a usar casi nada ninguno de ellos ¿aportaría en estos chipsets alguna ventaja un backport a Backfire?

[JaR]

A mi me parece una idea estupenda.
Poder tener una versión de firmware estable a la que poder añadir paquetes sin problemas de dependencias :)

Eso sí ... lo veo muuuuucho trabajo :(

Saludos.

[Álvaro Fernández Rojas]

Buenas de nuevo,

Aqu� pod�is comprobar que he hecho unos cuantos commits (73 :D):
https://github.com/openwrt-es/backfire-openwrt/commits/next

Desde el �ltimo correo he hecho lo siguiente (resumido):
- Actualizado el detector de particiones de la flash: para que reconozca bien las particiones, aunque faltar�a incluir la detecci�n de los caldata. De todas formas, ya es un comienzo que funcione el "mtd fixtrx" (antes jod�a el boot).
- Simplificada la detecci�n del CFE + incorporado mi parche de detecci�n de los diferentes tipos seg�n el fabricante.
- Quitado soporte para los kernels antiguos (a�n queda alguna que otra cosa que eliminar, pero funcionar funciona, as� que si lo quito ser� m�s adelante por est�tica xD).
- Actualizado el kernel a la �ltima versi�n disponible (https://www.kernel.org/ 2.6.32.61). Como me he centrado en la plataforma brcm63xx las otras ni las he probado, as� que las he marcado como "broken" para que no aparezcan porque estoy 100% seguro de que dan fallos al compilar.
- A�adido el parche para el EraseSuspend en el driver CFI que danitool a�ade en el backport a Backfire del HG556a.
- Kernel de brcm63xx actualizado a uno de los puntos intermedios. A�n falta que migre el c�digo de las IRQs y cuando lo haga podr� probar el arranque en un Broadcom 6368.

TODO:
- Broadcom 6368 <- M�xima prioridad.
- Driver ethernet m�s actualizado y probar el que hay ahora, que ya es m�s actualizado que el original. El problema es que el HG520v no se lleva bien con estos drivers antiguos por problemas de inicializaci�n. Por eso quiero conseguir soporte para Broadcom 6368 lo antes posible, para tenerlo todo probado mientras lo voy actualizando.
- Kernel m�s actualizado (Flash SPI? / Broadcom 6328?).
- Caldata (detector de particiones de la flash). Lo dejar� para m�s adelante, ya que no me corre prisa.
- Driver brcm-wl para el WiFi + actualizaciones de b43. Tamib�n lo dejar� para m�s adelante, ya que tampoco es relevante para ir tirando.

Bueno, pues no os aburro m�s. �Qu� os parece de momento? �C�mo lo v�is?

Demo (Status): https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_01/status.png
Demo (Dmesg): https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_01/dmesg.txt

Saludos!

[José Vázquez]

Sorry, no me di cuenta al responder y se lo envié sólo a Noltari. :(

El 28/11/13, José Vázquez <ppvazq...@gmail.com> escribió:
> Perdón por no estar muy atento a este backport, pero me estaba dando
> de leches con florian y blogic, que son como niños. xD
> https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022659.html
>
> El 28/11/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:
>> Buenas de nuevo,
>>
>> Aquí podéis comprobar que he hecho unos cuantos commits (73 :D):
>> https://github.com/openwrt-es/backfire-openwrt/commits/next
>>
> ¡Impresionante!
>
>> Desde el último correo he hecho lo siguiente (resumido):

>> - Actualizado el detector de particiones de la flash: para que reconozca

>> bien las particiones, aunque faltaría incluir la detección de los

>> caldata.
>> De todas formas, ya es un comienzo que funcione el "mtd fixtrx" (antes

>> jodía
>> el boot).
>> - Simplificada la detección del CFE + incorporado mi parche de detección
>> de
>> los diferentes tipos según el fabricante.
>> - Quitado soporte para los kernels antiguos (aún queda alguna que otra
>> cosa
>> que eliminar, pero funcionar funciona, así que si lo quito será más
>> adelante
>> por estética xD).
>> - Actualizado el kernel a la última versión disponible

>> (https://www.kernel.org/ 2.6.32.61). Como me he centrado en la plataforma

>> brcm63xx las otras ni las he probado, así que las he marcado como

>> "broken"
>> para que no aparezcan porque estoy 100% seguro de que dan fallos al
>> compilar.

>> - Añadido el parche para el EraseSuspend en el driver CFI que danitool
>> añade

>> en el backport a Backfire del HG556a.

>> - Kernel de brcm63xx actualizado a uno de los puntos intermedios. Aún
>> falta
>> que migre el código de las IRQs y cuando lo haga podré probar el arranque

>> en
>> un Broadcom 6368.
>>
>> TODO:

>> - Broadcom 6368 <- Máxima prioridad.
> Conseguí que smp funcione con kernel 3.3, con lo que no debería ser
> demasiado complicado hacerlo en 2.6.32. Si quieres me puedo encargar
> de actualizar los archivos de include/asm/mach-bcm63xx, que no es muy
> difícil.
>> - Driver ethernet más actualizado y probar el que hay ahora, que ya es
>> más

>> actualizado que el original. El problema es que el HG520v no se lleva
>> bien

>> con estos drivers antiguos por problemas de inicialización. Por eso

>> quiero
>> conseguir soporte para Broadcom 6368 lo antes posible, para tenerlo todo
>> probado mientras lo voy actualizando.

>> - Kernel más actualizado (Flash SPI? / Broadcom 6328?).
> ¿Valdrá la pena?
>> - Caldata (detector de particiones de la flash). Lo dejaré para más

>> adelante, ya que no me corre prisa.

>> - Driver brcm-wl para el WiFi + actualizaciones de b43. Tamibén lo dejaré
>> para más adelante, ya que tampoco es relevante para ir tirando.
> Creo que a brcm-wl le puedo dar un tiento...
>>
>> Bueno, pues no os aburro más. ¿Qué os parece de momento? ¿Cómo lo véis?
> Que hay que ayudarte para que vaya adelante; cuenta conmigo.

>>
>> Demo (Status):
>> https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_01/status.png
>> Demo (Dmesg):
>> https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_01/dmesg.txt
>>
>> Saludos!
>>

> Un saludo:
>
> Pepe
>

[Álvaro Fernández Rojas]

Buenas otra vez,

Actualizaci�n: Broadcom 6368 funcionando, con Ethernet y todo :D
https://github.com/openwrt-es/backfire-openwrt/commits/next

Dmesg: https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_02/vr3025u_dmesg.txt
Status: https://dl.dropboxusercontent.com/u/4708147/openwrt/backfire/backport/demo_02/vr3025u_status.png

Obviamente el wifi no funciona (hay que actualizarlo y a�adir el PCI ID).

De momento es un buen progreso, porque me permite meterme con las configuraciones de las interfaces ;).

Saludos!

El 28/11/2013 19:36, Jos� V�zquez escribi�:
> Sorry, no me di cuenta al responder y se lo envi� s�lo a Noltari. :(
>
> El 28/11/13, Jos� V�zquez <ppvazq...@gmail.com> escribi�:
>> Perd�n por no estar muy atento a este backport, pero me estaba dando
>> de leches con florian y blogic, que son como ni�os. xD
>> https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022659.html
>>
>> El 28/11/13, �lvaro Fern�ndez Rojas <nol...@gmail.com> escribi�:
>>> Buenas de nuevo,
>>>
>>> Aqu� pod�is comprobar que he hecho unos cuantos commits (73 :D):
>>> https://github.com/openwrt-es/backfire-openwrt/commits/next
>>>
>> �Impresionante!
>>
>>> Desde el �ltimo correo he hecho lo siguiente (resumido):

>>> - Actualizado el detector de particiones de la flash: para que reconozca

>>> bien las particiones, aunque faltar�a incluir la detecci�n de los

>>> caldata.
>>> De todas formas, ya es un comienzo que funcione el "mtd fixtrx" (antes

>>> jod�a
>>> el boot).

>>> - Simplificada la detecci�n del CFE + incorporado mi parche de detecci�n
>>> de

>>> los diferentes tipos seg�n el fabricante.
>>> - Quitado soporte para los kernels antiguos (a�n queda alguna que otra
>>> cosa

>>> que eliminar, pero funcionar funciona, as� que si lo quito ser� m�s
>>> adelante

>>> por est�tica xD).
>>> - Actualizado el kernel a la �ltima versi�n disponible

>>> (https://www.kernel.org/ 2.6.32.61). Como me he centrado en la plataforma

>>> brcm63xx las otras ni las he probado, as� que las he marcado como

>>> "broken"
>>> para que no aparezcan porque estoy 100% seguro de que dan fallos al
>>> compilar.

>>> - A�adido el parche para el EraseSuspend en el driver CFI que danitool
>>> a�ade

>>> en el backport a Backfire del HG556a.

>>> - Kernel de brcm63xx actualizado a uno de los puntos intermedios. A�n
>>> falta

>>> que migre el c�digo de las IRQs y cuando lo haga podr� probar el arranque

>>> en
>>> un Broadcom 6368.
>>>
>>> TODO:

>>> - Broadcom 6368 <- M�xima prioridad.
>> Consegu� que smp funcione con kernel 3.3, con lo que no deber�a ser

>> demasiado complicado hacerlo en 2.6.32. Si quieres me puedo encargar
>> de actualizar los archivos de include/asm/mach-bcm63xx, que no es muy

>> dif�cil.
>>> - Driver ethernet m�s actualizado y probar el que hay ahora, que ya es
>>> m�s

>>> actualizado que el original. El problema es que el HG520v no se lleva
>>> bien

>>> con estos drivers antiguos por problemas de inicializaci�n. Por eso

>>> quiero
>>> conseguir soporte para Broadcom 6368 lo antes posible, para tenerlo todo
>>> probado mientras lo voy actualizando.

>>> - Kernel m�s actualizado (Flash SPI? / Broadcom 6328?).
>> �Valdr� la pena?
>>> - Caldata (detector de particiones de la flash). Lo dejar� para m�s

>>> adelante, ya que no me corre prisa.

>>> - Driver brcm-wl para el WiFi + actualizaciones de b43. Tamib�n lo dejar�

>>> para m�s adelante, ya que tampoco es relevante para ir tirando.

>> Creo que a brcm-wl le puedo dar un tiento...
>>>

>>> Bueno, pues no os aburro m�s. �Qu� os parece de momento? �C�mo lo v�is?

[Álvaro Fernández Rojas]

Por cierto Pepe,

En cuanto al SMP lo dejamos mejor para m�s adelante, que de momento prefiero incorporar lo que sabemos que funciona bien en trunk.
Con respecto a blogic y Florian, ya hab�a visto esos mensajes cuando me llegaron los correos de la lista. A ver si se pican y te hacen caso xD.

En cuanto a las actualizaciones, el problema es que no se puede hacer copy & paste del c�digo del kernel 3.10 al kernel 2.6 porque muchas cosas han cambiado y la mayor�a de las veces "casca".
As� que hay que ir mirando poco a poco, actualizaci�n por actualizaci�n, e incorporarlo poco a poco, probando que todo funciona.
Se podr�a incoporar directamente la �ltima versi�n, pero igual acabas peg�ndote un tiro.
Adem�s, yo as� lo veo f�cil.

B�sicamente lo que voy haciendo es ir revisar commit a commit lo que se ha ido haciendo en brcm63xx e ir incorpor�ndolo poco a poco:
https://dev.openwrt.org/log/trunk/target/linux/brcm63xx?rev=32000

Si quieres, cuando haga un merge de la rama next a la master (lo avisar� seguramente), puedes probar a meterle brcm-wl a ver si lo consigues.

Saludos!

El 28/11/2013 19:36, Jos� V�zquez escribi�:
> Sorry, no me di cuenta al responder y se lo envi� s�lo a Noltari. :(
>
> El 28/11/13, Jos� V�zquez <ppvazq...@gmail.com> escribi�:

>> Perd�n por no estar muy atento a este backport, pero me estaba dando
>> de leches con florian y blogic, que son como ni�os. xD
>> https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022659.html
>>

>> El 28/11/13, �lvaro Fern�ndez Rojas <nol...@gmail.com> escribi�:

>>> Buenas de nuevo,
>>>
>>> Aqu� pod�is comprobar que he hecho unos cuantos commits (73 :D):
>>> https://github.com/openwrt-es/backfire-openwrt/commits/next
>>>
>> �Impresionante!
>>
>>> Desde el �ltimo correo he hecho lo siguiente (resumido):

>>> - Actualizado el detector de particiones de la flash: para que reconozca

>>> bien las particiones, aunque faltar�a incluir la detecci�n de los

>>> caldata.
>>> De todas formas, ya es un comienzo que funcione el "mtd fixtrx" (antes

>>> jod�a
>>> el boot).

>>> - Simplificada la detecci�n del CFE + incorporado mi parche de detecci�n
>>> de

>>> los diferentes tipos seg�n el fabricante.
>>> - Quitado soporte para los kernels antiguos (a�n queda alguna que otra
>>> cosa

>>> que eliminar, pero funcionar funciona, as� que si lo quito ser� m�s
>>> adelante

>>> por est�tica xD).
>>> - Actualizado el kernel a la �ltima versi�n disponible

>>> (https://www.kernel.org/ 2.6.32.61). Como me he centrado en la plataforma

>>> brcm63xx las otras ni las he probado, as� que las he marcado como

>>> "broken"
>>> para que no aparezcan porque estoy 100% seguro de que dan fallos al
>>> compilar.

>>> - A�adido el parche para el EraseSuspend en el driver CFI que danitool
>>> a�ade

>>> en el backport a Backfire del HG556a.

>>> - Kernel de brcm63xx actualizado a uno de los puntos intermedios. A�n
>>> falta

>>> que migre el c�digo de las IRQs y cuando lo haga podr� probar el arranque

>>> en
>>> un Broadcom 6368.
>>>
>>> TODO:

>>> - Broadcom 6368 <- M�xima prioridad.
>> Consegu� que smp funcione con kernel 3.3, con lo que no deber�a ser

>> demasiado complicado hacerlo en 2.6.32. Si quieres me puedo encargar
>> de actualizar los archivos de include/asm/mach-bcm63xx, que no es muy

>> dif�cil.
>>> - Driver ethernet m�s actualizado y probar el que hay ahora, que ya es
>>> m�s

>>> actualizado que el original. El problema es que el HG520v no se lleva
>>> bien

>>> con estos drivers antiguos por problemas de inicializaci�n. Por eso

>>> quiero
>>> conseguir soporte para Broadcom 6368 lo antes posible, para tenerlo todo
>>> probado mientras lo voy actualizando.

>>> - Kernel m�s actualizado (Flash SPI? / Broadcom 6328?).
>> �Valdr� la pena?
>>> - Caldata (detector de particiones de la flash). Lo dejar� para m�s

>>> adelante, ya que no me corre prisa.

>>> - Driver brcm-wl para el WiFi + actualizaciones de b43. Tamib�n lo dejar�

>>> para m�s adelante, ya que tampoco es relevante para ir tirando.

>> Creo que a brcm-wl le puedo dar un tiento...
>>>

>>> Bueno, pues no os aburro m�s. �Qu� os parece de momento? �C�mo lo v�is?

[JaR]

Soys unos máquinas XD

A veces me veo leyendo lo que escribís y poniendo unas caras de asombro ... ;-)

Pepe, así que has conseguido que podamos usar SMP sin problemas aparentes ?

Saludos.

El 28 de noviembre de 2013 22:25, Álvaro Fernández Rojas <nol...@gmail.com> escribió:

Por cierto Pepe,

En cuanto al SMP lo dejamos mejor para más adelante, que de momento prefiero incorporar lo que sabemos que funciona bien en trunk.
Con respecto a blogic y Florian, ya había visto esos mensajes cuando me llegaron los correos de la lista. A ver si se pican y te hacen caso xD.

En cuanto a las actualizaciones, el problema es que no se puede hacer copy & paste del código del kernel 3.10 al kernel 2.6 porque muchas cosas han cambiado y la mayoría de las veces "casca".
Así que hay que ir mirando poco a poco, actualización por actualización, e incorporarlo poco a poco, probando que todo funciona.
Se podría incoporar directamente la última versión, pero igual acabas pegándote un tiro.
Además, yo así lo veo fácil.

Básicamente lo que voy haciendo es ir revisar commit a commit lo que se ha ido haciendo en brcm63xx e ir incorporándolo poco a poco:
https://dev.openwrt.org/log/trunk/target/linux/brcm63xx?rev=32000

Si quieres, cuando haga un merge de la rama next a la master (lo avisaré seguramente), puedes probar a meterle brcm-wl a ver si lo consigues.

Saludos!

El 28/11/2013 19:36, José Vázquez escribió:

> Sorry, no me di cuenta al responder y se lo envié sólo a Noltari. :(

>
> El 28/11/13, José Vázquez <ppvazq...@gmail.com> escribió:

>> Perdón por no estar muy atento a este backport, pero me estaba dando
>> de leches con florian y blogic, que son como niños. xD
>> https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022659.html
>>

>> El 28/11/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:
>>> Buenas de nuevo,
>>>

>>> Aquí podéis comprobar que he hecho unos cuantos commits (73 :D):
>>> https://github.com/openwrt-es/backfire-openwrt/commits/next
>>>
>> ¡Impresionante!
>>
>>> Desde el último correo he hecho lo siguiente (resumido):

>>> - Actualizado el detector de particiones de la flash: para que reconozca

>>> bien las particiones, aunque faltaría incluir la detección de los

>>> caldata.
>>> De todas formas, ya es un comienzo que funcione el "mtd fixtrx" (antes

>>> jodía
>>> el boot).

>>> - Simplificada la detección del CFE + incorporado mi parche de detección
>>> de

>>> los diferentes tipos según el fabricante.
>>> - Quitado soporte para los kernels antiguos (aún queda alguna que otra
>>> cosa

>>> que eliminar, pero funcionar funciona, así que si lo quito será más
>>> adelante

>>> por estética xD).
>>> - Actualizado el kernel a la última versión disponible

>>> (https://www.kernel.org/ 2.6.32.61). Como me he centrado en la plataforma

>>> brcm63xx las otras ni las he probado, así que las he marcado como

>>> "broken"
>>> para que no aparezcan porque estoy 100% seguro de que dan fallos al
>>> compilar.

>>> - Añadido el parche para el EraseSuspend en el driver CFI que danitool
>>> añade

>>> en el backport a Backfire del HG556a.

>>> - Kernel de brcm63xx actualizado a uno de los puntos intermedios. Aún
>>> falta

>>> que migre el código de las IRQs y cuando lo haga podré probar el arranque

>>> en
>>> un Broadcom 6368.
>>>
>>> TODO:

>>> - Broadcom 6368 <- Máxima prioridad.
>> Conseguí que smp funcione con kernel 3.3, con lo que no debería ser

>> demasiado complicado hacerlo en 2.6.32. Si quieres me puedo encargar
>> de actualizar los archivos de include/asm/mach-bcm63xx, que no es muy

>> difícil.
>>> - Driver ethernet más actualizado y probar el que hay ahora, que ya es
>>> más

>>> actualizado que el original. El problema es que el HG520v no se lleva
>>> bien

>>> con estos drivers antiguos por problemas de inicialización. Por eso

>>> quiero
>>> conseguir soporte para Broadcom 6368 lo antes posible, para tenerlo todo
>>> probado mientras lo voy actualizando.

>>> - Kernel más actualizado (Flash SPI? / Broadcom 6328?).
>> ¿Valdrá la pena?
>>> - Caldata (detector de particiones de la flash). Lo dejaré para más

>>> adelante, ya que no me corre prisa.

>>> - Driver brcm-wl para el WiFi + actualizaciones de b43. Tamibén lo dejaré

>>> para más adelante, ya que tampoco es relevante para ir tirando.

>> Creo que a brcm-wl le puedo dar un tiento...
>>>

>>> Bueno, pues no os aburro más. ¿Qué os parece de momento? ¿Cómo lo véis?

[Álvaro Fernández Rojas]

Buenas de nuevo,

Ya he hecho el merge de la rama next a la master:
https://github.com/openwrt-es/backfire-openwrt/commits/master

Aviso que puede haber bugs y cosas que no compilen. Ser�a lo m�s normal, pero que no cunda el p�nico xD.
De momento lo que s� seguro es lo siguiente:
- Los botones no lanzan eventos (pero funcionan perfectamente con /sys/kernel/debug/gpio o algo as�, no recuerdo bien el fichero y la ruta completa).
- El USB no funciona (al menos en el VR-3025u, o sea en 6368). No lo he probado en 6358 porque el HG520v no tiene USB y no he querido a�adir soporte para el HG556a todav�a.
- El HG520v tiene un bug muy curioso: si arranco una imagen de la flash el ethernet tira una excepci�n y el kernel se cuelga, pero si arranco un ramdisk, el ethernet se inicia perfectamente y funciona. Esto me hace pensar que el kernel "tumba" el ethernet antes de iniciar un firmware normal, pero no lo hace al cargar el ramdisk (en parte porque lo usa para descargar el mismo ramdisk). �Alguien tiene alguna idea al respecto?

Lo que he hecho desde la �ltima vez, a parte de hacer un merge de la rama next a la master es lo siguiente:
- Arreglar el bug del JFFS2 famoso por el que hay que arrancar con failsafe y hacer "mtd erase -r rootfs_data" (el de los bad blocks).
- A�adir scripts de configuraci�n para todos los routers soportados.
- Desactivar la creaci�n de im�genes JFFS2 por defecto.
- Habilitar el target x86, ya que funciona perfectamente. He detectado que a OpenWrt no le mola tener s�lo un target operativo y realiza malas configuraciones en dicho caso.
- Arreglar los drivers USB para que compilen (aunque, como ya he dicho, en 6368 no funcionan).
- A�adir soporte para el Comtrend VR-3025un.

Saludos!

[José Vázquez]

El 01/12/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:

> Buenas de nuevo,
>
> Ya he hecho el merge de la rama next a la master:
> https://github.com/openwrt-es/backfire-openwrt/commits/master
>

> Aviso que puede haber bugs y cosas que no compilen. Sería lo más normal,
> pero que no cunda el pánico xD.
Para eso estamos, ¿no? Hago un hueco en el disco duro y pruebo con un CT-5361.
> De momento lo que sé seguro es lo siguiente:

> - Los botones no lanzan eventos (pero funcionan perfectamente con

> /sys/kernel/debug/gpio o algo así, no recuerdo bien el fichero y la ruta

> completa).
> - El USB no funciona (al menos en el VR-3025u, o sea en 6368). No lo he

> probado en 6358 porque el HG520v no tiene USB y no he querido añadir soporte
> para el HG556a todavía.

> - El HG520v tiene un bug muy curioso: si arranco una imagen de la flash el

> ethernet tira una excepción y el kernel se cuelga, pero si arranco un

> ramdisk, el ethernet se inicia perfectamente y funciona. Esto me hace pensar
> que el kernel "tumba" el ethernet antes de iniciar un firmware normal, pero
> no lo hace al cargar el ramdisk (en parte porque lo usa para descargar el
> mismo ramdisk). ¿Alguien tiene alguna idea al respecto?

Se puede probar con un HG553 a ver si peta también, y de paso los USB.
Puede ser también porque falta incluir esto:
http://patchwork.linux-mips.org/patch/4454/
Además, aquí (https://github.com/openwrt-es/backfire-openwrt/commit/c95bfdff197f9d4987a0d757349e702b16667a31#diff-9c346ac1eb720b68134046e43c3dbe1bL471)
creo que estaba bien al principio, pero no estoy seguro, ya que el
código fuente que revise nombra los interfaces EMACx en vez de ENETx:

uint32 GPIOMode;
#define GPIO_MODE_EMAC1_MII_CLK_INV (1<<31)
#define GPIO_MODE_EMAC2_MII_CLK_INV (1<<30)
#define GPIO_MODE_SYS_IRQ (1<<15)
#define GPIO_MODE_PWM_SYNC_CLK (1<<14)
#define GPIO_MODE_CLKRST (1<<13)
#define GPIO_MODE_UTOPIA_OVERLAY (1<<12)
#define GPIO_MODE_LED_OVERLAY (1<<11)
#define GPIO_MODE_SERIAL_LED_OVERLAY (1<<10)
#define GPIO_MODE_LEGACY_LED_OVERLAY (1<<9)
#define GPIO_MODE_ASYNC_MODEM_OVERLAY (1<<8)
#define GPIO_MODE_SPI_SS_OVERLAY (1<<7)
#define GPIO_MODE_UART1_OVERLAY (1<<6)
#define GPIO_MODE_EXTRA_CS_OVERLAY (1<<5)

>
> Lo que he hecho desde la última vez, a parte de hacer un merge de la rama

> next a la master es lo siguiente:
> - Arreglar el bug del JFFS2 famoso por el que hay que arrancar con failsafe
> y hacer "mtd erase -r rootfs_data" (el de los bad blocks).

> - Añadir scripts de configuración para todos los routers soportados.
> - Desactivar la creación de imágenes JFFS2 por defecto.

> - Habilitar el target x86, ya que funciona perfectamente. He detectado que a

> OpenWrt no le mola tener sólo un target operativo y realiza malas

> configuraciones en dicho caso.
> - Arreglar los drivers USB para que compilen (aunque, como ya he dicho, en
> 6368 no funcionan).

Fijo que es una tontería.
> - Añadir soporte para el Comtrend VR-3025un.
;)
>
> Saludos!
>

Un saludo.

[Álvaro Fernández Rojas]

Respuesta a Pepe, que me ha pillado redactando este email:

El ethernet creo que est� bien as�, de hecho, fue introducido en OpenWrt en este commit:
https://dev.openwrt.org/changeset/33157

Si quer�is puedo a�adir soporte para el Broadcom HW553 y que alguien lo pruebe, porque yo no tengo ese router :/

---

Buenas otra vez m�s xD,

Ya he solucionado el bug de los botones, ya funcionan perfectamente y se puede entrar en failsafe.
https://github.com/openwrt-es/backfire-openwrt/commit/d298e7e16260ca07d9333213c1d8e58757dfe591

El problema era que efectivamente, en trunk la carga de m�dulos la gestiona procd, y en backfire faltaba un archivo que cargara los m�dulos necesarios para los botones.

Adem�s tambi�n he actualizado button-hotplug y he a�adido un soporte inicial para Broadcom 6328 (aunque todav�a no se puede usar):
https://github.com/openwrt-es/backfire-openwrt/commits/master

Como es estable he hecho un merge a la rama master.
De hecho, creo que ahora ir� haciendo merges de la rama next a la master poco a poco, ya que ahora puedo ir probando que todo funciona.

Con respecto a lo del bug del USB me gustar�a probar si s�lo se produce en 6368, porque si es as� podr�a ser debido a que no he hecho el backport de las interrupciones correctamente :$.

De todas formas no queda mucho para que a�ada soporte para el HG556a, ya que despu�s de introducir el soporte para Broadcom 6328 es cuando toca el de las particiones de los datos de calibraci�n del WiFi.
En dicho momento podr� probar si funciona en 6358.

Saludos!

[José Vázquez]

El 01/12/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:

> Buenas de nuevo,
>
> Ya he hecho el merge de la rama next a la master:
> https://github.com/openwrt-es/backfire-openwrt/commits/master
>

> Aviso que puede haber bugs y cosas que no compilen. Sería lo más normal,
> pero que no cunda el pánico xD.
> De momento lo que sé seguro es lo siguiente:

> - Los botones no lanzan eventos (pero funcionan perfectamente con

> /sys/kernel/debug/gpio o algo así, no recuerdo bien el fichero y la ruta

> completa).
> - El USB no funciona (al menos en el VR-3025u, o sea en 6368). No lo he

> probado en 6358 porque el HG520v no tiene USB y no he querido añadir soporte
> para el HG556a todavía.

Funciona correctamente en el HG553.

> - El HG520v tiene un bug muy curioso: si arranco una imagen de la flash el

> ethernet tira una excepción y el kernel se cuelga, pero si arranco un

> ramdisk, el ethernet se inicia perfectamente y funciona. Esto me hace pensar
> que el kernel "tumba" el ethernet antes de iniciar un firmware normal, pero
> no lo hace al cargar el ramdisk (en parte porque lo usa para descargar el
> mismo ramdisk). ¿Alguien tiene alguna idea al respecto?

Con el HG553 no da problemas. ¿Podrías poner el bootlog cuando falla?

>
> Lo que he hecho desde la última vez, a parte de hacer un merge de la rama

> next a la master es lo siguiente:
> - Arreglar el bug del JFFS2 famoso por el que hay que arrancar con failsafe
> y hacer "mtd erase -r rootfs_data" (el de los bad blocks).

> - Añadir scripts de configuración para todos los routers soportados.
> - Desactivar la creación de imágenes JFFS2 por defecto.

> - Habilitar el target x86, ya que funciona perfectamente. He detectado que a

> OpenWrt no le mola tener sólo un target operativo y realiza malas

> configuraciones en dicho caso.
> - Arreglar los drivers USB para que compilen (aunque, como ya he dicho, en
> 6368 no funcionan).

> - Añadir soporte para el Comtrend VR-3025un.
>
Adjuntos van un parche para el HG553 y algunos logs.

Un saludo.

[Álvaro Fernández Rojas]

Buenas Pepe,

Gracias por el parche y por los logs.
Ahora mismo estoy en la universidad y no puedo ponerte los logs del
ethernet del HG520v, pero cuando llegue a casa si puedo los pongo.

�Has encontrado algo que fallara?
Si los USBs funcionan en el HW553, y por tanto en todos los 6358,
mientras que no lo hacen en 6368, asumo que es un problema de
interrupciones o de los drivers en s�. M�s adelante intentar� mirarlo a
ver qu� pasa.

De todas formas, �qu� tal lo ves? �vamos bien hasta ahora?

Saludos!

[Álvaro Fernández Rojas]

Otra cosa,

Por la fotos veo que el HG553 tiene bot�n de Reset (o al menos tiene un
bot�n).
�Por qu� OpenWrt no lo tiene definido?
�Podr�as averiguar qu� GPIO tiene el bot�n?

Saludos!

[José Vázquez]

El 02/12/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:

> Buenas Pepe,
>
> Gracias por el parche y por los logs.
> Ahora mismo estoy en la universidad y no puedo ponerte los logs del
> ethernet del HG520v, pero cuando llegue a casa si puedo los pongo.

No corre prisa; simplemente me pica la curiosidad ya que en el 6358 no peta.
>
> ¿Has encontrado algo que fallara?

> Si los USBs funcionan en el HW553, y por tanto en todos los 6358,
> mientras que no lo hacen en 6368, asumo que es un problema de

> interrupciones o de los drivers en sí. Más adelante intentaré mirarlo a
> ver qué pasa.
Yo también le echaré un ojo, aunque dudo que encuentre nada.
>
> De todas formas, ¿qué tal lo ves? ¿vamos bien hasta ahora?
Quienes deben decirlo son JaR, danitool, gmtii y tú, que sois quienes
los exprimís; mientras no me de problemas y vaya bien, para mi vale.
Mi opinión es que va teniendo muy buena pinta, aunque muchos paquetes
habrá que revisarlos y actualizarlos o añadirlos.
Una cosa a la que sí le dedicaría esfuerzo es actualizar GCC a la
versión 4.6 (o el toolchain en general si estamos suficientemente
locos), pues danitool mencionó que había un salto significativo de
rendimiento entre Backfire y Attitude Adjustment.
A ver si termino de añadir el soporte smp a este backport de AA:
https://github.com/Pteridium/Attitude-Adjustment-ARV4518PWR01/commits/devel
>
> Saludos!
>
Un saludo.

[dani]

Lo del rendimiento en principio no tendría nada que ver con la toolchain, tal vez más con los módulos de iptables. Las pruebas de rendimiento que hice fueron de transferencia en red y quizás en kernels más actuales los iptables estén más pulidos y es más fluida la inspección de paquetes.

Lo que sí existía era un bug o varios, en backfire, que impedía que se compilase correctamente la toolchain en sistemas operativos que usasen gcc relativamente actuales. Yo uso Arch con lo último de lo último y esto me supuso un problema ya hace tiempo, no recuerdo desde que versiones de gcc y librerías varias de mi sistema, lo cual era un gran problema. Pero no sé si eso ya lo solucionó Noltari en este backport. Si detecto algo cuando compile ya avisaré con sus parches correspondientes.

[Álvaro Fernández Rojas]

Buenas,

@Pepe
Ok, no me supone mucho problema lo del HG520v, ya que la mayor parte de las veces pruebo ramdisks.
Si necesitas ayuda con lo del backport del SMP a AA avisa.
Lo de los paquetes no es problema, pero en mi opini�n es m�s prioritario disponer de un kernel en el que funcione todo antes de eso ;).

@danitool
El 02/12/2013 20:04, dani escribi�:
> Lo del rendimiento en principio no tendr�a nada que ver con la toolchain, tal vez m�s con los m�dulos de iptables. Las pruebas de rendimiento que hice fueron de transferencia en red y quiz�s en kernels m�s actuales los iptables est�n m�s pulidos y es m�s fluida la inspecci�n de paquetes.
iptables tambi�n se podr�a actualizar haciendo un backport, el caso es que merezca o no la pena xD.
> Lo que s� exist�a era un bug o varios, en backfire, que imped�a que se compilase correctamente la toolchain en sistemas operativos que usasen gcc relativamente actuales. Yo uso Arch con lo �ltimo de lo �ltimo y esto me supuso un problema ya hace tiempo, no recuerdo desde que versiones de gcc y librer�as varias de mi sistema, lo cual era un gran problema. Pero no s� si eso ya lo solucion� Noltari en este backport. Si detecto algo cuando compile ya avisar� con sus parches correspondientes.
Eso no lo he corregido, aunque he visto los parches en tu backport del HG556a. Como a mi me funciona no he intentado integrarlos.

P.D: Entonces, �Qui�n me puede decir qu� GPIO se corresponde con el bot�n de reset del HG553? (si existen m�s botones estar�a bien saberlo tambi�n).

Saludos!

[José Vázquez]

El 02/12/13, Álvaro Fernández Rojas <nol...@gmail.com> escribió:

> Buenas,
>
> @Pepe
> Ok, no me supone mucho problema lo del HG520v, ya que la mayor parte de las
> veces pruebo ramdisks.
> Si necesitas ayuda con lo del backport del SMP a AA avisa.

No creo: sólo falta poner los subtargets y un par de detalles más para
que quede bonito.
> Lo de los paquetes no es problema, pero en mi opinión es más prioritario

> disponer de un kernel en el que funcione todo antes de eso ;).
>
> @danitool

> El 02/12/2013 20:04, dani escribió:
>> Lo del rendimiento en principio no tendría nada que ver con la toolchain,
>> tal vez más con los módulos de iptables. Las pruebas de rendimiento que
>> hice fueron de transferencia en red y quizás en kernels más actuales los
>> iptables estén más pulidos y es más fluida la inspección de paquetes.

No termino de ver claro que sea sólo por las iptables. Con trunk,
compilando cpuminer con GCC 4.6 saca 0'07 khash/s por cada core del
bcm6368, y con GCC 4.8 sube a 0'08 khash/s.
Haré alguna prueba más a fondo, a ver qué dice.
> iptables también se podría actualizar haciendo un backport, el caso es que

> merezca o no la pena xD.

>> Lo que sí existía era un bug o varios, en backfire, que impedía que se

>> compilase correctamente la toolchain en sistemas operativos que usasen gcc

>> relativamente actuales. Yo uso Arch con lo último de lo último y esto me

>> supuso un problema ya hace tiempo, no recuerdo desde que versiones de gcc

>> y librerías varias de mi sistema, lo cual era un gran problema. Pero no sé

>> si eso ya lo solucionó Noltari en este backport. Si detecto algo cuando
>> compile ya avisaré con sus parches correspondientes.

> Eso no lo he corregido, aunque he visto los parches en tu backport del
> HG556a. Como a mi me funciona no he intentado integrarlos.

Creo que se refiere a que los que compilan con Arch linux tenían un
montón de problemas por las versiones de make, GCC y algunos programas
más.
>
> P.D: Entonces, ¿Quién me puede decir qué GPIO se corresponde con el botón de
> reset del HG553? (si existen más botones estaría bien saberlo también).
Tiene 2 botones: wifi y reset. Mañana te los mando por mensajería urgente. ;)
>
> Saludos!
>

[dani]

sobre los botones del hg553, envié hace tiempo un parche, el cual fue ignorado finalmente

http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/15831

[José Vázquez]

El 02/12/13, dani <dgc...@gmail.com> escribió:

> sobre los botones del hg553, envié hace tiempo un parche, el cual fue
> ignorado finalmente

Pasa hasta en las mejores casas.
>
> http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/15831
>
>
Adjuntos van los parches para que funcione broadcom-wl. Hubo que ir a
la revisión 23899 para que no diera muchos dolores de cabeza. Como
base para los parches se usó r25590.

Un saludo:

Pepe

[Álvaro Fernández Rojas]

Buenas de nuevo,

@Pepe
No he podido ponerme con brcm-wl a�n, pero tengo pensado a�adirlo pronto.

@Todos
He vuelto a hacer un merge de la rama de desarrollo a la master:
https://github.com/openwrt-es/backfire-openwrt/commits/master

Una de las cosas que he arreglado son los USBs en los VR-3025u y VR-3025un. S�, era una completa gilipollez, no hab�a declarado el soporte para ohci y ehci en la estructura :/.
Tambi�n he a�adido soporte para el Comtrend WAP-5813n, ya que lo us� para probar unas cosillas.
Por otro lado, he a�adido el driver HSSPI (spi en Broadcom 6328) y le he metido actualizaciones al driver SPI. Tambi�n he a�adido soporte para el Comtrend AR-5381u.
Aprovechando que ya ten�a el driver SPI se me ha ido la olla y he decidido meter soporte para flashes SPI (muy necesarias en los 6328). Esto ha sido con diferencia lo m�s dif�cil que hecho hasta ahora:
- En primer lugar he tenido que migrar el c�digo de las particiones al que se usa en linux 3.3+, physmap: https://github.com/openwrt-es/backfire-openwrt/commit/c0f059c495dcd46319ecbaaf92fb025776f1d333
- Aprovechando que me he mirado bastante c�digo del mtd he dejado el camino preparado para a�adir las particiones de los datos de calibraci�n: https://github.com/openwrt-es/backfire-openwrt/commit/7799da5b1b080438c61410e2002d3253240d7480
- Despu�s, he actualizado m25p80 para que soporte el mismo physmap que he comentado antes: https://github.com/openwrt-es/backfire-openwrt/commit/7b56817269bdebf91a84c7b16ffa873a4ac2df7c
- Por �ltimo he a�adido el registro de las flashes SPI y he activado el soporte en Broadcom 6328: https://github.com/openwrt-es/backfire-openwrt/commit/764105d0a79623002235f908b848f2e019e66ade
Resultado: no me lo creo ni yo, pero funciona xD. He conseguido arrancar una imagen en el Comtrend AR-5381u y ha reconocido la flash, las particiones y lee, escribe y borra perfectamente.

As� que lo siguiente ser� seguir con el timeline por orden cronol�gico, pasando por los datos de calibraci�n (momento en el cual a�adir� soporte para el HG556a).
Bugs conocidos: No funciona el USB en los 6328 (es normal, ya que por orden cron�ligico primero se introdujo soporte para el 6328 y m�s adelante se arregl� el soporte USB).

Saludos!