**** BEGIN LOGGING AT Mon Nov 22 02:59:56 2021 Nov 22 04:10:37 is beaglecfg done already? I am askin' b/c I see it is a bit buggy. I was scrolling in the GPIO pins section and received some errors. Nov 22 04:11:59 The errors were just random alpha-numeric characters showing on different parts of the screen. Nov 22 04:12:11 i.e. in the terminal. Nov 22 04:14:56 GenTooMan: Where are you? Get to the ole 'puter. I am senseless and learnin' while takin' notes. Nov 22 04:17:37 Anyway, when you get the message, look at this figure...$600.00. Does that seem reasonable for three to five boards? I know the answer is no but other, cheaper outlet places are asking about holes. Nov 22 04:37:50 set_, hmm you may want to look at automated calculators for assembly for ideas on costs for assembly. It mostly depends on what they are doing. pick and place versus hand assembly. Nov 22 04:39:30 Oh. Nov 22 04:39:32 Okay. Nov 22 04:39:42 I looked online at automation. Nov 22 04:40:13 I keep getting these questions, "How many holes do you have?" Then, there are other normal questions but... Nov 22 04:40:25 How should I derive the amount of holes w/out knowing? Nov 22 04:41:43 I mean...I can count the holes on the PCBs made by OSH Park but some of them are very tiny. myeyes. Nov 22 04:41:45 Ha. Nov 22 04:42:43 I found some actual nice automated customer survey data on the automation assembly quoters. Nov 22 04:43:15 But! Holes still...I really feel like counting holes is far beyond what needs to happen. Nov 22 04:43:46 i was going to deal w/ SmallBatchAssembly but I think they went under. Nov 22 04:44:10 Like that... Nov 22 04:44:31 Poof. Nov 22 04:56:47 hmm you mean through holes or vias? is that for the board or for through hole parts? Nov 22 05:05:31 Right. Nov 22 05:06:20 The automation sites just kept asking about and I quote, "holes." Nov 22 05:06:37 Literally, "How many holes are on the board?" Nov 22 05:12:33 I got tired of searching Chinese and Japanese and Taiwanese suppliers. At first, I figured, "This is a good idea and cheap!" Nov 22 05:12:36 I soon learned. Nov 22 05:12:56 That they are asking too much for something that may not be as is stated when purchasing. Nov 22 05:13:43 Who can I get to when things go awkward? You know? I am not traveling to Japan over some $350.00 in boards. Nov 22 05:15:04 I know these are not issues to you. So, I am just chatting about it b/c it has to do w/ making Capes for my BBB type boards. Nov 22 06:07:52 Hi guys, We are using the Avahi service for resolving domain names in Beaglebone devices in the local network. A set of 7 devices connected and running successfully for 3 days with the domain name. After that, we could not access the device using the domain name. Avahi logs were not found in the message log or Syslog. What might cause the domain Nov 22 06:07:52 name resolving to fail? The local network was created using Ethernet beagle bone black boards. Nov 22 06:07:53 Note: Similar set of another 7 devices in other network was working good. Avahi service documentation link - http://avahi.org/ Nov 22 11:31:14 Raajeshwar: an annoying thing that can happen with avahi when certain network changes occur is that it manages to conflict with its own registration, causing the avahi hostname to get renamed... that would result in logs though, check with "journalctl -u avahi-daemon" Nov 22 11:32:22 one way to check the current avahi hostname is with: busctl call org.freedesktop.Avahi / org.freedesktop.Avahi.Server GetHostName Nov 22 11:33:05 (the issue is tracked at https://github.com/lathiat/avahi/issues/117 ) Nov 22 11:33:29 that's the only thing I can think of that may cause hostname resolution to suddenly start failing Nov 22 11:41:20 We didn't check journalctl -u avahi-daemon when this happened. But checked /var/log/syslog and /var/log/messages and found nothing from avahi. The problem is we then restarted avahi in all devices and then we didn't see this issue. Nov 22 11:42:59 I have no idea what is or isn't logged by rsyslogd, I haven't used it in many many years Nov 22 11:43:22 I think it's *supposed* to log these things too, but dunno Nov 22 11:43:48 (if you have rsyslog installed that is, which I don't but afaik it is still installed by default0 Nov 22 11:43:51 ) Nov 22 11:47:15 Thank you, let us see if we can replicate again and run "journalctl -u avahi-daemon". Nov 22 11:47:40 you can add the -f option to journalctl to continuously monitor the log output (exit with control-C) Nov 22 15:59:47 Hello, I have a 4D LCD cape which is identified by BB-BONE-LCD4-01-00A1.kernel. I want to use the buttons on the cape programmatically. I saw in https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts that the buttons are disabled to be used by other programs, and then are defined to do some keymapping( up down, left right. How do I get this stuff removed? Do I have to rebuild the kernel? Does the extension i Nov 22 15:59:48 .kernel, imply that this thing is resident in the kernel? Nov 22 16:20:36 johanhenselmans, .kernel means it was a *.dtbo in the kernel build, vs the exernally built version.. Nov 22 16:21:15 aka, bb.org-overlays will eventually go away, do to kenrel abi changes breaking the generic *.dtbo's.. Nov 22 16:22:02 johanhenselmans, ".kernel" version are stored here, grab the branch for your kenrel: https://github.com/beagleboard/BeagleBoard-DeviceTrees Nov 22 16:22:59 So that means that changing the behaviour of a cape means recompiling a complete kernel, or are these dynamically loaded from /lib/firmware or some such? Nov 22 16:24:17 johanhenselmans, no changing in building, other then the repo: Nov 22 16:24:36 kernel specific overlays are located under: ls /boot/dtbs/`uname -r`/overlays Nov 22 16:24:42 where as generic are /lib/firmware/ Nov 22 16:25:06 https://github.com/beagleboard/BeagleBoard-DeviceTrees has the exact same "make make install" as https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts Nov 22 16:27:21 OK, so BB-BONE-LCD4-01-00A1.dtbo is found in /boot/dtbs/`uname -r`/overlays, so that means recompiling the kernel, correct? Nov 22 16:28:22 johanhenselmans, 'no'... that doesn't mean recomping the kernel.. if you want to modify that specific overlay, clone the branch specific to the kernel version from: https://github.com/beagleboard/BeagleBoard-DeviceTrees then modify hte *.dts, and run make ; make install.. Nov 22 16:28:35 which kernel are you using today? Nov 22 16:29:00 5.10.78-bone57 as per instruction... Nov 22 16:29:13 i've got a lot of instructions. ;) Nov 22 16:29:28 That's this branch: https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v5.10.x Nov 22 16:30:08 git clone -b v5.10.x https://github.com/beagleboard/BeagleBoard-DeviceTrees Nov 22 16:32:11 Already checked out the repo. Now to get a compile running via NFS, with Mac OS as a server… (I’ll just clone it to another BBB). Nov 22 16:32:45 only gcc, device-tree-compiler is required.. Nov 22 16:32:57 should build in less then a minute on a bbb.. Nov 22 16:38:45 And…. dtc is missing (starting from a the 1GB console image) Nov 22 16:46:06 Hmm, make src/arm/overlays/BB-BONE-LCD4-01-00A1.dtb does indeed compile only that specific dts, but make install src/arm/overlays/BB-BONE-LCD4-01-00A1.dtb starts compiling all the stuff. Anyway, I’ll just copy the dtb file to /boot/dtbs/`uname -r`/overlays. Nov 22 16:47:12 Should I rename it ot dtbo? Any difference? Nov 22 16:49:02 And reboot… Nov 22 16:49:39 just do a 'make ; sudo make install', other things aren't really tested.. Nov 22 16:57:03 Ah, OK. Just rebooted, button pins are not seen as part of the cape, and display stilll works. Only problem is that ‘config-pin p9.15’ now says ‘ open() for /sys/devices/platform/ocp/ocp:P9_15_pinmux/state’ failed, No such file or directory. Should it not be a default pin config? Nov 22 16:58:35 Ah, missed the ‘disabled part in the beginning. Recompile in a minute. Nov 22 17:26:46 Nearly there. It seems that P9.16 is now part of something called ocp/P9_16_pinmux (pinmux_P9_16_gpio_input_pin), which prevents it from setting via ‘config-pin p9.16 gpio_input’. Where did that one come from? Nov 22 21:42:57 what's "gpio_input" ? Nov 22 21:43:05 that mode makes no sense Nov 22 21:43:29 johanhenselmans: and "ocp/P9_16_pinmux" is actually thing that allows config-pin to work Nov 22 21:44:07 note that all configurable pins except P9.19/20 default to gpio anyway Nov 22 21:46:00 there are three relevant gpio modes: "gpio_pd" (internal pull-down enabled), "gpio_pu" (internal pull-up enabled), "gpio" (internal pull-up/down disabled" ... the "default" mode is a synonym for "gpio_pu" or "gpio_pd" (which of the two varies per pin), except for P9.19/20 for which default is i2c Nov 22 21:52:42 it seems inconsistent whether "gpio_input" mode exists or not, but whenever it does it appears to be a synonym for "gpio" Nov 22 21:52:56 I have no idea why it exists Nov 23 00:51:54 Does anyone know where I can find a doc that shows the pinouts of the pin header on the BeagleBone AI? Nov 23 01:27:53 Guest32: Yes. Nov 23 01:28:03 I say github. Nov 23 01:37:28 Hey...are you guys building a 64-bit AI? Nov 23 01:40:11 Guest32: Here... https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual . That should bring you to the 32-bit SiP AI. Nov 23 01:41:44 Sorry. SoC AI. Nov 23 01:43:13 So, the pinouts are here: https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#71-expansion-connectors . Nov 23 02:01:08 mattb0ne: Look here ... https://community.element14.com/learn/learning-center/essentials/w/documents/23151/mechatronics-ii-magnetic-encoders?ICID=essentials-featured-widget Nov 23 02:01:37 I know you were going over encoders of different types w/ actuators, right. So, look at that specific example. Nov 23 02:01:43 It is a short on ideas. **** ENDING LOGGING AT Tue Nov 23 02:59:57 2021