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