Re: memcpy regression

[Michal Sojka <sojkam1@fel.cvut.cz>]

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.

-Michal