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

[Stefan Reinauer]

Rudolf Marek wrote:
> Hi,
>
> I have some questions:
>
> 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.

> 2)
>
> You seem to follow different way how to detect S3.
>
Not sure I can follow. I didn't change that part of your code

> I had in the code for all boards (like memory controller init)
>
> ifdef ACPI_IS_WAKEUP_EARLY
> <------>int suspend = acpi_is_wakeup_early();
> #else
> <------>int suspend = 0;
> #endif
>
>
> And for per chipset CAR code  I defined a function which is doing it:
>
> define ACPI_IS_WAKEUP_EARLY 1
>
> int acpi_is_wakeup_early(void) {
> device_t dev;
> u16 tmp;
> print_debug("IN TEST WAKEUP\n");
> ...
>
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.

> And for the normal ram stage there is:
>
> /* this is to be filled by SB code - startup value what was found */
>
> u8 acpi_slp_type = 0;
>
> int acpi_is_wakeup(void)
> {
> <------>return (acpi_slp_type == 3);
> }
>
> Which is backup what was the sleep type. I think this is how you deal
> with that
> using the scratchpads.

Yes, I am using your mechanism here. But since it's not safe to leave
the value in PM1_CNT (at least on i945), I had to move it somewhere
else. SKPAD seemed like a good place to get it over to stage 2.


>
> 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.


> 4) Changes to the stack
>
> I think you changed the stack to some other place, not sure how to
> change that
> for K8 CAR? Also there is an remaining issue if CAR gets flushed to
> memory or
> not. I think Carl-Daniel had some patch for this.

On i945 the cache as ram area is not backed by RAM, so the copy trickery
from K8 does not work here.

Stack setup is more than fishy on most platforms, but that's pretty
unrelated to my ACPI resume patch.

What patch are you referring to?

> 5) Don't understand much the cbmem_reinit((u64)high_ram_base)) in CAR
> code, you
> seem to take the TOM from PCI reg but this gets more complicated for
> UMA, I dont
> know how to do that for K8. Partially because the high_ram_base gets
> dynamically
>  lowered in K8M890 resource code :/ In other words there is no easy
> way for me
> to find it in memory.
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?

> 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...



Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866