[coreboot] question on disable_cache_as_ram() function.

Russell Whitaker russ at ashlandhome.net
Wed Dec 22 05:04:11 CET 2010

On Wed, 22 Dec 2010, Stefan Reinauer wrote:

> * Fengwei Zhang <namedylan at gmail.com> [101222 00:31]:
>> Hi all,
>> I have tested S3 on board m2v-mx_se. it works. But if I put two DDR2
>> on board, it would die at post_cache_as_ram. it because stack
>> variable resume_backup_memory changed its value to 0xffffffff after
>> invoking disable_cache_as_ram_bsp(). I am trying to fix this. but I
>> got some question about the whole picture of disable_cache_as_ram().
>> I am also not quite understand why we need backup_resume() function
>> in post_cache_as_ram(). I thought all previous state info are saved
>> at RAM after S3 sleep. When we are doing wakeup, we just need to
>> copy current information from cache_as_ram to RAM at
>> post_cache_as_ram() function, right? Why do we need to do
>> backup_resume() at this point(it is still at cache_as_ram step)?
> backup_resume copies some memory into a safe place because it will be
> overwritten by copying coreboot to memory. After coreboot's device
> allocation is done, that memory will be copied back. We do this to
> prevent memory corruption through overwriting OS memory with coreboot.
> We could get rid of those two copies by setting up a non 1:1
> virtual/physical mapping and copy coreboot to the end of physical
> memory, running with virtual adressing. However, that would require us
> to modify each and every driver that accesses memory mapped devices to
> use phys_to_virt()
What if you copied coreboot to the end of physical memory and then told
the OS that physical memory ends just below coreboot?


More information about the coreboot mailing list