**** BEGIN LOGGING AT Sun Jul 22 03:00:00 2018 Jul 22 04:35:24 e Jul 22 13:28:47 after moving my $USER to my SD card mounted in /media/store as ext4 file format and changing the path in /etc/passwd I am unable to exicute c++ binary files. anyone know what I need to do? Jul 22 13:35:34 i get this when i try to execute swaine@beaglebone:~$ ./newremoteLED -bash: ./newremoteLED: Permission denied swaine@beaglebone:~$ sudo ./newremoteLED sudo: unable to execute ./newremoteLED: Permission denied Jul 22 13:40:10 that shouldn't relate to your changed home Jul 22 13:40:24 are you sure your user owns the file and it's marked +x? Jul 22 13:41:23 looks like it. -rwxrwxr-x 1 swaine swaine 105160 Jul 22 08:35 newremoteLED Jul 22 13:42:41 ah, is the mount using the noexec option? Jul 22 13:46:06 that I do not know. is there a way to check? Jul 22 13:46:24 I dont recall using a noexec option when I mounted it Jul 22 13:50:50 if I move an executable to my root directory they execute. Jul 22 13:56:20 look in your fstab Jul 22 13:56:25 in /etc/fstab Jul 22 13:57:27 for example my sdcard is: /dev/mmcblk0p1 /home auto auto,rw,async,user,nofail 0 0 Jul 22 13:57:42 (not to say yours should look identical) Jul 22 13:57:51 but if you see noexec in that line, it'd be the issue Jul 22 13:58:05 the output of "mount" with no option/parameters should include the info Jul 22 13:58:38 it does yeah, but it also displays a LOT of other stuff, I was trying to keep it simple :) Jul 22 13:59:08 # /etc/fstab: static file system information. # /dev/mmcblk1p1 / ext4 noatime,errors=remount-ro 0 1 debugfs /sys/kernel/debug debugfs defaults 0 0 UUID=940cef3e-7b98-4eb1-81d8-8108d29c0b17 /media/store ext4 defaults,nofail,user,auto 0 0 Jul 22 13:59:14 thats my fstab file Jul 22 13:59:16 mount /media/store Jul 22 13:59:24 that will just output one line Jul 22 14:00:56 well it's not noexec Jul 22 14:01:29 i did find this when I used mount with no option.. /dev/mmcblk0p1 on /media/store type ext4 (rw,nosuid,nodev,noexec,relatime,data=ordered,user) Jul 22 14:01:43 *ding* Jul 22 14:01:46 noexec is in there Jul 22 14:02:19 do I need to remount without using that option somehow? Or is there a way to take that option out. Jul 22 14:02:19 that means you will not be allowed to run any binary/script from there Jul 22 14:02:51 try adding 'exec' to the options for /media/store and rebooting Jul 22 14:03:16 how do I do that? Jul 22 14:03:32 .. I mean how do I add exec to the options Jul 22 14:03:42 you edit the file, as root Jul 22 14:04:03 "/media/store ext4 defaults,nofail,user,auto" → "/media/store ext4 defaults,nofail,user,auto,exec" Jul 22 14:06:02 edit the fstab file correct? Jul 22 14:06:09 yes Jul 22 14:10:20 'user' by default implies 'noexec,nodev,nosuid' Jul 22 14:10:22 iirc Jul 22 14:12:18 that did it! I appreciate all the help. I learn that much more everytime I talk to anyone on here. Jul 22 16:46:17 What is the difference dcan1 and can1? Jul 22 17:24:40 What is the difference dcan1 and can1? Jul 22 17:24:49 the letter 'd' Jul 22 17:24:59 Oh Jul 22 17:25:13 context? Jul 22 17:25:37 'dcan' is the name of the particular design of CAN controller used on the am335x Jul 22 17:25:56 both can instances are dcan modules Jul 22 17:26:03 Used to see dcan1 to set up can cape now i see can1 in lib/firmware Jul 22 17:27:52 on recent images in default config you don't need to use an overlay to enable can1, it's enabled by default. you just need to configure the pins using the config-pin utility Jul 22 17:51:18 what is the meaning of "of" in "of_id" "dev->of_node" "MODULE_DEVICE_TABLE(of..." ? Jul 22 17:52:33 open firmware Jul 22 17:52:43 that's the origin of DTs Jul 22 17:54:36 in systems that use Open Firmware, the firmware makes a devicetree that can also be queried by the OS. linux would during early loading iterate over that and build a flattened data structure out of that, the dtb, to pass to the later stages when calling into OF would no longer be possible Jul 22 17:56:40 these dtbs were then reused for ARM and probably other embedded systems, where the dtb isn't produced by firmware but just loaded from a file Jul 22 18:00:48 I see Jul 22 21:18:28 How do you debug whether or not your cape is loaded? Jul 22 21:36:48 Unee0x: it's typically easy to tell from the current pin configuration Jul 22 21:37:31 on older (pre-uboot-overlays) systems you can also inspect /sys/devices/platform/bone_capemgr/slots Jul 22 21:38:31 on current systems you can check the serial console to see the log messages of u-boot loading the overlays Jul 22 21:38:41 Are you saying the cape is only loaded into a slot if it’s connected? Jul 22 21:39:47 in all cases you can just inspect the pin config (e.g. using https://github.com/mvduin/bbb-pin-utils/#show-pins ) or the device tree (via /proc/device-tree ) Jul 22 21:40:21 Ok. Checking now thanks Jul 22 21:40:27 overlays are loaded either Jul 22 21:40:37 1. because a cape was autodetected Jul 22 21:40:38 or Jul 22 21:40:47 2. because you manually specified one in /boot/uEnv.txt Jul 22 21:41:34 "the cape is only loaded into a slot if it's connected?" ... ehh, how would you imagine an overlay for a cape would get loaded if that cape isn't connected? Jul 22 21:41:52 I mean, unless you request it manually, then autodetection doesn't matter Jul 22 21:42:58 Ok zmatt, you’ve very helpful... Jul 22 21:52:00 Unee0x: btw, just to warn of a common issue: if you're booting from sd card rather than eMMC, you'll probably want to erase eMMC (sudo blkdiscard /dev/mmcblk1) to prevent an old bootloader on eMMC being used to boot linux from SD card Jul 22 21:52:22 otherwise you can end up with non-functioning u-boot overlays Jul 22 21:52:33 (if the u-boot on eMMC is too old) Jul 22 21:56:06 I’m not booting from sd, but that’s good info Jul 23 00:16:23 Loiter Mode w/ the BBBlue and ArduCopter! Jul 23 00:16:39 myself: I am onto calibration of the components next. Jul 23 00:16:40 ... Jul 23 00:17:21 I have to "calibrate" my GPS, my other thing, and something else. Jul 23 00:17:33 Then...onto the real task. Flight control! Jul 23 00:17:51 "Ready to Fly" is already on my terminal screen. Jul 23 00:18:18 ... Jul 23 00:18:55 If anyone is using arducopter, look here: https://github.com/imfatant/test. This is a start. Jul 23 00:21:26 I made a look-alike here at: https://www.hackster.io/silver2row/bbblue-and-getting-arducopter-to-run-c034dd. Jul 23 00:21:34 ... Jul 23 00:21:41 Do not laugh but I went backwards. Jul 23 00:25:29 Ouch! Jul 23 00:27:28 I tried to give credit but I think I failed b/c the Header Photo was taken from BBBlue stuff at github.com and I did not create it. Jul 23 00:27:31 Is that right? Jul 23 00:29:11 Oh...do I need to give credit to BeagleBoard.org for that specific Header Photo? Jul 23 00:29:45 i.e. at the hackster.io/silver2row address? Jul 23 00:33:48 https://hackster.imgix.net/uploads/attachments/529695/bbblue_67mh0FeqJy.png?auto=compress%2Cformat&w=900&h=675&fit=min Jul 23 00:33:56 ^ that photo! Jul 23 00:38:07 brb Jul 23 02:12:31 Sorry...I got lost on the bench. Jul 23 02:12:43 Damn LiPo batteries. Jul 23 02:21:11 My battery tester went out. I know! I am out of c2023s. Boo! Jul 23 02:22:06 The battery has spark but it is not ready for a full-fledged take off. Jul 23 02:24:11 myself: Are you getting this? Jul 23 02:24:37 Oh...myself left. Boo! Jul 23 02:28:07 I just saw a .zip file on the BBBlue page on GitHub.com for the enclosure. Jul 23 02:28:12 stl? Jul 23 02:28:53 Wait. Would I just unzip that file, the .zip file, and get an .stl file out of it? Jul 23 02:35:23 it tis! Jul 23 02:35:45 three .stl files out of one .zip. Magic! **** ENDING LOGGING AT Mon Jul 23 03:00:01 2018