Dudas sobre piBacteria

[antoniovillena]

Gracias a ti, zx81. Le echaré un vistazo al u-boot

Compilarlo es fácil. Lo que me resultó trabajoso es generar una imagen que funcione por el método correcto. Si te atascas (lo dudo mucho) no pelees. Pregunta y tus dudas serán respondidas en la medida de lo posible, claro.

Pues tardaré algo en preguntarte. Voy a estar 2 semanas sin acceso a la raspberry. Muchas gracias

[antoniovillena]

Gracias a ti, zx81. Le echaré un vistazo al u-boot

Compilarlo es fácil. Lo que me resultó trabajoso es generar una imagen que funcione por el método correcto. Si te atascas (lo dudo mucho) no pelees. Pregunta y tus dudas serán respondidas en la medida de lo posible, claro.

Pues tardaré algo en preguntarte. Voy a estar 2 semanas sin acceso a la raspberry. Muchas gracias

Hola zx81. Ya tengo tiempo para meterme con esto. Dime por dónde empezar. De dónde me bajo u-boot, instrucciones para compilarlo, ¿funciona con teclado USB o necesita conversor USB-UART?

[zx81]

A ver el, repo git clonado que yo tengo es git://git.denx.de/u-boot.git.

Hay que definir la variable de entorno CROSS_COMPILE con el PATH del directorio donde tengas las utilidades de compilación cruzada, por ejemplo,

Código: Seleccionar todo

export CROSS_COMPILE=/home/jsanchez/src/Raspberry-Pi/arm-none-eabi/bin/arm-none-eabi-

luego:

Código: Seleccionar todo

make [rpi_defconfig | rpi_2_defconfig | rpi_3_32b_defconfig]  (según tengas la PI B/B+, la PI-2 o la PI-3)
make

Ahora solo tienes que copiar el archivo u-boot.bin a la SD donde tengas también los archivos de arranque estándar (bootcode.bin, fixup.dat, start.elf), con el nombre adecuado al modelo de PI (kernel.img, kernel7.img).

U-Boot inicializa el subsistema USB, y la red. Las entradas/salidas de consola las pone duplicadas en el framebuffer y en el puerto serie, cualquiera de los dos vale. Puedes conectar tranquilamente un teclado USB sin problemas.

Una vez que arranque, el comando 'help' te da una lista de comandos utilizables. Hay varios comandos que permiten enviar la imagen por el puerto serie usando X-Modem, Y-Modem, Kermit o en formato S-Record (comandos load*). También permite cargar un binario desde la SD, pero eso es lo que intentamos evitar, claro.

Para poder cargar por red, tienes que tener un servidor TFTP accesible. La IP a la PI se le puede dar fija o dejar que la pille por DHCP. Yo he acabdo por ponerlas fijas, es más cómodo y rápido, por ejemplo:

Código: Seleccionar todo

setenv ipaddr 192.168.1.5
setenv serverip 192.168.1.10 (la dirección de mi servidor TFTP)
saveenv (para guardar la configuración en un archivo en la SD)
printenv (para ver las variables existentes)

El asunto ahora es que u-boot necesita un binario con una cabecera especial que le dice las características de ese binario. Una vez que tienes el kernel.img que quieres ejecutar, hay que usar una utilidad que se habrá creado en el directorio 'tools' de uboot, llamada mkimage de la siguiente forma:

Código: Seleccionar todo

mkimage kernelv6.img -A arm -O linux -T standalone -C none -a 0x8000 -e 0x8000 -d kernel.img -n piBacteria

El parámetro '-a' le dice la dirección final de ubicación del binario y el '-e' le dice la dirección de arranque. En '-d' se pone la imagen binaria a convertir y que finalmente se llamará kernelv6.img (ese nombre es el que yo le pongo, podría llamarse pepitoperez.img si así lo deseas). Copias ese kernelv6.img al directorio que sirvas por TFTP y en la línea de comandos de u-boo pones,

Código: Seleccionar todo

tftp kernelv6.img (para cargar la imagen desde el server)
bootm (para arrancar la imagen cargada)

Este es un breve resumen de las posibilidades más básicas de u-boot, que admite más, claro. Recordarte que, hasta donde yo he podido detectar, u-boot deja configurada en otra dirección la tabla de excepciones que debería estar en 0x00000000 y el Strict Alignment Fault Cheking Enabled. Por ambas razones piBacteria no funcionará. Todo programa que espere la tabla de excepciones en 0x00000000 tampoco funcionará (la mayoría).

