Hey Dennis, Thanks for the reply. It makes a lot sense for cross-compiler. Thanks for the explanation. I am pretty sure I am running on 4.19.x-ti kernel. uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
I don't have any problem running other PRU examples. I also noticed that the original firmware is not running at first. But once it is loaded, it seems ok. I tried creating /dev/rpmsg by using "echo hello > /dev/rpmsg_pru30" before running example code. But it would leads to program freeze. I am also exploring direct memory access method to save acquired values in shared memory, but I haven't got any results yet. I think I will investigate into the device tree issue as you suggested. Thanks! Regards, Cheng 在2021年4月30日星期五 UTC-4 下午8:45:57<Dennis Bieber> 写道： > On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Cheng Chen > <[email protected]> wrote: > > > >My BBB wireless can compile pru code successfully because I installed > >PRU_CGT compiler. But it is unable to compile ARM code. I think that is > >because ARM_CCT cross-compiler toochain environment is missing, in > another > >word, I need to install processor-sdk-am335x > > > The key is probably in the phrase "cross-compiler"... If you are > compiling ON the Beagle, you are using the "native" compiler, not a > cross-compiler ("cross" implies a toolchain that runs on a different > OS/architecture but which builds binary files meant for the target of the > toolchain -- but you are ON ARM, building FOR ARM). > > >My first questions is can I install processor-sdk-am335x into Debian > >system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a > little > >confused about the relationship between this SDK and Debian system. Why > is > >the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. > >I thought it is supposed to be executed in a cross-compilation > environment. > > > > Cross compilation is used mostly for a couple of reasons: either the > target system does not support a native compiler (you aren't going to run a > compiler on something like a Tiva C board, or an Arduino Due [both of which > run ARM M-series processors] -- though the native compiler on a > Beagle/Debian might be able to build files that can be downloaded to such > boards); the target board is not yet built -- in which case one is likely > going to be "running" the code using something like QEMU or other software > emulation of the hardware system; the target board has a compiler, but the > speed of the cross-compiler environment is much faster (consider a > hyper-threaded 64-bit processor -- which is seen as 8-cores by the OS, each > running at 2.5-3.5GHz, with 12GB of RAM, vs a single 32-bit core running at > 1GB with less than 1GB of RAM). > > >I ended up installing processor-sdk-am335x on my linux desktop and > compiled > >successfully. Then I copied the generated file back to BBB wireless. But > >when I tried to run the program, it shows the following error. > > > >Reading voltage at ADC Channel: 5 > >/dev/rpmsg_pru30 could not be opened. > >Trying to initialize PRU using sysfs interface. > >ERROR: Could not open /dev/rpmsg_pru30 > > > > This is a different matter, and likely means the device tree > configuration is not set correctly -- over the last few years there have > been two INCOMPATIBLE means of accessing the PRU. RemoteProc/RPMsg is the > newer system, pru_uio is older -- current images for the Beagle load > RemoteProc -- check /boot/uEnv.txt to see what version your system is > loading... > > ###PRUSS OPTIONS > ###pru_rproc (4.14.x-ti kernel) > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo > ###pru_rproc (4.19.x-ti kernel) > uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo > ###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel) > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > ### > > ... however, I don't seem to have any /dev/rpmsg* entries either. > > I'm sure this have been brought up in this forum a few times in the > last year or so, but I don't recall the solution (if any). I did find that > the default firmware was not "running"... But starting it didn't add the > /dev/rpmsg* > > debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/* > cat: /sys/class/remoteproc/remoteproc1/device: Is a directory > am335x-pru0-fw > 4a334000.pru > cat: /sys/class/remoteproc/remoteproc1/power: Is a directory > offline <***************************************** > cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory > DEVTYPE=remoteproc > debian@beaglebone:~$ echo 'start' > /sys/class/remoteproc/remoteproc1/state > debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/* > cat: /sys/class/remoteproc/remoteproc1/device: Is a directory > am335x-pru0-fw > 4a334000.pru > cat: /sys/class/remoteproc/remoteproc1/power: Is a directory > running <********************************************* > cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory > DEVTYPE=remoteproc > > > > -- > Dennis L Bieber > > -- 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/f662fea1-becb-48f7-b48e-d2edf573ee3bn%40googlegroups.com.
