Mark, git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or any of the parent directories): .git
I'm such a neophyte on git. What do I need to do? And, what do you mean by updating to a new version of the SD card? The OS is booting from the SD card and the version.sh information posted earlier is based on that. On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote: > I suggest updating to a new version of the SD card. It looks like the > PRUs are getting started at boot time, but the path isn't setup right. I > think we setup some links so the path* /dev/remoteproc/pruss-core0/state > *points to the right place. > > You could also try: > *cd */var/lib/cloud9 > *git* pull > to update cloud9 folders. > > --Mark > > On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 > [email protected] wrote: > >> Mark, >> >> I got the latest PRUCookbook downloaded and when trying to make the >> hello.pru0.c program in 1.6, I got this error. >> >> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make >> TARGET=hello.pru0* >> */var/lib/cloud9/common/Makefile:29: >> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0* >> *- Stopping PRU 0* >> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory >> nonexistent* >> *Cannot stop 0* >> *CC hello.pru0.c* >> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning >> directive: "Found am335x"* >> *LD /tmp/cloud9-examples/hello.pru0.o* >> *- copying firmware file /tmp/cloud9-examples/hello.pru0.out to >> /lib/firmware/am335x-pru0-fw* >> *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': >> Permission denied* >> */var/lib/cloud9/common/Makefile:180: recipe for target 'install' failed* >> *make: *** [install] Error 1* >> *rm /tmp/cloud9-examples/hello.pru0.o* >> >> Initially, I did not have a folder called /var/lib/cloud9/common. To >> remedy this I copied the contents of >> /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common. Maybe >> this created a problem?Nevertheless, I found some other discussions that >> suggested updating the scripts and kernels from beagleboard.org/upgrade >> which I did. I am now running... >> >> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 >> 01:48:39 UTC 2020 armv7l GNU/Linux >> >> And the output of version.sh is >> >> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh* >> *[sudo] password for debian:* >> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]* >> *eeprom:[A335BNLT00C04417BBBK1847]* >> *model:[TI_AM335x_BeagleBone_Black]* >> *dogtag:[BeagleBoard.org Debian Image 2018-10-07]* >> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL >> 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd >> MBR]* >> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot >> 2018.09-00002-g0b54a51eee]:[location: dd MBR]* >> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL >> 2018.03-00002-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd >> MBR]* >> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot >> 2018.03-00002-gac9cce7c6a]:[location: dd MBR]* >> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]* >> *kernel:[4.14.108-ti-r137]* >> *nodejs:[v6.14.4]* >> */boot/uEnv.txt Settings:* >> *uboot_overlay_options:[enable_uboot_overlays=1]* >> >> *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]* >> *uboot_overlay_options:[disable_uboot_overlay_video=1]* >> >> *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]* >> *uboot_overlay_options:[enable_uboot_cape_universal=1]* >> *pkg check: to individually upgrade run: [sudo apt install --only-upgrade >> <pkg>]* >> *pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]* >> *pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]* >> *WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]* >> *pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]* >> *pkg:[kmod]:[23-2rcnee1~stretch+20171005]* >> *pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]* >> *pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]* >> *groups:[debian : debian adm kmem dialout cdrom floppy audio dip video >> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep >> admin spi tisdk weston-launch xenomai]* >> *cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 >> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M >> net.ifnames=0 quiet]* >> *dmesg | grep remote* >> *[ 1.147260] remoteproc remoteproc0: wkup_m3 is available* >> *[ 1.231303] remoteproc remoteproc0: powering up wkup_m3* >> *[ 1.231426] remoteproc remoteproc0: Booting fw image >> am335x-pm-firmware.elf, size 217168* >> *[ 1.233981] remoteproc remoteproc0: remote processor wkup_m3 is now >> up* >> *[ 108.634522] remoteproc remoteproc1: 4a334000.pru is available* >> *[ 108.656634] remoteproc remoteproc2: 4a338000.pru is available* >> *dmesg | grep pru* >> *[ 108.019424] pruss 4a300000.pruss: creating PRU cores and other child >> platform devices* >> *[ 108.634522] remoteproc remoteproc1: 4a334000.pru is available* >> *[ 108.634642] pru-rproc 4a334000.pru: PRU rproc node >> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully* >> *[ 108.656634] remoteproc remoteproc2: 4a338000.pru is available* >> *[ 108.656808] pru-rproc 4a338000.pru: PRU rproc node >> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully* >> *dmesg | grep pinctrl-single* >> *[ 0.783913] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 >> size 568* >> *dmesg | grep gpio-of-helper* >> *[ 0.796624] gpio-of-helper ocp:cape-universal: ready* >> *lsusb* >> *Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub* >> *END* >> >> Any ideas? >> >> On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote: >> >>> The PRUs can give you 10's of ns timing, which is more than good enough >>> for milliseconds, but might be over kill. >>> >>> I'd think using C on the ARM processor should be fast enough. I'd use >>> gpiod[1]. >>> >>> If you really want the ns timing of the PRUs, check out the PRU >>> Cookbook[2] >>> >>> --Mark >>> >>> [1] https://github.com/starnight/libgpiod-example >>> [2] https://github.com/MarkAYoder/PRUCookbook >>> >>> On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 [email protected] >>> wrote: >>> >>>> Depending on how precise you need to be, I would go for the PRU-ICSS. >>>> They can control the GPIOs pretty easily. >>>> >>>> Le mardi 16 février 2021 à 10:03:47 UTC-5, [email protected] >>>> a écrit : >>>> >>>>> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP >>>>> PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux >>>>> >>>>> I am writing in C. >>>>> >>>>> I turn a valve on and then need to read some sensors for N >>>>> milliseconds and then turn the valve off. >>>>> >>>>> What's the best way to read milliseconds on the BBBw? I don't have a >>>>> RTC on this particular unit but could add one using I2C. I have an >>>>> Adafruit 4282 with a DS3231 RTC on it on another BBBw that I could use >>>>> temporarily to prove it works. What other options are available? >>>>> >>>>> >>>>> -- 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/b564fa21-687b-4593-ac0c-4753c85736d8n%40googlegroups.com.
