On 03/23/2012 09:24 PM, Prabhakar Kushwaha wrote:
On Friday 23 March 2012 11:44 PM, Scott Wood wrote:
On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote:
After internal discussion we can have following settings for non-RAMBOOT(NOR boot) ==> I + G for RAMBOOT ==> I, cache inhibited is required as L1 cache is used as stack.
Why does using L1 for a stack mean that the mapping must be cache inhibited? Why do we even need to use L1 for a stack with ramboot?
it is done at label "_start_cont". L1 is set for Stack address as "switch_as" label. am i wrong??
I don't doubt that we do use the L1 for stack unconditionally -- just that in the ramboot case we could probably get away without it if it were a problem. I don't think it's a problem, though, because it doesn't conflict with creating cacheable mappings.
Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration.
Then why do we need to set MSR[DE] on entry, if the debugger can take care of it?
Yes. You are right. It is required only for SD/SPI boot not for NAND_SPL/NOR boot. But to make MSR[DE] bit set general way (out of #define) throughout u-boot code. I did.
I'm not saying it should be conditional -- just trying to understand when it's needed at all, and what we can expect the debugger to have already done.
So, I will use as #ifdef CONFIG_ENABLE_36BIT_PHYS lis r10,0x0000 #endif
for 36 bit physical address, address should be 0x0_1107_f000 or 0x0_ffff_fffc for destination
mas7 should be programmed. To make sure mas7 is 0. I am setting it. if not required i can remove.
CONFIG_ENABLE_36BIT_PHYS should be protecting the MAS7 mtspr, not the lis.
-Scott