Op do 13 feb. 2020 15:18 schreef Stephan Böck <[email protected]>:
> > > 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. > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/3031e625-dd07-44f0-b8f9-eea42be3a671%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/3031e625-dd07-44f0-b8f9-eea42be3a671%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHK0gJ3-C6MHvtHsVDW-MnPpzbzJ4dEbFXDsWs8Lz_qoKzT6ZQ%40mail.gmail.com.
