* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL @ 2017-03-28 17:14 Philipp Tomsich 2017-03-29 2:31 ` Kever Yang 0 siblings, 1 reply; 7+ messages in thread From: Philipp Tomsich @ 2017-03-28 17:14 UTC (permalink / raw) To: u-boot 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; -- 1.9.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-28 17:14 [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL Philipp Tomsich @ 2017-03-29 2:31 ` Kever Yang 2017-03-29 7:51 ` Dr. Philipp Tomsich 0 siblings, 1 reply; 7+ messages in thread From: Kever Yang @ 2017-03-29 2:31 UTC (permalink / raw) To: u-boot 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; ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-29 2:31 ` Kever Yang @ 2017-03-29 7:51 ` Dr. Philipp Tomsich 2017-03-29 12:59 ` Dr. Philipp Tomsich 0 siblings, 1 reply; 7+ messages in thread From: Dr. Philipp Tomsich @ 2017-03-29 7:51 UTC (permalink / raw) To: u-boot 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; > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-29 7:51 ` Dr. Philipp Tomsich @ 2017-03-29 12:59 ` Dr. Philipp Tomsich 2017-03-30 3:01 ` Kever Yang 0 siblings, 1 reply; 7+ messages in thread From: Dr. Philipp Tomsich @ 2017-03-29 12:59 UTC (permalink / raw) To: u-boot 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; >> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-29 12:59 ` Dr. Philipp Tomsich @ 2017-03-30 3:01 ` Kever Yang 2017-03-30 5:04 ` Jaehoon Chung 0 siblings, 1 reply; 7+ messages in thread From: Kever Yang @ 2017-03-30 3:01 UTC (permalink / raw) To: u-boot 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; >>> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-30 3:01 ` Kever Yang @ 2017-03-30 5:04 ` Jaehoon Chung 2017-03-30 6:30 ` Kever Yang 0 siblings, 1 reply; 7+ messages in thread From: Jaehoon Chung @ 2017-03-30 5:04 UTC (permalink / raw) To: u-boot 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; >>>> >> > > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL 2017-03-30 5:04 ` Jaehoon Chung @ 2017-03-30 6:30 ` Kever Yang 0 siblings, 0 replies; 7+ messages in thread From: Kever Yang @ 2017-03-30 6:30 UTC (permalink / raw) To: u-boot 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 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; >> >> >> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-30 6:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-28 17:14 [U-Boot] [PATCH v2] rockchip: mmc: rk3399: work around DMA issue in SPL Philipp Tomsich 2017-03-29 2:31 ` Kever Yang 2017-03-29 7:51 ` Dr. Philipp Tomsich 2017-03-29 12:59 ` Dr. Philipp Tomsich 2017-03-30 3:01 ` Kever Yang 2017-03-30 5:04 ` Jaehoon Chung 2017-03-30 6:30 ` Kever Yang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.