[U-Boot] [PATCH v2 1/2] rockchip: dwmmc: add handling for u-boot, spl-fifo-mode

From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Rockchips dwmmc controllers can't do dma to non-ddr addresses, like for example the soc-internal sram but during boot parts of TrustedFirmware need to be placed there from the read FIT image.
So add handling for a u-boot,spl-fifo-mode to not put the mmc controllers into fifo mode for all time.
The regular fifo-mode property still takes precedent and only if not set do we check for the spl-specific property.
Suggested-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com --- drivers/mmc/rockchip_dw_mmc.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c index b2a1201631..a0e1be8794 100644 --- a/drivers/mmc/rockchip_dw_mmc.c +++ b/drivers/mmc/rockchip_dw_mmc.c @@ -72,6 +72,11 @@ static int rockchip_dwmmc_ofdata_to_platdata(struct udevice *dev) return -EINVAL; priv->fifo_mode = dev_read_bool(dev, "fifo-mode");
+#ifdef CONFIG_SPL_BUILD + if (!priv->fifo_mode) + priv->fifo_mode = dev_read_bool(dev, "u-boot,spl-fifo-mode"); +#endif + /* * 'clock-freq-min-max' is deprecated * (see https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64...)

From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
As part of loading trustedfirmware, the SPL is required to place portions of code into the socs sram but the mmc controllers can only do dma transfers into the regular memory, not sram.
The results of this are not directly visible in u-boot itself, but manifest as security-relate cpu aborts during boot of for example Linux.
There were a number of attempts to solve this elegantly but so far discussion is still ongoing, so to make the board at least boot correctly put both mmc controllers into fifo-mode, which also circumvents the issue for now.
Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com --- changes in v2: - moved to a spl-specific property, as suggested by Philipp
arch/arm/dts/px30-evb-u-boot.dtsi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/px30-evb-u-boot.dtsi b/arch/arm/dts/px30-evb-u-boot.dtsi index 3de9c7068e..a2a2c07dcc 100644 --- a/arch/arm/dts/px30-evb-u-boot.dtsi +++ b/arch/arm/dts/px30-evb-u-boot.dtsi @@ -31,12 +31,15 @@ &sdmmc { u-boot,dm-pre-reloc;
- /* temporary till I find out why dma mode doesn't work */ - fifo-mode; + /* mmc to sram can't do dma, prevent aborts transfering TF-A parts */ + u-boot,spl-fifo-mode; };
&emmc { u-boot,dm-pre-reloc; + + /* mmc to sram can't do dma, prevent aborts transfering TF-A parts */ + u-boot,spl-fifo-mode; };
&grf {

On 2019/11/19 下午7:04, Heiko Stuebner wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
As part of loading trustedfirmware, the SPL is required to place portions of code into the socs sram but the mmc controllers can only do dma transfers into the regular memory, not sram.
The results of this are not directly visible in u-boot itself, but manifest as security-relate cpu aborts during boot of for example Linux.
There were a number of attempts to solve this elegantly but so far discussion is still ongoing, so to make the board at least boot correctly put both mmc controllers into fifo-mode, which also circumvents the issue for now.
Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
changes in v2:
moved to a spl-specific property, as suggested by Philipp
arch/arm/dts/px30-evb-u-boot.dtsi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/px30-evb-u-boot.dtsi b/arch/arm/dts/px30-evb-u-boot.dtsi index 3de9c7068e..a2a2c07dcc 100644 --- a/arch/arm/dts/px30-evb-u-boot.dtsi +++ b/arch/arm/dts/px30-evb-u-boot.dtsi @@ -31,12 +31,15 @@ &sdmmc { u-boot,dm-pre-reloc;
- /* temporary till I find out why dma mode doesn't work */
- fifo-mode;
/* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
u-boot,spl-fifo-mode; };
&emmc { u-boot,dm-pre-reloc;
/* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
u-boot,spl-fifo-mode; };
&grf {

On 19.11.2019, at 12:04, Heiko Stuebner heiko@sntech.de wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
As part of loading trustedfirmware, the SPL is required to place portions of code into the socs sram but the mmc controllers can only do dma transfers into the regular memory, not sram.
The results of this are not directly visible in u-boot itself, but manifest as security-relate cpu aborts during boot of for example Linux.
There were a number of attempts to solve this elegantly but so far discussion is still ongoing, so to make the board at least boot correctly put both mmc controllers into fifo-mode, which also circumvents the issue for now.
Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com

On Tue, Nov 19, 2019 at 12:04:02PM +0100, Heiko Stuebner wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
As part of loading trustedfirmware, the SPL is required to place portions of code into the socs sram but the mmc controllers can only do dma transfers into the regular memory, not sram.
The results of this are not directly visible in u-boot itself, but manifest as security-relate cpu aborts during boot of for example Linux.
There were a number of attempts to solve this elegantly but so far discussion is still ongoing, so to make the board at least boot correctly put both mmc controllers into fifo-mode, which also circumvents the issue for now.
Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Hi,
is this also needed on RK3399 based machines? I have a NanoPC-T4, where the eMMC is on the Arasan controller and the SD card on the dwmmc. So if I boot from SD card I need this as well?
Patrick

Hi Patrick,
Am Donnerstag, 28. November 2019, 00:38:45 CET schrieb Patrick Wildt:
On Tue, Nov 19, 2019 at 12:04:02PM +0100, Heiko Stuebner wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
As part of loading trustedfirmware, the SPL is required to place portions of code into the socs sram but the mmc controllers can only do dma transfers into the regular memory, not sram.
The results of this are not directly visible in u-boot itself, but manifest as security-relate cpu aborts during boot of for example Linux.
There were a number of attempts to solve this elegantly but so far discussion is still ongoing, so to make the board at least boot correctly put both mmc controllers into fifo-mode, which also circumvents the issue for now.
Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Hi,
is this also needed on RK3399 based machines? I have a NanoPC-T4, where the eMMC is on the Arasan controller and the SD card on the dwmmc. So if I boot from SD card I need this as well?
I think so. That dma-to-sram issue is supposed to be present on a lot (maybe all?) Rockchip SoCs. And I think I remember running into that issue on rk3399 as well already in the past.
Not sure if that is limited to the dw-mmc only though or the arasan is also affected - maybe Kever knows :-)
Heiko

Heiko,
On 2019/11/19 下午7:04, Heiko Stuebner wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Rockchips dwmmc controllers can't do dma to non-ddr addresses, like for example the soc-internal sram but during boot parts of TrustedFirmware need to be placed there from the read FIT image.
So add handling for a u-boot,spl-fifo-mode to not put the mmc controllers into fifo mode for all time.
The regular fifo-mode property still takes precedent and only if not set do we check for the spl-specific property.
Suggested-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Well, this is a alternative solution of using bounce buffer for MMC in SPL.
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
drivers/mmc/rockchip_dw_mmc.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c index b2a1201631..a0e1be8794 100644 --- a/drivers/mmc/rockchip_dw_mmc.c +++ b/drivers/mmc/rockchip_dw_mmc.c @@ -72,6 +72,11 @@ static int rockchip_dwmmc_ofdata_to_platdata(struct udevice *dev) return -EINVAL; priv->fifo_mode = dev_read_bool(dev, "fifo-mode");
+#ifdef CONFIG_SPL_BUILD
- if (!priv->fifo_mode)
priv->fifo_mode = dev_read_bool(dev, "u-boot,spl-fifo-mode");
+#endif
- /*
- 'clock-freq-min-max' is deprecated
- (see https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64...)

On 19.11.2019, at 12:04, Heiko Stuebner heiko@sntech.de wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Rockchips dwmmc controllers can't do dma to non-ddr addresses, like for example the soc-internal sram but during boot parts of TrustedFirmware need to be placed there from the read FIT image.
So add handling for a u-boot,spl-fifo-mode to not put the mmc controllers into fifo mode for all time.
The regular fifo-mode property still takes precedent and only if not set do we check for the spl-specific property.
Suggested-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Signed-off-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
drivers/mmc/rockchip_dw_mmc.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c index b2a1201631..a0e1be8794 100644 --- a/drivers/mmc/rockchip_dw_mmc.c +++ b/drivers/mmc/rockchip_dw_mmc.c @@ -72,6 +72,11 @@ static int rockchip_dwmmc_ofdata_to_platdata(struct udevice *dev) return -EINVAL; priv->fifo_mode = dev_read_bool(dev, "fifo-mode");
+#ifdef CONFIG_SPL_BUILD
- if (!priv->fifo_mode)
priv->fifo_mode = dev_read_bool(dev, "u-boot,spl-fifo-mode");
+#endif
Nitpick: I would have used an “|=" instead of the "if(…)”.
- /*
- 'clock-freq-min-max' is deprecated
- (see https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64...)
-- 2.24.0

Sorry, I was confused and meant...
On 20.11.2019, at 12:09, Philipp Tomsich philipp.tomsich@theobroma-systems.com wrote:
On 19.11.2019, at 12:04, Heiko Stuebner heiko@sntech.de wrote:
From: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Rockchips dwmmc controllers can't do dma to non-ddr addresses, like for example the soc-internal sram but during boot parts of TrustedFirmware need to be placed there from the read FIT image.
So add handling for a u-boot,spl-fifo-mode to not put the mmc controllers into fifo mode for all time.
The regular fifo-mode property still takes precedent and only if not set do we check for the spl-specific property.
Suggested-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com Signed-off-by: Heiko Stuebner heiko.stuebner@theobroma-systems.com
Signed-off-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
participants (5)
-
Heiko Stuebner
-
Heiko Stübner
-
Kever Yang
-
Patrick Wildt
-
Philipp Tomsich