**** BEGIN LOGGING AT Mon Mar 22 02:59:56 2021 Mar 22 03:02:35 (and like the pdf you linked to points out, esd protection can also have an adverse effect on signal integrity) Mar 22 03:03:35 you obviously have way more experience than me with this subject, even if you are not totally sure, to build a usb hub for pocketbeagle, how would you break down the steps? Mar 22 03:03:44 usb hub cape* Mar 22 03:04:14 I dunno, I don't want to go that far... I'm not an electronics designer, I just know bits and pieces Mar 22 03:05:38 okay sure, but the amount of information you already gave me is worth tons Mar 22 03:05:52 anymore bits and pieces you have I would listen with full attention Mar 22 03:06:21 anything ,really Mar 22 03:06:30 Hey! Mar 22 03:06:40 Excuse me...hello! Mar 22 03:06:43 hello Mar 22 03:06:46 Hey. Mar 22 03:06:54 Did you get the micro? Mar 22 03:07:06 For your board, the BBB? Mar 22 03:07:10 The hdmi? Mar 22 03:07:27 Oh. You are working w/ the PB. Got it. Mar 22 03:08:22 Are you adding a HDMI micro to your PB? Mar 22 03:08:28 Nice! Mar 22 03:08:34 Good luck. Mar 22 03:09:53 Sorry for interrupting as usual, i.e. being sorry and interrupting. Mar 22 03:10:47 I am building usb hub for pocket beagle Mar 22 03:10:56 so I am here asking advice on how to do that Mar 22 03:11:05 Oh. Mar 22 03:11:30 last thing I was doing was confirming how much voltage and current the PB can give via USB without frying Mar 22 03:11:40 Okay. Sorry. Good luck. I am working on C++ stuff for learning adventures. Oh. Mar 22 03:11:48 Okay. Mar 22 03:12:56 I think testing w/ each pin and having said what @zmatt was saying, 'straight to the am335x', one would need to make sure each pin is tested which is near impossible w/out the proper equipment. Mar 22 03:12:58 But... Mar 22 03:13:34 normally I would have acess to the equipment, but with the covid, the acess is very limited nowadays Mar 22 03:13:42 No! Mar 22 03:13:52 Dang. Equipment is nice. Mar 22 03:13:55 I hope it works out. Mar 22 03:14:00 GRS26: voltage is 5V (or rather, slightly below whatever the input voltage is), it doesn't make sense to ask how much it "can give" Mar 22 03:14:28 Okay, now I know Mar 22 03:14:47 GRS26: or 3.3V on the 3.3V output, obviously :P Mar 22 03:14:55 (approximately) Mar 22 03:15:03 For instance, if you have a need to use 12 pins, test each one w/ your finalized set up to figure that hardware issue. Mar 22 03:15:13 set_: wtf are you talking about Mar 22 03:16:00 set_: the only situation in which you would ever "test" a pin is if you suspect you damaged it or something Mar 22 03:16:08 I am saying that one would need to make sure the am335x does not get overloaded if you are 'sourcing' from the PB. Mar 22 03:16:10 Oh. Mar 22 03:16:24 I thought you guys were going w/ making the PB handle things. Mar 22 03:16:27 that part would definitely never involve testing Mar 22 03:16:30 you look it up Mar 22 03:16:35 Okay. Mar 22 03:16:43 any test would give no information until you've already destroyed things Mar 22 03:17:10 No...before. Before destruction is when testing needs to take place. Mar 22 03:18:01 Right. So, one would need to make sure the supplied loop is not too much to take. Mar 22 03:18:11 set_: please just stop talking Mar 22 03:18:15 I am discussing...fine. Mar 22 03:18:39 Why do people hate theory? Mar 22 03:19:05 set_... Mar 22 03:19:23 @zmatt: Just b/c you know things does not mean everyone wants to admit or understand they know (at first). Mar 22 03:19:48 I always wanted to tell you that idea. Mar 22 03:20:12 set_: I have no idea what you're even trying to say Mar 22 03:20:22 I will refrain. You guys are busy. Mar 22 03:29:40 going back to the topic Mar 22 03:31:00 if I were to use the cypress chip, I would need to add protections right Mar 22 03:31:10 like a power switch,filters and esd Mar 22 03:31:35 power filtering on the downstream ports is a good idea (that isn't really a "protection" though) Mar 22 03:32:47 and if you have a power switch (with overcurrent protection) on the upstream side (between pocketbeagle and hub) then you don't strictly require them on the downstream ports Mar 22 03:33:14 in that case you've got a bus-powered hub rather than a self-powered hub Mar 22 03:34:31 a self-powered hub requires power switches on the downstream ports, like you see in the example schematic of the hub (https://www.cypress.com/file/117521/download) Mar 22 03:36:12 since I am thinking about powering it with pocketbeagle, it will be bus powered, so I will a power switch with overcurrent protection on the upstream, and won't require power switchs on the downstream ports Mar 22 03:36:15 If got that Mar 22 03:37:23 yep, that power switch with overcurrent protection is technically port of the usb port of the pocketbeagle, into which you're pluging your hub Mar 22 03:38:03 so the pocketbeagle already has one Mar 22 03:38:06 no Mar 22 03:38:46 what did you mean by this "is technically port of the usb port of the pocketbeagle" Mar 22 03:39:20 I meant, you'd basically be adding a usb port to the pocketbeagle, which itself requires adding a usb power switch with overcurrent protection, and then you're plugging your bus-powered usb hub into that Mar 22 03:40:53 don't worry about it, it was just a conceptual observation, it doesn't matter Mar 22 03:41:49 (the part about it being part of the pocketbeagle's downstream port rather than it being part of the hub's upstream port, that is) Mar 22 03:44:23 ok Mar 22 03:45:30 so power filter the downstream ports, power switch the upstream port Mar 22 03:45:41 and where the esd protection goes? Mar 22 03:46:06 probably just don't worry about it, but on the hub's downstream ports if anywhere Mar 22 03:47:11 esd protection goes on parts that end-users might touch with their hands, or into which they plug cables or devices they've touched with their hands (and in doing so might have electrostatically charged) Mar 22 03:47:40 okay Mar 22 03:47:55 you don't really have end-users, and you're probably already touching everything, so that's why I said probably don't worry about it Mar 22 03:48:04 chips do already have *some* degree of internal esd protection Mar 22 03:48:40 before when I worrying about how much current the pocketbeagle can give, I was just over worrying? Mar 22 03:50:44 my dad told me about early MOSFETs, they were so ESD-sensitive that they were shipped with the pins shorted together with some wrap (wire or aluminium foil, can't remember), and if you removed that wrap the MOSFET was basically instantly destroyed. they soldered them into place with the wrap still on it and *then* removed the wrap Mar 22 03:53:07 if you're drawing power from the 5V output (P1.24/P2.13) then you probably don't need to worry about it too much since it does already have internal protection, but nevertheless like we just established it's still a good idea to have a power switch with overcurrent protection between the pocketbeagle and the hub Mar 22 03:53:22 okay Mar 22 03:53:45 can you get away with omitting it? sure, you probably can Mar 22 03:54:13 would it be usb spec compliant? definitely not. does that matter? I dunno, that's up to you Mar 22 03:54:37 I would prefer this hub be as usb spec compliant as possible Mar 22 03:54:53 thats why I am asking all those questions about current, security measures and stuff Mar 22 04:04:50 with these measures, will the project be usb spec compliant zmatt? Mar 22 04:05:30 uhh, I don't have an answer to that. there's a lot of details to usb spec compliance Mar 22 04:06:09 if you want to know what the usb spec has to say about things, you can download it yourself :P Mar 22 04:06:40 https://www.usb.org/documents Mar 22 04:24:40 before when I worrying about how much current the pocketbeagle can give, I was just over worrying? Mar 22 04:25:19 you already asked that, I already answered it Mar 22 08:32:18 Hello there! Mar 22 16:52:43 h Mar 22 16:54:12 zmatt, sorry for the unanswered ping yesterday, i was just so happy about some facts i reached , where in the overall topic you once gavwe me some real insights .. so was in a gratefull memory of you Mar 22 16:54:53 eh ok, glad to have been of help I guess? :) Mar 22 16:55:19 definitly ! as you are always Mar 22 17:54:57 hi everyone. Is it bad practice to hack out all the unnecessary start up services that come by default with the recommended debian images? cloud9 and such are quite unnecessary for my purposes. I'm wondering whether it's better to play around with the startup behavior or just find a different image. Mar 22 17:56:49 masdf: there are also minimalist "console" images Mar 22 17:57:22 if you're comfortable with just installing what you need, using a console image is probably a good idea Mar 22 17:57:40 since it's generally easier to install what you need than to figure out what is unnecessary and remove it Mar 22 17:58:17 unfortunately there are for some reason no official console images at https://beagleboard.org/latest-images but you can find the latest testing image here: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Mar 22 18:00:26 zmatt that's very helpful thank you. I thought that's what I was getting with the IoT image but it seems like what I actually wanted was the console image Mar 22 18:00:49 the elinux link is exactly what I needed Mar 22 18:01:19 also, not sure what you mean by "hack out" .. you can simply disable services using "sudo systemctl disable SERVICENAME" or remove it entirely using "sudo apt purge PACKAGENAME" .. though be careful to check the latter doesn't cause an undesirable chain reaction of packages being removed ;) Mar 22 18:01:55 yeah no, the IoT images are pretty bloated Mar 22 18:02:42 thanks for bringing that up. What you described is what I tried to do initially but a few of the posts I found suggested that using systemctl to disable services didn't always work and they could be reenabled over time Mar 22 18:02:51 maybe disable + purge will do the trick Mar 22 18:03:18 disable doesn't prevent a service being pulled in as dependency by another service Mar 22 18:03:28 it just prevents it from being automatically started on its own Mar 22 18:09:01 if your goal is optimizing boot time, disabling generic-board-startup.service (using systemctl) will also help, at cost of disabling the usb gadget. getting rid of initramfs (sudo rm /boot/initrd.*) also speeds up boot. to prevent initramfs images from being regenerated when you update the kernel, download this dummy package: https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb and install it with ... Mar 22 18:09:07 ...sudo dpkg -i FILENAME Mar 22 18:09:43 Ah I see. I'm beginning to appreciate the differences between systemd and the init.d scripts I'm more used to Mar 22 18:09:50 this is all very helpful, thank you Mar 22 18:10:19 masdf: in fact, systemctl enable/disable just creates/removes symlinks to the unit in appropriate places Mar 22 18:10:49 I'm not terribly concerned with boot time (tho it is a bit slow), I'm more focused on using it as a network access point through which I can access some embedded devices over USB Mar 22 18:11:27 e.g. if the unit file has WantedBy=multi-user.target in its [Install] section then enabling the unit creates a symlink to that unit in /etc/systemd/system/multi-user.target.wants/ Mar 22 18:11:55 which tells systemd to try to start the unit as part of bringing up multi-user.target Mar 22 18:12:17 (which is the default default target) Mar 22 18:14:24 actually no, graphical.target is the default default target (ls -ld /lib/systemd/system/default.target) .. but that's essentially the same as multi-user.target on a system with no GUI stuff installed Mar 22 18:16:11 I don't quite understand this just yet as I'm still reading through the systemd services debian wiki but I suspect I'll be to parse this into useful tips shortly Mar 22 18:16:16 so thanks in advance lol Mar 22 18:17:22 masdf: I also have this example on how to write a systemd service, in case it's of any use or being enlightenment: https://pastebin.com/KXVdTNrL Mar 22 18:23:47 I always appreciate well documented reference code Mar 22 18:27:34 so far my only complaint with this paradigm is using semicolons for comments lol Mar 22 18:27:59 oh it accepts both # and ; and # is more common, but pastebin's syntax highlighting for INI files only knows about ; Mar 22 18:28:03 that's the only reason I used ; Mar 22 18:33:20 oh okay lovely haha that puts my mind at ease Mar 22 18:34:18 maybe I should clarify that in a comment Mar 22 18:37:27 doesn't hurt I suppose but not a big deal, it's very helpful and clear as is Mar 22 19:38:59 Once upon a time in Denver, did the kernel devs. develop Linux w/ /proc/device showing what pwm channel we are supposed to use? Mar 22 19:39:39 I am looking up the device name for pwm on the BBBlue for now. Mar 22 19:40:25 is that still located in /proc/device or is it now a block or character device? Or is it just plain, ole sysfs still? Mar 22 19:49:52 I have no idea what you're talking about Mar 22 19:50:13 the best way to locate a pwm has never been anywhere in /proc Mar 22 19:50:31 however there are convenient symlinks in /dev/pwm/ Mar 22 19:54:11 zmatt: jkridner: how hard would it be to add a link on beagleboard.org/latest- to 'minimal' images for building Up from? Mar 22 19:54:27 something not too prominent, but still visible Mar 22 19:54:52 kveremitz: I can do that. I might forget, so check back in a couple of days. Mar 22 19:55:00 akin to a sorta 'big' vs 'little' image :D Mar 22 19:55:04 got some other stuff to do right now. Mar 22 19:55:12 i.e. the console images, although "minimal" would be a better name for them Mar 22 19:55:20 yeah no hurry, just thought it was quite a common request Mar 22 19:55:48 zmatt: I'm sure some hyperlink 'magic' could easily fix that ;) Mar 22 19:56:08 jkridner__: ty :@) Mar 22 19:56:15 wow that went.. odd Mar 22 19:56:30 omg what happened to your nose? ;-) Mar 22 19:56:34 I seem to have acquired a pig snout Mar 22 19:56:47 unfortunate Mar 22 19:56:48 LUL Mar 22 19:57:19 ah, you watch twitch too? ;) Mar 22 20:00:03 its my new .. erm .. crutch :/ Mar 22 20:01:11 it does seem to be A Good Place though. Meeting some good peeps Mar 22 20:04:00 I can also appreciate some of the insane displays of skill there Mar 22 20:04:27 agreed Mar 22 20:05:16 I seem to have reached the point when I'm running into people I already know when I'm raiding new channels... :D Mar 22 20:05:38 raiding into+ Mar 22 20:06:13 @masdf, https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases search for console image Mar 22 20:06:17 its the smallest debian based image for bb i found Mar 22 20:06:38 architux: that wiki page hasn't been updated in a long time, use https://elinux.org/Beagleboard:Latest-images-testing instead Mar 22 20:07:54 kveremitz: I once saw a 1000-viewer streamer raiding a 10-viewer stream.. the poor girl was so flustered hehe Mar 22 20:08:18 @zmatt, you are right Mar 22 20:08:27 zmatt: those are great :D Mar 22 20:08:47 its great that larger streamers seek out smaller ones to promote Mar 22 20:09:14 its a surprisingly successful platform I think Mar 22 20:14:07 hey everyone! I'm trying network booting (uboot, nfs, tftp...) my beaglebone using rj45 conector, but i can't.. Could anyone send me any reference in which they explain what uboot commands to use? thank youuu!!!=D Mar 22 20:14:32 john11: oof, netbooting is a complicated topic Mar 22 20:15:52 last time I dug into it I got pretty far, but I don't really have anything like a summary for it Mar 22 20:17:27 I guess it also depends on whether you want to netboot "from scratch" (with no reliance on anything on the beaglebone other than the bootrom) or if it's fine to have a specially crafted u-boot present on eMMC (thus skipping the first two netboot stages) Mar 22 20:19:46 will the bootrom do pxe?(or equivalent) Mar 22 20:20:15 bootp+tftp Mar 22 20:20:18 I'd probably take the uboot route myself Mar 22 20:20:35 since the emmc is there for the taking .. is there an SPI on the bbb? Mar 22 20:21:12 my main use for it would be for flashing beaglebones, hence I had to use the "from scratch" method Mar 22 20:21:24 there is not, but you could add one externally Mar 22 20:21:28 ah yes .. doing that with usb is painful ;P Mar 22 20:21:32 an spi boot flash you mean I assume Mar 22 20:21:35 but possible also :D Mar 22 20:21:38 yes Mar 22 20:21:55 usb is the same as netbooting (bootrom acts like an RNDIS network interface) Mar 22 20:22:06 ahh Mar 22 20:23:29 to see different examples of how stuff is loaded by bootrom, see this tiny demo app I once made: https://github.com/mvduin/bbb-asm-demo Mar 22 20:23:41 it includes a dnsmasq.conf file for netbooting the example Mar 22 20:23:58 ooooh Mar 22 20:24:22 hmm, I should mention in the readme how to get the beaglebone into netboot mode Mar 22 20:26:07 👍 Mar 22 20:27:39 i've already flashed uboot in flash eMMC following the next tutorial https://bootlin.com/blog/tftp-nfs-booting-beagle-bone-black-wireless-pocket-beagle/ , but here they use directy the usb cable, I would like to know what changes I need to make in the bootarg to network boot using ethernet rj-45 cable for it Mar 22 20:31:43 thank you @zmatt for your demo app!!!!;D Mar 22 20:31:55 john11: probably just replace "usb0" by "eth0" and remove the unnecessary g_ether stuff? Mar 22 20:32:53 the demo app is probably not that interesting, I mostly just showed it for reference as to how the very first bootloading stage works Mar 22 20:33:46 when using u-boot, since it is too bloated to fit its fat ass into internal SRAM, that first bootloading stage would typically load u-boot "SPL", basically a stripped-down version of u-boot that just sets up the ddr3 memory controller and loads the full u-boot.img Mar 22 20:34:00 that stuff is pretty important .. Mar 22 20:34:29 I'm fighting ARM TF-A on a rpi3a because .. $raisins .. :/ Mar 22 20:34:40 TF-A ? Mar 22 20:34:46 very VERY hysterical raisins.. Mar 22 20:34:53 aarch64 trusted firmware Mar 22 20:34:56 ah Mar 22 20:35:21 it works on various boards, but I Can't get the config right for BL31->uboot :/ Mar 22 20:35:49 ah I see it's a reference implementation for a secure monitor Mar 22 20:35:52 TF-A is happy, standalone uboot is fine .. but the bootrom/tf-a won't jump over Mar 22 20:35:55 yup Mar 22 20:36:44 hey, at least you get to run stuff in secure world, unlike on TI SoCs where it's locked down into a useless state :/ Mar 22 20:36:44 something about load addresses/etc Mar 22 20:37:25 yea, its not -actually- secure .. although they've got the DT tweaked now .. but it remains all SRAM so.. Mar 22 20:38:01 I mean, the word "secure" is meaningless without specifying what is supposed to be secured against whom Mar 22 20:38:04 its all relative Mar 22 20:38:08 right Mar 22 20:41:05 I am typing up a PWM lib. @zmatt. That is all. I found some starter source and i have the kernel at my helm. I want to try to propose something but I am in an early phase right now. Mar 22 20:42:01 So, the evm states that 'cat /proc/device' shows the pwm channel needed to start the .c script. Mar 22 20:42:21 Is that outdated or am I off base again? Mar 22 20:42:49 Anyway, I know I can call it from sysfs but this is a one time call to the chip. Mar 22 20:42:56 so, pwmchip0 for instance... Mar 22 20:43:31 set_: there's no "/proc/device", nor has it ever existed. "/proc/devices" does exist, but there's no information there that's even remotely useful to a "pwm library" Mar 22 20:43:49 like I said earlier, the easy way to locate pwm devices on the beaglebone is via the symlinks in /dev/pwm/ Mar 22 20:44:32 You are right. Excuse me. I typo'd that error too many times. And you are right. It does not show /dev/pwm/pwmchip0 (or whatever chip is available) on the beaglebone. Mar 22 20:45:01 So, I should not use that location in the tree to account for anything... Mar 22 20:45:02 Right? Mar 22 20:45:14 I have no idea what you're asking Mar 22 20:45:20 In this instance, /dev/pwm/pwmchip0. Mar 22 20:45:25 that doesn't exist Mar 22 20:45:33 Let me check again. Mar 22 20:45:46 Sheesh. I am messing up left and right w/ this explanation of things. Mar 22 20:45:53 /dev/pwm/ contains a list of the individual pwm outputs on the beaglebone Mar 22 20:46:01 (on the am335x rather) Mar 22 20:46:05 Oh. Okay. Mar 22 20:46:23 Let me recheck. Mar 22 20:46:52 not sure when they were added, some time last year Mar 22 20:46:54 I think Mar 22 20:47:01 Oh. Mar 22 20:47:08 I am plugged in again. Mar 22 20:47:53 if you have the latest release-image (from april last year) it _may_ be required to update the bb-customizations package but I'm not 100% sure. if /dev/pwm/ doesn't exist then that's the culprit Mar 22 20:48:17 oh. Mar 22 20:48:18 Okay. Mar 22 20:48:40 Yea. /dev/pwm/ does not exist. Mar 22 20:48:53 I will update the customizations. Mar 22 20:49:41 sudo apt update && sudo apt install bb-customizations Mar 22 20:50:48 Got it. Okay. Mar 22 20:51:52 I told someone I would make this lib. but I am not sure if they actually want it from a person like me. So, I will make my proposal and see. Mar 22 20:53:03 That did not work. Mar 22 20:53:11 That is most likely the reasoning for my issues. Mar 22 20:53:29 I do not have /dev/pwm/ as a dir. or file. Mar 22 20:53:42 did you update bb-customizations and reboot? Mar 22 20:53:46 Oh! Mar 22 20:53:47 Reboot! Mar 22 20:54:07 It said I had the newest version and did nothing. Mar 22 20:54:29 Do I hardlink it? Mar 22 20:54:47 huh Mar 22 20:55:03 nothing. Mar 22 20:55:27 that makes no sense, if you have the newest bb-customizations you should have a /dev/pwm/ Mar 22 20:55:37 I do not! Mar 22 20:56:02 uname -r: 4.19.180-bone-rt-r61 Mar 22 20:56:26 oh that probably explains things. why are you running such a weird kernel Mar 22 20:57:07 Is that odd? I wanted to try Rover from ardupilot b/c of not having access to the dc motors on the BBBlue. Mar 22 20:57:30 even if you want an -rt kernel it should be -ti-rt, not -bone-rt Mar 22 20:57:35 Oh. Mar 22 20:57:38 Okay. No issue. Mar 22 20:57:45 I will transfer kernels. Mar 22 20:57:51 Maybe that is it. Mar 22 20:58:14 -rt btw has no influence on "having access to the dc motors", -rt only has relevance for certain performance characteristics Mar 22 20:58:54 Right. Mar 22 20:58:56 Okay. Mar 22 20:59:14 (decreased latency, at the expense of decreased overall performance and usually decreased system stability) Mar 22 21:00:32 Man. As usual you have more info. on subjects than I can assertain. Mar 22 21:00:44 And as usual, thank you. Mar 22 21:01:44 Why is the bone-channel available for use? I mean...is it for a particular few? Mar 22 21:02:20 basically yes Mar 22 21:02:45 Okay. No need to explain. Mar 22 21:09:44 Nope. Mar 22 21:09:49 It is not there on my system. Mar 22 21:10:47 I have pwmchip0 and others in /sys/class/pwm//. Mar 22 21:12:59 can you pastebin the output of the following two commands: Mar 22 21:13:01 sudo /opt/scripts/tools/version.sh Mar 22 21:13:05 yes sir. Mar 22 21:13:06 apt-cache policy bb-customizations Mar 22 21:15:13 https://pastebin.com/W29WLRkg is version.sh Mar 22 21:16:34 https://pastebin.com/PUnxksGz Mar 22 21:16:38 that one is bb-cust. Mar 22 21:19:42 oh wtf rcn broke the udev rule Mar 22 21:20:05 Oh. Mar 22 21:20:18 Maybe he got busy and forgot. Mar 22 21:20:58 I am guilty of that every now and then (secretly happening all the time)! Mar 22 21:21:50 "forgetting" does not explain why something has been broken that worked Mar 22 21:22:13 in /etc/udev/rules.d/81-pwm-noroot.rules the two lines below "automatically export pwm channels" have been commented out, which makes the entire udeve rule useless Mar 22 21:22:22 ha. Mar 22 21:22:23 Okay. Mar 22 21:23:03 Man. I have not seen an udev rule like this before... Mar 22 21:24:11 I will test it now. Mar 22 21:24:31 after fixing the udev rule you may need to regenerate the initramfs with "sudo update-initramfs -u" Mar 22 21:24:37 and reboot Mar 22 21:24:45 got it, okay. Mar 22 21:24:58 I've filed a bug report Mar 22 21:25:22 Okay. I guess I can tell you what happens after the reboot. Mar 22 21:26:06 All this time, I was thinking, "I am not getting any better ta this sourcing." Mar 22 21:26:17 For a year! Mar 22 21:26:18 ha. Mar 22 21:26:30 I just left pwm channels alone. Mar 22 21:26:51 This started a long time ago w/ the ServoCape stuff. Mar 22 21:26:53 pretty sure this was recently broken, like last month Mar 22 21:27:00 Oh. Mar 22 21:27:02 Hmm. Mar 22 21:27:15 Okay...I am most likely wrong (as usual). Mar 22 21:28:22 Dang it! Mar 22 21:28:24 You are right! Mar 22 21:28:30 Nice! Mar 22 21:28:41 It is all there like you described. Mar 22 21:30:57 Is the 2019 uboot from version.sh an okay uboot to have on my BBBlue in '21? Mar 22 21:32:03 sure Mar 22 21:32:18 it's what shipped with the image so it's fine Mar 22 21:32:37 Okay. Mar 23 00:47:11 BBBlue! Mar 23 00:47:21 DC Motors/fast track! Mar 23 00:48:16 My motors are slow but they work! Mar 23 00:49:18 It actually took me four years to use the DC Motor controllers on the BBBlue. Dang. Mar 23 00:49:33 I was caught up in that ardupilot stuff for years. Mar 23 02:24:05 Well, I can only move in reverse but it is a better start than usual! Mar 23 02:33:51 I can go in reverse twice now w/ two different inputs in python3. Argh! Mar 23 02:54:00 Is the two gpio peripheral pins on the BBBlue for DC motor one for moving cw and ccw? Mar 23 02:54:35 It has to be, right? **** ENDING LOGGING AT Tue Mar 23 02:59:56 2021