**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2022 Aug 02 03:18:33 August snapshots are now up... https://forum.beagleboard.org/tag/latest-images (BBAI-64 had a late fix, those massive files are uploading in the same directory, i'll update the forum page tomorrow..) Aug 02 03:31:24 Nice! Aug 02 20:28:33 Can I used a 5v battery connected to the BBB's USB port (P4 I think) to powerup the BBB which would then trigger a relay that would supply power to the BBB via the barrel connector? Aug 02 20:28:52 I.e., what happens if I connect two power sources to the BBB? Aug 02 21:21:01 Hi Aug 02 21:21:12 It's about 400 mA consumption Aug 02 21:21:48 You could provided you regulate properly, there's no 5V battery, go for 5V +/- 5% approximately. Aug 02 21:22:06 So you probably need a regulator, which is battery type ? Aug 02 21:25:22 Guest4494: usb and the 5v barrel jack are independent power inputs for the BBB, it will switch between them automatically Aug 02 21:26:14 jfsimon1981_b: given we're talking about usb here, presumably they mean a usb battery pack (with regulated 5v output) Aug 02 21:26:59 zmatt, does the barrel have higher priority? Aug 02 21:27:36 not sure, although it's possible to force the selection using software Aug 02 21:28:07 jfsimon1981_b, yes.  The BBB controls a device that will provide power to the BBB, but not until the BBB closes a switch on the device. Aug 02 21:28:54 Guest4494: what's the goal of this arrangement? Aug 02 21:28:59 So, my thought was use a 5v USB battery to start the BBB which would then toggle the device on which could then power the BBB, so the battery is only needed for the first  minute or so. Aug 02 21:29:59 Yes got it Aug 02 21:31:33 The BBB is controlling an inverter in a temperature-hostile environment.  We'll have some temp sensors also attached to the BBB.  The inverter will power the BBB most of the time, but chicken & egg problem, it can't do so until the BBB has toggled the inverter on.  So, I thought we'd start the BBB via battery, and then the BBB could switch to Aug 02 21:31:34 the barrel jack power once the inverter is turned on by the BBB. Aug 02 21:33:31 This way the battery only has to power the BBB for the first minute or two. Aug 02 21:34:27 The question is once there's power on the barrel jack, will the BBB cease drawing power on the USB connector? Aug 02 21:34:41 and presumably also if a situation requires the BBB to shut off the inverter? Aug 02 21:34:56 (since if no such situation exists you wouldn't be having the BBB control it) Aug 02 21:35:56 zmatt, yes, although in that scenario we anticipate intervention, too, (the BBB will send alerts via ethernet). Aug 02 21:36:44 it's possible to disable/enable the usb power input in the pmic through i2c writes, so you could disable it once you've turned on the relay and confirmed power via the barrel input is stable, and conversely you'd reenable usb power prior to disabling the inverter relay Aug 02 21:38:28 Right.  But I'm wondering if the BBB does that automatically, i.e., switch between power sources (?). Aug 02 21:38:49 the pmic will switch automatically but it's a bit vague based on what it will switch Aug 02 21:39:13 so I probably wouldn't rely on that Aug 02 21:39:16 Ah, uncertainty!  Just what we want. ;-) Aug 02 21:40:09 Yes, if I can/must control it myself directly, that's fine.  Just wasn't sure what the BBB needed. Aug 02 21:41:04 that would be the best way to ensure it won't drain the battery while the inverter is on Aug 02 21:42:16 there isn't even a status bit that shows from which of the two inputs it's drawing power, it only has a status bit for each of the two inputs showing whether power is available on that input Aug 02 21:43:46 But I can explicitly tell it which input to use, right?  IOW, I can give it direction but not ask it any questions? Aug 02 21:44:05 you can disable one of the inputs, thus forcing it to use the other one Aug 02 21:46:28 i2cget -f -y 0 0x24 0x01 shows 0x3f by default, which means both inputs are enabled Aug 02 21:46:51 i2cset -f -y 0 0x24 0x01 0x2f would disable the usb power input Aug 02 21:47:11 i2cset -f -y 0 0x24 0x01 0x3f reenables the usb power input Aug 02 21:49:05 How do I determine if power on the barrel input is there/stable yet? Aug 02 21:50:00 I could just wait x minutes but that seems to assume a lot. Aug 02 21:50:15 i2cget -f -y 0 0x24 0x0a bit 2 indicates usb power is present and stable, bit 3 indicates power is present and stable on the barrel jack Aug 02 21:52:06 (bit 7 is always set, bit 0 indicates whether the power button is currently pressed, the remaining bits are unused) Aug 02 21:57:33 Does bit 0 remain on (1) once the power button is pressed, i.e., while it's powering down? Aug 02 21:58:16 bit 0 just shows the current status of the button, i.e. whether it's currently being pressed or not Aug 02 21:58:48 Ok, that's fine.  Shouldn't really need that (but good to know). Aug 02 21:58:52 the kernel driver also gets an interrupt when the button is pressed and generates a KEY_POWER event which, depending on configuration, may trigger systemd to perform a poweroff Aug 02 21:59:06 (or some other action) Aug 02 22:03:36 (and long-pressing the button causes the pmic itself to perform either a hard power-cycle or a hard power-off... it's supposed to be a power-cycle but due to the braindead design of the pmic it may end up doing a power-off instead, depending on how much current is being drawn at the moment it's doing this) Aug 02 22:04:56 This will be mostly unattended, so there shouldn't be too many people around pushing buttons on the BBB. Aug 02 22:06:46 Thanks for the help. Aug 02 22:06:58 you're welcome Aug 02 22:46:57 I have been using BeagleBone Black Wireless and due to the lead times of 4+ months (currently Nov-Dec 2022), I am being forced to use BeagleBone Black (non-wireless). Our programming is hard coded to use GPIO_120 and GPIO_122 (Pins 30 and 31) on the P9 header. Is there an equivalent pair of pins that I can use on standard BeagleBone without Aug 02 22:46:57 changing the code? Aug 02 22:51:57 uhh what, the black and black-wireless are completely equivalent in terms of their expansion headers Aug 02 22:54:10 those are not the gpio numbers of those pins though Aug 02 22:55:52 the only difference between the black and the black-wireless is that one has ethernet while the other has wifi and bluetooth Aug 02 22:56:19 and the wireless uses a micro-usb connector instead of mini-usb Aug 02 22:56:26 if I remember correctly Aug 02 22:56:54 ok, when I checked the pin out diagrams, I found a different one from what was given to me by our dev team, so that's what is confusing to me Aug 02 22:56:56 the P9 and P8 expansion headers are completely identical Aug 02 22:57:06 like, 100% identical for all of the pins on those headers Aug 02 22:57:10 I will check if I can get a link Aug 02 22:58:32 for a detailed overview of the expansion headers on the black/black-wireless, see the P9/P8 tabs of my spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Aug 02 22:59:28 https://elinux.org/Beagleboard:Cape_Expansion_Headers Aug 02 22:59:40 That's where some of the info was given to me Aug 02 22:59:57 yes those are other overviews Aug 02 23:00:03 Dev team told me this is what they were using: https://elinux.org/File:4.5_serial_UARTs.PNG Aug 02 23:00:43 might be a typo, let me double-check Aug 02 23:01:47 I am using a sparkfun Lumini 8x8 matrix, so Vdd and Ground are straightforward, I have been told to use GPIO_120 and GPIO_122 for DI and CI Aug 02 23:02:18 These are pins 31 and 30 on BBBW, so I was expecting those to work the same for BBB Aug 02 23:02:28 those numbers are wrong (for both the BBB and BBBW) Aug 02 23:02:53 Dang! :-) Aug 02 23:03:32 P9.30 is gpio 3.16, i.e. 3*32+16 = 112 Aug 02 23:03:47 P9.31 os gpio 3.14, i.e. 3*32+14 = 110 Aug 02 23:04:29 ok that makes sense! Pin 30 on the BBB is listed as GPIO_112 Aug 02 23:05:04 Pin 31 is listed as SP11_SCLK Aug 02 23:06:23 the diagrams on https://elinux.org/Beagleboard:Cape_Expansion_Headers just seem to be erroneous, at least for those two pins... I'm too lazy to check all of them Aug 02 23:07:45 you can find the correct gpio numbers in my spreadsheet I linked earlier (which uses the X.YY numbering scheme where X is the gpio controller number and YY the gpio number of that controller) Aug 02 23:08:11 for the contiguous gpio numbers used by the kernel use X*32+YY Aug 02 23:08:38 or here's a list of named symlinks created for the gpios using a simple udev rule: https://pastebin.com/R5pP0jSQ Aug 02 23:09:02 Ok, I think it's working fine! thank you for responding to me. I was worried that I will fry a precious board or something trying the original configuration based on the info that BBB and BBBW are separate! You literally saved me weeks worth of running around, my man! Thank you so much!!! Aug 02 23:09:03 (with such a udev rule in place you can entirely avoid having to know or care about gpio numbers) Aug 02 23:09:31 yeah no worried, BBB and BBBW are completely interchangeable w.r.t. their expansion headers Aug 02 23:09:58 (but beware that this is _not_ the case for the BeagleBone Green Wireless!) Aug 02 23:10:45 Does the BeagleBone Industrial also interchangeable with the BBB and BBBW? Aug 02 23:11:03 yes Aug 02 23:12:27 ok that's awesome, we deploy in Northern Alberta and in the Middle East, so hopefully will start using those when they come back in stock Aug 02 23:13:21 the Industrial just uses parts that are rated to tolerate sub-freezing temperatures Aug 02 23:13:26 but is otherwise the same Aug 02 23:13:51 Thanks! have a great day! Aug 02 23:18:08 Sorry, I forgot to ask regarding BeagleBone AI, does that have the same interfaces as BBB and BBBW? I would love to use it instead of BBB/BBBW since it has 16 GB of storage. By the time I install updates on the BBB and BBBW, the 4 GB is nearly used up Aug 02 23:18:51 the AI is a completely different device with a different SoC (and the AI-64 is yet again a different SoC) Aug 02 23:19:05 if you run out of 4GB... try having less crap installed ;) Aug 02 23:20:50 ha ha ha! Touche! I don't have ANY crap install, but I am usually required to update the OS image to 9.13 which is not possible with the onboard storage. So I put in a 32 GB Sandisk extreme card but I have had failures of those too at times. Aug 02 23:21:16 *update* to 9.13 ? debian 9 is ancient and obsolete Aug 02 23:22:44 Yeah, I know, but we have some restrictions which I am battling Aug 02 23:22:59 AM3358 Debian 10.3 2020-04-06 4GB SD IoT is that the latest stable image? Aug 02 23:23:03 even the current official debian 10 images are getting rather old, the latest testing images are debian 11 (https://forum.beagleboard.org/tag/latest-images) Aug 02 23:23:48 I would love to install one image which will leave about 500 MB of space out of the 4 GB so that I don't have to use an SD card Aug 02 23:23:53 yeah, but there are also minimal images available if you don't want all the crap that's preinstalled on the IoT images and are comfortable with just installing the packages you want/need yourself Aug 02 23:24:15 the image you just listed leaves way more free space than that I'm pretty sure Aug 02 23:24:39 while minimal images leave more than 3G of free space Aug 02 23:25:09 Are the minimal images also listed on https://beagleboard.org/latest-images Aug 02 23:25:25 no, they're currently only available as testing images Aug 02 23:25:56 ok Aug 02 23:26:00 if you're comfortable enough with debian to be considering a minimal image then I'd recommend using debian 11 (bullseye) anyway Aug 02 23:30:09 It's mentioned that Bullseye is for BeagleBone AI Aug 02 23:30:20 it's for all devices Aug 02 23:31:57 Is this the page from which it needs to be downloaded? https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots-arm64/32318 Aug 02 23:32:13 https://rcn-ee.com/rootfs/bb.org/testing/2022-08-01/bullseye-minimal-arm64/bbai64-emmc-flasher-debian-11.4-minimal-arm64-2022-08-01-4gb.img.xz Aug 02 23:32:32 that's ARM64, i.e. for the AI-64 Aug 02 23:33:03 bbai64-images are for the BeagleBone AI-64 Aug 02 23:33:24 am57xx-images are for the BeagleBone AI and the BeagleBoard X15 Aug 02 23:33:49 am335x-images are for all BeagleBone devices except the AI and AI-64 Aug 02 23:34:57 ok thanks Aug 02 23:35:38 the am335x/am57xx images are in the other (non-ARM64) Bullseye snapshots topic, https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280 Aug 02 23:37:59 ok thanks! So I am installing in a production environment in very remote locations only manned by construction workers usually and no IT support other than me supporting remotely. We don't make any changes for a couple of years once deployed. Will it be ok to install the testing images or is it just a risk that we have to weigh? Aug 02 23:38:52 I mean, you should properly test your final system (including your own software) anyway Aug 02 23:39:25 if you want a more thoroughly tested kernel you could downgrade to the 4.19-ti kernel series Aug 02 23:39:40 debian bullseye itself is a stable release of debian Aug 02 23:40:07 ok thanks! Your inputs have been very valuable! Aug 03 02:10:01 On BeagleBone Black, there is no spidev2.0 directory under /dev with a flash image 10.3 factory installed. If I flash a microSD with 9.9 (later upgraded to 9.13), then it has the spidev2.0 under /dev. Our application (not written by me!) needs access to /dev/spidev2.0 directory, so any help is appreciated! Aug 03 02:13:50 you mean device, not directory... and yeah ancient images had an off-by-one error which caused the spidev devices for the spi0 bus to be named /dev/spidev1.* and the devices for the spi1 bus to be named /dev/spidev2.* Aug 03 02:13:54 that off-by-one error has been fixed Aug 03 02:14:41 dunno in which kernel version that change was introduced, it was a long time ago Aug 03 02:15:20 is it possible to change the application to use the new name, /dev/spidev1.0 ? Aug 03 02:15:30 Ok, so the best option if the code cannot be changed is Ioad the older image 9.9 I guess Aug 03 02:15:44 yeah application change is not possible as we have many of these devices in remote locations Aug 03 02:16:11 Eventually I will force them to change it for new devices moving forward Aug 03 02:16:22 how is that relevant? if you can't update your application on those devices then you also can't update anything else on those devices Aug 03 02:16:42 so what does that have to do with whatever you're doing currently? Aug 03 02:17:19 if you're trying to build a more uptodate system, then why would updating the application not be a feasible part for that? Aug 03 02:18:14 Yeah I should have been more clearer. There is zero bandwidth currently for dev team to make a change and rebuild the application for any new devices. So for devices that may need to immediately go out, I will have no choice but to load the older kernel Aug 03 02:18:22 anyway, you certainly don't need to stick to an ancient system for that particular reason, you could just create a symlink from /dev/spidev2.0 to /dev/spidev1.0 or use a device-tree overlay to change the spi bus numbering Aug 03 02:18:51 Is there an article which will help me explain creation of a symlink? Aug 03 02:19:52 Just googled it. Is this like ln -s? I use this for NTP usually to update timezones, so I may be able to work through it Aug 03 02:19:57 create a /dev/udev/rules.d/spidev-compat-hack.rules (the exact filename isn't important) containing the following line: Aug 03 02:20:05 /etc/udev/rules.d/ I mean Aug 03 02:20:39 KERNEL=="spidev1.0", SYMLINK="spidev2.0" Aug 03 02:21:19 you could also make the symlink using ln -s but then you'd need to find the right time to do so during boot, since the contents of /dev/ is not persistent Aug 03 02:21:38 the udev rule would make udev create the symlink for you as soon as the device shows up Aug 03 02:23:03 ok thanks! Aug 03 02:29:20 That worked like a charm! thank you so much! Aug 03 02:35:03 If there is a favorite charity or something of yours, just let me know :-) Aug 03 02:36:00 beagleboard.org! Aug 03 02:45:04 Yeah, I honestly would not have a job if not for the Beagles, deployed probably a 100 devices over the past four years Aug 03 02:48:59 Nice. Aug 03 02:49:44 beagleboard.org is a charity still. At least, I think I am up-to-date on that statement. Aug 03 02:51:42 I am not in their dealings like knowing if they earn or whatever... Aug 03 02:52:05 I just pitch in when I can, i.e. selfishlessly and selflessly. Aug 03 02:54:09 I know this is a bit off subject of udev and building tools but... Aug 03 02:54:56 amazon has a way to support 401(c) or whatever businesses/charities called smile! smile, you just gave back! Aug 03 02:59:42 Yeah true **** ENDING LOGGING AT Wed Aug 03 02:59:57 2022