Hi Stephan,
This is already the third post you did on the topic.
Could you provide some more details?
Are you using the uio_pruss from the kernel directly?
It creates 8 devices /dev/uioX, for each interrupt line a separate device and sets the memory ranges on the 8 devices.
Thanks for your extensive answer.
I initialize and start the PRUs from C++ code with the help of the package. Then I load an assembly image to the PRUs (this assembly code basically checks and sets I/Os).
The PRU-ICSS in the AM572X has a different base address than the PRU-ICSS in the AM335X.
In fact, it seems that there are two PRU subsystems in teh AM572*, which one are you using?
First, I just need it running. So for simplification, I just want to use one subbsystem, lets say PRU-ICSS1 (Bassaddr 0x4B20_0000). Former, the used PRUs were set from my code via the bone_capemgr/slots file, which is now gone. Nevertheless, which PRUs should be used is something I set/will set in my code.
However, the am335x_pru_package uses /dev/uioX to know the base pointer.
So that should still work.
Here I see a problem. I am using the latest image (Debian 9.9 2019-08-03 4GB SD LXQT), therefore the kernel is 4.14.x. What I have read, the 4.x kernel relies on remoteproc rather than uio_pruss.
The pru_package uses the revision id of the interrupt controller to determine which chip is used.
The pru_package does not fail fast with a clear description if it could not detect a known revision.
That might explain that it is failing in a non obvious way.
The segmentation fault already occurs when I call the function prussdrv_open. I have to admit, that I didn’t decompile the libraries to check what is actually happening in this function.
As for the offset of the PRU-ICSS components, all components are at the same offsets as in the AM335X.
Therefore, you could try adding the AM5729 interrupt controller in __prussdrv.h, especially in __pruss_detect_hw_version.
You should actually should check that the PRU-ICSS components in AM335X and PRU-ICSS components in AM572* are the same by comparing the technical references.
From TI, I already found a migration guide for am335x to am57xx: http://www.ti.com/lit/an/sprac91/sprac91.pdf. I guess the firmware of the BB AI is alright. I am aware that there is work on the arm code is neccessary (new addresses, pinmuxing,…), but since I dont even come to the point of loding it
The offsets are the same so most of the AM335X defines apply for AM572* as well.
You can read out the interrupt device id yourself.
Read out the revision id in table 30.742 of the technical reference manual: http://www.ti.com/lit/ug/spruhz6l/spruhz6l.pdf.
Note that this is relative to the PRU-ICSS base, so I guess you should be reading from 0x4B22_0000 for the first and 0x4B2A_0000 for the second subsystem.
The revision ID is not mentioned in the manual.
I used a tool called devmem to read out the memory.
https://github.com/brgl/busybox/blob/master/miscutils/devmem.c
I hope this gives an idea of what is required to get it to work.
I don’t have a BB AI , so no way to test.
Best wishes,
Hugo
I will try my best on what you gave me and will give updates here. Thanks again.
Stephan