Joakim Tjernlund wrote:
Scott Wood <scottw...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
