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 <https://debian.beagleboard.org/images/am57xx-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz> ), 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3031e625-dd07-44f0-b8f9-eea42be3a671%40googlegroups.com.
