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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
