Hi Philipp,
On 15/04/20 6:30 pm, Philipp Tomsich wrote:
>> On 15.04.2020, at 05:25, Deepak Das <[email protected]> wrote:
>>
>> adapting commit fa2047c47310 ("rockchip: rk3328: enable spl-fifo-mode
>> for emmc and sdmmc") for rk3399.
>> Since mmc to sram can't do dma, add patch to prevent aborts transferring
>> TF-A parts.
>>
>> Signed-off-by: Deepak Das <[email protected]>
>> ---
>> arch/arm/dts/rk3399-u-boot.dtsi | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi
>> b/arch/arm/dts/rk3399-u-boot.dtsi
>> index 8b857ccfc7..3ad824450e 100644
>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>> @@ -84,6 +84,9 @@
>>
>> &sdmmc {
>> u-boot,dm-pre-reloc;
>> +
>> + /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
>> + u-boot,spl-fifo-mode;
> Most transfers in SPL mode will occur to RAM (i.e. most of TF-A and the full
> U-Boot),
> so this is a heavy-handed solution for a problem affecting only some
> transfers.
agreed with you.
> Can’t this be solved using bounce buffers?
> You will need to check if the target address cross the inaccessible memory
> regions
> and—if and only if—send these payloads through a bounce buffer...
Currently bounce buffer apis will use bounce buffer only if target address is
not
aligned for DMA. so I can see following options:-
1) use miss aligned address for required transfer (hackish workaround).
2) create another set of apis which will use bounce buffer even if the target
address
is aligned for DMA.
3) un-secure SRAM area since TF-A will anyway resecure it.
we now also need to get the sram area for that specific SOC so that we can
compare
the same with the target address and act accordingly for option 1&2.
do you have any suggestions ? may be I missed something...
>
>> };
>>
>> &spi1 {
>> --
>> 2.17.1
>>
