[U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL
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@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;
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@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;
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@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@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;
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.
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.
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 …
Regards, Philipp.
On 29 Mar 2017, at 09:51, Dr. Philipp Tomsich philipp.tomsich@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@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@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;
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 philipp.tomsich@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@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@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;
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@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@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@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;
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.tomsich@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@rock-chips.com wrote:
Hi Philipp,
So you got hang in SPL if the DWMMC is no in fifo mode, do you haveany 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@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;
participants (4)
-
Dr. Philipp Tomsich -
Jaehoon Chung -
Kever Yang -
Philipp Tomsich