[LinuxBIOS] Suspend to RAM with LinuxBIOSv2

[Rudolf Marek]

Hi,

> this is wonderful! Thank you very much for your work!

Yeah I'm happy that it works too. It costs me lot of time and I would rather win 
then lose ;) I'm taking this as broading up my know-how. It goes well because I 
got nearly all datasheets for all chips on the board except the marvel gigabit 
controller. I have in plan to add overclocking options, because I know how they 
work on this board - its on wiki now.

>> 1) consolidate the memory usage of LinuxBIOSv2
> What needs to be done here?

Well I think secondary CPUS (APs) are started by some code (secondary.S) Which 
is loaded to some location.Plus for example all memory from 0K-1M is clean etc 
etc. For S3 we cant act "as an elephant in the  pottery"

>> 2) dont clean arbitrary memory
> 
> This should at least be the case when waking up from S3.

Well we should just clean our heap, without the purge, resource management gets 
hoosed for some reason. We should not touch all the memory, only to defined regions.

We are missing the "reserved" memory infrastructure in LB. For the mmconfig and 
also for S3 we should pass via LB tables parts of memory which are reserved, and 
then build e820 based map on in in filo/grub.

> 
>> Perhaps we could reserve last 1MB of RAM or something after 8MB of mem and put
>> linuxBIOS heap there when using S3 we would just reserve the region + (some
>> region bellow the 1MB for AP CPU boot + ACPI tables etc)
>  
> Sounds reasonable. How do others do this?

Award is reserving last 1MB of memory for its SMM/resume handler. LB is not 
relocatable, and ACPI specs says reserved memory can start at 8MB.

Or we can try to put all linuxbios and its heap to A0000-FFFFF if we want to 
support the S3. (we can switch on VGA when we are done with heap). My system has 
fairly lot of devices, so I need lot of heap memory. I can try to measure how 
much actually (I'm using 256K now). I dont know if 384KB is enough for all the 
code. Maybe we can just move everything to 1MB somewhere in system RAM, but 
question is if APs can be started on 1MB above (this needs to be checked)

>> The patch has some errata update of code too, I will publish this as separate
>> patch - I did it because I thought I got still some memory related problem.
>  
> Thank you.

I will try to publish it in near future.
> 
> How nice ACPI _can_ be :)

Well some parts still missing and ACPI core in Linux is bit complaining:

sd 0:0:0:0: [sda] Stopping disk
ACPI: PCI interrupt for device 0000:06:00.0 disabled
sky2 eth0: disabling interface
ACPI handle has no context!
ACPI handle has no context!
ACPI: PCI interrupt for device 0000:00:11.5 disabled
ACPI handle has no context!
ACPI: PCI interrupt for device 0000:00:10.4 disabled
ACPI: PCI interrupt for device 0000:00:10.3 disabled
ACPI: PCI interrupt for device 0000:00:10.2 disabled
ACPI: PCI interrupt for device 0000:00:10.1 disabled
ACPI: PCI interrupt for device 0000:00:10.0 disabled
ACPI: PCI interrupt for device 0000:00:0f.1 disabled
ACPI: PCI interrupt for device 0000:00:0f.0 disabled
ACPI handle has no context!
pci_set_power_state(): 0000:00:00.0: state=3, current state=5
Disabling non-boot CPUs ...

But it works fine. The difference between full off and S3 is just one Watt ;)
so everything is shut off. For specific wakeups some ACPI AML code should be 
added. I'm waking up system with power button.


> 
>> Index: src/mainboard/asus/a8v-e_se/wakeup.c
>> ===================================================================
>> --- src/mainboard/asus/a8v-e_se/wakeup.c	(revision 0)
>> +++ src/mainboard/asus/a8v-e_se/wakeup.c	(revision 0)
>> @@ -0,0 +1,267 @@
>> +//reboot.c from linux
>> +
>> +#include <stdint.h>
>> +#include <string.h>
>> +#include <arch/io.h>
>> +#include <console/console.h>
>> +
> 
> [..]
> 
> A quick glimpse tells me that wakeup.c is mostly x86 generic code. We
> should put it somewhere else.

Yeah, that patch is quite experimental so I put it to that dir. Better layout of 
systems calls needs to be proposed/implemented.

Rudolf