[PATCH 00/10] Fix 8xx MMU/TLB

[Scott Wood]

Joakim Tjernlund wrote:
> Scott Wood <scottwood at freescale.com> wrote on 17/11/2009 01:40:11:
>> No...  I only meant that the ITLB pinning got rid of the boot hang.
>>
>> When I mentioned the EFAULTs before you said, "No surprise as the it
>> seems like the DAR decoding is broken."  I thought you meant you'd found
>> a bug and fixed it in this respin.
> 
> Oh, there seems to be a misunderstanding here :)
> Lets go back a bit, you said some time ago:
> /Quote
>>> +3:   lwz   r11, 0(r11)		 /* Get the level 1 entry */
>>>       DO_8xx_CPU6(0x3b80, r3)
>>>       mtspr SPRN_MD_TWC, r11		 /* Load pte table base address */
>>>       mfspr r11, SPRN_MD_TWC		 /* ....and get the pte address */
>>>       lwz   r11, 0(r11)		 /* Get the pte */
>>>       /* concat physical page address(r11) and page offset(r10) */
>>>       rlwimi      r11, r10, 0, 20, 31
>> But r10 here contains SRR0 from above, and this is a data TLB error.
> 
> Never mind that last one, forgot that you'd be wanting to load the
> instruction. :-P
> 
> But the rlwimi is what's causing the machine checks.  I replaced it with:
> rlwinm		 r11, r11, 0, 0x3ffff000
> rlwimi		 r11, r10, 22, 0xffc
> 
> and things seem to work.  You could probably replace the rlwinm by
> subtracting PAGE_OFFSET from swapper_pg_dir instead.
> /End Quote
> 
> I read this as now everything is working, but I guess I misunderstood?
> You still have EFAULT here?

Ah, that one -- I don't recall whether it was fully working back then, or 
whether I just didn't notice the EFAULTs and was commenting more on the machine 
checks going away.

In the current patchset, it's "8xx: start using dcbX instructions in various 
copy routines" that introduces the problem.

-Scott