Hi Jaehoon,
Philipp has send out another patch for disable t he secure region,
and this patch is no need now.
Thanks,
- Kever
On 03/30/2017 01:04 PM, Jaehoon Chung wrote:
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.toms...@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.y...@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.toms...@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;
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
