**** BEGIN LOGGING AT Wed Jan 16 02:59:56 2019 Jan 16 03:01:06 it seems like I should be able to echo start or stop into the `/sys/class/remoteproc/remoteproc1/state` but when I do I get permission denied errors :/ Jan 16 03:03:03 I saw that. Jan 16 03:03:11 I think sudo may be required. Jan 16 03:03:46 echo'stop'>state Jan 16 03:03:52 in that dir. Jan 16 03:05:08 I think you are supposed to git clone that bunch of examples and then put them where they belong. Jan 16 03:06:48 for instance: that echo'stop'>state comes from some header file or .c file. Jan 16 03:07:36 Now, linking them together is a difficult process. Jan 16 03:07:54 I know. I have failed until my eye turned blue. Jan 16 03:08:15 I even almost yelled. Aw! Jan 16 03:09:59 clpru --run_linker {--rom_model | --ram_model} filenames [--output_file= name.out] --library= libraryname Jan 16 03:10:00 ... Jan 16 03:10:20 This for example, would I need to put a rom model or ram model in those sections? Jan 16 03:10:26 For real? Jan 16 03:11:30 i.e. pr1_pru1_pru_r31? Jan 16 03:14:33 and for that idea, is the pr1_pru1 the rom model? Jan 16 04:30:21 still poking at this all Jan 16 04:33:09 Aw! Jan 16 04:33:19 Good luck meawoppl. Jan 16 04:35:10 Did you get prudebug? Jan 16 04:53:00 Hello @zmatt No questions. Just saying hi. Jan 16 05:10:10 set_: I don't know what that is Jan 16 05:10:27 I am currently stuck in the step that is supposed to start/stop the pru's Jan 16 05:10:36 which is to echo a string into the state file Jan 16 05:11:02 and I keep getting either Permission Denied (using sudo too), or "IOError" Jan 16 05:13:13 debian@beaglebone:/sys/class/remoteproc/remoteproc1$ sudo echo "start">/sys/class/remoteproc/remoteproc1/state -bash: /sys/class/remoteproc/remoteproc1/state: Permission denied debian@beaglebone:/sys/class/remoteproc/remoteproc1$ sudo sh -c "echo 'start'>/sys/class/remoteproc/remoteproc1/state" sh: echo: I/O error Jan 16 05:18:21 Try going to the dir. and then trying that cmd. Jan 16 05:26:02 same Jan 16 05:26:05 :/ Jan 16 05:34:01 Dang. Well, I guess w/ trial and error, some stuff may show resolve b/c I do not know why my system works and the issue on your side is happening. Jan 16 05:34:02 ... Jan 16 05:34:03 But... Jan 16 05:34:22 Come back and keep coming back. Right? I am sure someone during regular hours will help out. Jan 16 05:34:39 Or...you can try the googlegroups too. Jan 16 05:35:12 You can search the googlegroups too. They have a search feature for older posts. Who knows? You may get lucky. Jan 16 05:36:04 Oh prudebug! Jan 16 05:36:15 It can help solve some problems you may come across. Jan 16 05:38:00 dmesg | grep pru <-- try this cmd and see what pops up Jan 16 05:39:07 sudo -i might work too. Jan 16 05:39:55 I am going over the remoteproc stuff now. It is basically saying that you need to be in root for some of the cmds to work. Jan 16 05:48:43 Oh and you have to use config-pin to set your pins. For instance, if you are using pr1_pru1_pru_r30_5 where 5 signifies something (a gpio), then you need to find what enhanced GPIO pins are located at 5, e.g. GPIO2_11. Jan 16 05:55:00 the pin setting stuff I understand Jan 16 05:57:36 Making progress! Jan 16 05:57:40 [ 4229.020363] remoteproc remoteproc1: powering up 4a334000.pru [ 4229.020454] remoteproc remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2 Jan 16 06:01:00 Yes and no. Jan 16 06:01:52 prudebug is debug info. for pru addresses and stuff (I think). I saw it mentioned in here many times. I saw it in the book, too. Jan 16 06:02:07 I will look again. Jan 16 06:02:31 oh ho ho Jan 16 06:02:44 I got it to echo the start command into the state var w/o puking an error on me Jan 16 06:03:30 That is good news. Jan 16 06:04:34 Oh and meawoppl: Something to take in to account, remember that you need, after every reboot or boot, to set config-pin. Jan 16 06:04:54 It does not last. So, a .sh file and .service file can rid you of doing that over and over again. Jan 16 06:05:49 Can you cmd: cat regs? Jan 16 06:06:13 ? Jan 16 06:06:59 debian@beaglebone:~/exploringBB/chp15/pru/blinkLED$ cat /sys/class/remoteproc/remoteproc1/state running Jan 16 06:07:10 It should dump a bunch of register info. to you in this dir: sys/kernel/debug/remoteproc/remoteproc1. Jan 16 06:08:04 meawoppl: That is what I saw too. My state was running. I thought that meant I ran some software and the PRU is still active. Jan 16 06:08:09 But...most likely not. Jan 16 06:08:26 It means something completely different. Jan 16 06:09:50 https://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg is something I just found. It may be useful. Jan 16 06:11:28 meawoppl: There is a section on that page, the elinux.org page, that shows how to set up clpru so that it can find necessary files for compilation. Jan 16 06:11:45 http://paste.debian.net/1060791/ Jan 16 06:11:54 "PRU is executing, cannot print/access debug registers." Jan 16 06:11:59 seems promising Jan 16 06:15:06 Try, p. 687 on that book. Jan 16 06:15:49 p. 687 is actually two pages. Odd days. Jan 16 06:16:01 so... Jan 16 06:16:05 It is like this. Jan 16 06:16:24 make, make clean, and then make install_PRU0 or make install_PRU1. Jan 16 06:16:42 Right? Jan 16 06:18:18 Is that how you built the instructions? Jan 16 06:19:55 meawoppl: I am sorry I have been typing so much. I just finally cross-compiled a Linux Distro onto a board for the first time (b/c the other times it never worked). I am ecstatic! Jan 16 06:24:26 Are you performing the blinkLED function under PRU dir. in exploringBB? Jan 16 06:28:26 Anyway, you need to figure out how to set your PATH so that clpru can find those files or you can do this alternative. Set up clpru in the dir. of your choice for running clpru which is nonsense. Jan 16 06:29:38 So, if clpru is in /exploringBB/15/pru/clpru, it should be easy to run w/out the PATH set. Jan 16 06:30:00 But to do that over and over in other dir. is wasting time. Jan 16 06:32:03 https://pastebin.com/n87AVwSk is a way supposedly to set up your env. and PATH for clpru. Jan 16 06:36:52 https://pastebin.com/TKXaZbFF is the ideas around setting up .bashrc so you do not have to run it over and over and over and over. Jan 16 07:03:16 set_: clpru is setup on the bbb path by default Jan 16 07:12:46 Oh. Jan 16 07:12:49 That is good news. Jan 16 07:16:22 I just tried to make, make clean, make install_PRU0 in the /pru dir. and it did not go well. Jan 16 07:16:41 I guess everything was already done for everyone. I have no clue right now. Jan 16 07:27:44 hi anyone knows the price in production of beagleboards Jan 16 07:27:57 are they usable in high volume? Jan 16 07:29:17 Guest59529: as usual, ask your trusted distributor. we are not a sales channel/platform. Jan 16 11:44:46 Hi. I have just got a BBB Wireless and a BeagleBoard.org Comms Cape to try and use the CAN bus. I have connected them and ran the following commands `config-pin P9.24 can`, but I get an error "P9_24 pinmux file not found!Pin has no cape: P9_24" Any idea what I am missing? Jan 16 11:52:18 hmm Jan 16 11:52:25 altay: are you booting from sd card or eMMC ? Jan 16 11:52:50 sd card Jan 16 11:53:15 assuming you don't care about it, wipe the contents of eMMC using: sudo blkdiscard /dev/mmcblk1 Jan 16 11:53:20 then reboot and try again Jan 16 11:53:35 (reflashing eMMC would also fix the problem) Jan 16 11:55:28 zmatt: Thanks, I will try that and see how I get on. Thanks for your help. Jan 16 13:19:32 Hey, do you know if it's possible to flash a 4GB beaglebone image to a 32GB sd card? Will it boot from it after (holding USER-button)? Mine seemed to, but never finished flashing the mmc. Resetting it leads to the leds blinking like crazy so it seems alive, but I cant ssh to it either, nor if I remove the Sd-card either. Jan 16 13:19:45 (for firmware upgrade, is the reason for the above) Jan 16 13:20:02 the size of the sd card is irrelevant, as long as it's sufficiently large to hold the image Jan 16 13:20:18 All right, so then something else is wrong hm. Jan 16 13:20:34 "never finished flashing the mmc" ... are you sure it was flashing at all in the first place? Jan 16 13:21:32 I'm pretty sure that if it started flashing but didn't finish it, the result would be a non-booting system (only power led turns on) Jan 16 13:24:24 zmatt: Sorry me again. I was wrong before we are actually booting from eMMC. I did not erase it. Do I need to load an additional overlay at all? Jan 16 13:24:46 altay: are you using an old image maybe? or did you mess with /boot/uEnv.txt ? Jan 16 13:25:07 I havent touch uEnv.txt Jan 16 13:25:22 cat /etc/dogtag BeagleBoard.org Debian Image 2018-10-07 Jan 16 13:25:39 that's odd Jan 16 13:26:02 and you're using a BBB-wireless right? not a BBG-wireless? Jan 16 13:26:36 Yeah, BBB-wireless. I will double check though (BBB is remote and not on my desk, which makes it even harder) Jan 16 13:27:54 Yeah, BBB-Wireless Jan 16 13:28:36 can you use my show-pins utility to check what the current pin configuration looks like? => https://github.com/mvduin/bbb-pin-utils/#show-pins Jan 16 13:30:08 sudo show-pins | sort P8.03 / eMMC d6 6 fast rx up 1 mmc 1 d6 mmc@481d8000 (pinmux_emmc_pins) P8.04 / eMMC d7 7 fast rx up 1 mmc 1 d7 mmc@481d8000 (pinmux_emmc_pins) P8.05 / eMMC d2 2 fast rx up 1 mmc 1 d2 mmc@481d8000 (pinmux_emmc_pins) P8.06 / eMMC d3 3 fast rx up 1 mmc 1 d3 mmc@481d8000 (pinmux_emmc_pins) P8.07 Jan 16 13:30:17 don't paste multiline output into irc Jan 16 13:30:22 Ah, sorry! Jan 16 13:30:25 use a paste service like pastebin.com Jan 16 13:32:04 zmatt I mean "never finished the flashing meaning" I didnt see the 4 leds go lit constantly like it mentions in the guide: "When the flashing is complete, all 4 USRx LEDs will be lit solid." Jan 16 13:32:29 Johan__: what pattern did the leds show? Jan 16 13:33:42 zmatt: https://pastebin.com/BWagDVJ2 hopefully that has worked Jan 16 13:33:45 zmatt at start (now with another SD_card 8GB trying to get flashing working again) the rightmost led double blinks each second and the 3rd blinking around 6hz or so Jan 16 13:33:52 if it's flashing eMMC, the leds follow a regular back-and-forth pattern: 0 1 2 3 2 1 0 1 2 3 2 1 0 etc Jan 16 13:34:22 zmatt but the disk is also available in windows, like a usb-mounted disk, so that is strange, i dont think that should be available at this point Jan 16 13:34:34 zmatt ok so it's not flashing now Jan 16 13:34:34 i.e. it has booted normally Jan 16 13:35:16 zmatt: I've just been told its a BBB, and not wireless, not sure if that makes any difference or not to this issue though Jan 16 13:35:45 altay: okay, the universal overlay isn't loaded for whatever reason, hence config-pin won't work Jan 16 13:35:46 Would you say, this is correct (write image "bone-debian-9.5-iot-armhf-2018-10-07-4gb.img to a sd card, then having bbb powered off, inserting card, pressing user button close to ethernet connector, then power on, waiting for all 4 leds going lit is correct procedure? Jan 16 13:36:09 pressing and holding... Jan 16 13:37:07 Johan__: generally speaking you don't have to press any button to boot from sd card. in rare cases you may need to hold the S2 button (which is the one closest to the sd card slot, not close to the ethernet connector) during power-up (i.e. you can led go once the power led turns on) Jan 16 13:37:29 in any case you'll just boot from the image, it is not going to reflash anything Jan 16 13:37:51 unless you modified the /boot/uEnv.txt file on the sd card as indicated in the instructions for reflashing Jan 16 13:39:01 altay: can you pastebin the contents of /boot/uEnv.txt ? Jan 16 13:40:03 zmatt: https://pastebin.com/Kqf8eUZf Jan 16 13:40:16 zmatt: Thanks for your help with this Jan 16 13:40:18 zmatt I was disconnected for some reason, what you wrote is gone. Could you repost? Jan 16 13:41:06 johan__: https://pastebin.com/raw/YVs2tbBM Jan 16 13:45:27 altay: weird Jan 16 13:45:35 zmatt: Not sure if this output from `dmsg` is of any use, but it says there is a failure loading the BBORG_COMMS cape: https://pastebin.com/suYFkgzH Jan 16 13:45:54 the kernel shouldn't even be trying Jan 16 13:46:00 are you really sure you're not booting from sd card? Jan 16 13:46:06 what does findmnt / say? Jan 16 13:46:19 is it /dev/mmblk0p1 or 1p1 ? Jan 16 13:47:03 zmatt: mmblk0p1 Jan 16 13:47:24 sorry, mmcblk0p1 Jan 16 13:47:39 you're booting from sd card. Jan 16 13:47:48 original solution applies Jan 16 13:47:49 zmatt thanks. I meant the button close to the sdcard connector. Ok i will try without pressing. Any Idea on how to verify it has booted from the sdcard and not the mmc when it's ready? Jan 16 13:48:51 johan__: for one, powering up with the S2 button held down will ensure that it won't boot from eMMC. it will either boot from sd card, or not at all Jan 16 13:49:21 you can also easily check after boot by logging in and using findmnt / as I just had altay do Jan 16 13:50:17 it should also be possible to tell from the led activity during boot, but I'd need to dig up which led the standard image uses for eMMC and which for uSD (our own images use different led assignment) Jan 16 13:53:32 zmatt: Thanks for your help. From looking at the conversion you are having with johan__ it looks like it is fairly straight forward to reflash the eMMC. Jan 16 13:54:02 sure, uncomment the emmc-reflashing line in /boot/uEnv.txt (iirc it's the last line of the file) and reboot Jan 16 13:54:22 then once it has finished flashing, someone needs to physically eject the sd card Jan 16 13:54:56 Brilliant, thanks so much zmatt. I am going to try this now. Jan 16 13:55:24 make sure you don't have an ancient beaglebone with only 2GB of eMMC, since in that case it's not going to fit Jan 16 13:55:36 nm, you don't Jan 16 13:58:07 zmatt: Yeah, only delivered this week, so assume its fairly new. Jan 16 13:58:58 yeah it was manufactured in week 29 of last year Jan 16 14:03:23 zmatt it boots from emmc no matter if i press the user button or not. very confusing. I took the image from the beaglesite and write it. Confusing. Its not working then. I will need to try another image Jan 16 14:03:58 maybe something went wrong with writing the image? Jan 16 14:04:09 also, what you're saying is not possible Jan 16 14:04:23 like I said earlier, if you power up with the S2 button held down, it will _not_ boot from eMMC Jan 16 15:08:28 ls **** ENDING LOGGING AT Thu Jan 17 02:59:57 2019