-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Stefan,
- 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.
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...
- 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 ;)
- 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.
- 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