cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,793 Views
Registered: ‎01-10-2020

rpu memory access to dma control register

Jump to solution

Hi,

I am working with Petalinux 2019.2 and vitis. And I am trying to run linux on APU and baremtal application on the RPU. I am using openamp for the APU-RPU communication and it's running perfectly. The next step now is to try to receive some data from PL through a DMA block (managed by the RPU baremetal application) and to send it to the APU via OpenAMP. 
First we prepared a baremetal application which receives data from th DMA block and echoes them back in oder to test the communication between the RPU and DMA. It was working with no problem.

 


The problems started when we started running the RPU baremetal application from a linux master via remoteproc. The initialization of the DMA block could not be executed. The RPU has no access to the control register on the adress 0x80000000.

I added reserved memory node on the device tree of my petalinux project in order to reserve the two regions used by the DMA engine:

from 0x00_8000_0000 to 0x00_8000_FFFF (for DMA-Control Register)

from 0x0100_0000 to 0x014F_FFFF (for DMA BD_Space and TX/RX-Buffers)

And I added those regions to the list of the memory regions accessible by rpu in the memory-regions parameter in the device tree.

But my baremetal application failed to read or write to the ctrl-register stored on the adress: 0x80000000
Do we need other additional configurations of the memory protection unit to give the rpu access to this adress ?

thanks in advance

BR

Iheb

0 Kudos
1 Solution

Accepted Solutions
1,378 Views
Registered: ‎01-10-2020

Problem solved:

First I had to delete of course the dma channel nodes from the device tree. But the second mistake that I was making is that I was using the zynqmp_fsbl.elf file (generated by petalinux after building the petalinux project) as first stage bootloader in my boot.bin file. But since I am using the trenz board: trm te0808, I had to use the trenz fsbl file. 

I created a platform on vitis with my xsa file. I added the starterkit of trenz as a repository in my vitis workspace. Then I created an application on psu-cortexa-53. In one of the available demo projects, there is the trenz FSBL. After building this application, I used its elf file as a FSBL to generated the boot.bin file : (petalinux-package --boot --fsbl <path to FSBL file> --fpga images/linux/system.bit --pmufw images/linux/pmufw.elf --u-boot --force
)
Thanks for your support

BR

Iheb

View solution in original post

8 Replies
jovitac
Moderator
Moderator
1,753 Views
Registered: ‎05-10-2017

iheb.hnaien@siemens.com You don't need to change the MPU settings. See lines 158-169. We do that here in our BSP. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexr5/platform/ZynqMP/mpu.c

 
 

 

GitHub
Xilinx Embedded Software (embeddedsw) Development. Contribute to Xilinx/embeddedsw development by creating an account on GitHub.

 

You do need to make sure that Linux is not trying to initialize or access this DMA region. Please delete this dma node from your device-tree. Make sure that this is actually getting deleted. Decompile your final system.dtb to make sure that this is not getting included. You can also verify by checking your linux boot log to make sure that this is not getting probed.

 
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
1,667 Views
Registered: ‎01-10-2020

Hi Jovitac,

Thanks for your reply. I decompiled my final dtb file and here is my system.dts file (check the attachements). Dma nodes are not being defined. I double checked my boot logs. Dma engines are not being probed too (check boot logs in the attachements). I disabled any dma support from the kernel configuration. 

But I am still having the same problem. 
After debugging the baremetal application, I found out that my application gets stuck in the following function during the dma init: XAxiDma_CfgInitialize() -> XAxiDma_Reset() -> XAxiDma_BdRingSnapShotCurrBd(TxRingPtr) -> XAxiDma_ReadReg(RingPtr)->ChanBase,XAXIDMA_CDESC_OFFSET). At this point, the baremetal application is trying to read the content of the dma control register stored in 0x80000000. This adress is out of the 2GB range accessible by the rpu core. I tried to add this region to the memory regions of the rpu node in the device tree but I got the same problem.

How can we give the rpu access to this register ?

 

