From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaehoon Chung Date: Thu, 30 Mar 2017 14:04:28 +0900 Subject: [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL In-Reply-To: <458648e6-8105-6cad-0028-8352de2b0561@rock-chips.com> References: <1490721274-42782-1-git-send-email-philipp.tomsich@theobroma-systems.com> <23b3c3b3-9909-487d-8508-35be7ef6bced@rock-chips.com> <8900461C-E0D2-43CC-892A-429DA4465D7D@theobroma-systems.com> <78A19E6C-2ED5-4FB9-8C8E-C4D0081AA332@theobroma-systems.com> <458648e6-8105-6cad-0028-8352de2b0561@rock-chips.com> Message-ID: <7025df51-e63f-2158-3553-4d80d6b40925@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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 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 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 >>>>> >>>>> --- >>>>> >>>>> 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; >>>> >> > > > > >