On 11/02/2016 05:30 PM, Dinh Nguyen wrote:
> On Tue, Nov 1, 2016 at 3:43 PM, Dinh Nguyen <dingu...@kernel.org> wrote:
>>
>>
>> On 11/01/2016 03:42 PM, Marek Vasut wrote:
>>> On 11/01/2016 09:39 PM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 11/01/2016 03:09 PM, Marek Vasut wrote:
>>>>> On 11/01/2016 04:43 PM, Dinh Nguyen wrote:
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> SoCKit and MCVEVK.
>>>>>
>>>>> I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and
>>>>> I arrived at this patch. Maybe you can double-check this ?
>>>>>
>>>>
>>>> Okay, I can check it on the SoCKit.
>>>
>>> It also happens on MCVEVK, but that's probably moot for your test ;-)
>>>
>>
>> I don't have an MCVEVK.
>>
>
> The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.
Does it work on 2016.09.01 too ?
--
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
