From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kever Yang Date: Thu, 30 Mar 2017 11:01:47 +0800 Subject: [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL In-Reply-To: <78A19E6C-2ED5-4FB9-8C8E-C4D0081AA332@theobroma-systems.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> Message-ID: <458648e6-8105-6cad-0028-8352de2b0561@rock-chips.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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. > > 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. 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; >>> >