embedded - español - Velocidad de reloj ARM en raspberry pi

raspberry pi zero os

Question

Ejecutando bare-metal (sin sistema operativo, sin Linux)

Las especificaciones implican que ARM puede / ejecuta 700MHz, el reloj del sistema coincide con el manual y parece estar funcionando a 250MHz. Las pruebas simples en el ARM implican que está haciendo lo mismo, por ejemplo con el caché de instrucciones en

test:
  subs r0,r0,#1
  bne test

Y varía la cantidad de instrucciones de subunidades para dominar la sucursal, está en el parque de béisbol de 250MHz pero muy lejos de 700MHz.

¿Hay una configuración de phy que no estoy viendo en la hoja de datos para multiplicar el reloj ARM?

EDITAR:

Tal vez mis suposiciones son defectuosas ...

.globl ARMTEST0
ARMTEST0:
    subs r0,r0,#1
    bne ARMTEST0
    bx lr

.globl ARMTEST1
ARMTEST1:
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    bne ARMTEST1
    bx lr

.globl ARMTEST2
ARMTEST2:
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    subs r0,r0,#1
    bne ARMTEST2
    bx lr

.globl ARMTEST3
ARMTEST3:
    subs r1,r0,#1
    subs r2,r1,#1
    subs r3,r2,#1
    subs r0,r3,#1
    subs r1,r0,#1
    subs r2,r1,#1
    subs r3,r2,#1
    subs r0,r3,#1
    subs r1,r0,#1
    subs r2,r1,#1
    subs r3,r2,#1
    subs r0,r3,#1
    subs r1,r0,#1
    subs r2,r1,#1
    subs r3,r2,#1
    subs r0,r3,#1
    bne ARMTEST3
    bx lr

Temporizadores del sistema en hexadecimal por función (temporizador del sistema de 250Mhz verificado contra el cronómetro, etc.).

02DB6DF7 ARMTEST0
02DB6E1C ARMTEST0
00AB6E2A ARMTEST1
00836E46 ARMTEST2
00836E2A ARMTEST3

Lo que da:

ARMTEST0
0x01000000 subs instructions
0x01000000 bne  instructions
0x02000000 instructions
1.43 clocks per instruction.  175Mips.

ARMTEST1
0x01000000 sub instructions
0x00200000 bne instructions
0x01200000 instructions
1.68 instructions per clock. 420Mips

ARMTEST2
0x01000000 sub instructions
0x00100000 bne instructions
0x01100000 instructions
2.07 instructions per clock. 517Mips

ARMTEST3
0x01000000 sub instructions
0x00100000 bne instructions
0x01100000 instructions
2.07 instructions per clock. 517Mips

El ARM11 es súper escalar, más de una instrucción por reloj no es inesperada. Yo esperaría más sin embargo. Usar solo el registro 0 podría interferir con el conducto ya que tiene que esperar un resultado de una instrucción antes de ejecutar el siguiente. Esperaba ver una diferencia entre la prueba 2 y 3, tal vez otra mala suposición. Tal vez es realmente 500Mhz, ¿no 700? Hay una línea en las fuentes de Linux que menciona un reloj 500000000.

static struct clk osc_clk = {
#ifdef CONFIG_ARCH_BCM2708_CHIPIT
    .rate = 27000000,
#else
    .rate = 500000000,  /* ARM clock is set from the VideoCore booter */
#endif
};

/* warning - the USB needs a clock > 34MHz */

#ifdef CONFIG_MMC_BCM2708
static struct clk sdhost_clk = {
#ifdef CONFIG_ARCH_BCM2708_CHIPIT
    .rate = 4000000,    /* 4MHz */
#else
    .rate = 250000000,  /* 250MHz */
#endif
};
#endif

¿Tal vez lo que creo que he medido como 250Mhz es 270 y el ARM está a 500MHz?

EDIT2 ... DOH

Esa no fue una gran mejora en la tubería, mejor.

