[U-Boot-Users] set up stack before board_init_f() on ppc440 core?
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.
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
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.
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.
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@h ori r1,r1,CFG_INIT_SP_OFFSET@l
li r0,0 stwu r0,-4(r1) stwu r0,-4(r1) /* Terminate call chain */
Thanks a lot, -Shawn.
participants (3)
-
Grant Likely -
Shawn Jin -
Wolfgang Denk