On Tue, 2013-09-17 at 18:40 +0200, leroy christophe wrote: > Le 16/09/2013 23:02, Scott Wood a écrit : > > On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote: > >> Le 12/09/2013 20:44, Scott Wood a écrit : > >>> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote: > >>>> This is a reorganisation of the setup of the TLB at kernel startup, in > >>>> order > >>>> to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of > >>>> MPC866 > >>>> and MPC885 reference manuals. > >>>> > >>>> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> > >>>> > >>>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S > >>>> linux-3.11/arch/powerpc/kernel/head_8xx.S > >>>> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 > >>>> 22:46:10.000000000 +0200 > >>>> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 > >>>> 11:28:54.000000000 +0200 > >>>> @@ -785,27 +785,24 @@ > >>>> * these mappings is mapped by page tables. > >>>> */ > >>>> initial_mmu: > >>>> - tlbia /* Invalidate all TLB entries */ > >>>> -/* Always pin the first 8 MB ITLB to prevent ITLB > >>>> - misses while mucking around with SRR0/SRR1 in asm > >>>> -*/ > >>>> - lis r8, MI_RSV4I@h > >>>> - ori r8, r8, 0x1c00 > >>>> - > >>>> + lis r8, MI_RESETVAL@h > >>>> mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ > >>>> > >>>> -#ifdef CONFIG_PIN_TLB > >>>> - lis r10, (MD_RSV4I | MD_RESETVAL)@h > >>>> - ori r10, r10, 0x1c00 > >>>> - mr r8, r10 > >>>> -#else > >>>> lis r10, MD_RESETVAL@h > >>>> -#endif > >>>> #ifndef CONFIG_8xx_COPYBACK > >>>> oris r10, r10, MD_WTDEF@h > >>>> #endif > >>>> mtspr SPRN_MD_CTR, r10 /* Set data TLB control */ > >>>> > >>>> + tlbia /* Invalidate all TLB entries */ > >>> Is this change to make sure we invalidate everything even if the > >>> bootloader set RSV4I? > >> Most probably. It is step 2 of the process defined in MPC866 and MPC885 > >> Reference Manuals: > >> > >> §8.10.3 Loading Locked TLB Entries: > >> The process of loading a single reserved entry in the TLB is as follows: > > To minimize code churn we should just fix actual problems, rather than > > shuffle things around to conform to a suggested sequence. After all, > > we're not just trying to load a single entry. > Ok, I'll try again. > > > >>>> + ori r8, r8, 0x1c00 > >>>> + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */ > >>>> +#ifdef CONFIG_PIN_TLB > >>>> + ori r10, r10, 0x1c00 > >>>> + mtspr SPRN_MD_CTR, r10 /* Set data TLB control */ > >>>> +#endif > >>> Still 0x1c00? > >> Yes, I kept the same entries in order to limit modifications: > >> * 28 = First 8Mbytes page > >> * 29 = IMMR > >> * 30 = Second 8Mbytes page > >> * 31 = Third 8Mbytes page > > If you actually want to program them in increasing order then it looks > > like you're still missing a write to CTR between the last two 8M entries > > -- thus you'll overwrite the IMMR with the last 8M entry. That was the > > same problem that v1 fixed -- did that change get lost accidentally? > Oops, no, in fact I diffed from the version which was including it > already. My mistake. > > > > The hardware wants to decrement; why fight it? > I see your point. > However it is not clear in the documentation if the decrement is done > really after the update, or at xTLB interrupt. So I propose to still set > the CTR ourself as described in the reference Manual and not assume that > the HW decrements it.
It says "every update" -- do you have any reason to believe that's wrong? It could be tested... -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
