[coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

[Rudolf Marek]

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

Hi Stefan,


>> 1) is 0x600 as base for lowmem trampoline safe? it always makes me
>> wonder, this
>> was the reason why I did the realmode code which runs above 1MB ;)
>> Maybe we can
>> have that too and only copy the trampoline to the highmem save area
>> and execute
>> it there. This would mean all memory bellow 1MB is untouched.
> 
> It should be safe. The lower 4kb are supposed to be untouched by the OS,
> according to some information I found, including an old mail of yours on
> S3 Resume.

Aha, I think we could rework this and have the trampoline in CBMEM, because the
trick to run realmode code over 1MB would work too.


> 
>> 2)
> Since I only use the value in auto.c I did not put this into a one line
> function called externally. If that is what you suggest, we can easily
> do that, though.

Yes this is just for code to look same...


>> 3) I think your SMM code corrupts lowmem, or I have not seen any
>> backup of that
>> mem? Maybe I'm wrong?

> No, that is true... 0x38000 + size of SMM relocator is wiped out.

OK ;)


>> 4) Changes to the stack
>>
> 
> What patch are you referring to?

Well I think the previous one for CBMEM if I recall correctly or the ICH7
updates stuff.

>> 5) Don't understand much the cbmem_reinit((u64)high_ram_base)) in CAR

> Very ugly. Maybe we can fix the K8M890 resource code? What factors
> influence the high_ram_base on that chipset? How early can we determine
> them?

Yes I tried to fixed it with separate patch.

>> Except some hacks like make the cbmem look like some
>> proprietary ACPI table and walk acpi tables as for we do for resume
>> but in car
>> stage just to find out where the tables are...

> Speaking of hacks, we could remember the CBMEM base address in the low
> 4KB so we can find them again...

Yes I tried that I used 0:4F0 for the PRT which is some 'user data area'. I'm
having trouble with CBMEM refusing me to create the ACPI RESUME table. However
the bits I have rewritten to use the 0:4F0 trampoline are OK.

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

iEYEARECAAYFAkroxGYACgkQ3J9wPJqZRNVO5wCeKH96JfOLZep/VEmLnGl4S6Tk
aCMAnA/C/qXvGo/qiBPFwe1qeS3rY//y
=25u2
-----END PGP SIGNATURE-----