No creo que tengas problemas con esta breve guía, pero si los tienes, levanta la mano...

[antoniovillena]

Muchas gracias por la guía detallada. Cuando me ponga te digo cómo ha ido todo.

[antoniovillena]

Hola zx81

Ya he hecho la prueba. Todo ha ido perfecto. El u-boot se puede instalar de tal forma que si no pulsas ninguna tecla al inicio te arranque el Linux normalmente. Para ello te editas un fichero que se llame boot.scr (yo tengo B+)

Código: Seleccionar todo

fatload mmc 0 ${kernel_addr_r} kernel.bak
fatload mmc 0 ${fdt_addr_r} bcm2708-rpi-b-plus.dtb
setenv bootargs console=tty0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd
bootz ${kernel_addr_r} - ${fdt_addr_r}

Y lo transformas en un uImage tipo script:

Código: Seleccionar todo

mkimage -A arm -O linux -T script -C none -n boot.scr -d boot.scr boot.scr.uimg

Luego copias el boot.scr.uimg en la carpeta /boot de la SD. El antiguo kernel.img que tenía rasbpbian lo renombras a kernel.bak, y el u-boot.bin lo renombras a kernel.img. Todo esto está explicado aquí:
http://elinux.org/RPi_U-Boot

Respecto a cargar archivos en bare metal es mucho más sencillo. Se hace con estas 2 instrucciones:

Código: Seleccionar todo

dhcp 0x8000 prueba.img
go 0x8000

Eso sí, deberás cambiar el programa bare metal para que inicialice el Vector Base Address Register. Tal y como lo tengo en mis programas lo más fácil es añadir estas 2 instrucciones al comienzo, antes de las macros ADDEXC:

Código: Seleccionar todo

        mov     r0, #0
        mcr     p15, 0, r0, c12, c0, 0

No lo he probado en piBacteria aún, pero supongo que con esto y con el cambio de "Strict Alignment Fault Cheking Enabled" que decías, se solucionará

[zx81]

Hola zx81

Ya he hecho la prueba. Todo ha ido perfecto. El u-boot se puede instalar de tal forma que si no pulsas ninguna tecla al inicio te arranque el Linux normalmente. Para ello te editas un fichero que se llame boot.scr (yo tengo B+)

Código: Seleccionar todo

fatload mmc 0 ${kernel_addr_r} kernel.bak
fatload mmc 0 ${fdt_addr_r} bcm2708-rpi-b-plus.dtb
setenv bootargs console=tty0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd
bootz ${kernel_addr_r} - ${fdt_addr_r}

Y lo transformas en un uImage tipo script:

Código: Seleccionar todo

mkimage -A arm -O linux -T script -C none -n boot.scr -d boot.scr boot.scr.uimg

Luego copias el boot.scr.uimg en la carpeta /boot de la SD. El antiguo kernel.img que tenía rasbpbian lo renombras a kernel.bak, y el u-boot.bin lo renombras a kernel.img. Todo esto está explicado aquí:
http://elinux.org/RPi_U-Boot

Ya veo que has estado jugando con el cacharro. Como tengo una uSD exclusivamente para mis cacharreos, no he necesitado hacer un arranque dual. Pero está bien conocer el procedimiento.

Respecto a cargar archivos en bare metal es mucho más sencillo. Se hace con estas 2 instrucciones:

Código: Seleccionar todo

dhcp 0x8000 prueba.img
go 0x8000

Eso sí, deberás cambiar el programa bare metal para que inicialice el Vector Base Address Register. Tal y como lo tengo en mis programas lo más fácil es añadir estas 2 instrucciones al comienzo, antes de las macros ADDEXC:

Código: Seleccionar todo

        mov     r0, #0
        mcr     p15, 0, r0, c12, c0, 0

No lo he probado en piBacteria aún, pero supongo que con esto y con el cambio de "Strict Alignment Fault Cheking Enabled" que decías, se solucionará

Vayamos por partes. No uso el comando DHCP porque me parece un fastidio que cada vez pida la IP y toda la pesca. Me resulta más rápido que la IP esté en el archivo de configuración.

Pero lo que, a priori, no te sirve, es el comando 'go'. Si no me equivoco, la idea de ese comando es hacer imágenes 'standalone' que hagan uso de los servicios de u-boot y que, incluso, puedan retornar a la línea comandos del loader una vez que acaben su ejecución. Eso hace que cuando usas el comando, la CPU está en un estado que nada tiene que ver con la configuración que tiene tras un arranque normal, es decir, caché L1 habilitada y MMU funcionando, entre otras cosas.

