[U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible

[Scott Wood]

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