.globl ARMTEST3
ARMTEST3:
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    subs r0,r0,#1
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    bne ARMTEST3
    bx lr


    ARMTEST3
    0x01000000 sub instructions
    0x08000000 nop instructions
    0x00100000 bne instructions
    0x09100000 instructions
    037000D7 system clocks
    2.64 instructions per clock. 659Mips

Al principio no logré que config.txt funcionara, luego reconstruí una tarjeta sd de Linux, lo inicié para encontrar que el directorio / boot / es de hecho la partición "gorda" que contiene los archivos de inicio gpu y kernel.img. archivo. Así que NO en un boot / dir pero en el mismo directorio con el archivo .bin y .elf y .img crea config.txt y coloca arm_freq = something, el cargador de arranque gpu hace la modificación al multiplicador pll para que cuando el brazo comience está a esa velocidad. Todavía espero más de 700 millones de instrucciones por segundo y no estoy viendo eso, tendré que seguir intentando, supongo.

Answer 1

Puede valer la pena mirar el gestor de arranque provisto con la distribución de referencia de Arch Linux desde las páginas de descarga de la organización Raspberry Pi. No tengo idea si es una opción de trabajo, pero su config.txt incluye la línea

#arm_freq=800

También hay informes de personas que han overclockeado el Pi, por lo que la información sobre la inicialización del reloj está, sin duda, por ahí, en alguna parte.

Answer 2

Probablemente debido al hecho de que la Fundación Raspberry Pi se compone principalmente de empleados de Broadcom, han elegido un dispositivo Broadcom como CPU. Si bien esto significa que el RPi obtiene un ARM11 relativamente de alto rendimiento a un costo muy bajo, desafortunadamente Broadcom solo brinda detalles completos del chip a los licenciatarios, por lo que la información que necesita para configurar el PLL puede no estar disponible al público, y sospecho que incrustado en los binarios de "firmware" proporcionados por Broadcom.

Answer 3

No sé mucho sobre la programación bare metal, pero este código podría ser útil: https://github.com/dwelch67/raspberrypi

Es de destacar la parte del archivo léame que describe el orden de inicio:

1) arranca desde un chip rom de algún tipo
2) lee la tarjeta sd y busca archivos de arranque específicos de gpu adicionales bootcode.bin, loader.bin, start.elf en el directorio raíz de la primera partición (formato grueso)
3) en el mismo directorio busca config.txt que puede hacer cosas como cambiar la velocidad del brazo de 700MHz por defecto, cambiar la dirección donde cargar kernel.img, y muchos otros
4) lee kernel.img el archivo binario de arranque del brazo y lo copia en la memoria
5) libera el reinicio en el brazo de manera que se ejecute desde la dirección donde se escribieron los datos de kernel.img

Lo que significa que config.txt está separado del kernel de Linux y el chip establece la velocidad del reloj en sí misma (siempre que esta secuencia sea verdadera).

El código en ese repositorio puede ayudarte a responder tu pregunta.

Además, en el sitio web de Raspberry Pi, hicieron una publicación sobre el overclocking oficial: http://www.raspberrypi.org/archives/2008

Mencionan un controlador cpufreq al que debería poder acceder la fuente (ya que es parte del árbol fuente de Linux). Eso también podría ser útil.

Answer 4

Puede sintonizar su Raspberry Pi y cambiar, por ejemplo, la velocidad del reloj ARM y Ram / Video Ram. Un buen tutorial

Answer 5

Sé que esto fue preguntado y respondido hace un tiempo, pero encontré esta pregunta con la esperanza de obtener una respuesta rápida. En caso de que alguien más quiera saber, así es como lo arreglé para mi configuración de metal desnudo. Tuve éxito en el RPI3 al agregar

force_turbo = 1
arm_freq = 1200

Nuevamente, a pesar de que esto era puro metal, el firmware de la GPU lee el archivo config.txt antes de arrancar el ARM y cargar su código bare-metal (según tengo entendido). Encontré esto referenciado aquí . Tenga en cuenta que también traté de cambiar la frecuencia programáticamente, pero no pude encontrar una referencia (incluso busqué en el árbol fuente del kernel de Linux, pero soy un completo novato en el desarrollo del kernel).