**** BEGIN LOGGING AT Sun Nov 13 02:59:56 2022 Nov 13 06:46:37  I'm trying to move data from the PRUs to the am335x processor. I found on the am335x pru reference guide that there is shared memory at address 0x0001_0000 for the prus, I have a set up to write to that memory location on my pru code. How can I verify that it is writing and then read/write that memory from the command line or with a c program on Nov 13 06:46:37 the am335x host processor end? Nov 13 19:53:02 I asked yesterday but got no response yet, how do I configure and access the memory on my arm am335 processor to communicate and check the memory I'm writing to with my pru? I am writing to address 0x00010000 on my pru, which is designated as the shared, but not sure how to access that on the other end Nov 13 20:00:47 nick12310: in general by mmap()ing an uio device. afaik that's still the solution used even when using remoteproc-pru (which I don't use personally, but is the default nowadays) Nov 13 20:02:37 are you using uio-pruss or remoteproc-pru ? Nov 13 20:02:50 remoteproc Nov 13 20:03:25 for uio-pruss, my py-uio library (https://github.com/mvduin/py-uio) makes it particularly easy to use shared memory... for remoteproc I'd need to dig for a moment to check what they created Nov 13 20:03:55 since remoteproc kinda sucks and afaik doesn't provide shared memory support :P Nov 13 20:08:23 yeah, when using remoteproc there's a /dev/uio/pru-shmem device Nov 13 20:08:38 which gives direct access to all three pruss memories (dram0, dram1, dram2) Nov 13 20:12:51  Hmm. Ok I will try installing py uio/uiopruss and use that, kinda been going with remoteproc because TI says to use it and their drivers, but it does seem like I have to hack something together to try and get it to work Nov 13 20:13:31 so, if you're using remoteproc you can still use the /dev/uio/pru-shmem device (with py-uio or C code) to access pru shared memory Nov 13 20:15:40 should I be able to access /dev/uio/pru-shmem by default? I can't see that device in directory Nov 13 20:16:28 hmm? it exists on my beaglebone (after switching from uio-pruss to remoteproc-pru) Nov 13 20:17:13 https://pastebin.com/raw/eNWDgbi8 Nov 13 20:17:40 and I can use it via py-uio: https://pastebin.com/Z1Edinbd Nov 13 20:18:56 I just get "ls: cannot access '/dev/uio/pru-shmem': No such file or directory" . I can access dev, but no /dev/uio exists for me Nov 13 20:19:14 does /dev/uio0 exist? Nov 13 20:19:23 what kernel are you using? Nov 13 20:19:39 no Nov 13 20:20:03 (and what debian image?) Nov 13 20:20:07 4.19.94-ti-r42 Nov 13 20:20:23 Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux Nov 13 20:21:44 try: grep PRUSS_SHMEM /boot/config-$(uname -r) Nov 13 20:21:57 CONFIG_UIO_PRUSS_SHMEM=m Nov 13 20:22:36 hm, okay odd, then I don't really know why the device doesn't exist for you... though I am actually running a slightly newer kernel myself, 4.19.94-ti-r72 Nov 13 20:23:27 you could consider switching to uio-pruss and use py-uio to load your executable... there's not really any benefit to remoteproc-pru, it doesn't do anything *useful* that you can't do via uio-pruss (and uio-pruss can do much that remoteproc-pru doesn't) Nov 13 20:24:31 I guess remoteproc-pru may be useful when pru firmware is used in cooperation with a kernel driver rather than with in cooperation with userspace code Nov 13 20:27:52 when using uio-pruss, py-uio can be used to control and inspect pruss, including reading/writing/mapping pruss memory and pruss peripherals, loading code onto cores, running and halting cores, inspecting/modifying cpu registers when halted, single-stepping/debugging cpu cores Nov 13 20:28:27 documentation is unfortunately rather lacking, but it does have a bunch of examples and I'm here for questions Nov 13 20:29:32 Alright then. I'm installing it now, thanks for the help so far Nov 13 20:30:35 and py-uio supports loading both raw binaries as produced by pasm (the pru assembler that still has features that clpru doesn't) as well as ELF executables produced by clpru Nov 13 20:53:10 So I had my remoteproc pru code that toggled pins on and off and wrote to memory, is there an easy way to port that to uio pruss code , or how would I do those same things with the uio pruss? Nov 13 20:53:27 py-uio can load the exact same executable Nov 13 20:55:11 py-uio actually includes a C example: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw-c/test.c and associated python example: https://github.com/mvduin/py-uio/blob/master/pru-examples/elf-test.py Nov 13 20:55:16 which includes testing shared memory Nov 13 21:36:12 So in that case, I can take my compiled am335x-pru0-fw file from /lib/firmware/ and just load with python script? Nov 13 21:36:45 yep that should work Nov 13 21:37:13 unless the program uses remoteproc features not supported by py-uio, such as rpmsg Nov 13 22:40:28 So I think I'm either writing to the wrong memory or not writing to memory in my pru code, what is the address that py-uio reads from for shared memory? Nov 13 22:49:21 nick12310: ehh what do you mean? py-uio can read from anywhere in pruss memory Nov 13 22:51:33 I'm trying to adapt the ddr-ping.py to what I have for my pru code. This my pru code that I compile https://pastebin.com/jb6kDvyD, and this is the ddr-ping.py https://pastebin.com/Kmkr2jGx Nov 13 22:52:28 it write/read from address 0x10000 in both, I thought, but when I run, it doesn't pass the ping Nov 13 22:52:29 nick12310: ddr-ping as the name implies is about using ddr memory, not pruss memory Nov 13 22:53:05 elf-test.py is a good example of accessing pruss memory Nov 13 22:55:08 lol why the hell does elf-test.py import struct, it doesn't use it Nov 13 23:03:06 So what exactly is an elf file? Nov 13 23:03:22 ELF is the file format produced by clpru Nov 13 23:03:51 it's a common file format for compiled code, also used for linux executables and libraries Nov 13 23:26:49 nick12310: btw I just pushed a small fix to github (turned out the read()/write()/fill() methods were not implemented on the pruss object itself, so I quickly implemented those) Nov 13 23:50:49 nick12310: https://pastebin.com/WM0aU8M8 a summary of shared memory access using py-uio Nov 14 00:59:00 what does the mapping of foo and bar to memory do, in elf-test.py, does it  mean those variables now correspond to the values at those memory locations? Nov 14 01:12:11 nick12310: essentially yes... they're ctypes.c_uint32 objects representing 32-bit unsigned integers at those locations in pru memory Nov 14 01:12:29 so accessing foo.value will access pru memory Nov 14 01:13:45 ctypes also can be used to define structures and arrays, and those can likewise be mapped using map() Nov 14 01:13:54 Ok cool. I think my simple test is working. Nov 14 01:14:10 So can I make a ctype string to print out troubleshooting messages from pru? Nov 14 01:17:56 there are certainly ways to do that, although it requires a bit of care since strings are variable-length Nov 14 01:18:32 Hm, yea. I guess a better way would be just to return a code corresponding to the message? Nov 14 01:19:56 nick12310: look at fw-c/stream.cc and stream-c.py Nov 14 01:21:23 note: allocating variables in shared memory like this: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw-c/stream.cc#L24-L25 requires a linker script that places far data in shared memory, which the linker script in that directory (am335x.cmd) does, but I don't remember if that's standard/typical of linker scripts provided by TI Nov 14 01:22:45 in this example I'm not actually reporting a message but the file name and line number where I'm halting, but obviously you could easily use the same mechanism to pass a message Nov 14 01:32:09 (of course you're not _required_ to have clpru allocate stuff in shared memory for you, you can also keep doing it the manual way like you've been doing so far, but it's nice to have the linker verify your variables actually fit in shared memory and don't overlap) **** ENDING LOGGING AT Mon Nov 14 02:59:57 2022