**** BEGIN LOGGING AT Wed Apr 14 02:59:56 2021 Apr 14 03:00:03 ah, so I cloned the overlays Apr 14 03:00:13 bb.org-overlays Apr 14 03:00:16 Okay. Apr 14 03:00:16 not sure I installed it though Apr 14 03:00:19 maybe that's the problem? Apr 14 03:00:24 Maybe. Apr 14 03:00:34 make src/arm Apr 14 03:00:50 Let me boot my board to figure it out again. Apr 14 03:01:11 make: Nothing to be done for 'src/arm'. Apr 14 03:01:19 I'll  try apt installing though Apr 14 03:02:58 says it's already installed Apr 14 03:03:11 git clone the repos, please. Apr 14 03:03:11 hey I gotta go but I'll be back tomorrow Apr 14 03:03:14 I did Apr 14 03:03:16 Okay. Apr 14 03:03:18 Okay. Apr 14 03:03:23 I will catch up w/ you later. Apr 14 03:03:24 continue on stack overflow? Apr 14 03:03:27 Sure. Apr 14 03:03:28 thanks for the help! Apr 14 03:03:33 Hey! Apr 14 03:46:51 e Apr 14 05:18:56 Hi i bougth a BeagleBone Black and it's not working properly. the power LED blink once and that's all . Someone is passing for the same issue? Apr 14 05:55:54 just restarted debian.beagleboard.org Apr 14 07:43:57 beagleboard.org/blog finally restored. Apr 14 08:23:16 I am so irritated with AWS. turns out the fundamental problem with my restoration is that some AMIs are not compatible with some of their newer machine times and that was causing my backups to not boot. Apr 14 08:23:47 I just got a backup back on-line and am starting services and will move the IP address over in a little bit. Apr 14 08:24:15 when rebuilding the server, I kinda sorta cleaned things up, but it isn't worth it. Apr 14 08:35:51 ugh. not that simple. backup has a flaw with resolv.conf Apr 14 08:43:19 ah, yes, it is their crazy issue with the network adapter coming up as random ids. :-( Apr 14 08:59:50 ugh, ugh, ugh. everything seems to be running, but when I move the IP address I get no response. Apr 14 09:03:25 restored half-way restored backup and will try again tomorrow. night all. Apr 14 09:27:34 Hello, I'm looking for max operating system of beaglebone AI. Can anyone help about it? Apr 14 10:41:45 jkridner: problem of too many shinies upstream? ie. @amazon :) Apr 14 10:42:14 its one instance where its all designed to work with a set of tools, and if you don't use those tools, nothing works :/ Apr 14 10:42:40 whilst I see a use for that kinda devops software .. it should wrap functions, not re-write them! Apr 14 12:42:43 skr36: "max operating system" ? Apr 14 12:43:22 a system that operates maximally Apr 14 12:44:06 * kveremitz curses google translate Apr 14 13:28:18 bbb.io bring one to beagleboard.org but beagleboard.org does not bring you to beagleboard.org. Apr 14 13:34:11 wut Apr 14 13:34:21 that doesn't make sense Apr 14 14:35:30 m Apr 14 15:41:12 Hi ,anyone knows how to create a USB Gadget with the BeagleBoneBlack to recive packages from a HOST with libusb? Apr 14 15:44:53 I know there's a way to create custom usb gadget endpoints Apr 14 15:45:47 functionfs Apr 14 19:27:12 hey guys, I'm trying to figure out how to adjust the boot configuration of the GPIO pins Apr 14 19:27:19 on the baeglebone black Apr 14 19:27:54 I followed a process that was working at first, but then I accidentally bricked the beaglebone, and now when I redid the process it is not working Apr 14 19:27:58 I'm not sure what I did differently Apr 14 19:28:02 here's the process: Apr 14 19:28:34 1) installed ubuntu 18.04 on beaglebone black. the first time I put it on eMMC, the second time (after bricking) I put it on the SD card, because we wanted to switch to this anyways Apr 14 19:29:05 2) cloned this overlay repo: https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm and installed with sudo apt install bb-cape-overlays Apr 14 19:29:21 bb-cape-overlays wasn't installed by default? Apr 14 19:29:34 it said that it was already installed when I ran the command Apr 14 19:29:39 so I think it was Apr 14 19:29:42 by default Apr 14 19:30:06 3) I copied an example dts file from here: Apr 14 19:30:06 https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays Apr 14 19:30:09 I was about to say, the only reason for that to not be installed by default would be if ubuntu didn't support overlays at all Apr 14 19:30:28 for sure Apr 14 19:30:33 good point Apr 14 19:30:38 note that typically people just configure pins at runtime using config-pin Apr 14 19:30:55 yeah, that works for me, but I need to have it work at boot for hardware reasons Apr 14 19:30:59 interacting with another device Apr 14 19:31:40 4) I modified line 33 of the example file, just to change the pin mode (the 0x20) to see if that worked. I then compiled it into a .dtbo file with: dtc -O dtb -o out_file.dtbo -b 0 -@ in_file.dts Apr 14 19:31:43 fair enough, although all pins are by default in high-impedance with weak internal pull, and there's always some time between reset and being able to configure the pins Apr 14 19:32:18 5) I modified the /boot/uEnv.txt file so that it references the compiled dtbo file: Apr 14 19:32:21 if you need a line to be high or low _immediately_ at power-on, the appropriate solution is an external pull-up/down resistor (stronger than the internal pull) Apr 14 19:32:35 enable_uboot_overlays=1 Apr 14 19:32:36 uboot_overlay_addr0=~/test_gpio_configurations/test_config.dtbo Apr 14 19:32:46 that example looks very ancient Apr 14 19:32:51 6) I restarted Apr 14 19:32:53 and will run into problems on current images Apr 14 19:33:15 for sure Apr 14 19:33:24 I guess I would like to change the configuration in software as early as possible Apr 14 19:33:35 without making hardware modifications because the hardware design is already set Apr 14 19:33:51 I think this example worked for me before? but I'm certainly open to a different one Apr 14 19:34:11 I just want to be able to change the configuration of all the pins to various mode hex strings that I have put together Apr 14 19:34:12 I wouldn't expect it to work Apr 14 19:34:15 not sure the best way to do that Apr 14 19:34:32 there shouldn't be any magic hex strings in your overlay Apr 14 19:34:48 but concretely, what are you trying to configure? (to have a concrete example) Apr 14 19:36:02 I actually have a project intended to make overlays easier to write (using special preprocessing and better macros): https://github.com/mvduin/overlay-utils Apr 14 19:38:02 interesting, I thought they were not avoidable? Apr 14 19:38:12 here's what I'm trying to do Apr 14 19:38:17 (also, regardless of whether you use bb.org-overlays or my overlay-utils, please use the makefile to build overlays instead of manually invoking dtc) Apr 14 19:39:11 I think I tried that previously and it didn't work Apr 14 19:39:19 it said like "nothing to do for target" or something like that Apr 14 19:39:25 do you remember  the specific command? Apr 14 19:39:57 I am trying to change the configuration of the pins, mostly to be inputs or outputs, with no pull up/pull down resistors, to work with another piece of hardware Apr 14 19:40:07 when using bb.org-overlays put source code in e.g. src/arm/test_config.dts and invoke "make src/arm/test_config.dtbo" Apr 14 19:40:49 when using overlay-utils the source code is test_config.dtsi (and different in content) and the invocation is "make test_config.dtbo" Apr 14 19:40:59 UART example in overlay-utils: https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi Apr 14 19:41:51 this is essentially equivalent to this file in bb.org-overlays: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-00A0.dts Apr 14 19:42:13 ok, that compilation worked! Apr 14 19:42:41 (note that bb.org-overlays has a lot more boilerplate, although some of it is there for historical reasons and no longer actually needed) Apr 14 19:43:27 also, the bb.org-overlays BB-UART4-00A0.dts for some reason doesn't enable internal pull-up/down on the RxD pin, which is not recommended Apr 14 19:48:53 ok putting it in srcarm and compiling it with the new way worked! Apr 14 19:48:59 it's changing the pin configuration now Apr 14 19:49:07 but I'm certainly interested in a more user friendly version Apr 14 19:49:12 it'll still conflict with cape-universal Apr 14 19:49:14 unless you have that disabled? Apr 14 19:50:15 what is cape-universal? Apr 14 19:50:28 I have removed all the eMMC and am doing everything from the SD card, if that's relevant Apr 14 19:50:44 erased the eMMC you mean Apr 14 19:50:48 with blkdiscard? Apr 14 19:50:51 yes Apr 14 19:51:50 so if I use your overlay thing, then I clone the repo Apr 14 19:52:08 and modify uart4.dtsi? Apr 14 19:52:51 and compile with make, so it's very similar, except the syntax of the file is different? Apr 14 19:52:55 am I understanding correctly? Apr 14 19:53:08 it's very similar yeah Apr 14 19:53:42 even the file content is quite similar if you write it as "modern" as possible Apr 14 19:54:19 this is an as-literal-as-possible conversion of uart4.dtsi from overlay-utils to bb.org-overlays: https://pastebin.com/0GNY74mD Apr 14 19:55:38 if you compare them side by side you'll note the following differences: bb.org-overlays requires substantially more boilerplate at the top, it doesn't have my nice USES_PIN macro for disabling cape-universal nodes, and its pinmux macros are more verbose Apr 14 19:56:29 in overlay-utils I've stopped declaring pins as "input" or "output" in pinmux blocks since this doesn't actually do what people think it does Apr 14 19:57:12 (it only accepts whether the receiver is enabled, while having no effect on the pin's output-enable) Apr 14 19:57:18 *only affects Apr 14 19:59:16 huh Apr 14 20:00:13 bb.org-overlays has an advantage in having more overlays that can be used as example, but the downside that all of them are hideous due to using the older syntax originally required by dtc (which is much messier) Apr 14 20:00:33 do you have any examples that change more than just the UART pins? Apr 14 20:00:57 I want to change the configuration of like every GPIO pin, plus some UART, plus I2C and AIN1-3 Apr 14 20:01:07 I have the modes I want but I'm not sure where to pop them in in the file Apr 14 20:01:15 AIN doesn't have pin config Apr 14 20:01:33 also I am unable to connect to the internet on my beaglebone where I am right now (no ethernet), so I will have to play around with the old process Apr 14 20:01:35 for now Apr 14 20:01:51 is AIN permanently set? Apr 14 20:02:08 I mean, you can just rsync files from your computer to the beaglebone via usb Apr 14 20:02:58 scp or rsync Apr 14 20:04:20 e.g. if you git clone overlay-utils on your computer, you can "scp -rp overlay-utils ubuntu@HOSTNAME-OR-IP:" or "rsync -rpv overlay-utils ubuntu@HOSTNAME-OR-IP:" Apr 14 20:04:58 (I'd generally recommend rsync using scp) Apr 14 20:05:15 and yes the analog input have no pinmux Apr 14 20:06:21 as for gpios, the best way to configure those is using a gpio-helper, but that means you'll need to disable cape-universal Apr 14 20:06:34 i.e. lose the ability to use config-pin Apr 14 20:06:42 but it doesn't sound like that's a problem for your use-case Apr 14 20:07:01 for an overlay-utils example of that, see gpio-demo.dtsi Apr 14 20:07:49 there's also examples for a bunch of other stuff including i2c, just look around in the repo Apr 14 20:08:16 gotcha Apr 14 20:08:23 I will try to clone the repo and move with rsync Apr 14 20:08:51 note that with overlay-utils you can just combine multiple files into one .dtbo by either concatenating them or making one file that #includes the others Apr 14 20:09:12 (with bb.org-overlays a bit more care is needed to combine sources) Apr 14 20:09:33 losing the ability to use config-pin is maybe a bit annoying but not a dealbreaker Apr 14 20:09:54 how do I disable cape-universal though? Apr 14 20:10:11 yeah unfortunately cape-universal claims all gpios hence conflicts with basically any other use of gpios Apr 14 20:10:21 in /boot/uEnv.txt there's a setting that enables it, you can just comment it out Apr 14 20:10:48 can't remember the exact name, but it has "universal" in it Apr 14 20:11:25 (note: to disable it you need to comment it out, don't change it to =0 or whatever, that doesn't work) Apr 14 20:12:06 enable_uboot_cape_universal=1? Apr 14 20:12:15 currently commented for me Apr 14 20:13:02 then I'd assume config-pin currently doesn't work for you? (except maybe for P9.19/20) Apr 14 20:15:36 trying to query returns; Apr 14 20:15:36 P9_19 pinmux file not found! Apr 14 20:15:42 so I don't think so? Apr 14 20:15:49 also, sorry, I know this is a silly thing to get hung up on Apr 14 20:15:53 okay, then cape-universal is evidently not enabled :) Apr 14 20:15:57 but I'm having trouble scp/rsyncing Apr 14 20:16:00 glad to hear! Apr 14 20:16:20 I tried both commands you suggested, but overlay-utils isn't showing up at the destination Apr 14 20:16:35 the destination should be the same username@host you use for ssh, followed by a colon, optionally followed by the destination path Apr 14 20:16:41 don't forget the colon Apr 14 20:16:41 they didn't throw any errors, but they also didn't ask for authetnitcation which is suspiscious Apr 14 20:16:48 yeah you forgot the colon Apr 14 20:16:48 ah Apr 14 20:17:11 there we go Apr 14 20:17:14 you just created a local copy named "debian@whatever" on yoru computer ;) Apr 14 20:17:41 ah, interesting Apr 14 20:17:47 ok, I'm gonna try one of your config files now Apr 14 20:18:31 I also have a script for inspecting pinmux state which can be a rather useful diagnostic tool: https://github.com/mvduin/bbb-pin-utils/#show-pins Apr 14 20:18:53 ah, I'm already using that! Apr 14 20:18:57 didn't realize you wrote that Apr 14 20:18:58 it's great Apr 14 20:19:05 ok so I'm gonna try to use gpio-demo.dtsi Apr 14 20:19:08 I did indeed write that Apr 14 20:19:30 note that I think the image also shows with a show-pins.pl but that's an ancient version Apr 14 20:19:34 *ships with Apr 14 20:21:29 gotcha. I cloned the new one, someone else here suggested it Apr 14 20:21:32 very useful Apr 14 20:21:52 ok so I'm in overlay-utils Apr 14 20:22:01 building with make gpio-demo.dtbo Apr 14 20:23:01 says this: Apr 14 20:23:01 make: warning:  Clock skew detected.  Your build may be incomplete. Apr 14 20:23:11 I'm gonna ignore that though and see if it works anyway? Apr 14 20:23:18 yeah because your because has no internet access hence system date/time is wrong Apr 14 20:23:27 *because your beaglebone Apr 14 20:23:32 ahh Apr 14 20:23:45 so then I just change the line in /boot/uEnv.txt to reference that file? Apr 14 20:23:45 jeez my hands seem to be typing random words today Apr 14 20:23:51 haha Apr 14 20:23:58 because your because Apr 14 20:24:01 "why?" Apr 14 20:24:02 because Apr 14 20:24:30 yeah you can configure custom overlays into one of uboot_overlay_addr4..7 or dtb_overlay Apr 14 20:24:38 all five variables are equivalent Apr 14 20:25:06 (I'm not sure why it's not just one variable that accepts a list of paths instead... u-boot's scripting may be limited but it does have for-loops) Apr 14 20:25:59 fortunately the limit of max 5 custom overlays isn't really a problem since you can just combine overlays into one Apr 14 20:29:26 john_doe: btw if your host pc has ntpd running you can probably configure the beaglebone to use it (by configuring your host PC's IP on the usb-link into the "NTP" variable in /etc/systemd/timesyncd.conf and then "sudo systemctl restart systemd-timesyncd") Apr 14 20:29:45 to make it able to obtain the system date/time Apr 14 20:30:17 for sure Apr 14 20:30:24 is it gonna mess stuff up if I don't do that? Apr 14 20:30:28 or is it just a nice to have? Apr 14 20:30:58 well, files will have wrong timestamps, and make relies on those timestamps to work properly (which is why it complained about files having timestamps in the future) Apr 14 20:31:15 ah ok Apr 14 20:31:57 also, I restarted and  the beaglebone isn't bricked, so that's nice Apr 14 20:32:13 just trying to check to see if it worked now with show-pins Apr 14 20:32:22 PIN_PULLUP( P8_07, 7 )  // gpio 2.02 / button Apr 14 20:32:22                         PIN_PULLUP( P8_08, 7 )  // gpio 2.03 / reset-thing Apr 14 20:32:23                         PIN_PULLUP( P8_09, 7 )  // gpio 2.05 / input-bidi Apr 14 20:32:23                         PIN_PULLUP( P8_10, 7 )  // gpio 2.04 / output-bidi Apr 14 20:32:38 please don't paste multi-line stuff into chat Apr 14 20:32:45 my bad Apr 14 20:33:01 and yes, u-boot's usual way of reporting problems with an overlay file is by completely failing to boot Apr 14 20:33:11 haha Apr 14 20:34:42 that includes typos in node-references. for a main dtb such typos would be caught at compile-time by dtc, but for overlays dtc doesn't know which node-labels are valid and which aren't, so it just assumes they're valid and lets the runtime loader (i.e. u-boot) deal with invalid references Apr 14 20:34:53 (and u-boot doesn't deal with them very gracefully) Apr 14 20:35:24 ok well P8.7,8,9,10 are all inputs Apr 14 20:35:35 so I think it worked? Apr 14 20:35:39 gonna try adjusting one of them Apr 14 20:36:00 uhh two of then should be outputs? Apr 14 20:36:15 they all say rx Apr 14 20:36:29 that doesn't indicate anything Apr 14 20:36:50 well here's what show-pins says: Apr 14 20:36:50 well, it indicates the receiver is enabled, which is the case for all pins when using overlay-utils Apr 14 20:36:59 P8.08                             37 fast rx  up  7 gpio 2.03 hi >> Apr 14 20:37:04 that's output-high Apr 14 20:37:17 see https://github.com/mvduin/bbb-pin-utils/#gpio Apr 14 20:38:57 as far as I can tell from there, "rx" means "Whether the input receiver is enabled." Apr 14 20:39:07 so it seems like it should mean input? Apr 14 20:39:38 it means the pin can be used as input, it says nothing about whether the pin is used as output Apr 14 20:40:39 having rx disabled will make a pin useless as input since it will always appears to be low Apr 14 20:40:53 ah I see Apr 14 20:41:22 so it's the hi >> that I'm looking at Apr 14 20:41:42 so it looks like it's working then! Apr 14 20:42:00 for an output it usually doesn't matter whether rx is enabled or disabled (apart from a tiny amount of power consumption), though in a few causes certain outputs actually require rx being enabled for retiming purposes (notably for SPI clock output) Apr 14 20:42:10 gotcha Apr 14 20:42:25 so I just have to play around with the file then for my specific configuration Apr 14 20:42:26 since having rx enabled is always safe and there's very little benefit from ever disabling it, I don't bother with it in overlay-utils Apr 14 20:42:37 gotcha Apr 14 20:42:47 another question I have Apr 14 20:43:10 if I take out the SD card from this beaglebone and put it in another beaglebone now, should that bring along the configuration? Apr 14 20:43:29 of course, why would it not? Apr 14 20:43:48 I've been trying to do everything off the SD card (like disabling eMMC) but I'm not sure if the /boot files, etc. are on the local memory or the SD card Apr 14 20:43:48 the only thing to beware of is the risk of an old bootloader on its eMMC causing problems Apr 14 20:43:54 gotcha Apr 14 20:44:12 so I'll try putting it in the other one Apr 14 20:44:22 and if it doesn't work I'll look for the S2 button to hold while booting Apr 14 20:44:22 use "findmnt" to show a tree of mounted filesystems Apr 14 20:44:43 you'll see /boot is not a mountpoint, hence it's part of the root filesystem Apr 14 20:45:06 ok, and the root filesystem being on the SD card I'm guessing? Apr 14 20:45:32 obviously since you've booted from SD card... also, you've erased eMMC so it has no filesystem that could even be mounted Apr 14 20:46:01 and findmnt also directly shows whether the root filesystem is SD (/dev/mmcblk0p1) or eMMC (/dev/mmcblk1p1) Apr 14 20:46:07 dope Apr 14 20:48:10 ("findmnt /" gives more succinct output if you just want to check whether the root filesystem is on SD or eMMC) Apr 14 20:48:43 gotcha Apr 14 20:48:48 hmmm, I'm having trouble connecting to this one Apr 14 20:48:55 is it possible the IP changed? Apr 14 20:49:04 I'm able to try to connect but it doesn't accept the password Apr 14 20:49:06 which is the same Apr 14 20:49:16 usb networking uses static configuration Apr 14 20:49:19 or does that mean it's booting from the eMMC on the new beaglebone and I have to do the button thing? Apr 14 20:49:32 that would be my guess, if that thing still has an ancient eMMC Apr 14 20:49:41 it might Apr 14 20:49:48 I'll reboot and look for that button Apr 14 20:49:52 (or try logging in as debian/temppwd instead of ubuntu/temppwd) Apr 14 20:50:10 ah that worked Apr 14 20:50:21 ok so I'll just delete the eMMC then ya? Apr 14 20:50:31 note: the button needs to be held down when connecting power (i.e. while plugging it into usb), holding it down during reboot has no effect Apr 14 20:50:58 with blkdiscard /dev/mmcblk1 Apr 14 20:51:12 or can I not do that when the OS is currently loaded from the eMMC? Apr 14 20:51:18 I'm not sure if it will let you do that while it's booted from eMMC, but you can certainly try Apr 14 20:51:53 if it does it, I'd suggest unplugging it right away afterwards, don't try to reboot or whatever ;) Apr 14 20:51:55 haha it says Apr 14 20:52:13 you could definitely just wipe the bootloader though Apr 14 20:52:14 with great power comes great responsibility Apr 14 20:52:16 and it let me do it Apr 14 20:52:19 lol Apr 14 20:52:54 ok i unplugged and am holding the button Apr 14 20:53:01  while plugging in Apr 14 20:53:10 well if you just wiped eMMC you don't need the button Apr 14 20:53:55 gotcha Apr 14 20:56:03 ok, now it's not responding to SSH unfortunately Apr 14 20:56:30 does it seem to boot normally? (based on led activity) Apr 14 20:56:43 I don't think so, but I'm not sure Apr 14 20:56:46 the power led is on Apr 14 20:56:52 none of the other 4 are on Apr 14 20:56:58 I think they were on previously but am unsure Apr 14 20:57:17 after power-cycling? Apr 14 20:57:31 yes Apr 14 20:57:40 although I can try power cycling again if you think that'll help Apr 14 20:58:17 as in, do the leds have any activity when power-cycling? (apart from the power led) Apr 14 20:59:06 they do not Apr 14 20:59:15 ah I see Apr 14 20:59:27 did you forget to insert the sd card? :) Apr 14 20:59:28 the SD card wasn't plugged in all the way haha Apr 14 20:59:32 yeah Apr 14 20:59:40 You guys! Apr 14 20:59:52 yeah, I've noticed that sometimes the beaglebone ships with the sd card slot eject mechanism in the wrong state Apr 14 20:59:55 My sd card is in it! It still does not boot! Apr 14 21:00:08 (caused by pulling out the sd card after flashing instead of pressing it to eject) Apr 14 21:00:29 I think my Buildroot has ruined my life! Yea. Apr 14 21:00:29 so when you then insert a card the first time, you trigger the eject mechanism Apr 14 21:00:56 GenTooMan: Breathe! Apr 14 21:02:08 * set_ just got back from my first interview in 12 years! Yes! Did I nail it? No! But, was it fun? YES == YES! Apr 14 21:02:52 Boy, i tell you, the more I get older, the older I get. Apr 14 21:02:53 nice Apr 14 21:03:22 So, outside of that and buildroot ruining my current existence, proceed. Sorry for interrupting. Apr 14 21:04:13 for sure Apr 14 21:04:26 so I got the new beaglebone booting, including the new boot configuration Apr 14 21:04:38 Seriously? Apr 14 21:04:43 Nice! Apr 14 21:05:07 so now the only remaining thing is to adjust the boot configuration file for the specific configuration I need Apr 14 21:05:17 yeah, zmatt's been very helpful! Apr 14 21:05:18 the overlay you mean Apr 14 21:05:24 Do not use Buildroot! Apr 14 21:05:31 You will scorn the day! Apr 14 21:05:44 It is too easy and never works. Apr 14 21:05:56 set_: why the hell are you meddling with buildroot? Apr 14 21:06:11 B/c...buildroot called and I answered his willfully blow. Apr 14 21:06:18 also, why am I even still questioning why you do things Apr 14 21:06:24 I should know better Apr 14 21:06:25 I do not know! Apr 14 21:06:27 Oh. Apr 14 21:06:30 Right. Apr 14 21:06:35 I should but will I listen? Apr 14 21:06:51 Maybe or maybe not? Apr 14 21:06:56 Sir? Apr 14 21:06:58 Hey! Apr 14 21:07:09 @zmatt: Sorry. I will calm down. Apr 14 21:07:13 please do Apr 14 21:12:01 haha Apr 14 21:12:10 so in order to modify this file, there's a bunch of blocks like this: Apr 14 21:12:11 button {gpio = <&gpio2 2 ACTIVE_LOW>;  // P8.07 input;}; Apr 14 21:12:36 is the first word to be duplicated? or is it a unique variable name? Apr 14 21:12:40 "button" is the name Apr 14 21:12:46 a label for it Apr 14 21:12:52 ok so I can name that whatever Apr 14 21:13:04 and I'm assuming it should be a different name for each one? Apr 14 21:13:47 yes and yes. cape-universal names them after the expansion header pin (e.g. P8_07), though for an application-specific overlay like this I'd suggest naming them after the actual function of the gpio Apr 14 21:14:33 this is particularly useful when combined with a simple udev rule that creates symlinks in /dev/gpio/ Apr 14 21:15:00 since then applications can locate the gpio by name instead of having to know or care about gpio numbers or expansion header pins Apr 14 21:15:26 ok, so I just add more blocks Apr 14 21:15:32 name them based on the function Apr 14 21:15:38 adjust the gpio particular name Apr 14 21:15:44 and adjust the mode Apr 14 21:15:53 what about the part at the bottom? Apr 14 21:16:06 the PIN_PULLUP stuff? Apr 14 21:17:38 that's the actual pinmux block for your gpio-helper device, which should have one entry per pin, either PIN_PULLUP, PIN_PULLDN, or PIN_NOPULL, and all of them mode 7 (which is gpio mode) Apr 14 21:18:03 ahh I think I understand Apr 14 21:18:11 so each GPIO is modified in two places Apr 14 21:18:23 the upper block with the name that sets input/output Apr 14 21:18:43 and the lower block that sets it as PULLUP PULLDOWN etc. Apr 14 21:20:00 and is there any way to refer to them by P8_07, P8_08, etc. in both places? Apr 14 21:20:01 this might help a bit for mental model: https://photos.app.goo.gl/9Ph5ABujjCRTst9g9 Apr 14 21:20:21 or does it need to be by GPIO number at the top and P8/P9 number at the bottom? Apr 14 21:21:10 oh so I'll have to have a few groups of pinmuxes I guess? Apr 14 21:21:39 it has to be by gpio number in the gpio-declarations and P8/P9 number at the bottom... if it helps, the include/bone/black.h file that defines the P8/P9_ macros has the gpio numbers in comments Apr 14 21:21:55 the gpio-helper sets up the gpios in the gpio controllers Apr 14 21:22:17 which are identified by gpio controller (e.g. &gpio2) and which of its gpios (range 0-31) Apr 14 21:22:27 the gpio controller does not know anything about pinmux Apr 14 21:22:31 gotcha Apr 14 21:23:05 and do you know if any of your example files modifies a larger number of GPIO pins? Apr 14 21:23:05 the pinmux block at the bottom sets up the pinmux and other I/O cell characteristics, such as the internal pull-up/down resistor on the pin Apr 14 21:23:09 I think I understand how to change it Apr 14 21:23:29 but it's always faster/easier to screw up to adjust something then create Apr 14 21:23:52 well gpio-demo.dtsi already sets up 4 pins, I assumed that would be enough for the general pattern to be evident Apr 14 21:24:02 ok for sure Apr 14 21:24:15 for the pinmux thing, I still didn't get that Apr 14 21:24:31 will it just be one pinux block for all of them? Apr 14 21:24:42 ie &am33xx_pinmux Apr 14 21:24:44 it's already one pinmux block for four gpios Apr 14 21:24:53 names gpio_demo_pins Apr 14 21:25:02 is that pinmux usable for all the GPIOs? Apr 14 21:25:03 since it's the pinmux block for /gpio-demo Apr 14 21:25:40 so, you're creating a "gpio-of-helper" device, which is a virtual device that sets up and exports one or more gpios Apr 14 21:26:10 if it's a virtual pinmux, it sounds like I can just lump all the GPIOs in there? Apr 14 21:26:14 in gpio-demo.dtsi, that device is named "gpio-demo" ... that name is basically arbitrary, as long as it doesn't conflict with any other node in the root of the device tree Apr 14 21:26:30 yes, there's usually no reason to create more than one gpio-of-helper device Apr 14 21:26:43 so you could just name it "gpios" or whatever instead of "gpio-demo" Apr 14 21:27:40 hold on, lemme make a differently annotated example Apr 14 21:28:38 cool Apr 14 21:28:44 I'm filling in the GPIO configs now Apr 14 21:28:52 I'll test that then move to the other configs Apr 14 21:28:58 like UARTs and I2C's Apr 14 21:41:17 ok if I don't want pull up or pull down resistors Apr 14 21:41:23 then I replace PIN_PULLUP Apr 14 21:41:26 PIN_NOPULL Apr 14 21:41:34 with like PIN_NOPULL or something? Apr 14 21:41:34 cool Apr 14 21:41:45 that rings a bell, although I don't remember where i saw that Apr 14 21:42:09 is there a readme or something with the options? Apr 14 21:45:02 https://pastebin.com/GZPtyA8e Apr 14 21:45:12 ugh, pastebin uses a tab width of 4 instead of 8 Apr 14 21:47:25 ah ok, so in that comments Apr 14 21:47:27 comment Apr 14 21:47:55 updated it to clarify that "gpio-label" is an arbitrary label that must be unique per gpio Apr 14 21:49:10 note that having either pullup or pulldown enabled is recommended in most cases, just to ensure pins never are never floating Apr 14 21:49:32 though for pins configured as output, the output level will override the pull Apr 14 21:50:23 (but technically there's a short window of time between the pinmux being configured and the output being configured) Apr 14 21:51:39 (and if the gpio-of-helper probe fails for whatever reason the pinmux will still be setup even if the gpio setup may not be (fully) applied) Apr 14 21:54:26 I should probably add more guidance on pull-up/down ... brb though Apr 14 21:59:00 gotcha, we do not want pull ups/pull downs enabled as per our configuration Apr 14 22:01:55 where is the bone/black.h file? Apr 14 22:02:11 trying to figure out the pin correspondances between P8_17 and GPIOs, etc. Apr 14 22:06:26 in the include/ dir Apr 14 22:07:23 if have pull-ups/downs disabled, make sure that any gpio configured as input is at all times is externally pull or externally driven Apr 14 22:07:43 i.e. you should not configure pins as NOPULL if you do not have your hardware attached to the beaglebone Apr 14 22:08:04 (which is one reason I'd generally recommend configuring pins as either PULLUP or PULLDN) Apr 14 22:10:33 they should all be externally driven Apr 14 22:10:44 this lists P8_03 --> 6 for example Apr 14 22:10:53 ? Apr 14 22:11:20 where would I go to find the correspondance between P8_03 and GPIO1 17 or whatever? Apr 14 22:11:24 gpio number is in the comments Apr 14 22:11:26 (the black.h file) Apr 14 22:11:32 ah Apr 14 22:11:33 "io 1.17" Apr 14 22:11:36 I see Apr 14 22:11:37 thanks! Apr 14 22:11:46 note that P8.03 is normally in use by eMMC Apr 14 22:12:14 (P8.03-06 and P8.20-25) Apr 14 22:12:18 that was just a random one Apr 14 22:12:22 ok Apr 14 22:12:42 P8_17 though is weird Apr 14 22:12:49 corresponds to 0.27? Apr 14 22:12:55 what's weird about that? Apr 14 22:12:59 I thought there was only GPIO 1 and 2 Apr 14 22:13:03 like 1.27 and 2.27 Apr 14 22:13:16 there are four gpio controllers (0-3) Apr 14 22:13:30 oh huh Apr 14 22:14:46 note btw that show-pins also lists gpio numbers (for pins configured as gpio, which all digital I/O pins on the expansion headers are by default except for P9.19/20) Apr 14 22:16:11 or if you want a concise but detailed overview of the expansion header pins and their pinmux options, see the P9 and P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Apr 14 22:17:08 (which also has some warnings/cautions to be mindful of for some pins) Apr 14 22:17:12 gotcha Apr 14 22:17:18 ok I wrote down all the correspondances Apr 14 22:17:48 will do, thanks Apr 14 22:22:46 ok so I did the pinmux part Apr 14 22:22:46 note that if your inputs are always externally driven (when your hardware is attached) then there's probably no reason to configure them as NOPULL since the internal pull will be overridden by the external circuit... the only benefit of NOPULL would be a small reduction in power consumption, while the benefit of PULLUP/PULLDN will be that it'll ensure the inputs have a defined level (instead of ... Apr 14 22:22:52 ...floating) if you boot the beaglebone when it's not plugged into your hardware Apr 14 22:22:59 now I'm trying to figure out how to do the top part Apr 14 22:23:09 gotcha Apr 14 22:23:17 it'll always be plugged into hardware Apr 14 22:23:38 so if I want it to be input I put 'input' at the bottom Apr 14 22:23:52 and if I want output, I put 'init-high'? Apr 14 22:24:03 init-high or init-low depending on the initial output level Apr 14 22:24:20 ok Apr 14 22:24:27 again see comments in https://pastebin.com/GZPtyA8e Apr 14 22:24:33 which I thought explained it in fair detail Apr 14 22:25:12 ah I see Apr 14 22:25:18 sorry wasn't looking at that Apr 14 22:25:34 so it looks like all my stuff will be ACTIVE_HIGH Apr 14 22:25:39 cause that's apparently "normal" Apr 14 22:26:03 ACTIVE_HIGH versus ACTIVE_LOW just affects the interpretation of the levels Apr 14 22:26:13 ok Apr 14 22:26:27 so then I basically just put high or low Apr 14 22:26:32 ACTIVE_HIGH means a low voltage is "0" and a high voltage is "1" Apr 14 22:26:33 and an initial value if I want Apr 14 22:26:38 ACTIVE_LOW means a low voltage is "1" and a high voltage is "0" Apr 14 22:26:41 yeah that's what I want Apr 14 22:26:45 ACTIVE_HIGH Apr 14 22:26:50 gotcha Apr 14 22:28:22 e.g. when connecting a button: https://inside.mines.edu/~coulston/courses/EENG383/lecture/img/button.jpg Apr 14 22:29:39 (of course you could also account for it in software, but it's arguably more elegant to declare it in DT and allow software to not have to know or care) Apr 14 22:31:33 or for leds (or similar output circuits): https://inside.mines.edu/~coulston/courses/EENG383/lecture/img/led.jpg Apr 15 00:35:16 Hey...did you guys figure out what I acted like was so easy? Apr 15 00:35:45 That, um, that overlay business is what I am discussing here! Apr 15 00:38:02 On the job now, I am asking for breaks and food consumption ideas for knowledge. Also, I will need my smoke breaks. No offense to anyone who hates that about me. Apr 15 00:38:34 I think they want me to sit still in the electrical chair for hours on end until I snap! Apr 15 00:38:51 Anyway, off subject. Apr 15 00:38:53 Sorry. Apr 15 00:38:54 Dang it. Apr 15 01:40:44 set_, I will explain what can happen to you for smoking. Cancer is actually the rarer problem you get. You will end up with circulatory dysfunction, possible heart conditions as well as being a potential CVA candidate. Apr 15 01:41:30 set_, simply put you have nothing to gain by smoking, however nicotine is 400 times more addictive than heroine Apr 15 01:43:14 set_, my brother use to smoke then he had 2 CVA's now he doesn't smoke as he was in the hospital for a month afterwards. Apr 15 01:43:32 set_, and he was the fortunate one. Apr 15 01:44:46 We, including us, uses electricity. Apr 15 01:44:50 You too. Apr 15 01:45:05 * GenTooMan wonders what that has to do with smoking :D Apr 15 01:45:35 well, electricity can cause things to smoke Apr 15 01:45:38 Electrical shock, outside of my bad habits, is not something to take lightly. Apr 15 01:46:09 @zmatt: What things do electrical matters have to do w/ smoking, kind sir? Apr 15 01:46:29 sorry, smoke in general. Apr 15 01:46:54 I am not mad or anything but like w/ lasers? Apr 15 01:47:22 it was a joke set_ Apr 15 01:47:30 Oh. Apr 15 01:47:38 y'know, "releasing the magic smoke" Apr 15 01:47:45 I am terrible w/ jokes...you know this! Apr 15 01:47:49 Oh. Yes, yes. Apr 15 01:48:21 I keep hearing of that stuff. But...my boards have never done that (praying never) smoking stuff yet. Apr 15 01:49:55 My BBBlue was the closest so far. But, it just failed under pressure, current. Apr 15 01:54:52 I've smoked a few boards. I did warn the guy who was designing them that without a definite polarization marking on it someone who was even a little distracted could mess it up. I did that. :D Apr 15 02:23:12 * set_ Says "GenTooMan" in da 'hizzy! Apr 15 02:23:23 Not one single person is perfect as I do into hiding. Apr 15 02:25:43 do is actually go? Apr 15 02:27:40 Yes sir. Apr 15 02:28:01 Can one, "do" into hiding? Apr 15 02:28:43 I contacted Mouser about the board in question. Apr 15 02:29:16 I think the hardware was misconfigured on my end. Apr 15 02:32:40 well measure multiple times cut once. Apr 15 02:32:57 Yes sir. You burned a board! Apr 15 02:33:11 I have to learn by slowing down too. Apr 15 02:34:04 I think someone notified you that would be better or at least less expensive Apr 15 02:34:59 No notification here, kind sir. **** ENDING LOGGING AT Thu Apr 15 02:59:56 2021