On 11/03/2016 03:21 PM, Dinh Nguyen wrote: > > > On 11/02/2016 03:47 PM, Marek Vasut wrote: >> 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 ? >> > > Yes...reset works fine on 2016.09.01 and 2016.09 on my SoCKit. > > Dinh > Well it doesn't work on mine ... compiler problem ?
-- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot