[coreboot] [LinuxBIOS] Suspend to RAM with LinuxBIOSv2

[Carl-Daniel Hailfinger]

On 06.01.2008 19:06, Rudolf Marek wrote:
> 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.
>   

With wakeup.c moved to a generic x86 location, the patch is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

We can't afford to lose that code.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/