On 10/29/2016 02:59 PM, Marek Vasut wrote:
> On 10/18/2016 05:50 PM, Dinh Nguyen wrote:
>> On Sun, Oct 16, 2016 at 10:59 AM, Marek Vasut <ma...@denx.de> wrote:
>>> On 10/15/2016 12:10 AM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform
>>>>> makes
>>>>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC
>>>>> bit.
>>>>>
>>>>> This is only an RFC because after rebasing to v2016.11-rc1, I had to
>>>>> revert
>>>>> the following patch "a78cd8613204 ARM: Rework and correct barrier
>>>>> definitions"
>>>>> in order for this patch set to work correctly. With the above patch
>>>>> applied,
>>>>> after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
>>>>> device.
>>>>>
>>>>
>>>> I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
>>>> barrier definitions" is causing SPL to fail after the SDRAM scrub
>>>> operation. It appears that before the above mentioned patch, the dmb()
>>>> operation is defined as this:
>>>>
>>>> #define dmb() __asm__ __volatile__ ("" : : : "memory")
>>>>
>>>> after the patch, the dmb is now:
>>>>
>>>> #define DMB asm volatile ("dmb sy" : : : "memory")
>>>>
>>>> So the "dmb sy" as described in the ARM documentation is a "Full system
>>>> DMB operation". For whatever reason, this change is causing the SPL
>>>> error after the SDRAM scrub operation.
>>>
>>> Thanks for looking into this, can you poke into it some more ?
>>>
>>
>> Of course..
>
> The patch is causing a failure even in normal operation -- if you boot
> the socfpga board and type "reset", it won't reset with the patch.
>
Can I ask what board are you seeing this on? I'm seeing that on my Atlas
board, it does not reset properly(even with the patch reverted). But
"reset" is working fine on my devkit, with and without the patch.
Dinh
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
