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 | expand |
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
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 {