-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
While thinking how to implement the resume without memory hole I came cross following piece of code in AMD CAR:
set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */
print_debug("Copying data from cache to RAM -- switching to use RAM as stack... ");
memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE);
But! the memory is WB too. Therefore the memcopy _must_ evict some L1 to where? Please note that this code is executed still with CAR enabled.
I answered this question using the Perf counters:
Dumping perf counters 00000000 <- Eviction of L2 to system memory (writebacks to system) 00001172 <- Eviction of data L1 to L2 of all previous states (MOESI) 00000b5f <- L1 Data Cache Refills from System 00000000 Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf counters II 00000000 0000120b 00000b6b 00000000
With bit of different counters:
Dumping perf counters 00000039 <- L2 fills from L1 000007e2 <- Eviction of data L1 to L2 of all previous states (MOES) - excluding invalid 00000d0f <- L1 Data Cache Refills from System (excluding invalid) 00000000 Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf counters II 00000143 0000080e 00000d1c 00000000
It clearly shows that L2 is used for this kind of things. Was this intended? The L2 I think contains also the cached ROM code... so situation is bit more complicated than one can expect.
The patch for this kind of analysis is attached if anyone is interested.
Oh btw I had to add some clobbers to the inline assembly or GCC will not thing the content of ECX has been changed by inline assembly...
Rudolf