[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[Shawn Jin]

Hi,

Before board_init_f() is called, which is C code, a stack must be set
up. The stack is usually set up in internal SRAM. Where shall I put
stack in if I don't have an internal SRAM?

I read through cpu/ppc4xx/start.S and found some set up the temporary
stack in DCACHE (Walnut 405 is an example). But the CFG_INIT_RAM_ADDR
is 0x40000000, which is inside SDRAM. Why was it commented that the
stack was set in DCACHE? I don't quite understand how a cache acts
like RAM, i.e., a cache can be accessed by address xxxx_xxxx. Is a
cache only accessible by special cache instructions? The following
code is extracted from ppc4xx/start.S

#ifdef CFG_INIT_DCACHE_CS
	/*----------------------------------------------------------------------- */
	/* Memory Bank x (nothingness) initialization 1GB+64MEG */
	/* used as temporary stack pointer for stage0  */
	/*----------------------------------------------------------------------- */
	li	r4,PBxAP
	mtdcr	ebccfga,r4
	lis	r4,0x0380
	ori	r4,r4,0x0480
	mtdcr	ebccfgd,r4

	addi	r4,0,PBxCR
	mtdcr	ebccfga,r4
	lis	r4,0x400D
	ori	r4,r4,0xa000
	mtdcr	ebccfgd,r4

	/* turn on data chache for this region */
	lis	r4,0x0080
	mtdccr	r4

Thanks,
-Shawn.

[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[Wolfgang Denk]

Dear Shawn,

in message <c3d0340b05022510425a57a1a1@mail.gmail.com> you wrote:
> 
> Before board_init_f() is called, which is C code, a stack must be set
> up. The stack is usually set up in internal SRAM. Where shall I put
> stack in if I don't have an internal SRAM?

Which part of section "Initial Stack,  Global  Data"  in  the  README
don't you understand?

> I read through cpu/ppc4xx/start.S and found some set up the temporary
> stack in DCACHE (Walnut 405 is an example). But the CFG_INIT_RAM_ADDR
> is 0x40000000, which is inside SDRAM. Why was it commented that the

No, this is not inside SDRAM. There is no board (yet) with  1  GB  of
RAM.

> stack was set in DCACHE? I don't quite understand how a cache acts

Because the stack is in the data cache.

> like RAM, i.e., a cache can be accessed by address xxxx_xxxx. Is a
> cache only accessible by special cache instructions? The following

I'm afraid that explaining the basic operations of  cache  is  beyond
the topics for this mailing list.

In short: cache is like normal memory, just very fast (which does not
play a role here). We just have to make sure that no cache  fills  or
cache  flushes  will  be done (at least not for that part of the data
cache which is being used for the initial stack).

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
	-- Kirk, "The Squire of Gothos", stardate 2124.5

[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[Shawn Jin]

Dear Wolfgang,

> Which part of section "Initial Stack,  Global  Data"  in  the  README
> don't you understand?

Thanks for pointing out the section. I didn't read it through before. :(

> > stack in DCACHE (Walnut 405 is an example). But the CFG_INIT_RAM_ADDR
> > is 0x40000000, which is inside SDRAM. Why was it commented that the
> 
> No, this is not inside SDRAM. There is no board (yet) with  1  GB  of
> RAM.

Well, "inside SDRAM" is what is commented on WALNUT.h. Now I
understand the value of CFG_INIT_RAM_ADDR is better not to interfere
with the system design.

> In short: cache is like normal memory, just very fast (which does not
> play a role here). We just have to make sure that no cache  fills  or
> cache  flushes  will  be done (at least not for that part of the data
> cache which is being used for the initial stack).

I don't see any caches are in a system memory mapping. Then I thought
it could be only accessed by those cache specific instructions, like
dcread. That's my misunderstanding.

Thanks,
-Shawn.

[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[Grant Likely]

On Fri, 25 Feb 2005 14:56:17 -0800, Shawn Jin <shawnxjin@gmail.com> wrote:
> > In short: cache is like normal memory, just very fast (which does not
> > play a role here). We just have to make sure that no cache  fills  or
> > cache  flushes  will  be done (at least not for that part of the data
> > cache which is being used for the initial stack).
> 
> I don't see any caches are in a system memory mapping. Then I thought
> it could be only accessed by those cache specific instructions, like
> dcread. That's my misunderstanding.
Cache is a dynamic 'shadow' of main memory.  Any region marked
cacheable may loaded into the cache so that subsequent reads are
faster.  Cache operation is transparent to the code (except for cache
control operations like flush and invalidate).  With some careful
coding you can make sure that stack is fully in the cached so that
stack read/writes do not go out to SDRAM.

There are plenty of descriptions of how a cache works online.  It's
worth the time to research and understand it.  Cache operation has
complex and subtle impact on your firmware.

[U-Boot-Users] set up stack before board_init_f() on ppc440 core?

[Shawn Jin]

Hi,

I'm experimenting to set up the initial stack in DCACHE instead of the
internal SRAM on Ebony. In our SoC, no internal SRAM is available.

After reading README's <initial stack, global data> section and the
sample code of ppc405 which sets the stack in DCACHE, I understand the
ideas behind using DCACHE to be the initial stack. Well, I guess.
1. The CFG_INIT_RAM_ADDR is set to an address which nobody uses it.
2. Enable that area cacheable and all others are cache inhibited.

So I did several changes on cpu/ppc4xx/start.S,
include/configs/EBONY.h, and board/ebony/init.S, trying to set up the
stack correctly.
1. changed CFG_ISRAM_BASE to 0x40000000, whose original value is 0xc0000000.
2. commented out ISRAM setting in start.S
3. changed the TLB entries for ISRAM to the following.

#ifndef CFG_440_NO_ISRAM
    tlbentry( CFG_ISRAM_BASE, SZ_4K, 0x80000000, 0, AC_R|AC_W|AC_X )
    tlbentry( CFG_ISRAM_BASE + 0x1000, SZ_4K, 0x80001000, 0, AC_R|AC_W|AC_X )
#else
    tlbentry( CFG_ISRAM_BASE, SZ_256M, 0x40000000, 0, AC_R|AC_W|AC_X )
#endif

However these changes are not successful. A machine check exception
occurs when setting up the stack (2nd stwu). What am I missing here?

	/*----------------------------------------------------------------*/
	/* Setup the stack in internal SRAM or DCACHE */
	/*----------------------------------------------------------------*/
	lis	r1,CFG_INIT_RAM_ADDR at h
	ori	r1,r1,CFG_INIT_SP_OFFSET at l

	li	r0,0
	stwu	r0,-4(r1)
	stwu	r0,-4(r1)		/* Terminate call chain */

Thanks a lot,
-Shawn.