[coreboot] [PATCH] Fix the NULL dev resource usage

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

During the suspend/resume programming I came to an issue that first 4KB of
memory must be clear with 0s because otherwise the resources of K8 will be
totally messed up.

It took long to figure it out and here it is:

res = probe_resource(dev, 0x100 + (reg | link));

This is called with dev = NULL and this is no good for probe_resource at all.
The attached patch fixes the potential problems and of course the problem
itself. On one particular place was missing test if the device really exists.
This was copied to fam10 and perhaps the same issue is in v3 (DID NOT check).
The rest of the patch is just very paranoid and do all checkings.

This was tested in SimNOW but I believe it will work on real hw too.

Signed-off-by: Rudolf Marek <r.marek at assembler.cz>

Anyone knows if SimNOW can do breaks on memory ranges?

Because it was quite stupid to get to the bug. When the resources just worked
again I used data breakpoint to see what routine it is. Problem was that I
needed to find the address where it stop to work.

Maybe we really should allow writes to mem only in _RAMBASE - MEMTOPK range (of
course with some exception for table stuff).

- --- src/cpu/amd/car/clear_init_ram.c<-->(revision 4026)
+++ src/cpu/amd/car/clear_init_ram.c<-->(working copy)
@@ -6,7 +6,23 @@
 <----->// gcc 3.4.5 will inline the copy_and_run and clear_init_ram in
post_cache_as_ram
 <----->// will reuse %edi as 0 from clear_memory for copy_and_run part,
actually it is increased already
 <----->// so noline clear_init_ram
- -        clear_memory(0,  ((CONFIG_LB_MEM_TOPK<<10) - DCACHE_RAM_SIZE));
+        clear_memory(_RAMBASE,  ((CONFIG_LB_MEM_TOPK<<10) -_RAMBASE -
DCACHE_RAM_SIZE));
+<----->//512 NOT OK - I previously though this works so I need to test MORE :/
+<----->//256 NOT OK
+<----->//384 NOT OK
+<----->//448 NOT OK
+<----->//480 NOT OK
+<----->//496 NOT OK
+<----->//504 NOT OK
+<----->//508 NOT OK
+<----->// 768 NOT OK
+<----->//896 NOT OK
+<----->//960 OK
+<----->//928 OK
+<----->//912 NOT OK
+<----->//920 NOT OK
+<----->//924 OK
+        clear_memory(0, 924);
.

Oh btw the suspend/resume works, but the code needs to be fixed on some places.
There is a  copy_secondary_start_to_1m_below which just uses first 64KB of mem
for some reason - I dont understand why it cannot be realocable to something
different addr. Please check and tell.

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknKdOAACgkQ3J9wPJqZRNXabQCdFRWA4pYWDuY+VDyFROATejRC
oDcAn02iYJM4fivIzcpJlQ/D9Qu4DFYE
=dtVh
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_null_devs.patch
Type: text/x-diff
Size: 3516 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090325/1b7bdb5f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_null_devs.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090325/1b7bdb5f/attachment.obj>