**** BEGIN LOGGING AT Tue Dec 05 03:00:01 2017 Dec 05 03:07:02 Hey! Dec 05 03:08:09 Anyway...if I take away/uncomment the # of disable-uboot-emmc=1, does it mean I have access to those pins afterwards/after the reboot? Dec 05 03:08:48 sudo nano /boot/uEnv.txt is where that disable-uboot-emmc=1 is located. Dec 05 03:09:28 disable_uboot_overlay_emmc=1 <<<<< this is what I uncommented. Dec 05 03:09:34 Now...I think I can use those pins. Dec 05 03:09:54 Could it be true? Dec 05 03:10:35 cough...let me start over. Dec 05 03:10:37 ... Dec 05 03:12:14 If I uncomment out #disable_uboot_overlay_emmc=1 to disable_uboot_overlay_emmc=1 in the /boot directory under the uEnv.txt file and w/ my pins "hi," could I use them and then make them GPIO enabled? Dec 05 03:12:44 ... Dec 05 03:13:19 I mean (yes) I think I can. Therefore, it is possible but w/ my lack of knowledge, could I? Dec 05 03:14:51 I am asking b/c this person, stranger danger to me, needs to know. This person wants to use all their GPIO pins, e.g. even the eMMC enabled pins. Dec 05 03:15:21 I thought and thought about it. I said, "What the hell?" So, I jumped in and pitched in. Dec 05 03:23:30 I typed all that b/c I read that we are no longer using DTS files and only using uboot overlays now, i.e. w/ current image files and kernels. Dec 05 03:23:36 Right-o? Dec 05 03:23:54 i.e. 4.9.x and up. Dec 05 03:45:52 Forget it. He is using Jessie. Dec 05 03:46:04 He/She is not using Stretch. Oops! Dec 05 03:49:01 I notified the person. do not fret... Dec 05 04:29:24 uhh, u-boot overlays are just a different mechanism to apply overlays to the main DT Dec 05 04:29:31 it replaces capemgr Dec 05 06:36:52 Hi! We would like to purchase Beagleboard X15 through Digi-key.As company policy requirement, we need a certificate of distribution. But Digi-Key can not porivde it. Can Beagle send an Email to confirm the distribution? Dec 05 06:38:00 ? Dec 05 06:41:05 can someone answer me? Dec 05 06:49:55 BGI_: take some time, there are knowledgeable people here but not always at the keyboard Dec 05 06:50:17 (i am not one of them, though) Dec 05 07:07:24 i am affraid of log out by system Dec 05 07:13:24 Hi! We would like to purchase Beagleboard X15 through Digi-key.As company policy requirement, we need a certificate of distribution. But Digi-Key can not porivde it. Can Beagle send an Email to confirm the distribution? Dec 05 07:30:50 you might want to try and ask on the google-group / mailing list Dec 05 07:43:56 Hi! We would like to purchase Beagleboard X15 through Digi-key.As company policy requirement, we need a certificate of distribution. But Digi-Key can not porivde it. Can Beagle send an Email to confirm the distribution? Dec 05 07:52:40 while compiling kernel for beagle bone black i am getting below error include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Dec 05 07:53:00 please can someone help me out on this Dec 05 07:53:02 BGI_: no need to keep re-posting to the channel, most people who could respond might catch it in backlog Dec 05 07:53:53 BGI_: most likely asleep, though Dec 05 07:54:03 BGI_: posting to the mailing list might make more sense Dec 05 07:54:06 suresh_: this means that you are trying to build a very old kernel that is not yet gcc5 aware. Dec 05 07:54:13 suresh_: -> upgrade to a newer one. Dec 05 07:54:41 ok i will try with the latest kernel version. thank you Dec 05 07:59:48 can you provide me a mail address Dec 05 08:00:45 beagleboard-x15@googlegroups.com Dec 05 08:01:00 good luck! Dec 05 08:01:02 * vagrantc waves Dec 05 08:01:06 BGI_: we are a community run support channel, and not a sales department. Dec 05 08:01:18 BGI_: contact your distributor, or pick another one. Dec 05 08:02:12 ok thanks Dec 05 08:02:51 https://groups.google.com/forum/#!forum/beagleboard-x15 Dec 05 15:30:54 morning folks Dec 05 15:31:13 bbbw uspposed to just blink the one LED while flashing? Dec 05 15:41:33 no, flashing shows a back-and-forth pattern across all four leds Dec 05 15:43:22 (at least, it does when using rcn's flasher) Dec 05 15:57:00 nope Dec 05 15:57:02 did that initially Dec 05 15:57:13 then just user0 Dec 05 16:03:03 so its been at this for about half an hour now.. just USR0 blinking twice Dec 05 16:08:23 that's an idle running system Dec 05 16:09:13 ok it didn't flash Dec 05 16:09:18 how do i get to flash? Dec 05 16:09:33 i have a flash card in there with the latest os Dec 05 16:09:37 iamge Dec 05 16:10:08 unless you specifically downloaded a flasher image, it will simply boot from sd rather than flashing Dec 05 16:10:28 you can turn such a "standalone" card into a flasher card by uncommenting one line in /boot/uEnv.txt though Dec 05 16:11:49 well i downloaded Stretch IoT (non-GUI) for BeagleBone Dec 05 16:12:02 is that a flash image or do i need to comment that line out? Dec 05 16:12:16 oh shit Dec 05 16:12:19 just saw it.. ugh Dec 05 16:12:35 none of the images at https://beagleboard.org/latest-images are flashers, as described below the download links Dec 05 16:12:53 which also describes how to make it a flasher :) Dec 05 16:14:35 yea it shows that you need to edit /boot/uEnv.txt as you said Dec 05 16:15:50 you can also find premade flasher images at https://elinux.org/Beagleboard:BeagleBoneBlack_Debian (Debian Image Testing Snapshots -> Stretch Snapshot iot -> Flasher) Dec 05 16:16:37 got it Dec 05 16:18:57 anywhere i can see what stretch comes with? Dec 05 16:19:50 ? Dec 05 16:21:36 if you mean which packages are preinstalled, you can get a listing using dpkg --get-selections or apt list --installed (the former is much faster, the latter gives slightly more info) Dec 05 16:22:29 or maybe apt-mark showmanual to get a list of manually-installed packages (skipping automatically installed dependencies) Dec 05 16:25:01 hmm Dec 05 16:25:07 ok will try that Dec 05 16:27:11 i've been trying forever to get a current version of node running Dec 05 16:27:25 Node that comes preinstalled with Debian images is always a hundred years behind Dec 05 16:27:35 and apt upgrade node doesn't do much Dec 05 16:28:01 correct, we use the packages from nodesource.com by adding it as apt repository Dec 05 16:28:18 how do we do that? Dec 05 16:28:41 '/etc/apt/sources.list' or something like that.. Dec 05 16:28:53 create a file /etc/apt/sources.list.d/nodesource.list Dec 05 16:28:55 with the contents: Dec 05 16:28:57 deb https://deb.nodesource.com/node_8.x stretch main Dec 05 16:29:08 :) Dec 05 16:29:17 top of my todo list Dec 05 16:29:18 or 9.x is probably available already Dec 05 16:29:19 as soon as i flash this thing Dec 05 16:29:24 yep, 9.2 Dec 05 16:29:49 8.x is LTS Dec 05 16:29:55 now after all this hard work... if i could only source a part that runs some version of *nix for under $5/chip Dec 05 16:30:07 LTS? Dec 05 16:30:15 long-term-support release Dec 05 16:30:21 ah Dec 05 16:30:43 oh fun... https://nodejs.org/en/blog/vulnerability/december-2017-security-releases/ Dec 05 16:31:20 found QCA4531 -- a qualcom part running Open WRT, which is close enough i guess.. Dec 05 16:31:39 prototyping with BBB is fun but the parts are still expensive Dec 05 16:32:18 CHIP (https://getchip.com/pages/chip) is pretty cheap Dec 05 16:32:46 dunno how much the SoC itself costs Dec 05 16:32:48 is that a $9 linux board? Dec 05 16:33:51 it was subsidized by a government Dec 05 16:33:54 yeah, if it were still for sale anyway Dec 05 16:33:58 ah, didn't know that Dec 05 16:34:07 e.g. the parts, labor, etc. cost well more than the $9 Dec 05 16:34:19 i thought that seemed a bit low Dec 05 16:34:40 and there's the rpi zero Dec 05 16:34:40 that said, it was very nice to have all of the pins clearly labeled on the header :) Dec 05 16:35:03 hope bbb peeps are listening Dec 05 16:35:56 it's only the sort of detail you can manage if you're able to spend more than you sell it for Dec 05 16:36:15 stormbytes: listening to...? Dec 05 16:36:29 .... labeling the pin headers Dec 05 16:36:32 ah Dec 05 16:37:03 no real part# data from CHIP Dec 05 16:37:28 that openWRT chip from qualcomm is ~ $4-5 Dec 05 16:37:45 not a particularly tasty distribution but.. at that price, hard to complain Dec 05 16:37:57 it's an allwinner r8 Dec 05 16:39:28 the AM3352BZCE30 is $6 (@ 1k) Dec 05 16:39:50 hmm i didn't see that Dec 05 16:39:58 from where? Dec 05 16:40:04 mouser has it at $7.95 Dec 05 16:40:52 list price at TI Dec 05 16:40:58 http://www.ti.com/product/AM3352/samplebuy Dec 05 16:40:59 shit Dec 05 16:41:07 i need to hire you lol Dec 05 16:41:33 of course whether it suffices for your needs depends heavily on your needs... "runs linux" is rather vague Dec 05 16:42:02 people run linux of some form on much weaker processors Dec 05 16:42:35 (like am1xxx) Dec 05 16:42:41 well, just basic i/o Dec 05 16:42:43 nothing heavy duty Dec 05 16:42:58 99% uart ops Dec 05 16:43:11 with the added bonus of the tcp/ip stack Dec 05 16:43:31 and that it runs debian Dec 05 16:44:44 alright, got my flash img burned on Dec 05 16:44:55 so hold the boot + power it up, that right? Dec 05 16:45:05 normally no need to hold the boot button Dec 05 16:45:07 and i'm assuming the boot btn is still the one closest to the flash card reader Dec 05 16:45:10 oh? Dec 05 16:45:13 it is Dec 05 16:45:14 just power it up? Dec 05 16:45:36 boot button may be needed if the system (or more specifically the bootloader) currently flasher is really ancient or weird Dec 05 16:45:57 this is a brand new bbbw board Dec 05 16:46:12 then it shouldn't be needed Dec 05 16:46:18 ok doke... Dec 05 16:46:33 boot button forces the bootloader on eMMC to be bypassed and the one on SD be used instead Dec 05 16:46:40 4 lights came up at first.. now cycling through leds randomly Dec 05 16:46:49 randomly? Dec 05 16:47:07 ok,, now we see that night rider pattern goign on Dec 05 16:47:08 there we go Dec 05 16:47:08 :) Dec 05 16:47:08 *knight Dec 05 16:47:18 debated that *k for a minute Dec 05 16:47:26 was it knite? Dec 05 16:47:29 eerr.. knight? Dec 05 16:47:44 damg... Dec 05 16:47:47 huh, weird, the am17xx/am18xx processors are actually more expensive than the am3352bzce30 Dec 05 16:48:04 circuitry in my head is getting old, it was Knight Rider indeed Dec 05 16:48:04 I guess the am335x is really high production volume Dec 05 16:48:31 what are the am17/18s? Dec 05 16:48:45 older arm9-based SoCs from TI Dec 05 16:48:47 ah Dec 05 16:48:56 M or A ? Dec 05 16:49:01 no Dec 05 16:49:21 cortex came after arm11 Dec 05 16:49:30 i see Dec 05 16:50:21 speaking of prices.. i was looking into a micro for some accessory gadgets and the ATSAMD21 is actually cheaper than the old Atmega338p Dec 05 16:50:26 obviously the am3352bzce30 is pretty much a wastebin of the production line, being binned at max 300 MHz Dec 05 16:50:27 which i found rather suprising Dec 05 16:51:09 at $6 for a Sitara running Debian i can't complain Dec 05 16:53:32 yeah, and the am335x family has quite a few variants, allowing fine-tuned trade-off between price and performance/functionality Dec 05 16:54:07 e.g. the am3352zce60 (600 MHz) is $6.34 (@ 1k) Dec 05 16:54:27 the simplicity and ubiquity of debian is worth paying the extra $2 Dec 05 16:55:16 if you want a "light" system, it does pay off to tune your kernel config a bit to your needs and prune unnecessary system services Dec 05 16:55:51 this didn't take a huge amount of effort -> https://liktaanjeneus.nl/boot.svg Dec 05 16:56:44 well okay, I guess I may have spent a non-trivial amount of time on kernel config over time maybe Dec 05 16:57:09 it cut the kernel size in half though Dec 05 16:58:34 damn, the extended-temperature version (max 125 ͏°C) is expensive Dec 05 17:34:18 once i create the nodesoure.list file Dec 05 17:34:40 do i just run an install or upgrade form apt? Dec 05 17:47:21 sudo apt-get update && sudo apt-get install nodejs Dec 05 17:47:41 just fired up the new image so running apt-get update Dec 05 17:48:14 E: Failed to fetch https://deb.nodesource.com/node_8.x/dists/stretch/InRelease Dec 05 17:48:15 E: Some index files failed to download. They have been ignored, or old ones used instead Dec 05 17:49:11 yea its not taking it.. thinks the system version is the newest Dec 05 17:49:30 does it have internet access at all? Dec 05 17:49:41 looks like it Dec 05 17:49:48 pings google just fine Dec 05 17:50:08 well https://deb.nodesource.com/node_8.x/dists/stretch/InRelease definitely does exist Dec 05 17:50:09 i'm gonna try rebooting it now Dec 05 17:52:59 here's the output Dec 05 17:52:59 https://gist.github.com Dec 05 17:53:00 no dice Dec 05 17:53:37 looks like some issue with https Dec 05 17:54:01 might need apt-transport-https Dec 05 17:54:13 yea just saw that Dec 05 17:54:16 unless you have a very new version of apt Dec 05 17:54:21 looks to be workign onw Dec 05 17:55:48 ok, 8.9.1 installed Dec 05 17:55:58 how do you get it to install the latest? Dec 05 17:56:00 9.2 Dec 05 17:57:00 What is the exact weight of the BeagleboardX15? Dec 05 17:57:52 stormbytes: latest what? Dec 05 17:58:01 latest version of nodejs Dec 05 17:58:09 i think i'm just going to grab nvm and do it that way Dec 05 18:02:50 stormbytes: change the 8.x to 9.x in the .list file Dec 05 18:03:09 thats it? Dec 05 18:03:10 ok Dec 05 18:03:46 (and then again apt-get update and either 'install nodejs' or 'upgrade' to install any pending updates) Dec 05 18:06:08 easy enough :) Dec 05 18:06:27 doesn't 'upgrade' upgrade pretty much everything on the system? Dec 05 18:07:05 nope :) no dice.. Dec 05 18:07:07 yes, which is generally a good thing Dec 05 18:07:20 hmm? Dec 05 18:07:24 neither install nodjs nor uprade does anything Dec 05 18:07:40 you've first done 'update' ? Dec 05 18:07:55 damn irc client keeps crashing Dec 05 18:08:59 you've done apt-get update after changing the .list file, before trying to upgrade the package? Dec 05 18:09:24 i'm gonna do it again just in case.. i think i did Dec 05 18:09:36 just seems like nvm is a lot less hassle Dec 05 18:09:47 lol Dec 05 18:10:13 i've resisted before as I was just using my local mac to develop and brew does a terrific job of installing node Dec 05 18:10:14 we regularly have tons of problems with nvm. I've never had trouble installing/updating nodejs with apt Dec 05 18:10:24 wow that right Dec 05 18:10:29 ok, will scratch that thten.. Dec 05 18:11:11 oh wait, nvm, I misread as npm... but I think we've used nvm too at some point Dec 05 18:11:34 running it now.. i see why you asked that.. need to update local caches Dec 05 18:11:37 I know I've run into messes created by coworkers by having multiple copies of nodejs installed on the system Dec 05 18:11:49 yeah, apt-get update downloads the package lists Dec 05 18:11:54 that doesn't suprise me Dec 05 18:12:18 ok we're good.. that's what was mising Dec 05 18:12:33 needed to update local repo caches before running install/upgrade Dec 05 18:12:48 yea i prefer a single native installation too.. no question its less headaches overall Dec 05 18:13:07 whoot whoot 9.2 :) Dec 05 18:14:33 …heh same problem with git now Dec 05 18:14:36 its a couple versions behind Dec 05 18:14:46 do i need to add a source for that as well? Dec 05 18:17:10 hmm? I can't say I've ever run into anything "missing" in the stretch version of git... Dec 05 18:17:26 you can add the stretch-backports repository to get 2.14.2 Dec 05 18:18:43 deb http://deb.debian.org/debian stretch-backports main Dec 05 18:19:01 if 2.11 is recent enough i'm fine with it Dec 05 18:19:08 i'm not doing anything bleeding edge Dec 05 18:19:57 then you should probably just stick to the version in stretch Dec 05 18:20:13 no point in complicating package management to get a newer version if you don't need it Dec 05 18:20:21 agreed Dec 05 18:20:37 yea the only thing i really care about most recent version is node Dec 05 18:20:58 with something as mature as git its always just more bells and whistles Dec 05 18:23:16 yeah, nodejs is the only "foreign" repo we're using, and I'm using stretch-backports for systemd (and related packages) and buster for gcc/g++ Dec 05 18:23:48 (using an apt-preferences file to avoid packages being pulled from those unintentionally) Dec 05 18:26:45 will have to get the hang of this eventually Dec 05 18:30:13 using a mix of repositories (stretch/buster) is definitely not something one should do unless you accept the risk of ending up in a serious fight with APT when installing or upgrading packages :) Dec 05 18:32:47 (backports should be safe, but doesn't get maintained after the next stable release (buster), which means that at that point you'd be pretty much forced to downgrade them to stretch or update everything to buster to be able to get any updates at all, including security updates) Dec 05 18:33:20 hm Dec 05 18:57:08 zmatt so does /dev/ttyO0 map to uart1 ? Dec 05 19:19:39 ttyO0 is a backwards-compat symlink to ttyS0, which corresponds to uart0 Dec 05 19:21:41 hah i'm a moron Dec 05 19:21:46 just fried a brand new bbbw Dec 05 19:23:59 lol what? how? Dec 05 19:38:10 oh i'm really good at being a dumbass Dec 05 19:38:28 tried to get the UART pins off the diagram Dec 05 19:38:41 must've shorted something while poking around Dec 05 19:40:30 BBB docs are atrocious Dec 05 19:40:50 hmm, I get the impression the bbb isn't that easy to kill with a short... I think most if not all of our beaglebones that have died did so due to exposure to overvoltage on i/o Dec 05 19:40:51 this is my third or fourth board.. still have the original BB white Dec 05 19:41:32 I've made a spreadsheet that includes overviews of the P9 and P8 headers, if you're interested -> https://goo.gl/Jkcg0w Dec 05 19:41:45 well.. i was connecting the (barrel jack powered) BBB's pins to an XBee explorer board Dec 05 19:41:47 (unpowered0 Dec 05 19:42:59 before or after configuring the pins to uart? (by default they're tristated gpio) Dec 05 19:43:13 had VDD & Ground (p9 i think) jumpered into the xbee and i was fiddling around with tx/rx pins and a console trying to find the right ones Dec 05 19:43:21 omfg Dec 05 19:43:27 like i said... i'm really good at being a dumbass Dec 05 19:43:44 didn't realize you had to configure them to UART Dec 05 19:43:53 well if you didn't, then it's possible to cause a short Dec 05 19:44:03 so whatever you did to kill the board, it wasn't that Dec 05 19:44:11 that's all i was doing Dec 05 19:44:22 the xbee has 3.3v i/o ? Dec 05 19:44:28 i could have inadvertently shorted to ground or VCC Dec 05 19:44:36 5V on this explorer board Dec 05 19:45:13 xbee module is just fine Dec 05 19:45:17 the bbb does not have 5v-compatible i/o Dec 05 19:45:36 connecting a 5v output to any bbb i/o is the quickest and easiest way to deep-fry is Dec 05 19:45:40 *it Dec 05 19:45:44 oh i didn't do that Dec 05 19:46:02 i was thinking the bbb had a 5v VCC so I was using that to power the xbee explorer Dec 05 19:46:12 if anything, it should have been underpowered Dec 05 19:46:19 there is 5v available on P9 Dec 05 19:47:14 P9.07-08 are 5v Dec 05 19:47:21 http://beagleboard.org/support/bone101 Dec 05 19:47:33 P9.05-06 are 5v if the bbb is powered via the barrel jack Dec 05 19:47:45 i was connected to.. VDD-5V on p5-6 Dec 05 19:47:45 P9.03-04 are 3.3v Dec 05 19:47:46 exactly Dec 05 19:47:53 and it was Dec 05 19:48:36 i'll just pick up another one Dec 05 19:48:37 shit happens Dec 05 19:48:38 so, does the xbee module have 5v outputs? (just being powered at 5V doesn't say much) Dec 05 19:48:48 xbee has inputs Dec 05 19:48:55 well.. the explorer breakout board at least Dec 05 19:49:01 Hey can anyone point me to docs for the bone_capemgr in kernel version 4.4.69-bone17? Dec 05 19:49:11 you mentioned tx/rx, so one of those is obviously an output Dec 05 19:49:17 true Dec 05 19:49:20 hmm Dec 05 19:49:22 i didn't think about that Dec 05 19:49:44 stormbytes: also, i/o voltage is relevant for inputs too... Dec 05 19:49:47 I'm trying to add a virtual cape to my Replicape so it'll mux these 4 pins appropriately and let me run two extra stepper drivers off-board. Dec 05 19:49:50 clearly Dec 05 19:50:07 so if tx/rx on the xbee were 5V i could have shorted the pins on the bbb Dec 05 19:50:18 But the cape manager in Umikaze 2.1.1 (ubuntu 16.04 based image for replicape) doesn't behave like any of the various cape managers I've found documented online. Dec 05 19:50:30 nickparker: capemgr hasn't changed much at all over time Dec 05 19:50:39 I don't know anything about ubuntu Dec 05 19:50:59 stormbytes: overvoltage isn't the same thing as a short Dec 05 19:51:10 ...fried i should have said Dec 05 19:51:13 stormbytes: a short is an extreme case of overcurrent Dec 05 19:51:55 so i'll have to find out if the i/o on the xbee explorer is 5v or 3.3 Dec 05 19:52:04 if its the latter, then its okay? Dec 05 19:52:11 otherwise will have to use a level shifter Dec 05 19:52:14 correct Dec 05 19:52:30 but since you managed to fry a bbb while connecting it to a tristated i/o, I'd guess it's 5v Dec 05 19:52:39 zmatt: The slots file is in a slightly unusual place /sys/devices/platform/bone_capemgr/slots, and for whatever reason I don't have permission to echo my cape into it even as root Dec 05 19:52:42 since that's pretty much the only way to fry the bbb in that case Dec 05 19:53:11 nickparker: pretty sure that's been its location for a long long time Dec 05 19:53:25 did you check kernel log w.r.t the error? Dec 05 19:54:21 zmatt : here's the board, they are kind of ambiguous about i/o voltage -- https://www.sparkfun.com/products/11373 Dec 05 19:54:51 zmatt: Pretty much all the docs I've found online expect /sys/devices/bone_capemgr.*/slots Dec 05 19:55:19 Is there a canonical docs location for cape manager that my google-fu has just failed to find? Dec 05 19:55:40 nickparker: that path was for the ancient 3.8 kernel series Dec 05 19:56:29 stormbytes: that says it's a level shifter board for xbee modules... I'm guessing that since you connected 5v, it produced 5v output Dec 05 19:56:56 it steps down the input to 3v but i'm not sure about the i/o lines Dec 05 19:57:03 3.3v is very common for uart Dec 05 19:57:43 are you saying i could have simply fed the Xbee from a 3.3V pin? Dec 05 19:57:49 meaning.. didn't need 5v Dec 05 19:58:21 dang Dec 05 19:58:26 didn't have to fry the board Dec 05 19:58:48 how do you enable UARTs on bbb? Dec 05 19:58:53 OK so I'm looking at the right slots file then. What should I try next if I can't echo into it? Dec 05 19:58:54 my impression from that description is that the xbee uses 3.3v, and that level shifter board is designed to connect such modules to e.g. older arduinos which use 5v i/o Dec 05 19:59:02 nickparker: 20:53 < zmatt> did you check kernel log w.r.t the error? Dec 05 19:59:03 i have another board.. a bbb (not wireless) which i can try next Dec 05 19:59:35 of course it's best to just check the datasheet or whatever of the actual module you're using Dec 05 19:59:37 zmatt: that makes sense.. it says " It translates the 5V serial signals to 3.3V so that you can connect a 5V (down to 3.3V) system to any XBee module. " Dec 05 19:59:55 so maybe 3.3 would have worked as well.. hmm Dec 05 19:59:58 config-pin $pin uart Dec 05 20:00:09 where $pin is e.g. P9.11 Dec 05 20:00:54 config-pin is some sort of utility that does this? Dec 05 20:01:14 note that it's safer to connect the wires first and then config the pins Dec 05 20:01:20 yes Dec 05 20:01:37 i'm gonna flash my older bbb and give this a shot Dec 05 20:01:41 part of something called "cape-universal", which is enabled by default Dec 05 20:01:44 got a new board on order now Dec 05 20:02:04 (it can still be disabled in /boot/uEnv.txt to allow using the older way of configuring pins using overlays and bone_capemgr) Dec 05 20:04:33 i'll poke around Dec 05 20:13:06 zmatt: I'm not sure what I'm looking for in here. /var/log/kern.log right? Dec 05 20:13:19 output of the dmesg command Dec 05 20:13:58 (it should also get logged to journal, and possibly to file depending on system setup, but best to just get it straight from dmesg) Dec 05 20:14:35 and you're looking for any messages being logged in response to attempting to load the overlay Dec 05 20:17:42 zmatt: dmesg is sort of the log from boot right? So far I'm just trying to load by echoing into the slots file. I just copied dmesg to a text file, echoed, and copied to a second file and the files are identical Dec 05 20:18:32 dmesg outputs all messages in the kernel log ringbuffer (when it's full, the oldest messages get dropped) Dec 05 20:18:44 hmm, okay Dec 05 20:19:21 capemgr is known to have crappy diagnostics, but I'd have expected at least some kind of message if an error occurred Dec 05 20:19:33 what's the current contents of the slots file? Dec 05 20:19:50 (paste via pastebin.com or similar site) Dec 05 20:20:12 https://pastebin.com/i6jWLK0v Dec 05 20:20:31 'kay Dec 05 20:21:06 then dunno Dec 05 20:21:13 That reminds me, perhaps my other approach here might be easier: I tried to modify the .dts file for replicape to include the pins I wanted, compiled it and put the dtbo in /lib/firmware, but the contents of that dtbo don't seem to have any effect on what actually loads at boot. Dec 05 20:21:29 that sounds odd Dec 05 20:21:32 Is it possible my system is getting its device tree setup from somewhere other than /lib/firmware? Dec 05 20:21:42 what did you put in exactly? Dec 05 20:21:54 not really, unless the system you're using has some unusual setup Dec 05 20:22:02 I only have experience with debian Dec 05 20:23:14 I added everything after fragment@7 https://github.com/nick-parker/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-0B3A.dts#L319 Dec 05 20:23:28 And added the corresponding entries to the exclusive_use section Dec 05 20:24:52 But I also tried removing a bunch of pins from lines 76-80, and cat'ing my pingroups file still showed they were in pruicss_stepper_pins after a reboot Dec 05 20:25:24 that does sound like it's getting the overlay from a non-standard path Dec 05 20:25:44 The stuff I added is just a copy/paste of this file btw, which is the other overlay I've been trying to load: https://github.com/nick-parker/bb.org-overlays/blob/master/src/arm/BB-BONE-REACH-00B0.dts Dec 05 20:26:11 Hmm OK well thanks for the help, this sounds like a specific enough problem now to go bug the creator of the Umikaze image over on replicape Slack Dec 05 20:26:21 btw, is it intentional that you're replacing the existing set of "stepper pins" rather than augmenting them? Dec 05 20:26:35 Er, no. The intent is to augment Dec 05 20:26:54 then use pinctrl-0 = <&pruicss_stepper_pins>, <&pruicss_stepper_pins_reach>; Dec 05 20:27:05 or add your pins to the pruicss_stepper_pins block instead of making a new one Dec 05 20:28:16 likewise your fragment 9 is overwriting properties of the node created in fragment 3 Dec 05 20:28:18 Yeah I was thinking I would try adding to the existing block next. I'm just trying to figure out how to modify anything at all first, then I'll get the .dts saying precisely what I want Dec 05 20:28:32 either change the name of the node, or augment the existing node Dec 05 20:29:27 If I loaded a separate dts file with the new fragments in them, would everything work properly together? Because I thought that's what the original dev of this system had done... Dec 05 20:29:52 no Dec 05 20:30:52 the way dts works is that declaring a property at some path overwrites any earlier property declaration at the same path Dec 05 20:30:58 while node declarations are merged Dec 05 20:31:21 this is still true when using an overlay to modify the in-kernel device tree, although in that case some changes may end up having no effect Dec 05 20:31:49 for example adding pinmux to a device that's already been enabled has no effect since the pinmux has already been performed and the kernel won't notice the changes you made Dec 05 20:32:13 Interesting. Well I'm glad I finally found someone who knows how all this works! Dec 05 20:33:49 :) Dec 05 20:41:00 I also made a script a while ago that allows writing overlays in the normal format of device tree files instead of the ugly crap that's inexplicably required for overlays Dec 05 20:41:22 it turns https://pastebin.com/raw/9hc5vS7G into https://pastebin.com/raw/uuz9Kw98 (well, not as nicely formatted, but equivalent) Dec 05 20:42:04 you can find it at https://github.com/mvduin/overlay-utils/blob/master/bin/dtsi-to-overlay ... the same repository also has examples Dec 05 20:42:18 gotto run, bbl Dec 05 21:39:47 pretty cool.. i just discovered you can configure the pins on the BBB Dec 05 21:45:21 because I told you? :P Dec 05 21:46:45 also, how did you manage to miss it initially? pretty sure that's something you'd normally run into pretty early Dec 05 21:48:24 especially since you mentioned you also have a beaglebone white (which has exactly the same i/o) Dec 05 21:55:13 exactly :) Dec 05 21:55:27 i used the boards as linux machines rather than for iot Dec 05 21:55:29 iOT Dec 05 21:56:20 i always knew there was the option to tinker with the headers but always found it complicated and intimidating, so stuck with the good old arduinos Dec 05 21:56:50 now i'm on a project where i really can't run and hide anymore.. so 1 dead board later and 1 good piece of advice, and.. presto! eureka moment lol Dec 05 21:57:20 another thing was that i never had much luck getting reliable wifi with the usb dongles Dec 05 21:57:38 so the whole idea of projects tethered to an ethernet hub was kind of a kill joy Dec 05 21:59:20 when i originally got the white it came with an Angstrom distro (I believe) which was totally greek! Only think worse that I can think of would be the late Edison's distro.. i forget the name. I wonder what genius at Intel came up with that brilliant idea Dec 05 22:16:26 heh Dec 05 22:38:49 isn't the overlay saved in kernel memory? Dec 05 22:39:10 ds2: ? Dec 05 22:42:05 zmatt: adding a pinmux section... doesn't that cause the memory copy to grow? Dec 05 22:43:31 I'm pretty sure it doesn't maintain a flat representation of the overall DT in memory, rather there is a tree structure that has pointers into the flat representation for property data Dec 05 22:43:48 so the overlay would be loaded into memory and then those trees get patched up Dec 05 22:44:10 but I've never looked in detail how overlays work exactly... it needs to do enough bookkeeping to able to undo it too, since you can unload overlays Dec 05 22:45:28 and there's a notification system to allow things to be aware of changes in the tree... some things are, some things aren't Dec 05 22:50:11 what I am leading to is - if you if you can use 2 (or more DT overlays) to do something like this: Dec 05 22:50:53 Block A, B, C, D are configured by SW (and have state); A, B, C, D all share the same phyiscal pin (and the HW is appropriately tolerant of that) Dec 05 22:51:05 dynamically switch between A, B, C, D functionalities Dec 05 22:51:23 that's exactly what cape-universal does Dec 05 22:52:01 either I misunderstand that or you are misunderstanding what I am getting at Dec 05 22:52:16 pretty much all peripherals are enabled, and there are bone-pinmux-helper (or something) "devices" that can be used to switch pinmux Dec 05 22:52:41 say a pin can do: GPIO, EGPIO (via PRUSS), LCD data Dec 05 22:53:07 can the kernel driver behave as if I just manually swap the connections around? Dec 05 22:53:40 doesn't cape universal's switch have side effect beyond just changing the mux? Dec 05 22:53:49 no, none Dec 05 22:54:15 the various drivers (e.g. gpio and lcdc) are unaware that any switching is happening Dec 05 22:54:58 Hmmm Dec 05 22:55:48 does the requests work from K-space? Dec 05 22:56:15 the pinmux helper device just has references to various pinmux blocks and lets you switch between them via sysfs: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-common.dtsi#L502-L516 Dec 05 22:56:32 from kernel space you'd need nothing more than the pinmux api Dec 05 22:56:44 bone-pinmux-helper just exists to bridge that functionality to userspace Dec 05 22:57:03 if I recall correctly, the pinmux-api has been neutered and rendered useless Dec 05 22:57:16 that sounds unlikely Dec 05 22:57:16 ah... _BLOCKS_ that is a side effect, IMO Dec 05 22:57:28 ? Dec 05 22:57:37 the pinmux-api has the concept of a owning driver Dec 05 22:57:58 blocks as in switch in ALL pins of the peripheral at once, right? Dec 05 22:58:42 ultimately, what I am looking at is a clean way to talk to a morphing peripheral, i.e. a FPGA or similar device Dec 05 22:58:43 you can put one or more pins in a pinmux block, as long as they belong to the same pin controller (and there's only one on the am335x) Dec 05 22:59:13 and yes there's an owning driver, that would be the driver responsible for performing the pinmux switching Dec 05 22:59:34 right so I need a shim driver to own things Dec 05 22:59:53 I considered that neutered functionality (older API's didn't have that restriction) Dec 05 23:00:07 your code isn't part of any driver whatsoever? Dec 05 23:00:29 it is... but that can vary Dec 05 23:00:42 think of this - AM335x in a sea of FPGA (or similar) Dec 05 23:01:30 there's still going to be some code responsible for coordinating the pinmux change Dec 05 23:01:54 in the 3.2 model, the board file can supply that Dec 05 23:03:03 I guess, though associating it with a device (if the api genuinely requires that, I haven't checked) shouldn't be much of a bother Dec 05 23:04:25 except the new model of things makes that @#$#$@!#$@!#@!# more complex Dec 05 23:04:40 the reason I want a AM335x in a sea of FPGA is being able to change things around on the fy Dec 05 23:04:41 fly Dec 05 23:05:00 by? based on...? Dec 05 23:05:45 whatever is needed Dec 05 23:06:31 so why it is a problem to make a shim device for just that? similar to the bone-pinmux-helper Dec 05 23:06:49 and I just checked, the API does indeed strictly require a struct device * Dec 05 23:07:02 more things to deal with compared to 3.2 Dec 05 23:07:07 3.2 things just worked :P Dec 05 23:07:29 if someone wants to pay for that extra work, that's fine but otherwise, there are better things to do Dec 05 23:07:35 so, don't request the pins at all via the kernel api and just poke the appropriate registers in the control module Dec 05 23:07:46 :P Dec 05 23:07:47 :P Dec 05 23:07:58 problem solved, you're welcome Dec 05 23:09:32 trying to find a good reason to go 4.x Dec 05 23:10:00 not running old unmaintained crap? Dec 05 23:10:04 ;) Dec 05 23:10:27 The 4.x is just as unmaintained after adding those hacks Dec 05 23:10:43 what hacks? Dec 05 23:11:17 poking CM Dec 05 23:12:11 I wasn't being very serious, although I don't see any plausible way that could ever break Dec 05 23:12:44 IMO, it would be cleaner to backport stuff to the old kernel Dec 05 23:13:08 I wouldn't want to be you, that's ultimately your call Dec 05 23:13:52 :) Dec 05 23:14:00 backporting is easy... do that all the time **** ENDING LOGGING AT Wed Dec 06 02:59:59 2017