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 {