I'm seeing code reads to memset() in coreboot_ram interleaved with byte writes to somewhere high on the stack (_estack -0x1fC). This is a k8.
I can't find the place during the RAM stage when we are calling memset with caches disabled. Does this ring a bell for anyone?
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maybe you can run under SimNow and use a memory access breakpoint?
Rudolf
Maybe you can run under SimNow and use a memory access breakpoint?
Good idea. How do you tell in SimNow if an access is cached or not?
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Myles Watson wrote:
Maybe you can run under SimNow and use a memory access breakpoint?
Good idea. How do you tell in SimNow if an access is cached or not?
Dont know maybe you can check CPU state after a breakpoint?
Rudolf
Thanks, Myles
On Tue, Apr 06, 2010 at 04:21:57PM -0600, Myles Watson wrote:
I'm seeing code reads to memset() in coreboot_ram interleaved with byte writes to somewhere high on the stack (_estack -0x1fC). This is a k8.
I can't find the place during the RAM stage when we are calling memset with caches disabled. Does this ring a bell for anyone?
Probably not related, but I found the code at src/arch/i386/init/crt0.S.lb: movl %ebp, %esi /* FIXME: look for a proper place for the stack */ movl $0x4000000, %esp movl %esp, %ebp pushl %esi pushl $str_coreboot_ram_name call cbfs_and_run_core
to be problematic on my epia-cn back when I was running timing tests. The stack was set to 0x4000000, but that memory wasn't cached. It caused a really long delay - doubly so when lzma compression was used.
-Kevin
On Tue, Apr 06, 2010 at 04:21:57PM -0600, Myles Watson wrote:
I'm seeing code reads to memset() in coreboot_ram interleaved with byte writes to somewhere high on the stack (_estack -0x1fC). This is a k8.
I can't find the place during the RAM stage when we are calling memset
with
caches disabled. Does this ring a bell for anyone?
Probably not related, but I found the code at src/arch/i386/init/crt0.S.lb: movl %ebp, %esi /* FIXME: look for a proper place for the stack */ movl $0x4000000, %esp movl %esp, %ebp pushl %esi pushl $str_coreboot_ram_name call cbfs_and_run_core
to be problematic on my epia-cn back when I was running timing tests. The stack was set to 0x4000000, but that memory wasn't cached. It caused a really long delay - doubly so when lzma compression was used.
It isn't the same address range, but thanks for reminding us.
All:
Does this interfere with suspend/resume? Is there a ticket already created for this? It looks like something that would be hard to debug in system.
Thanks, Myles
Does this interfere with suspend/resume? Is there a ticket already created for this? It looks like something that would be hard to debug in system.
It does, but I ignore that because I think this code is not used when CAR is used?
Rudolf
On 4/9/10 12:47 PM, Rudolf Marek wrote:
Does this interfere with suspend/resume? Is there a ticket already created for this? It looks like something that would be hard to debug in system.
It does, but I ignore that because I think this code is not used when CAR is used?
On intel core / core 2 we use CONFIG_RAMBASE + HIGH_MEMORY_SAFE for the stack, so it lives in the area we are backing up (and thus are allowed to overwrite)
This needs much cleanup but check src/cpu/intel/model_6ex/cache_as_ram_disable.c
Stefan
On Tue, Apr 6, 2010 at 4:21 PM, Myles Watson mylesgw@gmail.com wrote:
I'm seeing code reads to memset() in coreboot_ram interleaved with byte writes to somewhere high on the stack (_estack -0x1fC). This is a k8.
It turns out init_processor_name() was being called with the cache disabled. It doesn't look like it needs to be. Boot tested on my box. This makes it more similar to model_10.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
-
Kevin O'Connor -
Myles Watson -
Rudolf Marek -
Stefan Reinauer