**** BEGIN LOGGING AT Wed Mar 17 02:59:56 2021 Mar 17 03:06:21 I think I have a bug on my AI... My uEnv.txt file is in a /tmp dir... Mar 17 09:28:55 Hi! I have a problem with the bus can. I would like to do some tests with the cansend command (I have installed everything I need and set pins 9_19 and 9_20 as possible). Mar 17 09:28:57 When I type for example: Mar 17 09:28:59 cansend can0 5AA # Mar 17 09:28:59 I am given this error: Mar 17 09:28:59 write: network is down Mar 17 09:30:34 Sorry I'm using a translator, I meant that I set pins 9_19 and 9_20 in can Mar 17 10:23:39 Hi! I have a problem with the bus can. I would like to do some tests with the cansend command (I have installed everything I need and set pins 9_19 and 9_20 in can). Mar 17 10:23:46 When I type for example: Mar 17 10:23:53 cansend can0 5AA #beagle Mar 17 10:24:31 cansend can0 5AA# Mar 17 10:24:37 I am given this error: Mar 17 10:24:44 write: network is down Mar 17 10:50:09 Hi! I have a problem with using the can bus. I would like to use cansend (I have installed everything that is needed and I have set pins 9_19 and 9_20 as can). Mar 17 10:50:10 When I enter the command: Mar 17 10:50:10 cansend can0 213 ## 311 Mar 17 10:50:11 I am given this error: Mar 17 10:50:11 write: Network is down Mar 17 12:46:26 Hello, I have two BeagleBone Blacks, I want to connect to either one with my iMAC, I am running a macOS which the driver installation tells me is not supported I have macOS Big Sur version 11.2.3, is there any option for me? Mar 17 12:47:20 if you're running the latest image it should work plug&play, no driver installation required Mar 17 12:47:35 also, connecting via ethernet instead of usb is always an option Mar 17 12:47:48 I just dug them out of a box from several years ago....so they won't be up to date. Mar 17 12:48:15 I don't know the IP address, or at least I thought I did but it doesn't respond to ping Mar 17 12:48:39 even if you received them today there'd be no reason to assume they're uptodate, you never know how long it's been sitting in a box in a warehouse somewhere Mar 17 12:48:51 the way to ensure they're uptodate is by reflashing them Mar 17 12:49:09 and instead of ssh'ing to an IP address, try ssh debian@beaglebone.local Mar 17 12:49:30 I can't connect to them at the moment, thats the problem.  I need t know what IP they are on. Mar 17 12:49:55 on a Mac (and usually on Linux) using the hostname.local will work no matter what IP address the beaglebone has, so you don't need to worry about IPs Mar 17 12:50:47 but the host name is only known to the device isn't it? Mar 17 12:51:04 (but, for completeness, the beaglebone's IP when connected via usb will be 192.168.6.2) Mar 17 12:51:16 a .local hostname uses "multicast dns" name resolution Mar 17 12:51:30 basically it just shouts on every network interface "HEY, who here is beaglebone.local ?" Mar 17 12:51:52 :)  I have a response from 192.168.6.2 Mar 17 12:51:55 thank you Mar 17 12:52:27 if you try beaglebone.local instead of the IP with ping it should work too Mar 17 12:52:47 can I ssh into a BB using the USB IP ? Mar 17 12:53:11 yes, ssh debian@beaglebone.local or ssh debian@192.168.6.2 Mar 17 12:53:42 trying now....not happening atm Mar 17 12:54:29 in all cases I still strongly recommend you first reflash to the latest image Mar 17 12:54:37 especially if they're *known* to run ancient firmware Mar 17 12:55:29 is there an idiots guide on how to do that?  Its literally years since I messed around with these... Mar 17 12:55:55 download the latest AM3358 flasher image (currently "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher") from https://beagleboard.org/latest-images Mar 17 12:56:18 write it to SD card using Etcher (https://www.balena.io/etcher/) Mar 17 12:57:07 boot the beaglebone from SD card... this is *usually* as simple as sticking the card in and rebooting/power-cycling the beaglebone Mar 17 12:57:08 Thanks for your help Mar 17 12:57:52 downloading both now...will take a look when done. Mar 17 12:58:25 but if the bootloader on eMMC is sufficiently ancient it may be too incompatible to be able to boot the flasher card, in which case you need to bypass the eMMC bootloader by powering on while holding down the S2 button (the one closest to the card slot) .. you can let go of the button once the power led turns on Mar 17 12:59:48 it's easy to tell if it's reflashing by the led pattern: after a few seconds of booting (with "normal" led activity), the four leds start showing a back-and-forth pattern (a.k.a "knight rider" or "cylon") Mar 17 13:00:17 thanks Mar 17 13:00:35 have to hunt down my SD cards now... Mar 17 13:01:04 you can of course use other tools to flash the sd card, but Etcher is recommended because 1. it can decompress .xz files on-the-fly so you don't have to decompress it first 2. it will verify the image on the sd card after writing it Mar 17 13:01:48 will give it a go. Mar 17 13:02:20 once it's done the beaglebone will turn itself off Mar 17 13:03:13 once you've reflashed both beaglebones it's probably a good idea to erase the sd card so you don't accidently boot a beaglebone from it and reflash it again :) Mar 17 13:09:59 SD card now ready, going to insert into BBB and try. Mar 17 13:10:16 Flashing now... Mar 17 13:10:40 I thought it was ready but that was just decompressing... Mar 17 13:11:04 it shouldn't have a separate decompressing phase Mar 17 13:11:38 I selected the DMG file then the media, it decompressed first, now its flashing. Mar 17 13:11:56 the .img.xz file you mean? Mar 17 13:12:06 I think because it was a DMG, it decompressed this to the IMG Mar 17 13:12:19 ?? Mar 17 13:13:02 The download was img.xz, I think it decompressed this to .img Mar 17 13:13:28 50% now Mar 17 13:13:46 my understanding is that it would do so on the fly, not in a separate phase, but I've never actually used Etcher Mar 17 13:14:12 separately decompressing the image would require a ton of extra disk space and would in general be a silly thing to do Mar 17 13:14:40 maybe MacOS was trying to helpful and did it for it or something Mar 17 13:15:03 I don't see any .img file in the file system, I have a lot of memory 16GB so I assume its all in memory whilst its flashing. Mar 17 13:15:41 right, but then there wouldn't be a separate phase, it would just be flashing/verifying (while decompressing at the same time) Mar 17 13:16:20 well thats what I saw...almost finished flashing. Mar 17 13:16:48 Now validating .... Mar 17 13:17:04 I should probably try out Etcher myself some time so I know what people can expect to see :P Mar 17 13:17:08 does it take long for the SD card to flash the BBB ? Mar 17 13:17:18 not too long usually Mar 17 13:17:28 ok, I have two to do Mar 17 13:18:58 well it's not like you have to synchronously wait for the second one, you can just leave that one flashing while you start trying to work with the first one Mar 17 13:19:26 Now finished, ejecting and will try it now. Mar 17 13:21:47 Lots of LED activity Mar 17 13:22:02 What will I see when its done? Mar 17 13:22:52 is it showing a back-and-forth sweep across the four leds? (0 1 2 3 2 1 0 1 2 3 2 1 0 etc) Mar 17 13:23:25 No, just the top LED flashing Mar 17 13:24:03 that sounds like it may just have booted from eMMC, try powering on with the S2 button held down. Mar 17 13:24:31 I've just pulled the power and held down the button on the opposite side of the PCB to the SD Card Mar 17 13:24:45 heartbeat-flashing of led0 is just the "system is running normally" indicator Mar 17 13:26:57 here's a trick if you're not sure whether you were successfully holding down the tiny S2 button (in my experience it can be fiddly sometimes): remove SD card, power on with S2 button held down... the expected result is that it's not booting at all (just power led, no other led activity), now insert the sd card and press the reset button (S1, in the corner of the pcb near the leds) Mar 17 13:29:12 also, just to verify, you *did* download a flasher image? (bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) ? if you downloaded the non-flasher image (bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) you'll need to let it boot normally then log in via ssh and modify a config file to turn it into a flasher image Mar 17 13:29:55 (or download the flasher image and write it onto the sd card, but that's more work than modifying the non-flasher into a flasher) Mar 17 13:30:19 That worked thank you, removed SD card, powered up with S2 down, no LED's on....inserted SD Card, pressed S1, all LED's came on from top to bottom, now all LED's are on and top is flashing. Mar 17 13:30:38 How will I know when its complete? Mar 17 13:31:22 is it showing a back-and-forth sweep across the four leds? (led0 led1 led2 led3 2 1 0 1 2 3 2 1 0 etc) Mar 17 13:32:02 no, the top led is flashing constantly, others are flickering now and then Mar 17 13:33:08 that sounds like you didn't download a flasher image but a normal image, i.e. it's just booting normally into linux Mar 17 13:34:32 sorry, you are correct, I will download and try again Mar 17 13:34:38 that's no biggie, you can just log in an uncomment the last line of /boot/uEnv.txt ("cmdline=init=...") and reboot Mar 17 13:34:55 that's the only difference between a normal image and a flasher Mar 17 13:36:29 Downloading the correct image now. Mar 17 13:36:43 ... or you can do that if you prefer I guess Mar 17 13:37:19 Presently I cannot connect to the BBB except with USB, thats why I need to reflash Mar 17 13:37:39 ?? Mar 17 13:38:08 I don't know what the login details are, I set these up years ago. Mar 17 13:38:11 isn't it connected via usb right now? if you cannot connect to the beaglebone when booted from the normal image on sd card Mar 17 13:38:18 then you wouldn't be able to after reflashing either Mar 17 13:38:24 Yes, but I cannot login because I have no details Mar 17 13:38:46 you've booted from a fresh image on sd card, the login details are the defaults Mar 17 13:38:52 (login debian password temppwd) Mar 17 13:39:09 But I haven't refreshed have i Mar 17 13:39:21 no but you've booted from sd card, not from your old system on eMMC Mar 17 13:40:00 I see Mar 17 13:40:32 so you should be able to ssh debian@beaglebone.local (password "temppwd") Mar 17 13:41:31 ok, but I've started refreshing the SD card now. Mar 17 13:41:40 *Reflashing Mar 17 13:41:57 k Mar 17 13:53:49 Now I have knight rider activity Mar 17 13:58:24 ok it'll turn itself off once it's done Mar 17 13:58:26 brb meeting Mar 17 15:00:56 how long should I expect to wait for an SD card reflash to complete? Mar 17 15:01:39 10-20 minutes Mar 17 15:02:28 and then what, because the knight rider effect stopped, but there was still flashing on the lights Mar 17 15:02:44 all leds flashing at the same time? Mar 17 15:03:47 no Mar 17 15:03:52 no set pattern Mar 17 15:04:49 uhh, that makes no sense, I've never seen or heard of that, I don't even see how that would be possible in theory Mar 17 15:05:43 I'll have another go... Mar 17 15:06:56 even if it were to somehow get power-cycled, it would just reboot into the flasher and reflash it again Mar 17 15:07:53 once the flasher has started, the only way to get it to boot normally should be for the flasher to complete, then remove the sd card, and then power-cycle Mar 17 15:08:12 ok, knight rider effect has started, leaving now... Mar 17 15:16:22 is there a copy of the beaglebone root filesystem online somewhere? I would like to look through it's systemscripts Mar 17 15:22:50 Knight Rider effect has finished...now all lights flashing together Mar 17 15:23:31 zmatt, sorry I got timeout... Mar 17 15:23:35 knight rider effect, is that the same as cylon? Mar 17 15:23:47 yes Mar 17 15:24:09 Sy88: so you said you got these beaglebones a "few years" ago, how many is "a few" exactly? :P Mar 17 15:24:13 its stopped doing that now, just flashing twice then off Mar 17 15:24:35 when the BeagleBone Black first came on the market Mar 17 15:25:28 see, that would have been useful to know sooner, since that means you have an early version which only had 2GB of eMMC instead of 4GB Mar 17 15:25:39 It would have been 2013 Mar 17 15:25:53 yeah that's not "several years", that's nearly a decade Mar 17 15:26:17 so I'm guessing I need. different image? Mar 17 15:27:27 the IoT image won't fit on it. your options are 1. wipe eMMC, just boot from SD card 2. flash a minimal image onto eMMC and just install things you need (instead of starting with an image that has everything and the kitchen sink preinstalled) Mar 17 15:27:43 Is there a revision number on the circuit boar that would help identify it Mar 17 15:28:19 my rev A5A had a sticker which said so, dunno if such a sticker is on all of the early ones Mar 17 15:28:22 I don't need a GUI, just want to use nodeJS on them Mar 17 15:28:39 no steakers Mar 17 15:28:52 oh the IoT image doesn't include a GUI either, that doesn't even fit in 4GB nowadays... stuff is so bloated -.- Mar 17 15:29:43 if you just want a basic linux system and nodejs, I'd suggest flashing the latest console image: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console and then installing nodejs Mar 17 15:31:06 thank you 👍 will have a go Mar 17 15:31:33 which one SD-card or EEMC Mar 17 15:31:36 *eMMC Mar 17 15:31:38 Hi, I tried to debug the spi interface using the oscilloscope when running the spidev_test. I do receive the bytes stream on the MOSI pins but somehow the data is not received by the MISO pins. Also the data is transmitted as per the spi clock but it is very noisy. Mar 17 15:31:55 Sy88: though installing stuff does require the BBB to have internet access (well, not strictly "require" I guess, but it'll be tricky without it) .. if there's no convenient way to connect the BBB to your local network via ethernet, then (assuming your iMac has internet via wifi) you could connect it via ethernet to your iMac and enable internet sharing to it Mar 17 15:32:06 Still the spidev_test returns stream of 0's. Mar 17 15:32:26 thats ok, I have access... Mar 17 15:32:30 I hope Mar 17 15:33:00 Sy88: and to flash to eMMC you'd want the eMMC flasher obviously Mar 17 15:33:12 Sy88: bone-eMMC-flasher-debian-10.5-console-armhf-2020-08-25-1gb.img.xz Mar 17 15:34:20 Sy88: installing nodejs via apt will by default get you nodejs 10 on debian buster, follow these steps to get nodejs 12 instead: https://pastebin.com/fAGYJRTp and you can probably just replace the "12.x" by "14.x" in step 1 to get nodejs 14 Mar 17 15:36:22 AnandPrakash[m]: "very noisy" suggests a problem with your measurement setup Mar 17 15:37:17 AnandPrakash[m]: which board are you using? Mar 17 15:37:54 Beaglebone AI Mar 17 15:39:45 ok... haven't gotten around to testing spi on the BBAI, but it works fine on the beagleboard-x15 which uses the same SoC, so it seems very unlikely there are hardware issues with spi on the BBAI Mar 17 15:40:11 and I'm fairly sure other people have used SPI on the BBAI with success Mar 17 15:45:08 Its one of the basic interfaces, should have been straight forward to configure..however I do not find any example on the internet where spi interface is used with other device. Mar 17 15:47:07 * Its one of the basic interfaces, should have been straight forward to configure..however I do not find any example on the internet where spi interface(on Beaglebone AI ) is used with other device . Mar 17 15:47:08 yes it should be straightforward, or at least it is on normal beaglebones, but even on the BBAI it should be as straightforward as anything is on the BBAI :P Mar 17 15:50:12 honestly it should just have shipped with working cape-universal just like on other beaglebones, despite the padconf erratum, since ultimately it got ignored anyway Mar 17 15:51:03 I do find lot of content where it says how to enable a SPI interface on Beaglebone AI. However, not any on a working SPI interface. for example : https://github.com/adafruit/Adafruit_Blinka/pull/397 Mar 17 15:52:16 the spi controllers are the same as on the AM335x, there shouldn't be any significant difference other than getting pin configuration right Mar 17 15:56:30 which pins are you trying to use? Mar 17 15:58:45 I tried with pins P9.21B and P9.18A as MISO and MOSI pins and also with P9.29A and P9.30 pins. Mar 17 16:10:26 zmatt, so the flash completed in that all the lights went out and I then unplugged and reconnected....but I cannot ping 192.168.6.2 Mar 17 16:11:30 All the lights are on solid Mar 17 16:11:49 uhhh Mar 17 16:14:56 Sy30: I'm really puzzled... early boot failure? there shouldn't be any problem with the latest image on early BBB revisions, and more importantly if there were then the flasher image itself also shouldn't have booted Mar 17 16:15:29 I just tried again, now all the lights have gone out. Mar 17 16:15:41 ?? Mar 17 16:16:07 ugh what is it today with people having bizarre issues with things that should just work Mar 17 16:18:47 you may need to just try stuff yourself for a bit since I'm running out of tech-support-energy :P Mar 17 16:26:05 * AnandPrakash[m] uploaded an image: (9KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/NDMyppUOcmIWCACjqDLaOYSO/bbai_console.PNG > Mar 17 16:26:27 I've made a quick summary of BBAI mcspi pins: https://pastebin.com/F6Ew9nnW Mar 17 16:26:28 This is my bbai output when I run the spidev test Mar 17 16:27:09 And here is the waveform image from oscilloscope Mar 17 16:27:16 * AnandPrakash[m] uploaded an image: (1127KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/mSgIkFGjCwIJkOFObIIPoZea/tek00000.png > Mar 17 16:27:21 AnandPrakash[m]: in the future, instead of screenshotting text, share it using a paste service like pastebin.com Mar 17 16:27:54 @zma Mar 17 16:28:15 sure Mar 17 16:28:34 that scope capture looks fine Mar 17 16:29:01 tiny bit of overshoot but that's probably due to wiring Mar 17 16:30:29 that ramp in between the bytes may look weird but that's just because mosi goes high-impedence between transfers Mar 17 16:30:59 (it'll get pulled low or pulled high depending on how internal pull has been configured) Mar 17 16:33:37 okay this explains a bit regarding the waveform..but I should atleast receive the same response, right? Mar 17 16:34:18 maybe just to be sure try it with something other than this spidev_test ? e.g. install python3's spidev module with "pip3 install spidev" and then try the code snippet at the bottom of this paste: https://pastebin.com/nS6FELGH (lines 53-58) Mar 17 16:34:25 but with SpiDev(2,0) Mar 17 16:36:08 and/or try it with a different wire for the loopback connection... I've definitely been bitten in the past by a wire that turned out to have an internal break Mar 17 16:37:21 or maybe your board is haunted by ghosts, try an exorcism ;) Mar 17 16:38:23 I kinda need to go though... I'll *try* to get around to testing spi on the BBAI myself later today Mar 17 16:38:47 okay so I have already tried the loopback connection which didn't work either. Mar 17 16:39:06 I will try to use the python library Mar 17 17:59:10 What script actually loads up the usb gadget interface? I can't seem to find it in the rootfs Mar 17 18:00:44 I think that's changed over time... if fully uptodate then it's in the scripts from the bb-usb-gadgets package (dpkg -L bb-usb-gadgets) Mar 17 18:01:33 if you don't have that package installed, it's done by scripts in /opt/scripts/boot/ Mar 17 18:02:01 in all cases /opt/scripts/boot/generic-startup.sh is the starting point Mar 17 18:02:10 (invoked by generic-board-startup.service) Mar 17 18:11:09 haha found it. Mar 17 18:11:48 yup thats where it was in opt/boot Mar 17 18:16:52 yeah, am335x_evm.sh Mar 17 19:46:42 Hi, I have systemctl script to start/stop/restart canbus interface. 1. it runs from /etc/init.d. But the interface can0 doesn't show. I need to run systemctl restart can_if again. Mar 17 19:47:21 it probably runs too soon then Mar 17 19:47:46 needs pre-condition, such as network ? Mar 17 19:50:11 there's more than one solution for this... you could either have an udev rule for the can interface with ENV{SYSTEMD_WANTS}="can_if.service" instead of having any WantedBy in your service's [Install] section Mar 17 19:51:10 or pull in something that waits until udev is entirely done with loading modules and setting things up, I'd need to check what the correct dependency is for that Mar 17 19:51:47 I already have the script, Can you take a look the script for me, please? Mar 17 19:52:20 It was downloaded from internet, not my creation Mar 17 19:52:51 oh you're using a legacy init.d script? that's kinda obsolete and deprecated, dunno if appropriate dependencies can be expressed in that (or how) Mar 17 19:52:58 yes Mar 17 19:53:18 and feel free to link to the script of course Mar 17 19:53:36 it might have a straightforward translation to a systemd service Mar 17 19:54:10 https://pastebin.com/RcHRSJ6e Mar 17 19:54:43 It seems the script is called 3 times. Mar 17 19:55:36 It works well, if it starts. Mar 17 19:56:03 brb, pizza is ready Mar 17 20:00:58 2 issues: 1. It seems called 3 times, the echo "frc-.." line is written 3 times. 2. It needs a restart or stop/start for ifconfig to show can0/can1 (two CANs) Mar 17 20:04:39 you shouldn't be doing any configuration at the top of the script regardless, you should only do that in the start-section... but regardless, like I said init.d scripts are deprecated anyway, and I don't think you can express the relevant dependencies in one anyway... I'll see if I can cook up a suggestion, once I'm done eating my pizza Mar 17 20:04:40 these are dmesg text for CAN_IF: https://pastebin.com/SDkfFhAV Mar 17 20:05:14 setting up both interfaces in one script also complicates things a bit... and what are these gpios you're configuring? Mar 17 20:05:15 Thank you Mar 17 20:06:27 GPIO pins, I added. These are hardware required to turn on/off power for can module, and set can modes gpio pins Mar 17 20:07:30 btw when changing a gpio to output you should do so by specifying the initial output level, i.e. "echo low >/sys/class/gpio/gpio60/direction" and "echo high >/sys/class/gpio/gpio115/direction" since you can't really change a gpio to output without having a value to output. writing "out" to direction is (regrettably) regarded as a synonym for writing "low" Mar 17 20:10:20 thanks. good to know Mar 17 20:11:34 probably the more elegant solution overall is using a DT overlay to enable CAN and setup the gpios and then configure your can interfaces in /etc/network/interfaces in which case you don't need any custom startup script at all Mar 17 20:11:54 DT overlay requires any compilation, or just some configuration? Mar 17 20:12:32 I have never used DT overlay stuff Mar 17 20:13:06 but I know DT overlays are generally considered intimidating (and setting up gpios in an overlay requires disabling cape-universal I think, i.e. forcing you to do all pin configuration using overlays instead of using config-pin) Mar 17 20:14:18 If too much, I have to give up, due to tight schedule. Mar 17 20:14:20 here's an example of an overlay that sets up can0 (using my overlay-utils, which makes overlays easier to read in general): https://github.com/mvduin/overlay-utils/blob/master/can0.dtsi Mar 17 20:14:24 yeah no worries Mar 17 20:14:28 pizza almost done Mar 17 20:14:56 a proper systemd service for the setup script also shouldn't be a problem Mar 17 20:15:01 enjoy your pizza, first Mar 17 20:16:46 run script from service instead of init.d with rc0.d..., etc Mar 17 20:20:49 can0.dtsi needs to be compiled to generated dbt file, and install as overlay? It is intimidating. I have done yocto, which is easier after bitbake tools setup.But to compile BeagleBone source, needs a lot of tools setup, and source code, too. Mar 17 20:22:10 tiger: 'make can0.dtbo' in a checkout of the repository, then configure the path to the overlay into one of the "custom cape" variables in /boot/uEnv.txt (uboot_overlay_addr4..7 and dtb_overlay) Mar 17 20:24:11 the fact that you can configure only 5 custom overlays isn't really a limitation: overlay-utils also lets you easily combine multiple overlays into one, e.g. https://pastebin.com/JaHr6DHz Mar 17 20:24:35 gpio-demo.dtsi is an example of setting up gpios Mar 17 20:25:32 Needs debian Host PC to compile 'make can0.dtbo' ? Mar 17 20:26:37 but like I said (and like the comment at the top of that file says), this isn't compatible with cape-universal, so that would need to be disabled (comment out the enable_uboot_cape_universal line in /boot/uEnv.txt), which means config-pin will no longer work and to get gpios exported you must configure them in your overlay (like gpio-demo does) Mar 17 20:27:06 also, again, you don't have to do this, you can stick with cape-universal and a startup script if you prefer Mar 17 20:27:55 ("cape-universal" aka the universal overlay is basically a giant overlay that enables most peripherals, exports all gpios, and creates "pinmux helper" devices to allow userspace to configure pins at runtime using config-pin) Mar 17 20:28:20 Let me stick to a startup script, through a service. I more straight-forward approach for me. Mar 17 20:28:54 I have an idea in that regard, hold in while I check some things Mar 17 20:28:58 *hold on Mar 17 20:30:49 tiger: and yeah to compile overlays you need a linux system with the device tree compiler (dtc) installed, typically you'd just use the beaglebone itself Mar 17 20:43:36 I just run the can_if script from rc.local instead of installing as a service under /init.d. It runs ok. Mar 17 20:44:00 yeah because rc.local is run suuuper late Mar 17 20:44:44 I think anyway Mar 17 20:45:33 hmm, it actually doesn't look like it, unless there's some magic exception for it... I thought it had Type=idle but it bizarrely has Type=forking Mar 17 20:45:33 It may require network layer up-runing first? Mar 17 20:45:48 so it may be pure luck that your script works in /etc/rc.local Mar 17 20:45:56 and not necessarily consistent Mar 17 20:46:26 anyway, I'm writing a service file to test what are appropriate ordering dependencies Mar 17 20:46:37 (note that /etc/rc.local is also legacy/deprecated) Mar 17 20:47:38 I may change it to service under /etc/systemd/system as you suggested ealier Mar 17 20:48:29 I don't like rc.local, it is too late. It seems slow, too. Mar 17 20:49:13 like I said, just hold on, I have an idea on how to do this nicely and I'm checking things Mar 17 20:49:18 checking/testing Mar 17 20:49:36 Ok. Take your time. I will wait Mar 17 20:57:31 if you care about boot time (which I'm waiting for right now -.-), cape-universal and startup scripts is definitely not optimal ;P Mar 17 20:58:31 How much longer ? Mar 17 20:58:48 ? Mar 17 20:58:58 the boot time Mar 17 20:59:09 compared to what? Mar 17 20:59:28 ok I think I have the right dependencies Mar 17 21:01:33 what are the dependencies (cape-universal, startup scripts ?) Mar 17 21:03:27 so here's my idea: a oneshot startup script to configure pins and gpios: https://pastebin.com/bkMSdPpi Mar 17 21:03:48 whose dependencies ensure it'll get run before networking interfaces are brought up Mar 17 21:03:58 which means you can configure your can interfaces in /etc/network/interfaces Mar 17 21:05:12 It is dependent on networking interfaces, Mar 17 21:06:03 Thank you, I will import it and test it, tomorrow. Mar 17 21:06:28 I'm checking for an example for setting up a can interface in /etc/network/interfaces Mar 17 21:07:03 one I've found looks like bullshit Mar 17 21:07:19 systemd service is much a better choice than init.d, for sure Mar 17 21:09:13 ugh why is this so hard to find Mar 17 21:09:25 (it doesn't help that "can" is a useless search term) Mar 17 21:09:30 BTW: is the process for BBB to connect to a hotspot the same as the process to connect to WIFI Access Point? Mar 17 21:10:05 uhh, those words mean essentially the same Mar 17 21:11:17 what precisely do you mean by a "hotspot" ? Mar 17 21:11:45 such as a WIFI HotSpot on iPhone Mar 17 21:12:25 that's just a wifi access point, nothing special about it Mar 17 21:13:11 Ok. Thank you @zmatt for your help. Good night Mar 17 21:14:59 tiger: https://pastebin.com/PQxXuCGy Mar 17 21:15:12 my best guess at configuring CAN interfaces in /etc/network/interfaces **** ENDING LOGGING AT Thu Mar 18 02:59:56 2021