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 <[EMAIL PROTECTED]> We can't afford to lose that code. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
