**** BEGIN LOGGING AT Wed Dec 02 02:59:57 2020 Dec 02 03:54:05 question Dec 02 03:54:22 why would the kernal complain about an overlay being set already Dec 02 03:54:31 that is the point of an overlay to change it Dec 02 03:54:32 https://pastebin.com/kS8vKPQh Dec 02 03:55:16 working off of this file Dec 02 03:55:17 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_BB-BONE-LCD7-01-00A3.dts Dec 02 06:22:26 it's complaining about pinmux conflicts Dec 02 09:48:06 anyone know how to map the PMIC's interrupt on the beagle so as to be able to use it programmatically? Its in /proc/interrupts under "tps65217-irq", but I don't know how to use that in my code to respond to interrupts Dec 02 09:48:17 I'm guessing I need to make some kind of device tree overlay Dec 02 09:48:34 the pmic has a kernel driver which uses the interrupt Dec 02 09:48:53 right Dec 02 09:49:01 that means I can't use it? Dec 02 09:49:05 (and checks the interrupt status and distributes those to drivers for component features) Dec 02 09:49:42 it means that it doesn't even make sense to want to "use" it Dec 02 09:49:49 since the pmic's interrupts are being managed by its kernel driver Dec 02 09:50:12 ah Dec 02 09:54:52 e.g. if you press the power button the interrupt will fire, the tps65217 multi-function driver (drivers/mfd/tps65217.c) will receive that interrupt, it reads the interrupt status register to find out the reason for the interrupt, discovers it was a power button state change, hence passes the interrupt on to the tps65217/65218 power button driver (drivers/input/misc/tps65218-pwrbutton.c), which emits a ... Dec 02 09:54:58 ...power key pressed/released event as appropriate Dec 02 09:55:37 yea that makes sense Dec 02 09:56:16 I have a device with the same chip on it as the beagle, which runs on battery, and wanted to be able to respond to "USB power plugged in" events programmatically Dec 02 09:56:19 hence my question Dec 02 09:56:49 yeah there's a mechanism for that too I think Dec 02 09:57:05 in the PMIC's driver? Dec 02 10:00:23 the tps65217_charger driver requests the "USB" and "AC" irqs Dec 02 10:00:44 is that this one too https://elixir.bootlin.com/linux/latest/source/drivers/mfd/tps65217.c Dec 02 10:01:00 that's the top-level driver Dec 02 10:01:12 (mfd = multi-function device) Dec 02 10:01:35 ah I see, not super familiar with kernel things Dec 02 10:02:20 found it https://github.com/torvalds/linux/blob/master/drivers/power/supply/tps65217_charger.c Dec 02 10:03:36 so that driver manages the register interface, interrupt identification/dispatching, and a tiny misc bit of initialization (disabling rtc-only mode) Dec 02 10:06:05 okay, thanks :) Dec 02 10:06:08 for the pmic's actual (mostly independent) functionalities there are various drivers: the regulators (drivers/regulator/tps65217-regulator.c), the power button (drivers/input/misc/tps65218-pwrbutton.c), the charger (drivers/power/supply/tps65217_charger.c), the backlight (drivers/video/backlight/tps65217_bl.c) Dec 02 10:06:53 oh wow, I did not realize these things all had independent drivers Dec 02 10:07:19 yeah, since they really have nothing to do with each other Dec 02 10:07:33 they're basically just random functions shoveled together into one chip Dec 02 10:08:18 (except all of them are related to "power" in the broadest sense) Dec 02 10:08:35 hehe Dec 02 10:08:53 so much for "single responsibility principle" at hardware level Dec 02 10:09:21 but it seems what you want is actually missing Dec 02 10:10:14 you mean the driver doesn't have it? Dec 02 10:10:33 like, on my laptop I have a power supply device for each of the two battery packs, as well as a power supply device for the AC input which just indicates whether my laptop is connected to charger Dec 02 10:12:03 something like that AC device is what you want, but for the BBB's USB power input Dec 02 10:12:44 oh what Dec 02 10:12:53 the PMIC has an interrupt you can enable, and is enabled that tells you that the USB is plugged in Dec 02 10:13:09 its in the PMIC's doc Dec 02 10:13:42 "USB power status change interrupt mask" Dec 02 10:13:58 yes, which the tps65217 mfd driver emits as "USB" and "AC" irqs to its subordinate drivers Dec 02 10:14:07 ah okay Dec 02 10:14:19 e.g. the tps65217_charger driver listens to both: https://elixir.bootlin.com/linux/latest/source/drivers/power/supply/tps65217_charger.c#L213 Dec 02 10:15:19 oh I see, so "AC device is what you want" is something else you meant? Dec 02 10:16:33 I was explaining how normally there should be a power_supply device for each power source of the system (e.g. battery or external input) Dec 02 10:17:08 this tps65217_charger driver is kinda weird... it's for managing the battery, but it doesn't declare a battery-type device Dec 02 10:17:25 ah right Dec 02 10:17:39 but it's really close to what you need Dec 02 10:18:49 so I'd need to modify the driver Dec 02 10:18:58 no, create a new one based on it Dec 02 10:19:23 like, the tps65217_charger driver is ultimately for managing the battery charger Dec 02 10:19:26 and it would expose or forward USB interrupts received so my program could act on them Dec 02 10:19:28 which is not what you care about Dec 02 10:20:18 ye, I only want to know if the USB power is plugged in or not Dec 02 10:22:17 yeah, so the tps65217_charger driver does listen for that event (though also for the AC event) and uses it as trigger to update its state and the charger config Dec 02 10:22:38 while in your case all it needs to do is update its "online" status Dec 02 10:26:00 is that "online" status then exposed somewhere to the user? Dec 02 10:27:00 yeah it would show up as /sys/class/power_supply/USB/online Dec 02 10:27:11 and changes also result in some sort of event, I'd need to check what/how Dec 02 10:52:33 sorry, distraction from work :P Dec 02 10:54:43 power supply changes emit udev events... unfortunately it doesn't seem to use POLLPRI-based notification on the "online" attribute itself (which is the standard way of notifying userspace about changes in sysfs attributes) Dec 02 11:11:13 ah, does that mean I could use an existing udev event? Dec 02 11:12:38 ah, ? Dec 02 11:12:44 what? Dec 02 11:13:05 your driver just calls power_supply_changed() Dec 02 11:13:25 you said "psu changes emit udev events" and I assumed that is already what is happening Dec 02 11:13:33 so I wondered if I could just use that Dec 02 11:14:19 sorry, no, I meant power supply devices announce their property-changes using udev events Dec 02 11:14:32 ah okay Dec 02 11:14:46 as in, when your driver calls power_supply_changed(), like tps65217_charger does here: https://elixir.bootlin.com/linux/latest/source/drivers/power/supply/tps65217_charger.c#L146 Dec 02 11:15:31 the power supply framework will (some time soon) fetch the properties of your device and emit them in an udev event Dec 02 11:15:46 I see Dec 02 11:17:20 you could probably also call sysfs_notify() to announce the "online" sysfs property has changed Dec 02 11:17:50 hmmm, so really making this driver is not actually that hard Dec 02 11:18:15 because most of the infrastructure exists in the charger driver, I just have to remove the charging bits, and call one of those functions when "online" has changed Dec 02 11:18:19 this mechanism is perhaps a bit simpler for userspace: you just open() the "online" property and use select()/poll()/epoll or your favorite event loop framework to receive POLLPRI events Dec 02 11:18:45 ye epoll is my goto framework here :P Dec 02 11:18:50 so the charger driver already calls power_supply_changed() when the online status has changed, as I linked Dec 02 11:19:32 I used to use my own minimalistic epolll wrapper, but these days I generally use sd_event (part of libsystemd) Dec 02 11:20:05 https://elixir.bootlin.com/linux/latest/source/drivers/power/supply/power_supply_core.c#L114 that doesn't do anything that looks like writing to userspace Dec 02 11:20:22 the main changes are: you only care about USB, not AC (both the irq and the status bit checked) Dec 02 11:20:45 all logic for the charger is irrelevant Dec 02 11:23:05 you could also ditch the polling stuff that's used as a fallback in case the irq is unavailable (i.e. some idiot didn't wire up the interrupt line of the pmic to the processor) .. I see no reason to care about that scenario, just fail if the irq is unavailable (like tps65218_pwrbutton does) Dec 02 11:32:29 ye Dec 02 11:35:44 TonyTheLion: quick draft, probably full of mistakes, haven't tried to compile it ;) https://pastebin.com/9FgiAC6L Dec 02 11:36:31 ideally it would be made generic enough so that it can be instantiated twice: one for USB and one for AC Dec 02 11:36:51 but I haven't attempted that here, just made it USB specific Dec 02 11:39:05 cool! Dec 02 11:39:20 not sure I understand how power_supply_changed would emit something in userspace? Dec 02 11:39:25 is that a udev thing? Dec 02 11:40:05 I would probably go with sysfs_notify so I can epoll the sysfs interface it exposes Dec 02 11:40:17 I just described that: power_supply_changed() causes the power supply framework to emit an udev event to userspace Dec 02 11:40:34 which you could monitor using e.g. libudev Dec 02 11:41:02 sorry, this kernel stuff is new to me Dec 02 11:41:33 if you have a linux laptop, try connecting/disconnecting its charger while running "udevadm monitor -kp" Dec 02 11:41:36 okay but that makes sense Dec 02 11:41:40 to see it in action Dec 02 11:41:55 I only have Windows laptop :D Dec 02 11:44:00 to also support using sysfs notification you'd add sysfs_notify(kobj, NULL, "online"); after updating the online property (before calling power_supply_changed()) .. I'd just need to check where you get the right kobj from Dec 02 11:45:52 huh, it seems using "struct power_supply *psy" wasn't a weird choice by the tps65217_charger driver, the power_supply framework itself uses the same weird abbreviation "psy" Dec 02 11:46:37 maybe it was written by a psycho Dec 02 11:47:10 or maybe it's just Power SupplY Dec 02 11:49:27 :D Dec 02 11:50:05 TonyTheLion: so, renamed the struct power_supply * back to psy, and added a sysfs_notify line that has a non-zero probability of not being totally wrong: https://pastebin.com/vZ5HmH3G Dec 02 11:50:14 that'll be my last version, have fun with it Dec 02 11:53:16 thanks so much for your help :) Dec 02 11:53:24 much appreciated Dec 02 13:18:53 hmmm, Dts overlay keeps saying i have a compile syntax error on gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; Dec 02 13:31:19 missing the #include for that macro Dec 02 13:31:53 bahhh, so i can only compile with the include from a specific location? Dec 02 13:32:18 ? Dec 02 13:32:29 you need #include Dec 02 13:32:53 is the dt-bindings/gpio/ location found in the image, or is that something i need to pull from git? Dec 02 13:32:55 oh. yeah use a makefile that uses the right cpp invocation Dec 02 13:33:21 I was just calling dtc to make a dtb Dec 02 13:34:16 you can find a git checkout of bb.org-overlays in /opt/source/ Dec 02 13:34:34 which has both the headers and a suitable makefile Dec 02 13:34:49 sweet, thanks! Dec 02 13:35:59 (it also has and so you don't need to use magic hex constants for pinmux declarations) Dec 02 13:36:31 haha, already went through and copy pasted those magic hexes Dec 02 13:36:58 wouldn't recommend, it sucks to have source code that's incomprehensible Dec 02 13:37:04 good to know, now to figure out that makfile to figure out the workflow. Dec 02 13:37:32 if you drop your .dts in the src/arm/ subdir you can do "make src/arm/FILENAME.dtbo" Dec 02 13:37:35 iirc Dec 02 13:39:16 I also have my own overlay utils project which works a bit differently but has a makefile that's only 21 lines hence not very intimidating ;) Dec 02 13:39:54 but its input syntax is different and for historical reasons my headers are different (though you can of course just mix and match) Dec 02 13:40:34 yea, i can see how making your own tool for this helped Dec 02 13:43:42 back when I made it there wasn't much use of macros yet (magic hex values everywhere) and dtc wasn't able yet to perform the transformation from sane syntax into the crap required for overlays (which is a transformation my overlay-utils does using a perl script) Dec 02 13:46:02 the perl script still has some benefits, e.g. it supports overlay metadata supplied as top-level properties ( https://github.com/mvduin/overlay-utils/blob/master/TT3201-001-01.dtsi#L6-L25 ) and you can write / { ... }; like normal instead of having to write &{/} { ... }; Dec 02 13:47:06 and it automatically adds the overlay identification / timestamp fragment ( i.e. one of these: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/AM335X-PRU-UIO-00A0.dts#L18-L31 ) Dec 02 13:52:20 woot! it lives! now to test the wifi subsection, and move on to battery charger. Dec 02 13:52:27 Thank you good sir! Dec 02 16:59:40 hmmm. what would prevent usb_gadget from loading with my dts? Dec 02 17:37:57 what do you mean by "prevent usb_gadget from loading" ? what are you observing exactly? Dec 02 17:44:54 doesn't show up on usb connection to pocketbeagle, can still talk via uart0 Dec 02 17:47:56 does /sys/class/udc/musb-hdrc.0 exist? Dec 02 17:49:38 if no, then what about /sys/bus/platform/devices/musb-hdrc.0 ? Dec 02 17:49:51 does /sys/kernel/config/usb_gadget/ exist? Dec 02 17:51:03 summary of enabling usb in DT for the am335x: https://pastebin.com/h4ESYvQk Dec 02 18:14:39 hmmm, usb_gadget doesn't exist but that first location does. Dec 02 18:14:52 it's is_otg is 0 Dec 02 18:15:54 re: that paste, is that meant to go in an overlay? I assumed my pin modified BB-Gateway dts was an overlay Dec 02 18:16:55 what are you doing exactly? Dec 02 18:17:08 like, for any beaglebone the necessary stuff for usb will already be in the base dts Dec 02 18:17:26 so enabling usb in DT is really only applicable to custom boards Dec 02 18:17:57 the sound of "my pin modified BB-Gateway dts" makes me worried Dec 02 18:18:29 what do you mean by that exactly? Dec 02 18:19:12 haha Dec 02 18:20:18 i made a cape for the pocketbeagle with a wifi chip. trying to get it running. just want to make an overlay that switches the appropriate pins to mmc2 4bit mode and talk to the wl1837 Dec 02 18:20:50 not trying to do anything to the usb, but it stops working with my cape... Dec 02 18:21:08 https://pastebin.com/EEkTLGVU Dec 02 18:22:46 ohh the bb-gateway is a cape... I got confused with the beaglebone green gateway Dec 02 18:23:56 yup yup. broke out the mcaxp as well as in the green, but ignoring that for now. Dec 02 18:24:26 why did you comment out the identification fragment? Dec 02 18:24:48 (lines 45-55) Dec 02 18:25:33 anyway, pretty sure the usb gadget is fine, presumably the startup script that normally sets it up failed for some reason.... check journal I guess Dec 02 18:29:56 didn't work when i was testing with dtc direct compile Dec 02 18:32:05 will hunt around Dec 02 18:36:13 ? Dec 02 18:36:51 right, __TIMESTAMP__ is a preprocessor macro Dec 02 18:42:57 oh, I know why the startup script broke Dec 02 18:43:02 you changed the board model Dec 02 18:43:06 merp.. Dec 02 18:43:19 part number? Dec 02 18:43:24 model = "MTI AM335x Power Beagle breakout"; Dec 02 18:43:29 ahhhhh Dec 02 18:43:44 changing the compatible to ti,am335x-bone-black is also a really bad idea Dec 02 18:43:53 woot! thank you! Dec 02 18:44:21 that very much seems like a arbitrary string Dec 02 18:45:07 riiiggghttttt, the drivers look for those "compatible" strings. Dec 02 18:46:22 also, your overlay's own compatible-string claims it's for a beaglebone rather than a pocketbeagle (fortunately u-boot overlays ignores all the metadata and performs no compatibility-check :P ) Dec 02 18:46:24 hmmm, i didn't change to the ti,am335x-bone-black, thats from the original Dec 02 18:46:43 "the original" ? Dec 02 18:46:47 ha, i take i should change it to pocketbeagle Dec 02 18:47:20 "ti,am335x-pocketbeagle" Dec 02 18:47:39 based on what's in am335x-pocketbeagle.dts Dec 02 18:48:04 original being the Gateway dts Dec 02 18:50:01 btw dtc nowadays allows you to write it like this: https://pastebin.com/raw/YWC6Npd1 (very close to what my overlay-utils uses) Dec 02 18:50:08 no more manual fragment numbering Dec 02 18:51:08 that looks a lot neater Dec 02 18:51:54 and you're right, the same garbage is in BB-GATEWAY-WL1837-00A0.dts Dec 02 18:52:21 unfortunately it's not that uncommon to encounter really weird things in overlays Dec 02 18:52:54 it's a bit less destructive there since it's setting the system's compatible-string to the value it already had anyway Dec 02 18:53:44 wooo! usb is up with the overlay! Dec 02 18:54:18 oh, fun, the model-string "TI AM335x BeagleBone Black Gateway Cape" actually has special-case handling in the startup scripts Dec 02 18:54:44 (/opt/scripts/boot/am335x_evm.sh) Dec 02 18:55:51 I don't really know why it cares... if it has special stuff to do for the wl18xx, it should just detect a wl18xx instead of having a hardcoded list of boards Dec 02 19:24:05 hmmm, what would be a good way to debug this device? usb is back up, but still no wifi interface Dec 02 19:24:42 I don't have an easy answer for that Dec 02 19:24:56 that's the fun of debugging ;) Dec 02 19:25:58 haha gotcha! Dec 02 19:27:58 my guess would be it's either hardware or software Dec 02 19:37:01 im thinking issue is between keyboard and chair. Dec 02 20:17:19 hmmm, mmc2 doesn't seem to exist in my sys/devices/platform/ocp Dec 02 20:17:51 perhaps it doesn't get called out by default and the overlay @mm2 doesn't do anything. Dec 02 20:19:16 you've enabled it, it ought to show up Dec 02 20:19:25 as /sys/bus/platform/devices/481d8000.mmc Dec 02 20:19:30 I think Dec 02 20:19:36 wait no Dec 02 20:19:42 hmm. that points to mmc1 no? Dec 02 20:19:48 47810000 Dec 02 20:20:04 but I also found the cause of your problems Dec 02 20:20:28 merp? Dec 02 20:20:42 it seems that mmc device node labels are the last remaining off-by-one numbering garbage in am33xx.dtsi Dec 02 20:20:47 so it's &mmc3 Dec 02 20:21:11 aww man, bah! Dec 02 20:21:55 should the exclusive-use list refer to it as such or only the @mmc2 Dec 02 20:23:32 no idea, but nothing currently uses that metadata anyway Dec 02 20:24:02 woo! boot loop...i feel like i'm having deja-vu. Dec 02 20:24:08 at least there's progress Dec 02 20:27:34 I really shouldave taken notes last time i was here. Dec 02 20:40:38 whelp, time to python collect the logs kept of this channel so i can find what i was asking way back when i was trying to get wifi up on beagleblack Dec 02 21:08:49 Probes away!! Dec 02 21:20:38 damnit, i didn't have any questions here relating to that apparently :( Dec 02 21:21:32 konsgnxx: I would like those scripts Dec 02 21:21:37 that sounds handy Dec 02 21:23:29 https://pastebin.com/GeJaeFPB .. replace the "onsgn" with whatever text you are looking for.. and fix the csv writer if you don't have a large scrollback. Dec 02 21:24:36 ehm, instead of spamming the kernel with requests each time you want to search, how about you just mirror it using wget so you can grep your local mirror at your leisure Dec 02 21:24:41 *spamming the server Dec 02 21:25:27 that's a very good point. i will remove that post now. Dec 02 21:27:41 merp, not possible. Dec 02 21:59:56 MCSPI_CH0CTRL.EXTCLK is a bit confusing or not quite right in the spec, quoting "Then the maximum value reached is a 4096 clock divider ratio", but the value shown below for FFh is just "Clock ratio is CLKD + 1 + 4080" Dec 02 22:01:28 ha no sorry, it's right, just not immediately clear, I see now Dec 03 01:00:45 GenTooMan: Are you around to tell me how little I know in time and space? Dec 03 01:04:56 https://imgur.com/m7qsZu7 is a short I put together, do not laugh, on a flowchart. Is this what you were describing to me? Dec 03 01:05:46 Right now, it is simple. I plan on choosing a better flowchart later. Dec 03 01:07:02 Just for reference, I know nothing, i.e. even on flowcharts. Dec 03 01:07:11 So, it is completely wrong for now. Dec 03 01:07:44 But. The basic idea is on paper as a start to solving this equation of start, stop, restart. Dec 03 01:12:52 On/Off should have the diamond or is that I/O too, i.e. which needs the parallelogram? Dec 03 01:22:13 https://imgur.com/bQqg61U is better but needs work. So, I will work on it. Dec 03 02:36:09 Neat-O! Dec 03 02:36:31 So, now, the motor can be interrupted and stop or retract as one would like. Dec 03 02:36:36 hmm flow charts haven't done those in a long while. Was good at them for a bit. So let's talk about flow charts briefly. Flow charts are sequential flow logic only and have no states. Dec 03 02:36:55 GenTooMan: I did it! Dec 03 02:37:25 did what? Dec 03 02:37:27 I grasped the concept of interrupts and used them in a real-life situation. Dec 03 02:37:52 Just like you were saying, I got the ideas, used logic, and solved. Satisfying...no? Dec 03 02:38:26 It is cold early here and the mosquitos are clinging to pop to live. Ha. Dec 03 02:38:40 Anyway, thank you. Dec 03 02:40:25 Ok I am glad someone made sense of what I said. It's cold here today as well with 4 inches of snow. Dec 03 02:40:35 I got this motor on the way and it is a nice servo motor w/ its own electronics on the interior. Snow. Forget that mess. Dec 03 02:40:50 4 inches. Damn. Dec 03 02:41:16 right snow is a four letter word. so you have a servo motor with electronics ready to smash through the front door? Dec 03 02:41:28 Right. Ha. Dec 03 02:42:06 I got this cheap, outdated ball screw, 18", w/ slides. Dec 03 02:42:23 Now, I am going to fasten the nice servo to the doo-dad. Dec 03 02:42:48 And add a spindle or writing utencil. Dec 03 02:43:09 I should have a neat get-up sooner or later. Dec 03 02:43:21 hmm so you have a linear actuator. Well I was going to suggest using an over current sensing device to detect end of travel if you were stepping things. Dec 03 02:43:45 I am trying source now to use the interrupts for stopping the motors when the things go past their respective marks. Dec 03 02:44:16 Servo, 300 degree continuously rotating! Dec 03 02:44:22 Sorry. 360! Dec 03 02:44:52 I am still working on a Cape for this thing. Dec 03 02:45:03 right I was wondering if that was some "new math thing" metric angles or something. Dec 03 02:45:14 I do not know what to do just yet. Dec 03 02:45:15 ha. Dec 03 02:45:47 W/ respect to hardware, I could go w/ another chip and use i2c or try to do everything on the BBB. Dec 03 02:45:54 you don't huh? you want to work on a cape? Well KiCAD is not up to 5.1.8 and I've made my 12 layout... Dec 03 02:46:06 Oh? Dec 03 02:46:11 I know about the version. Dec 03 02:46:18 I am using it w/ an old Cape layout. Dec 03 02:46:34 you did the schematic then the PCB layout? Dec 03 02:46:44 I am trying to get more familiar w/ trace layout Dec 03 02:46:45 Oh. Dec 03 02:46:46 No. Dec 03 02:47:09 It was an older Cape version from the Beagleboard.org people on KiCAD. Dec 03 02:47:24 I found it before updating my source for KiCAD. Dec 03 02:47:35 luckily, things still worked. Dec 03 02:47:54 The update caused no friction. Dec 03 02:48:30 Error free! Dec 03 02:48:42 error filled ... impressive. :D Dec 03 02:49:00 Now, my electric stop works in practice and not in my mind. Dec 03 02:49:11 it looked good on paper but looks better w/ LEDs! Dec 03 02:50:05 Now, I was going to take some ideas from different portions of my existence while reading and mash 'em up good so it works well. Dec 03 02:50:38 PCB + doo-dads + Caps and + maybe a diode! Dec 03 02:51:29 Those traces are tricky from what you told me. I am still trying to understand the Analog Pocket Ref. book from TI.com on traces. Dec 03 02:58:59 some arbitrary and perhaps randomized thoughts. Stops are used to find position of a stepper. However a DC servo motor isn't stepped. That requires the use of an encoder or some such thing to know where it's at when the DC servo moves. Dec 03 02:59:29 Aw. **** ENDING LOGGING AT Thu Dec 03 02:59:57 2020