PS: 1- I have an enabled sata host controller in my design which has a built-in dma engine (I need a sata drive in my linux application). I tried to delete the sata :ahci@fd0c0000 node from the device tree but this didn't solve my problem.

       2- I am booting from an SD-card. Is linux using dma in order to get thee boot files from the sd card ?

       3- in the boot logs we have the following message:  created DMA memory pool at 0x000000003ed40000. This pool will be needed later for the remoteproc module. I am using remoteproc to boot up rpu from linux master. Remoteproc driver uses dma_alloc_coherent() in order to carve out this memory region for the rpu. So Linux uses dma_mapping.h functions for its remoteproc module. Does this prevent the rpu from initializing and using the axi_dma engine?

BR

Iheb

0 Kudos
jovitac
Moderator
Moderator
1,520 Views
Registered: ‎05-10-2017

1. I don't think your sata controller would be affecting your rpu application

2. Linux does not use dma to access the files from the sd card.

3. I don't believe it should. I will try to find out from the dev team about this. I think you mentioned that this works standalone without the use of Linux. Is that still correct? One thing I would try is not loading the rpu-firmware via remoteproc and include in the bif so that it get's loaded by FSBL. Does it work in that case?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
1,497 Views
Registered: ‎01-10-2020

Thanks a lot.

1.Yes it's still working standalone without linux. 

2. How can I include my rpu firmware in the bif file ?

0 Kudos
jovitac
Moderator
Moderator
1,461 Views
Registered: ‎05-10-2017
How to Generate BOOT.BIN
Below is a sample bootgen.bif file that you can create or modify in the top level directory of your Petalinux project that you can use to help construct the BOOT.BIN:
the
the_ROM_image:
{
[fsbl_config] a53_x64
[bootloader, destination_cpu=a53-0] ./images/linux/zynqmp_fsbl.elf
[pmufw_image, destination_cpu=a53-0] ./images/linux/pmufw.elf
[destination_cpu=a53-0, exception_level=el-3, trustzone] ./images/linux/bl31.elf
[destination_cpu=a53-0, exception_level=el-2] ./images/linux/u-boot.elf
}
Using this .bif file and petalinux tools, we will build a BOOT.BIN file that you can use for your ZynqMP board.
petalinux-package --boot --force --u-boot ./images/linux/u-boot.elf --cpu r5-0 --add /path/to/firmware
Here we have shown a few things:
* We specify to which RPU the data file (your firmware) will go with the --cpu option and r5-0. You can also use r5-1 or r5-lockstep options.
* The --add option where the following argument specifies the path to your firmware.
* The --force option overwrites the existing BOOT.BIN file into the current directory.
* The --u-boot option that specifies the location of the u-boot.elf
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,455 Views
Registered: ‎01-10-2020

unfortunately this didn't solve the problem. My baremetal application is still failing to access the dma control register stored at 0x80000000.

Are there any other possible linux modules or configurations that are preventing the baremetal application from accessing this register ?

BR

Iheb

0 Kudos
1,422 Views
Registered: ‎01-10-2020

in the following manual user: https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf : Page 550. It's written that if a dma channel is secure then only secure masters can access their control and status registers. 

I checked the value of both registers: LPD_SLCR_SECURE.slcr_adma and FPD_SLCR_SECURE.slcr_gdma. They were both set on 0xFF (=> so the dma channels are in non-secure mode. I guess this means they are correctly configured and both RPU and APU should have access to their control  and statur registers. 

 

 

0 Kudos
1,379 Views
Registered: ‎01-10-2020

Problem solved:

First I had to delete of course the dma channel nodes from the device tree. But the second mistake that I was making is that I was using the zynqmp_fsbl.elf file (generated by petalinux after building the petalinux project) as first stage bootloader in my boot.bin file. But since I am using the trenz board: trm te0808, I had to use the trenz fsbl file. 

I created a platform on vitis with my xsa file. I added the starterkit of trenz as a repository in my vitis workspace. Then I created an application on psu-cortexa-53. In one of the available demo projects, there is the trenz FSBL. After building this application, I used its elf file as a FSBL to generated the boot.bin file : (petalinux-package --boot --fsbl <path to FSBL file> --fpga images/linux/system.bit --pmufw images/linux/pmufw.elf --u-boot --force
)
Thanks for your support

BR

Iheb

View solution in original post