[U-Boot,v2,2/2] rockchip: px30: enable spl-fifo-mode for both emmc and sdmmc on evb
diff mbox series

Message ID 20191119110402.17876-2-heiko@sntech.de
State Accepted
Commit 8019d32c4701b95410113541deb7f28d5c2b02a5
Delegated to: Kever Yang
Headers show
Series
  • [U-Boot,v2,1/2] rockchip: dwmmc: add handling for u-boot, spl-fifo-mode
Related show

Commit Message

Heiko Stübner Nov. 19, 2019, 11:04 a.m. UTC
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(-)

Comments

Kever Yang Nov. 20, 2019, 7:20 a.m. UTC | #1
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 {
Philipp Tomsich Nov. 20, 2019, 11:11 a.m. UTC | #2
> 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>
Patrick Wildt Nov. 27, 2019, 11:38 p.m. UTC | #3
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
Heiko Stübner Nov. 28, 2019, 8:19 a.m. UTC | #4
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

Patch
diff mbox series

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 {