为什么uboot在开始时无效TLB，icache，BP数组

Question

在arm平台上，u-boot将在开始时使TLB，icache和BP阵列无效，但是这是什么原因？有必要吗？

cpu_init_crit:
/*
 * Invalidate L1 I/D
 */
mov r0, #0          @ set up for MCR
mcr p15, 0, r0, c8, c7, 0   @ invalidate TLBs
mcr p15, 0, r0, c7, c5, 0   @ invalidate icache
mcr p15, 0, r0, c7, c5, 6   @ invalidate BP array
mcr     p15, 0, r0, c7, c10, 4  @ DSB
mcr     p15, 0, r0, c7, c5, 4   @ ISB

Answer 1

重置可能很难或很软。某些东西可能会跳转到重置向量。如果使用过时条目启用高速缓存，则代码可能会崩溃，从而导致系统无法引导。这可能比您想象的更常见，因为SDRAM可能会在冷启动和错误读取导致崩溃后失效。看门狗或不可恢复的故障通常会跳转到复位向量。最后，在XIP NOR闪存中可能有 u-boot 系统。某些系统/代码可能只是跳转到此代码以执行软复位。

在所有这些情况下， debug 可用 NIL 。在99.9999％的情况下，您可能有一个工作系统。不得不在特殊硬件上拍摄引导故障，这些硬件只发生在热棒或冰淇淋冷冻柜中，这可能会让您享受这些额外的代码。即，在极少数情况下需要它。

随着电源轨的上线，硬件故障更为常见。数据表描述了在范围内具有功率/温度等的正确行为系统。 u-boot 可能无法在这个理想的世界中运行。如果您关注的是启动时间，那么编写自己的加载程序（尽管保留此代码）或优化BSS清理等事情会更好。

Answer 2

在A15 / A7 / A12上，您不需要在重置后执行缓存/ mmu / btb失效，因此这只是出于“偏执”的原因。但是，可能存在在重置时不执行自动无效的内核，因此此代码只是确保在不同的内核类型中保留相同的行为。

Answer 3

在复位（冷或暖）中未在硬件中进行无效的情况下，这是必要的。另一个更实际的原因是U-Boot通常不是在硬件上运行的第一段代码。在大多数情况下，会有在U-Boot之前运行的ROM代码，并且为了避免在U-Boot控制系统时对硬件状态做出任何假设，总是尝试将硬件置于已知状态并且更安全。从那里开始。