On Sun, Sep 06 2015, christophe leroy wrote: > Le 05/09/2015 02:08, Michal Sojka a écrit : >> On 4.9.2015 21:49, Michal Sojka wrote: >>> On 4.9.2015 20:10, christophe leroy wrote: >>>> >>>> >>>> Le 04/09/2015 16:35, Michal Sojka a écrit : >>>>> On Fri, Sep 04 2015, Christophe LEROY wrote: >>>>>> Le 04/09/2015 15:33, Michal Sojka a écrit : >>>>>>> Dear Christophe, >>>>>>> >>>>>>> my MPC5200-based system stopped booting recently. I bisected the >>>>>>> problem >>>>>>> to your commit below. If I revert that commit (on top of >>>>>>> 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my >>>>>>> system boots again. >>>>>>> >>>>>>> >>>>>> Do you use mainline code only, or do you have home-made code ? >>>>> I use mainline only sources with non-mainline device-tree. >>>>> >>>>>> memcpy() is not supposed to be used on non-cacheable memory. >>>>>> memcpy_toio() is the function to use when copying to non-cacheble >>>>>> area. >>>>>> >>>>>> When I submitted the patch, I looked for erroneous use of memcpy() >>>>>> and >>>>>> memset(). >>>>>> I found one wrong use of memset() that I changed to memset_io() but I >>>>>> didn't find any misuse of memcpy(). >>>>>> But I may have missed one. >>>>> I attach my .config, if it helps. I have there >>>>> >>>>> CONFIG_PPC_MPC52xx=y >>>>> CONFIG_PPC_MPC5200_SIMPLE=y >>>>> >>>>> so arch/powerpc/platforms/52xx is probably the directory to look. >>>>> Do you >>>>> see any mempcy misuse there? >>>> I only found one suspect use of memcpy() in >>>> arch/powerpc/platforms/52xx/ >>>> It is in mpc52xx_pm.c but it's linked to CONFIG_PM which is not >>>> selected by your .config >>>> I'll check in the drivers selected by your .config >>>> >>>> In parallele, are you able to try with CONFIG_PPC_EARLY_DEBUG in >>>> order to try and locate the blocking point ? >>> I don't get any output from the system even with CONFIG_PPC_EARLY_DEBUG. >> >> Hmm, there is no udbg console for MPC5200. I hacked something up and >> the earliest place I was able to initialize it is after >> early_init_devtree() in setup_32.c. Even with this console, I got no >> output when the problematic patch was applied. So the problem is >> somewhere earlier. >> > > In early_init() in setup_32.c, there is the following comment: > /* First zero the BSS -- use memset_io, some platforms don't have caches > on yet */ > > In that case, when does cache get activated ? > > In move_device_tree(), called from early_init_devtree(), there is a call > to memcpy(). > Can you try replacing it by memcpy_io() ?
I tried replacing it by memcpy_toio(), memcpy_fromio() and by generic_memcpy(). Nothing helped :( -Michal _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev