**** BEGIN LOGGING AT Thu Dec 03 02:59:57 2020 Dec 03 03:00:13 be sure to read the documentation for sanity sake. Dec 03 03:00:15 Luckily, these people that produced the "smart" software controlled servo got that idea in advance before I got it. Dec 03 03:00:17 Right. Dec 03 03:00:32 I will. This actually has a manual and they are built in the ole, USA. Yea boy! Dec 03 03:00:57 I could not find anyone in town just yet to deal servos to me. So, I had to reach out. Dec 03 03:01:05 Blah. Dec 03 03:01:58 If anything, I will an add-on board to control the servo for now. I will keep trying w/ the Cape idea later. Dec 03 03:02:10 an = use an Dec 03 03:07:30 If you want to sell one of those Capes, let me know. I would like to look at them to make up my mind if they are exactly what I am looking to attain. Dec 03 03:19:26 I would have to actually make one no? I just was looking at making a LCD supply board recently I designed from JLCPCB, but they don't have a part for it so I would have to assemble that part onto the board. Fortunately all the parts on on one side of the board. Dec 03 03:22:29 Oh. Dec 03 03:22:36 I thought you made them already? Dec 03 03:22:42 Not one? Dec 03 03:22:52 Dang, GenTooman. Dec 03 03:23:09 well I am the kind of person to plan everything out then do it. I've also been quite miserable. Dec 03 03:23:32 So between that and what not it didn't get done. Dec 03 03:23:53 I understand too. I am just getting to the point in life where I need to help instead of suck. Dec 03 03:24:22 So, w/out sucking and more helping, I should promote positivity or something. Who knows? Dec 03 03:24:57 But w/ backwards talk like that, who needs anything? Dec 03 03:25:34 Well, if you ever get up and get out again, let me know. I like my boards and Capes. Dec 03 03:25:55 I will try to fasten something sooner or later into a working unit. I think. Dec 03 03:44:48 How many quadrature encoders can the BBB support, off hand? Dec 03 03:52:03 Oh. Dec 03 03:57:32 Okay, dang it. Three minutes. Dec 03 03:57:34 I am out. Dec 03 03:57:39 Thank you, GenTooMan. Dec 03 04:42:10 hmm let me show you want I was up to. I designed a power supply board for this LCD https://www.mouser.com/ProductDetail/Displaytech/DT070BTFT?qs=eDRjYdeUVVkOXKcw30Z4oA%3D%3D . Dec 03 04:42:56 without it you can use the LCD at all (in summary) it's a break out board with 5V power input and 3.3V input for logic. Dec 03 04:43:17 can == can't (dain bramaged but it's only permanent). Dec 03 04:55:33 actual image https://embeddedemulation.blogspot.com/2020/12/break-out-board-for-dt070ctft-from.html Dec 03 04:59:36 Hey. Dec 03 04:59:43 It is past 10:00, what gives? Dec 03 04:59:48 I will look now. Dec 03 05:01:30 anyhow time to mentally crash. Dec 03 05:02:37 Fine. Dec 03 05:02:44 I will try to catch up w/ you another day. Dec 03 05:02:49 Later for now! Dec 03 05:02:51 Oh and neat! Dec 03 05:03:09 TFT! Dec 03 14:02:40 hey zmatt, are you sure that the mmc is still off by one? the bootloop i am seeing is similar to when others use an off by one gpio name, in that it cannot find a valid device tree. Dec 03 14:02:51 btw, i am running 4.19 now Dec 03 14:03:13 ... actually lemme update that to 5.4 first, then see if it works. Dec 03 14:44:02 https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am33xx.dtsi#L604 Dec 03 14:45:10 I'm assuming 4.19-ti kernel series Dec 03 14:45:22 since that's the current recommended and default kernel series Dec 03 14:47:40 hmm, so that status disabled is automatically updated when referred to? Dec 03 14:47:48 no? Dec 03 14:47:57 what do you mean? Dec 03 14:48:11 ahhh, i think i was missing an override to change the disabled to okay Dec 03 14:48:23 crap,,, no i wasn't Dec 03 14:48:39 that wouldn't be able to cause what you're describing anyway Dec 03 14:49:04 "cannot find a valid device tree" sounds like u-boot failed to apply the overlay (for which it has extremely poor error-handling) Dec 03 14:49:25 typically due to an unresolved symbol reference Dec 03 14:49:26 failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND Dec 03 14:49:26 start the errors. Dec 03 14:49:51 yeah the error reporting/handling here sucks hard Dec 03 14:50:13 yea, i'm starting to see that. Dec 03 14:50:22 both the lack of useful information in the message and the fact that the entire DT is gone if applying an overlay fails (instead of just, you know, not applying the overlay) Dec 03 14:51:45 combined with the fact that dtc cannot detect any unresolvable references when compiling an overlay (since it will assume these will resolve when the overlay is applied) Dec 03 14:52:19 what does your overlay look like currently? Dec 03 14:55:04 like shit.. probably, trying out now to exclusive use mmc3 rather than 2, lets see if that works Dec 03 14:55:20 again, that metadata is not used by anything whatsoever Dec 03 14:55:37 bah! Dec 03 14:56:44 anyway, I obviously can't provide feedback without seeing the dts, and it's not much use guessing the problem without it Dec 03 14:57:09 yea, one sec, trying to remember pastebin password... Dec 03 14:57:22 you know, the one i set up yesterday. Dec 03 14:57:31 :( Dec 03 14:59:57 https://pastebin.com/UiKinuHA Dec 03 15:01:01 still using old-style manual fragments? :P Dec 03 15:02:48 If that ain't broke don't fix it, will need to eventually write a much more complex dts, thats when I'll redo from scratch, this is just to test the wifi subsection. Dec 03 15:03:08 .. but I supplied the rewrite Dec 03 15:03:10 :P Dec 03 15:03:50 whelp, i didn't realize it was a rewrite, my bad, will find it now. Dec 03 15:05:58 well "rewrite" in the sense of a few quick regex search&replaces :P Dec 03 15:06:12 also your overlay has an undefined reference to &btbuf_pin Dec 03 15:06:26 I think Dec 03 15:06:59 yeah Dec 03 15:07:40 you reference &btbuf_pin in your &uart1 overlay but its declaration is commented out Dec 03 15:08:19 also i noticed that in the overlay i called it powerbeagle rather than the partnumber. Dec 03 15:08:33 that looks iffy anyway... why is it called "btbuf_pin" but the comment says something about eeprom disable? Dec 03 15:08:51 how is it different from wlbtbuf_pin ? why is it in the pinmux for uart1 ? Dec 03 15:08:57 woot, thank you, i don't have any eeprom on this cape. Dec 03 15:09:30 I don't understand what an eeprom disable pin is or what it would have to do with uart1 Dec 03 15:09:43 and yeah your metadata is wrong, but that's ignored anyway Dec 03 15:09:44 not sure why it's mentioned in uart, uart should be just 4 lines to the bt subsection of the chip Dec 03 15:10:11 oh right you copied an existing overlay and just assumed it actually makes sense Dec 03 15:10:52 why is wl18xx_bt_en declared as a led ? Dec 03 15:10:59 it does not sound like a led to me Dec 03 15:11:09 haha , indeed, to be fair, it did work for me on the beagle black with the respective hardware Dec 03 15:11:30 it had an led connected to the same line used to enable it. Dec 03 15:11:44 right, but the functionality is enabling the wifi chip Dec 03 15:11:50 and the led is merely an indicator of that Dec 03 15:12:00 "had", doesn't anymore, but i'm just copying Dec 03 15:12:08 yup Dec 03 15:12:17 either way, the led is irrelevant to the kernel, it's not a generic kernel-controlled led Dec 03 15:13:33 btw how I found this: I decompiled the dtbo (dtc -I dtb -O dts path/to/overlay.dtbo) and looked at the __fixups__ which are unresolved external references Dec 03 15:14:34 alright, with some updates: https://pastebin.com/UiKinuHA.. interesting, so the compiler adds in debug info the the dtbo? Dec 03 15:14:42 it's not "debug info" Dec 03 15:15:46 it's information required to resolve references between overlay and base dtb (or between overlay and overlay) Dec 03 15:16:29 as well as update internal reference within the overlay Dec 03 15:17:20 i gotta figure out how to work on the uboot shell. this pull card from device, load in vm, comment out dtb, and restart workflow is terrible Dec 03 15:17:32 cool! Dec 03 15:19:18 __symbols__ are the labels defined in your overlay (also present in the base dtb), __fixups__ are references to undefined labels (assumed to resolve to symbols from the base dtb or from a previously applied overlay), __local_fixups__ are internal references within your overlay (that need to be updated once phandles are assigned) Dec 03 15:19:37 just tried it, so much more debug info! ;) Dec 03 15:23:08 haha, just tried it, and the dtc failed... still got some good debug info Dec 03 15:23:17 dtc: livetree.c:565: get_node_by_phandle: Assertion `generate_fixups' failed. Dec 03 15:23:43 oh wow your overlay manages to get dtc to crash? Dec 03 15:23:48 haven't seen that yet Dec 03 15:24:51 decompiling it does Dec 03 15:25:26 o.O Dec 03 15:25:51 wut Dec 03 15:26:14 that makes even less sense Dec 03 15:29:10 like, I don't think it even make sense for it to be calling get_node_by_phandle() when decompiling a dtb Dec 03 15:29:34 bah, removing that reference to btbuf got me past the dt crash, shucks, no incentive to leart uboot shell anymore. Dec 03 15:30:08 /* shrug */ Dec 03 15:33:06 i made it to texas, and im back to work Dec 03 15:38:57 Quick question, how do you change the SPI clock speed on the BBB when using the universal cape? I'm sending data with the Adafruit_BBIO.SPI library in Python and it seems like the clock is running at 16MHz or so. I would like to make it <500kHz Dec 03 15:40:05 the speed can be reconfigured from userspace, and it can also be overridden per individual transfer Dec 03 15:40:19 hunter, there is probably a parameter of the spi module that you can update to your desired speed. Dec 03 15:41:17 according to this: https://adafruit-beaglebone-io-python.readthedocs.io/en/latest/SPI.html you want to declare the msh Dec 03 15:42:32 Oh yeah, thanks! Dec 03 15:42:39 hahahah I just remembered what my problem was last time and how i fixed it for wifi. Dec 03 15:44:00 the startup script /usr/bin/bb-wl18xx-wlan0 used cat /proc/device-tree/model to load appropriate actions, but the dts wasn't changing the dt model... same as what's happening now. i need to hardcode Gateway cape to get it detected right. Dec 03 15:45:38 or just not bother with whatever that script is doing :P Dec 03 15:46:19 (I've never felt any need for a custom startup script when using a wl18xx wifi chip) Dec 03 15:46:49 doesn't it load firmware on startup? Dec 03 15:46:52 it just shows up as wlan0 and wpa_supplicant or your network manager can take it from there Dec 03 15:46:58 kernel loads firmware automatically Dec 03 15:47:10 hmm, it's still not showing up.. Dec 03 15:47:17 then your DT is still wrong Dec 03 15:47:38 (or hardware problems) Dec 03 15:50:01 hmmm. output enable seems to be abit low.. .143v perhaps the translator chips are not enabling right Dec 03 15:51:34 what exactly is supposed to drive the enable-pin high anyway? you're configuring it as a led, default off Dec 03 15:52:44 perhaps the pull-up alone was enough... ohh and this is wlbtbuf_pin Dec 03 15:53:57 the wlbtbuf pin should definitely be high unless your gpio hog is for the wrong pin or something :P Dec 03 15:54:42 I was gonna say maybe double-check with my show-pins utility, but it doesn't seem like I ever made a branch for the pocketbeagle Dec 03 15:58:26 what would set it to output high? Dec 03 15:58:53 your overlay currently uses a gpio hog for it Dec 03 15:59:19 which is the typical way to force a gpio to a fixed output level Dec 03 15:59:59 ahhh, yea, wrong pin, should be at gpio2 not 3 Dec 03 16:02:06 interesting, it get set to 3v3 temporarily during bootup, but then drops back to .126v Dec 03 16:04:19 that definitely shouldn't happen with a gpio hog Dec 03 16:05:01 it's magic of course Dec 03 16:06:01 .. if it's one of those double tied pins, does that call for additional settings? Dec 03 16:06:02 my bet would be cape-universal is causing this problem.. it's exporting the gpio while it's already in use (which normally shouldn't even be possible but the bb.org kernel has a hack that patches out some checks) Dec 03 16:06:18 Hi guys. I am very new to beaglebone black. I am trying to run PTP linux on the beaglebone and for that when I am writing ethtool -T eth0. It is showing command not found. Can anybody help me out please. Dec 03 16:06:24 like the pin has ain5/ gpio86 attached Dec 03 16:06:53 konsgnxx: not really no, just don't configure conflicting uses Dec 03 16:07:39 merp, i already have: #enable_uboot_cape_universal=1 Dec 03 16:07:55 yeah it can't be disabled on the pocketbeagle, which totally sucks Dec 03 16:08:50 it would be nice if status = "disabled"; could be set on individual gpios of the gpio-of-helper Dec 03 16:09:12 but that doesn't work currently (though I suspect it would be a 2-line patch to add it) Dec 03 16:10:33 interesting, the directory /sys/devices/platform/ocp/ocp:P2_35_pinmux doesn't exist, but /sys/devices/platform/ocp/of_node has it listed Dec 03 16:11:13 how is that "interesting" ? your overlay explicitly disables it Dec 03 16:11:45 note that pinmux helpers and gpios are entirely unrelated things Dec 03 16:12:07 i'm lacking understanding what the of_node directory is. Dec 03 16:13:07 a symlink to a filesystem representation of your device tree Dec 03 16:13:15 (each node a directory, each property a file) Dec 03 16:15:44 Alright, imma shutup for a bit, reasearch into cape-universal, what it does, and why it's trying to pick a fight. Dec 03 16:16:45 cape-universal can fight you in multiple ways, but in this case it's that it's exporting gpios for all pins to userspace for direct control, which conflicts with any other use of gpios by an in-kernel consumer, such as a gpio hog Dec 03 16:17:21 shouldn't that mean a visible ocp pin name? Dec 03 16:17:39 a pinmux helper has nothing to do with a gpio Dec 03 16:18:02 a pinmux helper is a device for userspace-selectable pinmux state Dec 03 16:18:22 gpio is one of the functions a pin may be muxed to Dec 03 16:19:35 the gpio itself (general-purpose input/output functionality) is a separate thing which itself doesn't know or care about pinmux (same with all other peripherals and their drivers, they don't concern themselves with pinmux) Dec 03 16:20:33 yea, i get that concept. still not familiar enough with the lower levels of linux to see where everything is. Dec 03 16:22:46 wait,,, is it really as simple as cape-universal { status = "disabled"; }; in ocp section.... gotta try that Dec 03 16:23:07 you can disable the entire gpio-of-helper device yeah Dec 03 16:23:25 which means no gpios will be exported to userspace by default Dec 03 16:24:00 (you can also replace it with your own gpio-of-helper for gpios you specifically want to export, see https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi ) Dec 03 16:24:52 (note the ACTIVE_HIGH macro is GPIO_ACTIVE_HIGH when using mainline headers) Dec 03 16:30:07 hmm, would there be a quick way to test it by putting a line in the cmdline of uEnv that sets gpio value? Dec 03 16:30:19 no Dec 03 16:30:40 unless you mean on the u-boot commandline Dec 03 16:31:01 u-boot does have commands for controlling gpios (used e.g. for boot progress leds) Dec 03 16:31:39 i am thinking if i can just set the value of the pin early on, I can leave it in userspace control, just default to high. Dec 03 16:32:13 if that worked you wouldn't be having this problem since the gpio hog sets it early Dec 03 16:32:33 the problem is that the gpio-of-helper changes it back to input Dec 03 16:32:42 (or whatever is declared in DT) Dec 03 16:45:44 bah, stays high now, but i still see no attempts to talk to it. Dec 03 16:45:54 also kernel has wlan-en-regulator: disabling Dec 03 16:45:54 in the dmesg Dec 03 16:46:41 that just means the kernel didn't see any users for the regulator (e.g. because the device failed to probe) Dec 03 16:46:54 the wifi device I mean Dec 03 16:48:55 mmmm. hmm. this would be in the relevant drivers _probe section right? Dec 03 16:52:55 I've been able to ssh to my board via ethernet. But now it is giving me an error saying "Unable to open connection to beaglebone Host does not exist" Dec 03 16:53:17 ace, perhaps the ip changed Dec 03 16:53:50 How would I fix that? Dec 03 16:56:37 not via ethernet, use usb or serial connection to check the ip of the device Dec 03 16:57:15 perhaps you could nmap to see if you can find it, but that would be a shot in the dark Dec 03 16:59:31 yeah i have ethernet and usb connected Dec 03 16:59:33 when I ssh Dec 03 16:59:58 I got it to work, thank you konsgnxx Dec 03 17:01:41 it is frustrating when follow directions on github nad it does not work =( Dec 03 17:25:22 When I do ipconfig, it gives me a local ip address. How do I get the one from the board? Maybe I am reading it wrong Dec 03 18:55:21 Aceplosion: ? Dec 03 18:57:04 Aceplosion: i usually go to my router's pageto get the ip address for other devices on the network Dec 03 18:57:09 oh he's gone Dec 03 18:57:13 oh that was a long a time ago Dec 03 18:57:19 also, apparenly, at no point is the mmc clk line going high during boot. seems like the wl18xx isn't being hunted for. Dec 03 18:57:29 an hour? Dec 03 18:57:36 not that long. Dec 03 18:57:44 time is relative Dec 03 18:57:55 to the speed that you're traveling Dec 03 18:58:18 i sucessfully createda new LAN using dnsmasq! Dec 03 18:58:39 now i want to give all those devices access to the internet with the AIs wifi connection Dec 03 18:58:53 buttt i think that's going to be significantly harder Dec 03 18:59:30 i've seen talk about bridges but there is some issues with different mac addresses trying to talk on the same WAP Dec 03 18:59:47 hi Dec 03 19:00:07 how can I use MUP in BB Dec 03 19:00:09 ? Dec 03 19:01:33 what is mup Dec 03 19:03:06 MPU Dec 03 19:03:43 I would like write a script for my MPU in python Dec 03 19:03:55 but I don't now Dec 03 19:04:27 can someone help me? Dec 03 19:04:35 send a little script Dec 03 19:05:07 Still have no idea what you are talking about Dec 03 19:07:01 mpu6050, you can check in this site: https://www.teachmemicro.com/beaglebone-black-mpu6050-i2c-tutorial-part-2/ Dec 03 19:08:03 seems like that site shows you how to use it. Dec 03 19:11:30 but I need programming in python :( Dec 03 19:16:07 seems like the examples out there are made for raspberry pi. you may be able to re-write them using: https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/i2c calls instead Dec 03 19:30:56 ok, thank u very much Dec 03 20:27:55 gahhhh! hair pull, i was basing my dts off the wrong overlay. BB-Bone-wl1837 is the one that works, not gateway-wl1837 Dec 03 20:28:31 i think libvert might be the route i need to go Dec 03 20:55:17 hmmmmm, is the gpmc csn in any way related to mmc? Dec 03 21:00:54 I think i may be looking at a red-herring Dec 03 21:54:28 whelp it's a hardware issue, still wierd that the gpmc_csn0 mux is used for the buffere enables, but my issue may be a lot more basic: i have the signals going into the translators criss-crossed. Tomorrow will attempt some tombstone surgery Dec 03 22:54:12 konsgnxx: I think diagnosing HW would be easier than messing with these damn overlays Dec 04 00:04:12 is there a quick way to test a ubs port on a device Dec 04 00:04:20 like with a multi-meter **** ENDING LOGGING AT Fri Dec 04 02:59:56 2020