memcpy regression

[Michal Sojka]

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.

-Michal