arm bootloader mmu

ARM Bootloader: deshabilita MMU y cachés



(2)

La última pregunta es ¿por qué D-cache está deshabilitado pero I-caches es capaz? Para acelerar el proceso del instrumento?

La MMU tiene configuraciones para determinar qué regiones de memoria son almacenables o no. Si no tiene el mmu encendido pero tiene el caché de datos activado (si es posible), entonces no puede hablar de manera segura con los periféricos. si lee el registro de estado uart, por ejemplo, pasa por el caché como cualquier otra operación de datos, cualquiera que sea el estado permanece en el caché para lecturas posteriores hasta el momento en que se expulsa esa línea de caché y obtiene una captura más en el real registro. Digamos, por ejemplo, que tiene un código que sondea el registro de estado de espera esperando un carácter en el buffer de rx. Si esa primera lectura muestra que no hay un carácter, ese estado va en la caché, usted permanecerá en el ciclo para siempre, ya que nunca podrá volver a hablar con el registro de estado; simplemente obtendrá la copia en caché del registro. si había un personaje allí, entonces ese estado también se almacena en caché, usted lee el registro rx, y tal vez haga algo, si cuando vuelve nuevamente si el estado no ha sido desalojado de la memoria caché de datos, entonces obtiene el estado obsoleto que muestra hay un caracter, su lectura de buffer rx puede o no almacenarse en caché para que pueda obtener el valor obsoleto en la memoria caché, puede obtener un valor obsoleto o lo que sea que haga el periférico al leer y no hay un nuevo valor o puede que sea Obtenga un nuevo valor, pero lo que no obtiene en estas situaciones es un acceso adecuado al periférico. Cuando el mmu está activado, utiliza el mmu para marcar el espacio de direcciones utilizado por ese periférico como no cachable (de datos), y no tiene este problema. Con el mmu apagado, necesita la memoria caché de datos para los sistemas de brazos.

Dejar el I-cache encendido está bien porque la instrucción solo busca instrucciones de lectura ... Bueno, para una aplicación bare metal que está bien, ayuda por ejemplo si está usando un flash que tiene un potencial para leer molestar (flashes spi o i2c) . El problema es que esta aplicación es un gestor de arranque, por lo que debes tener un cuidado extra. Por ejemplo, su gestor de arranque tiene algún código en la dirección 0x8000 que se ejecuta al menos una vez, luego elige usarlo como gestor de arranque, el gestor de arranque puede estar en dicha dirección 0x10000000, lo que le permite cargar un nuevo programa en 0x8000, esta carga utiliza datos accede por lo que no pasa por la memoria caché de instrucciones. Por lo tanto, existe la posibilidad de que el caché de instrucciones contenga parte o la totalidad del código de la última vez que estuvo en el área 0x8000, y cuando se ramifica al código de carga en 0x8000 obtendrá el viejo programa de caché o una desagradable mezcla del programa anterior y el nuevo programa para las partes que se almacenan en caché y no en caché. Entonces, si su gestor de arranque permite que la i-caché esté activada, debe invalidar la memoria caché antes de ramificarla en el código de arranque.

Por último, si usted o alguien que usa este gestor de arranque quiere usar jtag, entonces tiene el mismo problema, pero lo que es peor, los ciclos de datos que no pasan por i-cache se utilizan para escribir el nuevo programa en ram, cuando le dice al jtag depurador para ejecutar el nuevo programa, obtendrá 1) solo el nuevo programa, 2) una mezcla del nuevo programa y los viejos fragmentos del programa de la memoria caché 3) el programa anterior de la memoria caché.

Así que d-cache es malo sin un mmu debido a cosas que no están en ram, periféricos, etc. El i-cache es un uso bajo su propio riesgo que usted puede mitigar a excepción de los tiempos que jtag se usa para la depuración .

Si tiene inquietudes o ha confirmado la alteración de la lectura en su flash (externo), le recomiendo que active el i-cache, use un bucle cerrado para copiar su aplicación al ram, bifurque a la copia RAM y ejecute allí, apague el i-caché (o use bajo su propio riesgo) y no toque el flash nuevamente, ciertamente no tiene acceso de lectura pesado a áreas pequeñas. Un circuito de votación estrecha como el que podría tener para un analizador de línea de comando, es un muy buen lugar para ser golpeado con lectura molesta.

De acuerdo con algunos tutoriales, deshabilitaremos MMU y I / D-Cachés al comienzo del bootlaoder. Si lo entiendo correctamente, apunta a usar la dirección física directamente en el programa, así que por favor corrígeme si me equivoco. ¡Gracias!

En segundo lugar, hacemos esto para desactivar MMU y cachés:

mrc P15, 0, R0, C1, C0, 0

bic R0, R0, # 0x00002300 @ bits claros 13, 9: 8

bic R0, R0, # 0x00000087 @ clear bits 7, 2: 0

orr R0, R0, # 0x00000002 @ set bit 2 (A) Align

orr R0, R0, # 0x00001000 @ set bit 12 (I) I-Cache

mcr P15, 0, R0, C1, C0, 0

D-Cache, MMU y Data Address Alignment Fault Checking se han desactivado con los bits de borrado 2: 0, pero ¿por qué activamos el bit 2 inmediatamente en el siguiente instrumento? Para asegurarse de que esta manipulación sea válida?

La última pregunta es ¿por qué D-cache está deshabilitado pero I-caches es capaz? Para acelerar el proceso del instrumento?


No especificó en qué ARM está trabajando. Las capacidades pueden variar de un ARM a otro (hay una gran brecha entre un ARM9 y un ARM Cortex A15).

En el código dado, el bit 2 se borra y luego se establece, pero no importa, ya que esos cambios se realizan en R0. No hay cambios en el comportamiento de ARM hasta que el registro de escritura en CP15 (hecho por la instrucción mcr P15, 0, R0, C1, C0, 0 ).

Con respecto a la habilitación de d-caché / i-cache, solo es una cuestión de elección, no hay ningún requisito. En los productos en los que trabajo, el gestor de arranque habilita L1 I-cache, D-cache, L2 cache y MMU (y desactiva todo eso antes de saltar sobre Linux). Asegúrese de seguir la documentación de ARM sobre la invalidación de caché y las barreras de memoria (de acuerdo con su núcleo ARM real) si utiliza caché y MMU en su gestor de arranque.