**** BEGIN LOGGING AT Fri Dec 11 02:59:56 2020 Dec 11 03:01:01 I just do not know if beagleboard.org supplied the X_X_config.h file already or if a person like me needs to dedicate time to make one for the different drivers. Dec 11 03:08:32 For instance, is the generic board.h file what beagleboard.org calls an overlay or is there no such thing w/ the am335x b/c of its size and attributes? Dec 11 03:11:23 I have used many libs. and they seem to point to the same kernel drivers. So, using an all-around board.h and different driver.h files for particular boards would be neat. It, for instance, would be too much work for one man b/c things change quickly. Dec 11 03:13:43 I saw Molloy's book do this exact thing. He created, far away from my expertise, some drivers for peripherals. Neat...yes. But just like the book had work dedicated to it, the kernel had work dedicated to it also. Since the kernel changed, some of his works are no longer viable. "beating a dead horse." I know but why not keep it up. WHy not work w/ the kernel files to create more drivers for Dec 11 03:13:43 the boards? Dec 11 03:20:09 So, would I use an Array of Pin Configurations from a particular code block per driver for that particular peripheral or oh. Dec 11 03:20:48 There is so much to grasp. I think using the pin configurations is just like another set of source that can be called. I was unfamiliarw w/ this aspect. Dec 11 03:21:42 So, I can put the init function from the Pin Config. in the driver for a particular peripheral? Dec 11 03:24:58 I got it. I can define the macros, make some assignments, and call those portions to the macros in the driver itself. Then, the lib. would be like a init() assignment to my Pin Config. macro in the driver(s). Dec 11 03:25:00 Right? Dec 11 03:30:07 I am just flipping out. Do not fret to answer any of it. Sorry. I got excited again. Dec 11 09:59:28 Hi, i have a big issue and i search for help Dec 11 10:00:14 I have a beaglebone black, the SD card port is broken, the debian img in the beaglebone is broken too. How i can flash again my bbb? Dec 11 13:48:29 m Dec 11 14:10:51 m2u :D Dec 11 14:27:07 set_: header files (.h) are used to share constants, structures, and other declarations across multiple source code files that need those declarations, in particular it includes declarations of functions that are defined in one file but called in another (both of which then need to #include the header file that declares the function) Dec 11 14:28:12 set_: I have no idea what you mean by this "beaglebone_driver_config.h file, there is no "beaglebone driver", drivers are for small individual components, not an entire board Dec 11 14:31:02 set_: the description of the board is given via Device Tree, a binary data structure containing information about the components of a board (including the internal sub-components of a SoC) and how they are interconnected. this data structure is written in text-based .dts format, then compiled (using dtc) to binary .dtb format, and this dtb file is then loaded by u-boot which passes it to the kernel Dec 11 14:34:59 overlays are a mechanism to describe patches to a dtb, i.e. an overlay (.dtbo) file describes a set of additions or changes to the device tree, which u-boot can apply to the loaded dtb before passing it to the kernel. this allows for making DT changes/variants more modular and dependent on e.g. u-boot config variables or auto-detected hardware (capes) instead of having to compile a new main dtb Dec 11 14:35:49 config-pin has nothing to do with any of this Dec 11 16:25:59 @zmatt: I've finally figured out why the charger driver didn't seem to be doing anything, it wasn't compiled into my kernel. Dec 11 16:26:21 but now having installed it, I get exactly the same error as my driver "genirq: Flags mismatch irq 59. 00000000 (tps65217-charger) vs. 00002000 (vbus)" Dec 11 16:26:29 I guess I need to figure out what "vbus" here is Dec 11 16:26:49 oh, I just realized what it is! Dec 11 16:28:06 I recall seeing that the bbb's usb0 declaration included a "vbus" interrupt declaration pointing to the pmic's usb power detection interrupt Dec 11 16:28:24 ohhh Dec 11 16:28:31 I have no idea why it has this, the usb subsystem includes vbus measurement Dec 11 16:28:42 there is an interrupt attached to "vbus" on my system Dec 11 16:29:19 okay, so vbus is USB Bus Voltage, helps to at least know that Dec 11 16:29:22 https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-bone-common.dtsi#L248-L249 Dec 11 16:29:29 the second interrupt of the two Dec 11 16:29:49 I see Dec 11 16:30:01 so thats why its not allowing me to hijack it with the charger driver Dec 11 16:30:41 I don't have that in the declaration of usb0 in our own devicetrees and I've never had any problems with it (but I rarely make use of usb) Dec 11 16:30:43 perhaps I could get that USB driver to what I need Dec 11 16:31:23 you could fix the conflict by having your overlay override these properties to revert them back to their original value Dec 11 16:31:29 its interesting that my device charges the batter without needing a charger driver Dec 11 16:31:37 interrupts-extended = <&intc 18>; interrupt-names = "mc"; Dec 11 16:31:38 must be just the hw doing its thing Dec 11 16:32:18 yeah I have no idea why the driver feels a need to fiddle with registers on power change Dec 11 16:32:27 :D Dec 11 16:34:25 actually, looking at it again.. it does almost nothing Dec 11 16:36:01 no it does literally nothing other than provide status information Dec 11 16:36:36 wow someone went through a lot of trouble writing that Dec 11 16:37:16 and possibly messing up the NTC type bit Dec 11 16:37:47 (which should normally be left at reset default) Dec 11 16:38:34 what is NTC? Dec 11 16:38:49 the temperature measurement resistor Dec 11 16:38:57 (embedded in the battery pack) Dec 11 16:43:05 can you try this on a bbb where the tps65217-charger driver is not loaded: i2cget -f -y 0 0x24 0x04 Dec 11 16:44:04 ok never mind, it's not loaded here either I see Dec 11 16:44:50 I got confused for a moment by the existence of /sys/bus/i2c/devices/0-0024/tps65217-charger in sysfs but that's just the mfd's declaration that such a subdevice can exist (but with no driver attached to it) Dec 11 16:45:35 okay yeah, the charger driver messes up the NTC setting Dec 11 16:47:04 tps65217_config_charger() clears the TPS65217_CHGCONFIG1_NTC_TYPE bit (bit 4 of register 0x04), which is set by default Dec 11 16:47:25 which is bad for exactly the reason outlined in the comment of that function Dec 11 16:49:08 oh Dec 11 16:49:13 I love how this comment is provided as a justification for changing the setting, even though spending 1 second of thought on it would make you realize that the argument says the bit should be left at the factory default setting, and the single best way to ensure this is by not modifying it thus leaving it at the factory default setting :P Dec 11 16:49:15 so I could change that before I try to use it Dec 11 16:49:37 *should Dec 11 16:50:10 "I got confused for a moment by the existence of /sys/bus/i2c/devices/0-0024/tps65217-charger" that also threw me off. Is that created by the device tree without the driver? Dec 11 16:51:14 yeah it's either created by the device tree or by the tps65217 mfd driver (which also has a list of possible subdevices) Dec 11 16:52:13 in general you'll get a device node in sysfs if the kernel knows about a device, prior to loading the driver (hence regardless of whether a driver exists for it) Dec 11 16:52:57 ah I see Dec 11 16:53:18 anyway, yes you should disable tps65217_config_charger() in some manner Dec 11 16:54:27 if I just remove the NTC bit unset from that function call, is that enough? Dec 11 16:54:43 or are the bits it unsets also potentially a problem Dec 11 16:54:49 *other bits* Dec 11 16:59:18 seems i just to remove that function call altogheter Dec 11 17:12:35 @zmatt: got a udev event. it works! Thanks so much :) Dec 11 17:18:24 TonyTheLion: the function doesn't do anything else, at least in 4.19-ti Dec 11 17:22:26 TonyTheLion: huh, it seems the musb_dsps driver does in fact use the vbus interrupt from the pmic is provided and falls back to polling otherwise.. big question is why though Dec 11 17:25:19 ah, because the hardware "won't expose several OTG-critical status change events (from the transceiver) otherwise" Dec 11 17:25:38 which seems odd Dec 11 17:30:31 TonyTheLion: so, the message about conflicting irq flags is because tps65217_charger passes 0 as irq flags, which is incorrect since "threaded irqs must provide a primary handler or set the IRQF_ONESHOT flag" and it doesn't provide a primary handler either (the NULL argument) Dec 11 17:30:54 so it should pass IRQF_ONESHOT just like tps65218-pwrbutton.c does Dec 11 17:31:55 the charger driver should do that or the usb driver? Dec 11 17:34:06 the charger driver, musb already uses IRQF_ONESHOT Dec 11 17:34:12 though this still would'nt allow them to share the irq Dec 11 17:34:26 huh, irq sharing should work though, from what I've read Dec 11 17:34:48 yeah I'm not sure, it's a bit weird Dec 11 17:34:59 ye its confusing Dec 11 17:36:02 like, logically sharing shouldn't be any problem in this case since the "interrupt" is in fact called from a thread context (the threaded irq handler of the pmic) via handle_nested_irq(), which is pretty much just a for-loop that calls the child interrupt handlers Dec 11 17:36:24 so the problem is more that the framework has restrictions designed for traditional interrupts Dec 11 17:45:19 I see Dec 11 17:45:38 I wonder if maybe the tps65217 mfd should have represented the three status bits (USB, AC, PB) as gpios instead, since they're level indicators with change-interrupts Dec 11 17:54:36 it also seems like the tps65217 should set IRQCHIP_ONESHOT_SAFE to indicate that IRQF_ONESHOT is unnecessary Dec 11 18:03:19 (which avoids runtime overhead, and would have avoided the irq flags disagreement warning) Dec 11 18:06:12 TonyTheLion: it looks like passing IRQF_ONESHOT | IRQF_SHARED as flags in both drivers (musb_dspd and tps65217_charger) should allow them to share the irq Dec 11 18:14:34 also, if I understand correctly, setting .flags = IRQCHIP_ONESHOT_SAFE in the struct irq_chip tps65217_irq_chip in drivers/mfd/tps65217.c would cause IRQF_ONESHOT to be ignored for the interrupts provided by this driver, and would allow that flag to mismatch between drivers that want to share it, though IRQF_SHARED would still be required Dec 11 18:17:17 IRQF_ONESHOT essentially causes the interrupt to be disabled when it fires and reenabled when the handler(s) are done; setting IRQCHIP_ONESHOT_SAFE on the irqchip (tps65217_irq_chip in this case) indicates doing so is pointless and can be skipped Dec 11 18:21:29 what weirds me out though is that almost no driver uses this flag, even though my understanding of it would imply every driver that uses handle_nested_irq() ought to be using it Dec 11 20:21:57 I see cloud9 works. I always thought it was broken for some reason. Nice! Dec 11 20:22:41 @zmatt: I saw what you typed. Okay. No issue. I was thinking of another board w/ less 'activity' on it. Dec 11 20:32:05 I guess I was comparing. My bad. Dec 11 21:24:21 Hello I was looking at using Lottie files for a UI running on the BBB. In the past, I ran vector images on the Midori browser which ran close to 100% of the CPU usage. Does anyone have familiarity using Lottie files on the BBB (couldn't see anything when I googled it) and what was your experience? Ideally I'd like to run these files on QT which I Dec 11 21:24:22 do know can play Lotte files https://www.qt.io/blog/2019/03/08/announcing-qtlottie Dec 11 21:56:42 well they left, but one can convert lottie files into gif animations under the hood and play the gif animations in a UI.. Dec 11 22:19:49 Nice! Dec 11 22:38:58 one can convert lottie files into gif animations under the hood and play the gif animations in a UI.. examine https://pypi.org/project/lottie/ Dec 11 22:40:53 thanks. @GenTooMan! Do you know if that will run smoothly on the BBB without clogging up CPU usage? Dec 11 22:46:11 honestly I have no idea but it's a start at least to control things to some extent Dec 11 22:47:02 got it - thanks! Dec 11 22:54:32 Hmm Dec 11 22:56:46 Hmm. Dec 11 22:57:35 What if I said "forty" and another person later came in to say "forty," do I still get credit? Dec 11 22:58:09 Dang stuff and multitudes of misfortune. Dec 12 00:17:32 Hi all, had a quick question about max throughput on the Beaglebone Black. It's a gigabit port, but I can't get it to transfer about 94Mbps, even when the ethernet cable goes from the desktop directly to the BBB. Is this a known limitation, or can the BBB transfer at higher speeds? I need a consistent >500Mbps throughput (it will be used for Dec 12 00:17:33 network testing) Dec 12 00:22:59 arg, okay, that's weird.. mii-tool shows the BBB is linked at 1000base-T, but lshw shows that ethernet is only 100Mbps! So I guess this board has a basic 10/100 port Dec 12 00:26:36 GenTooMan: I got a fancy-dan servo! Are you proud of me yet? Just wait. I am going to make something neat! Dec 12 00:27:25 I have been testing w/ the BBB and Motor Bridge Cape but I am just going to use the lib. they have for their integrated servo for source control. Dec 12 00:27:48 Watch out fingers and eyes, motors! Dec 12 00:28:39 Emmy87: Are you discussing the ethernet on the BBB? Dec 12 00:29:12 I think it is not Gigabit but I should make sure before I say something like that idea. Dec 12 00:29:24 Please hold. I will check. Dec 12 00:31:02 BBB 10/100. Dec 12 00:33:55 See, it does not matter to me since my ethernet cable coming from the co. is slow. So, I would have to pay them more for higher speeds. Dec 12 00:34:22 But, if you can achieve 1000Mbs from the co, more power to you! Dec 12 00:34:42 They damn co. wants $5.00 extra per month. Forget that! Dec 12 00:45:45 Anyway...yep. 10/100. Dec 12 01:57:33 my cable company just eliminated the lower cost plans. But that is just how nasty those people are. Dec 12 02:02:15 Little man out and big man in. It seems that sometimes even inexpensive plans are obsolete these days. I tried even for cheaper, more inexpensive plans for data on a cell phone. Forget searching online w/out wifi. Sheesh! Dec 12 02:02:40 GenTooMan: Integrated? Did that catch your eye? Dec 12 02:03:43 I have 127 pages to read before I plug this ole servo in. I cannot wait! I am super fantastical about it all. Ha. Dec 12 02:04:03 I am here to pump you up! Dec 12 02:04:52 It seems this motor is a powerful entity in life and i need to watch me undies. I am on system setup now. Page 9, I have a lot of reading to do. Dec 12 02:07:46 I finally have some work, e.g. figuring out power consumption, nominal V, and how it all affects my servo. Dec 12 02:37:18 I suggest doing one thing at a time Dec 12 02:38:43 Yes sir, these integrated servos are complicated to me so far. I am reading about them first. Then, testing, attaching it to the BBB, and then some neat machine. Dec 12 02:39:30 The instructions state that anything w/ a 127k baudrate can handle the servos. Dec 12 02:39:37 Linux! Dec 12 02:41:39 There is a set of c/c++ instructions provided to test things once I use the calculation source they provide to first test the mannerism in which the single servo moves. I can attach four w/ this add-on board and direct traffic via the BBB. It is neat. I am going to advance my findings in time. Dec 12 02:43:31 This thing even has a diagnostic port. Dec 12 02:43:44 I can make sure what I am viewing is what I need to be viewing. **** ENDING LOGGING AT Sat Dec 12 02:59:56 2020