On Wed, Jun 17, 2015 at 05:31:30PM -0500, Dinh Nguyen wrote: > Also, I am not seeing the error on the SoCFPGA Arria 10 platform at all. > This Arria10 platform is running a different version of bootloader than > the Cyclone5. Although, I also did test with the latest version of > U-Boot on the Cyclone5. It _shouldn't_ cause any issue, unless secondary_startup is called with caches already enabled (which it shouldn't.) If caches are enabled, that's incredibly dodgy even with the old code - cache lines could be migrated to the incoming CPU which v7_invalidate_l1() would then invalidate, resulting in the loss of data in those migrated cache lines. If caches are not enabled, this change should have no effect: caches should not be searched if the C bit is clear, and we still end up invalidating the local L1 cache later in the normal boot sequence. (If caches are searched with the C bit clear, and the caches initialise in an unpredictable state, the ARM ARM requires an implementation specific routine to be executed immediately on CPU startup. The idea is that if this option were to be chosen, the vendor must guarantee a certain code sequence can't be disrupted by the uninitialised state in the caches, which, if you're searching the caches for instruction fetches, is pretty much impossible to guarantee no matter what kind of code sequence you specify: even the first instruction fetched from the CPU reset vector could ultimately be sourced from the instruction cache if the i-cache reports that it thinks it has valid data.) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
