AM57XX_pru_package

[Stephan Böck]

Hey, 

at the moment I try to port a program to the BB AI, which was developed for the BB Black.

This program uses the PRUs and includes the headerfiles pruss_intc_mapping.h and prussdrv.h aswell as the libs (libprussdrv.a, libprussdrv.so, libprussdrvd.a and libprussdrvd.so) from the am335x_pru_package, which can be found in the beagleboard git repo https://github.com/beagleboard/am335x_pru_package 

Is there a chance that a pru package for the AM5729 is on the way?

Currently, I am facing segmentation faults. Which makes totally sense, since the base addresses changed. 

Stephan

[Hugo van den Brand]

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.

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?

However, the am335x_pru_package uses /dev/uioX to know the base pointer.

So that should still work.

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.

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.

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/08c3aa1e-e013-4c3e-9214-1b238b5d3924%40googlegroups.com.

[Jason Kridner]

On Wed, Feb 12, 2020 at 9:12 AM Stephan Böck <boeckh...@gmail.com> wrote:

Hey, 

at the moment I try to port a program to the BB AI, which was developed for the BB Black.

This program uses the PRUs and includes the headerfiles pruss_intc_mapping.h and prussdrv.h aswell as the libs (libprussdrv.a, libprussdrv.so, libprussdrvd.a and libprussdrvd.so) from the am335x_pru_package, which can be found in the beagleboard git repo https://github.com/beagleboard/am335x_pru_package 

Is there a chance that a pru package for the AM5729 is on the way?

What do you need out of the package first? I think we can tackle adding some cross AM3/AM5 device support to this library incrementally.

Mark Yoder and I have been working on BeagleBone AI PRU examples at:

https://github.com/beagleboard/cloud9-examples/tree/v2020.01/BeagleBone/AI/pru 

 

Currently, I am facing segmentation faults. Which makes totally sense, since the base addresses changed. 

Stephan

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/08c3aa1e-e013-4c3e-9214-1b238b5d3924%40googlegroups.com.

--

https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing

[Stephan Böck]

Am Mittwoch, 12. Februar 2020 22:07:13 UTC+1 schrieb Hugo van den Brand:

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

[Stephan Böck]

What do you need out of the package first? I think we can tackle adding some cross AM3/AM5 device support to this library incrementally.

I want to start the PRUs from c++ code and load some assembly code on to them. 

Therefore I am using different functions from the package like: prussdrv_init, prussdrv_open, prussdrv_exec_code, prussdrv_exit and more. Basically the whole communication with the PRUs is handled this way.

My program already fails at the point when prussdrv_open is called (prussdrv_init works). 

I was hoping that there is a similar package for the am57xx, but I also read something about changes in device addressing between kernel 3.8 and 4.x. 

[Hugo van den Brand]

Op do 13 feb. 2020 15:18 schreef Stephan Böck <boeckh...@gmail.com>:

Am Mittwoch, 12. Februar 2020 22:07:13 UTC+1 schrieb Hugo van den Brand:

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. 

You need to unload pru_rproc (modprobe -r pru_rproc) and load uio_pruss.

On am335x, the compatible flags used to match both pru_rproc and uio_pruss.

If it does not match you can force a particular module as driver and force the probing.

 ( I failed to quickly find a link about this. ).

However,  you should also consider why you use uio instead of remoteproc.

I am using uio because I want to see how far I can get with a mainline kernel. 

If remoteproc could also work for you I would stick to that. 

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.

You don't want to decompile.

You want to recompile after making sure that the software recognizes your pruss subsystem. 

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 guide tells that there aren't many differences. So the proposed change to the software will most likely do the trick. 

 

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

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3031e625-dd07-44f0-b8f9-eea42be3a671%40googlegroups.com.