Arm 为什么uboot在开始时使TLB s、icache、BP数组无效

在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

---

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

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

在所有这些情况下，可用的调试为零。在99.9999%的情况下，您可能有一个工作系统。在特定的硬件上排除开机故障（只发生在热酒吧或冰激凌冰箱中）可能会让您享受这段额外的代码。也就是说，很少有需要的情况

---

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

如果重置时没有在硬件中执行失效（冷或热），则这是必要的。另一个更实际的原因是U-Boot通常不是在硬件上运行的第一段代码。在大多数情况下，在U-Boot之前会有运行的ROM代码，为了避免在U-Boot控制系统时对硬件状态做出任何假设，更安全的做法是始终尝试将硬件恢复到已知状态并从那里继续