On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote: > Hi Scott, > > On Friday 23 March 2012 01:13 AM, Scott Wood wrote: >> On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: >>> Hi Scott, >>> >>> Please find my reply in-lined >>> >>> On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: >>>> On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: >>>>> Debugging of e500 and e500v1 processer requires debug exception >>>>> vecter (IVPR + >>>>> IVOR15) to have valid and fetchable OP code. >>>>> >>>>> While executing in translated space (AS=1), whenever a debug >>>>> exception is >>>>> generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor >>>>> tries to >>>>> fetch an instruction from the debug exception vector (IVPR + IVOR15); >>>>> since now >>>>> we are in AS=0, the application needs to ensure the proper TLB >>>>> configuration to >>>>> have (IVOR + IVOR15) accessible from AS=0 also. >>>>> >>>>> Create a temporary TLB in AS0 to make sure debug exception verctor is >>>>> accessible on debug exception. >>>>> >>>>> Signed-off-by: Radu Lazarescu<radu.lazare...@freescale.com> >>>>> Signed-off-by: Marius Grigoras<marius.grigo...@freescale.com> >>>>> Signed-off-by: Prabhakar Kushwaha<prabha...@freescale.com> >>>> Can you document the flow of exactly what TLB entries are present at >>>> various points of the boot flow, for all the various configurations >>>> (NOR >>>> boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). >>> Sure. May be separate patch will be send. >> Let's start with just an e-mail thoroughly describing your understanding >> of this. It will provide necessary context for review. >> >> We can clean it up for permanent documentation once it's clear to >> everyone what's going on. > > Sure. I will start this activity from now. > But i will suggest not to combine both patches. let debugger patch to go > ahead , if required i will send required patch later-on.
My point is that I cannot fully follow what's going on here without spending a bunch of time looking at it, and I don't see anyone else stepping up to review this, so I'd like to see a write-up of what's going on so that I can properly review these patches. >>>> In the ramboot case is this really supposed to be I+G? >>> I am not sure. But same is done under label "create_init_ram_area" for >>> TLB entry 15. >>> what you suggest. >> I suggest as part of the request to document all of this, you figure out >> what should actually be mapped in each configuration. The existing code >> might be wrong for some of them, but we shouldn't proceed ahead blindly >> and make an even bigger mess. >> > > 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? > I=0 it means the memory range is cacheable, so an access to an address > from that range could get the line in cache. If you are using the cache > as a memory zone(L1 as stack), it may overwrite some data in cache and > replace it with the last access. It will not do that -- when we use L1 (or part of it) for an early stack, we lock the cache lines. >>>> Which path will NAND SPL go through (not the payload, but the SPL >>>> itself)? That will be only a 4K window mapped, and guarded doesn't >>>> stop >>>> speculative instruction fetches, so we don't want to map more than is >>>> backed up by something. >>> NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. >>> >>> i think NAND_SPL does not require temporary TLB as NAND SPL even does >>> not have any interrupt vector. >> So there's no plan to support using breakpoints or single step during >> the SPL? That's fine with me, but should be documented, and we should >> make sure this code does not run in that case. >> > > Breakpoints will work as it is. No impact will be on debugging for NAND > SPL. > > 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? >>>>> + lis r10,0xffc00000@h >>>>> + ori r10,r10,0xffc00000@l >>>> Don't waste instructions -- this could be in an SPL. That ori is a >>>> no-op. >>> Please refer above response. May be this piece of code is not required >>> for NAND SPL >> Still, I'd like to know why you're writing 0xffc00000 to MAS7. Only the >> low 4 bits of MAS7 are valid on current e500. > > > The reason for using 0xffc00000 to support e6500 - since it supports > 40-bit physical addresses, the last 8 bits of MAS7 are defined. Regardless, you're setting the wrong end of MAS7. It's the *lower* bits, not the upper bits, that are used. And we should not be doing anything special for e6500 here. e6500 does not need this, and e6500 platforms should not set CONFIG_SYS_PPC_E500_DEBUG_TLB. > But i am not sure whether e6500 will be part of mpc85xx or not. It will. > So, I will use as > #ifdef CONFIG_ENABLE_36BIT_PHYS > lis r10,0x0000 > #endif Why? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