En cambio, con 'bootm' se respetan las normas de arranque necesarias para que un kernel de Linux no tenga problemas. Estas normas están descritas en el archivo:

https://git.kernel.org/cgit/linux/kerne ... ags/v4.8.6

Lo sorprendente es que algo tan importante como el registro VBAR no lo dejen como se debería. Lo del "Strict Fault Cheking" podría ser algo opcional. No obstante, en el manual de programación del ARMv8 dice explícitamente que el registro VBAR debería ser inicializado adecuadamente durante el arranque de un kernel y que no debe presuponerse configuración alguna. En las páginas anteriores de este mismo hilo puse la solución a los dos problemas. No recuerdo si lo puse antes o después de ADDEXC.

[antoniovillena]

Vayamos por partes. No uso el comando DHCP porque me parece un fastidio que cada vez pida la IP y toda la pesca. Me resulta más rápido que la IP esté en el archivo de configuración.

No me pide nada. Mediante algún protocolo deduce dónde está el servidor que corre TFTP y se baja el archivo.

Pero lo que, a priori, no te sirve, es el comando 'go'. Si no me equivoco, la idea de ese comando es hacer imágenes 'standalone' que hagan uso de los servicios de u-boot y que, incluso, puedan retornar a la línea comandos del loader una vez que acaben su ejecución. Eso hace que cuando usas el comando, la CPU está en un estado que nada tiene que ver con la configuración que tiene tras un arranque normal, es decir, caché L1 habilitada y MMU funcionando, entre otras cosas.

En cambio, con 'bootm' se respetan las normas de arranque necesarias para que un kernel de Linux no tenga problemas.

Para desarrollar un kernel será así, pero si lo que necesitas es correr pequeños programas en bare metal, te vale. Claro que no podrás retornar a u-boot. Hay que reiniciar la Raspberry para volver a la línea de commandos u-boot, lo cual es bastante rápido.

[zx81]

Para desarrollar un kernel será así, pero si lo que necesitas es correr pequeños programas en bare metal, te vale. Claro que no podrás retornar a u-boot. Hay que reiniciar la Raspberry para volver a la línea de commandos u-boot, lo cual es bastante rápido.

De hacerlo así no olvides la MMU y la caché, que te obligan a usar memory barriers para hacer algunas cosas.

Ahora que has descubierto una manera "fácil" para poder probar kernels, ¿veremos un piBacteria con soporte de USB?

[antoniovillena]

De hacerlo así no olvides la MMU y la caché, que te obligan a usar memory barriers para hacer algunas cosas.
Ahora que has descubierto una manera "fácil" para poder probar kernels, ¿veremos un piBacteria con soporte de USB?

Tengo el proyecto muy dejado por falta de tiempo. Este método es alternativo e interesante, pero es más lento para desarrollo que con conversor USB-serie y bootloader.

[zx81]

Por completar el hilo, añado que he encontrado otra "feature" de u-boot que solo afecta a las B+ y similares (no a las PI-2/3) cuando se intenta volver a habilitar la MMU. El problema es que quedan entradas en el caché TLB que dan por saco, entre otras cosas, en los accesos a la memoria de pantalla (de no haber sido porque afectaba, precisamente, a la pantalla seguramente jamás habría encontrado el problema y me hubiera vuelto loco con cosas que fallan sin sentido ni razón).

Según el ARM Cortex-A Series Programmer's Guide, documento DEN0013D, sección 8.8, después de deshabilitar la MMU hay que limpiar la caché-L1, el caché TLB y el predictor de saltos. En el caso de querer activar la L1 y la MMU (la ganancia de velocidad es tremenda) habría que ejecutar, tras el reseteo del registro VBAR:

Código: Seleccionar todo

mcr p15, 0, r0, c7, c5, 0 /* Invalidate Instruction Cache */
mcr p15, 0, r0, c7, c5, 6 /* Invalidate branch prediction array */
mcr p15, 0, r0, c8, c7, 0 /* Invalidate entire Unified Main TLB */
mcr p15, 0, r0, c7, c5, 4 /* Instruction Synchronization Barrier (need to be changed for ISB instruction on PI-2/3) */

Si no se activa la MMU, en principio no hay problema. Pero dejo constancia aquí porque a mi me ha dado por saco, pronto comentaré en qué contexto, hasta que he encontrado el problema, que lo mío me ha costado.