question on disable_cache_as_ram() function.

[Fengwei Zhang]

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

Thanks!

Best,
Fengwei

[Stefan Reinauer]

* Fengwei Zhang  [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()

Stefan

[Russell Whitaker]

On Wed, 22 Dec 2010, Stefan Reinauer wrote:
> Fengwei Zhang  [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

[Stefan Reinauer]

On 12/21/10 8:04 PM, Russell Whitaker wrote:
> On Wed, 22 Dec 2010, Stefan Reinauer wrote:
> > Fengwei Zhang  [101222 00:31]:
> >
> > 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?

That would be the plan. However, GCC will not produce code that is 
position independent enough to do this without special mappings.

Stefan

[Rudolf Marek]

Hi,

This looks more like some memory related problem - when exiting the self 
refresh. Check if you find some errata which might cause this.

Also check if DQS settings are stored / loaded correctly.

Thanks,
Rudolf