question about post_cache_as_ram() function

[Fengwei Zhang]

Hi all,

I am trying to understand how post_cache_as_ram() function works. As we 
know, there are two main parts of coreboot, which are cache_as_ram part 
and ram part. post_caches_as_ram function tries to copy data from 
cache_as_ram to ram.

I am very confused about the memory calculation such as
CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE - CONFIG_RAMTOP

I would appreciate if someone could explain a little bit for me.
CONFIG_DCACHE_RAM_BASE
CONFIG_DCACHE_RAM_SIZE
CONFIG_RAM_SIZE
CONFIG_RAMTOP

In addition, why do we need to set new esp here?
    	/* set new esp */ /* before CONFIG_RAMBASE */
    	"subl   %0, %%esp\n\t"
    	::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)- 
(CONFIG_RAMTOP) )

Best,
Fengwei

[Patrick Georgi]

Am Freitag, 17. Dezember 2010, um 15:08:38 schrieb Fengwei Zhang:
> I would appreciate if someone could explain a little bit for me.
> CONFIG_DCACHE_RAM_BASE
> CONFIG_DCACHE_RAM_SIZE
> CONFIG_RAMTOP

DCACHE_RAM_BASE is the start address of the memory addresses that are used for 
CAR.

DCACHE_RAM_SIZE is the size of that region.

RAMTOP is the highest address of the memory region that coreboot will use in 
RAM.
> In addition, why do we need to set new esp here?
>    	/* set new esp */ /* before CONFIG_RAMBASE */
>    	"subl   %0, %%esp\n\t"
> ::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)-
>
> (CONFIG_RAMTOP) )

This moves the stack from CAR area to RAM.

While in CAR, the stack is laid out at the top end of CAR, growing downwards 
(ie. starting at DCACHE_RAM_BASE + DCACHE_RAM_SIZE).
While in RAM, it starts at the top end of the ram area used for coreboot 
(RAMTOP).

Before that line the stack is copied from CAR to RAM, then esp is setup so it 
points to the same place in RAM that it pointed to in CAR (that's why we use 
sub, not mov).
This setup doesn't allow returning from the current function (we don't adjust 
addresses on the stack), but it makes sure that local variables in the scope 
of the current function are still usable.

Hope this helps,
Patrick

[Stefan Reinauer]

Can we automatically determine the value of RAMTOP during build time?

On 17.12.2010, at 12:29, Patrick Georgi  wrote:
> Am Freitag, 17. Dezember 2010, um 15:08:38 schrieb Fengwei Zhang:
> > I would appreciate if someone could explain a little bit for me.
> > CONFIG_DCACHE_RAM_BASE
> > CONFIG_DCACHE_RAM_SIZE
> > CONFIG_RAMTOP
>
> DCACHE_RAM_BASE is the start address of the memory addresses that are used for 
> CAR.
>
> DCACHE_RAM_SIZE is the size of that region.
>
> RAMTOP is the highest address of the memory region that coreboot will use in 
> RAM.
> > In addition, why do we need to set new esp here?
> >        /* set new esp */ /* before CONFIG_RAMBASE */
> >        "subl   %0, %%esp\n\t"
> >    ::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)-
> >
> > (CONFIG_RAMTOP) )
>
> This moves the stack from CAR area to RAM.
>
> While in CAR, the stack is laid out at the top end of CAR, growing downwards 
> (ie. starting at DCACHE_RAM_BASE + DCACHE_RAM_SIZE).
> While in RAM, it starts at the top end of the ram area used for coreboot 
> (RAMTOP).
>
> Before that line the stack is copied from CAR to RAM, then esp is setup so it 
> points to the same place in RAM that it pointed to in CAR (that's why we use 
> sub, not mov).
> This setup doesn't allow returning from the current function (we don't adjust 
> addresses on the stack), but it makes sure that local variables in the scope 
> of the current function are still usable.
>
> Hope this helps,
> Patrick

[Myles Watson]

On Fri, Dec 17, 2010 at 1:50 PM, Stefan Reinauer
 wrote:
> Can we automatically determine the value of RAMTOP during build time?

Yes.  It's a config variable.  It's not the top of physical RAM, it's
the top of what coreboot will use.

Thanks,
Myles
> On 17.12.2010, at 12:29, Patrick Georgi  wrote:
> > RAMTOP is the highest address of the memory region that coreboot will use in
> > RAM.

[Stefan Reinauer]

* Myles Watson  [101217 22:01]:
> On Fri, Dec 17, 2010 at 1:50 PM, Stefan Reinauer
>  wrote:
> > Can we automatically determine the value of RAMTOP during build time?
>
> Yes.  It's a config variable.  It's not the top of physical RAM, it's
> the top of what coreboot will use.

I know.. I was thinking along the line of not having it configured but
calculated to the size we actually need rather than making up to the
user/developer to choose a much too large value that gets copy&wasted
around for the next 25 chipsets we're going to implement.

Stefan

[Myles Watson]

On Fri, Dec 17, 2010 at 2:03 PM, Stefan Reinauer  wrote:
> Myles Watson  [101217 22:01]:
> > On Fri, Dec 17, 2010 at 1:50 PM, Stefan Reinauer
> >  wrote:
> > > Can we automatically determine the value of RAMTOP during build time?
> >
> > Yes.  It's a config variable.  It's not the top of physical RAM, it's
> > the top of what coreboot will use.
>
> I know..

Sorry :)
> I was thinking along the line of not having it configured but
> calculated to the size we actually need rather than making up to the
> user/developer to choose a much too large value that gets copy&wasted
> around for the next 25 chipsets we're going to implement.

So can we determine the "right" value of RAMTOP?

I think the only unknown is stack usage.  Actually, I guess you could
calculate it right now, since stack size is a parameter.  Something
like code + data + stack + padding to make it an even amount = RAMTOP.

Thanks,
Myles