[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?

   Russ




More information about the coreboot mailing list