[coreboot] AMD CAR questions

[Rudolf Marek]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktQ4V0ACgkQ3J9wPJqZRNWiCACgy6jnD7m0yaj/oEjIUrdbYVkR
B3wAoOEE0t34Nkar21c+Am2PQq9DXcqm
=/D4r
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: perf.patch
Type: text/x-diff
Size: 3630 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100115/7007eaa6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: perf.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100115/7007eaa6/attachment.obj>