[U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL

[Jaehoon Chung]

On 03/30/2017 12:01 PM, Kever Yang wrote:
> Hi Philipp,
> 
> 
> On 03/29/2017 08:59 PM, Dr. Philipp Tomsich wrote:
>> Kever,
>>
>> I did a bit of quick experiment by altering the DMA target addresses for
>> the DMA and can confirm that the root cause must be one of the security
>> registers.
> 
> Thanks for debugging on this, you are right about the root cause.
>>
>> The DMA target addresses are located on the SPL stack, which by default
>> grows down from 0x0008_0000 (so the addresses will be 0x0007_fxxx).
>> If I put the stack below 0x0100_0000 (DMA at 0x00ff_fxxx), I can revert
>> this patch and still have working DMA.
> 
> I'm confuse with this, from the document, all the DDR range should be
> be secured region, and othere master like dwmmc DMA should not able
> to access.

Right, it can't access there.

> 
>>
>> If you want to try yourself, you can use the CONFIG_SPL_STACK_R_ADDR
>> configuration to quickly change the address range for the DMA.
>>
>> Looks like we need to add additional initialisation for some of the security
>> registers into arch/arm/mach-rockchip/rk3399-board-spl.c …
> 
> Yes.

I think that fixing the main cause is better than this patch.

Best Regards,
Jaehoon Chung

> 
> 
> Thanks,
> - Kever
>>
>> Regards,
>> Philipp.
>>
>>> On 29 Mar 2017, at 09:51, Dr. Philipp Tomsich <philipp.tomsich at theobroma-systems.com> wrote:
>>>
>>> Kever,
>>>
>>> we didn’t have time to track this down yet, so we’ve put this work-around
>>> in place to be reverted once we isolate this issue.
>>>
>>> The problem goes away once ATF is running in EL3 and U-Boot executes
>>> in its normal privilege level… so our guess is that it’s either an issue with
>>> running in EL3 or a configuration issue of the various protection registers.
>>>
>>> Regards,
>>> Philipp.
>>>
>>>> On 29 Mar 2017, at 04:31, Kever Yang <kever.yang at rock-chips.com> wrote:
>>>>
>>>> Hi Philipp,
>>>>
>>>>    So you got hang in SPL if the DWMMC is no in fifo mode, do you have
>>>>
>>>> any clue for what's the root cause?
>>>>
>>>> + Ziyuan,
>>>>
>>>> Hi Ziyuan,
>>>>
>>>>    Could you double check this issue? Does it also happen at rk3288 dwmmc?
>>>>
>>>> Thanks,
>>>> - Kever
>>>> On 03/29/2017 01:14 AM, Philipp Tomsich wrote:
>>>>> The RK3399 hangs during DMA of the Designware MMC controller, when
>>>>> performing DMA-based transactions in SPL.  To work around this issue,
>>>>> we disable DMA-based access modes in the SPL stage.
>>>>>
>>>>> With this fix in place, we can now drop 'fifo-mode' in the DTS for the
>>>>> RK3399-Q7 (Puma).
>>>>>
>>>>> Signed-off-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Fixes switching to fifo_mode (should have been 1) in SPL. I broke
>>>>>   this at the 11th hour due to sloppy preparation of the patch.
>>>>>
>>>>> arch/arm/dts/rk3399-puma.dts  |  1 -
>>>>> drivers/mmc/rockchip_dw_mmc.c | 11 +++++++++++
>>>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/dts/rk3399-puma.dts b/arch/arm/dts/rk3399-puma.dts
>>>>> index 917df1e..71eb72d 100644
>>>>> --- a/arch/arm/dts/rk3399-puma.dts
>>>>> +++ b/arch/arm/dts/rk3399-puma.dts
>>>>> @@ -91,7 +91,6 @@
>>>>> &sdmmc {
>>>>>          u-boot,dm-pre-reloc;
>>>>>     bus-width = <4>;
>>>>> -    fifo-mode; /* until we fix DMA in SPL */
>>>>>     status = "okay";
>>>>> };
>>>>> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
>>>>> index c36eda0..5b4ed7a 100644
>>>>> --- a/drivers/mmc/rockchip_dw_mmc.c
>>>>> +++ b/drivers/mmc/rockchip_dw_mmc.c
>>>>> @@ -76,6 +76,17 @@ static int rockchip_dwmmc_ofdata_to_platdata(struct udevice *dev)
>>>>>         return -EINVAL;
>>>>>     priv->fifo_mode = fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),
>>>>>                       "fifo-mode");
>>>>> +
>>>>> +#if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
>>>>> +    /*
>>>>> +     * For a RK3399 SPL build, force fifo_mode to on (i.e. disable
>>>>> +     * DMA) as the MMC transaction will otherwise hang. This issue
>>>>> +     * reproduces only for SPL (i.e. BL2 in the ATF terminology),
>>>>> +     * but doesn't occur with the full U-Boot stage.
>>>>> +     */
>>>>> +    priv->fifo_mode = 1;
>>>>> +#endif
>>>>> +
>>>>>     if (fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev),
>>>>>                  "clock-freq-min-max", priv->minmax, 2))
>>>>>         return -EINVAL;
>>>>
>>
> 
> 
> 
> 
>