0

在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
4

3 回答 3

1

重置可能是硬的或软的。某些东西可能会跳转到重置向量。如果缓存启用了陈旧的条目，代码可能会崩溃，导致系统无法启动。这可能比您想象的更常见，因为 SDRAM 可能会在冷开机和误读导致崩溃后失去行为。通常，看门狗或不可恢复的故障会跳转到复位向量。最后，XIP NOR 闪存中可能还有u-boot系统。某些系统/代码可能只是跳转到此代码以执行软重置。

在所有这些情况下，可用的调试都是NIL。在 99.9999% 的情况下，您可能有一个工作系统。必须对仅在热吧或冰淇淋冷冻机中发生的特定硬件的启动故障进行故障排除可能会让您喜欢这个额外的代码。即，在极少数情况下需要它。

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

于 2014-01-14T15:27:56.003 回答
0

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

于 2014-01-20T10:23:00.943 回答
0

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

于 2014-01-14T14:43:03.803 回答