On 12/30/20 4:50 AM, Dimitar Dimitrov wrote:
> PRU port of GNU Binutils lacks support for separate address spaces.
> PRU IRAM addresses are marked with artificial offset to differentiate
> them from DRAM addresses. Hence remoteproc must mask IRAM addresses
> coming from GNU ELF in order to get the true hardware address.
>
> Patch was tested on top of latest linux-remoteproc/for-next branch:
> commit 4c0943255805 ("Merge branches 'hwspinlock-next', 'rpmsg-next' and 'rproc-next' into for-next")'
>
> PRU firmware used for testing was the example in:
> https://github.com/dinuxbg/pru-gcc-examples/tree/master/blinking-led/pru
>
> Signed-off-by: Dimitar Dimitrov <dimitar@xxxxxxxx>
Acked-by: Suman Anna <s-anna@xxxxxx>
> ---
> drivers/remoteproc/pru_rproc.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 2667919d76b3..5fad787ba012 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -450,6 +450,24 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da, size_t len)
> if (len == 0)
> return NULL;
>
> + /*
> + * GNU binutils do not support multiple address spaces. The GNU
> + * linker's default linker script places IRAM at an arbitrary high
> + * offset, in order to differentiate it from DRAM. Hence we need to
> + * strip the artificial offset in the IRAM addresses coming from the
> + * ELF file.
> + *
> + * The TI proprietary linker would never set those higher IRAM address
> + * bits anyway. PRU architecture limits the program counter to 16-bit
> + * word-address range. This in turn corresponds to 18-bit IRAM
> + * byte-address range for ELF.
> + *
> + * Two more bits are added just in case to make the final 20-bit mask.
> + * Idea is to have a safeguard in case TI decides to add banking
> + * in future SoCs.
> + */
> + da &= 0xfffff;
> +
> if (da >= PRU_IRAM_DA &&
> da + len <= PRU_IRAM_DA + pru->mem_regions[PRU_IOMEM_IRAM].size) {
> offset = da - PRU_IRAM_DA;
>
