**** BEGIN LOGGING AT Wed May 27 03:04:13 2020 May 27 10:45:57 anyone know a node-red thingamabob to read values from a hwmon temperature sensor? May 27 11:14:27 ok, that was that... May 27 11:17:02 npm install thingamabob May 27 11:17:04 ;) May 27 11:26:29 Does any one know which certificate Beagle bone AI has ? May 27 11:27:07 https://github.com/beagleboard/beaglebone-ai/tree/master/regulatory May 27 11:27:30 thanks May 27 13:28:43 I'm building a kernel, 4.19 for reasons I no longer recall. That appears to be working fine, but I can't for the life of me figure out how to get development headers extracted, so I may build a kernel module against it. I feel I'm missing something trivially simple. May 27 13:30:19 Ragnorok: if you use rcn's build_deb.sh script it should build a headers package May 27 13:30:25 in addition to the kernel image package May 27 13:30:33 Ah. I used build_kernel. lol May 27 13:30:44 See? Something simple. I'll try that. May 27 13:30:51 tools/rebuild_deb.sh May 27 13:30:59 Thanks! May 27 13:31:13 (to avoid recreating the source tree from scratch like ./build_deb.sh would do) May 27 13:32:02 Ragnorok: notes on building and customizing bbb kernels: https://pastebin.com/eLhrp1Hg May 27 13:36:07 Sweet. May 27 13:36:18 Hi, if I have a BBB, could I copy the SD card it with its OS and all newly downloaded libraries and plug it into a pocketbeagle? May 27 13:37:57 yeah a BBB system also works on the pocketbeagle May 27 13:38:32 as long as you don't, for example, have a custom overlay configured that's designed for the BBB May 27 13:39:57 but as long as you haven't done any customizations that create a dependency on specific hardware, the same image will work in any am335x-based beaglebone (i.e. all of them except the beaglebone-AI) and the pocketbeagle May 27 13:41:43 When I diff .config I see a lot of changes from the old kernel to the new one. Is it appropriate to just copy over .config? I'm not savvy enough to know what may have changed, and sort of assume rcn would have packaged a .config that's already good to go. May 27 13:43:04 I think the build script will grab patches/defconfig to use as the .config file and then run either make oldconfig or make menuconfig depending on AUTO_BUILD in system.sh, and then copy the resulting .config file back to patches/defconfig May 27 13:43:30 Okey doke. Guess I'll run it and see what happens. May 27 13:45:19 It ran menuconfig, which is what made me decide to compare. I just drove on. May 27 13:45:45 yeah by default AUTO_BUILD is disabled to give you an opportunity to review/tweak the config May 27 13:46:05 since... customizing the config is the most likely reason you'd want to build a custom kernel in the first place May 27 13:46:36 "for reasons I no longer recall" sounds like a sub-optimal situation to be in :P May 27 13:47:23 Yeah, it is. I know you and I discussed it maybe two months ago and I selected 4.19 for reasons. May 27 13:47:38 I'd recommend at least making git commits for your changes to patches/defconfig and/or any new local patches you add, to ensure you can easily merge your changes with (or rebase them onto) rcn's changes May 27 13:48:38 I mean, "selecting" 4.19 is a simple apt-get install, that doesn't explain the necessity to custom-build May 27 13:49:22 My recollection is we haven't actually changed anything in the kernel, but I didn't do this work originally. The guy that did is no longer available so I'm trying to retrace his steps. I don't know why he built a kernel, it's just part of the instructions he left behind. Technically I may be able to apt-get, fetch headers, and call it a day. May 27 13:50:03 I know we have a custom dtb & LKM; he did the former and I did the latter. May 27 13:50:57 I'm currently trying to get the LKM to build b/c that's the part I'm most familiar with. May 27 13:51:35 I've never tried building a custom KM out-of-tree, I've only ever made one in-tree as a custom patch May 27 13:51:47 and we use a completely separate repo for dtbs May 27 13:52:30 Ah. I didn't know enough to do a patch when I did it, it's a stand-alone thing that's built as part of the normal firmware construction. May 27 13:52:59 I don't know enough to make one out-of-tree, hah May 27 13:53:23 it's probably pretty trivial, just never looked into it May 27 13:53:31 It's not hard. The most complicated thing is getting the right headers and pointing at them. May 27 13:54:00 right, which is non-issue when building in-tree May 27 13:54:15 this is the driver I created: https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.14/patches/local/0015-clocksource-add-timer-ti-ecap-driver.patch May 27 13:54:22 I should try to get it upstream actually May 27 13:55:01 hopefully get some feedback about whether this is the right way to make a platform clocksource driver, since some parts of that seemed really unclear to me (and seriously every single driver in that directory seemed to do things differently) May 27 13:55:01 That may be why he built the kernel at all. It was the simplest and most repeatable way to get those headers. I understand about in-tree, and in a perfect world I'd probably go that route, but now I have headers again. (shrug) May 27 13:55:42 for out-of-tree I'd probably look into dkms May 27 13:56:42 to avoid having to manually recompile it after installing a new kernel May 27 13:56:53 to build oot modules, I generally use "make M=/path/to/module" from the main kernel tree May 27 13:57:07 that sounds convenient too May 27 13:57:38 though not as convenient as keeping it in-tree, especially since I already had a bunch of kernel patches anyway May 27 13:58:17 if it's my own code, I keep in-tree May 27 14:00:16 Yeah. Rebuild isn't the funnest, but this is the first time the kernel has been changed in some time. (shrug) May 27 14:06:48 hmm, interesting git commit message... "Add bothersome-borer and confounding-cockroach" May 27 14:11:05 where? May 27 14:11:22 kernel.org website May 27 14:13:16 who wrote it? May 27 14:14:09 https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=484d08a943c6213cf537edc1130ee0d4e8aad3af May 27 14:18:36 oh, that guy May 27 14:40:59 ok, that node red stuff is not so complicated, but whoever thought javascript was a good idea... May 27 14:54:11 javascript is... I mean, especially with the modern stuff it could be decent, if it weren't burdened by some really awful decisions early on (like strings being random-access sequence containers of utf-16 codeunits) May 27 14:54:38 and equality tests doubling as random-number generator May 27 14:55:10 quick, does an empty array compare not-equal to 'undefined'? May 27 14:55:42 who cares, use === and !== May 27 14:55:57 and yeah I think they do compare as not-equal May 27 14:56:07 yes, probably May 27 14:56:16 actually I'm 100% sure May 27 14:56:38 the only things that are == undefined or == null are null and undefined May 27 14:56:56 it's empty arrays and empty strings in bool contexts that get weird quickly May 27 14:57:15 or something May 27 14:57:26 empty string is falsy, empty array is truthy May 27 14:57:33 any object is truthy May 27 14:57:36 including arrays, empty or not May 27 14:57:45 there's a long list of surprising true/false things someone made May 27 14:58:11 I'm pretty sure the only things that are falsy are false, null, undefined, 0, and empty string May 27 14:58:56 the equality rules are not extremely complex, but they're weirder than they ought to be May 27 14:59:07 also addition May 27 14:59:17 there are just too many things that do something you wouldn't expect May 27 14:59:25 https://blog.kevinchisholm.com/javascript/javascript-wat/ May 27 15:01:12 + converts both sides to primitive, adds them if both are numbers, otherwise stringifies and concatenates them May 27 15:01:42 whatever the explanation, it's infuriating May 27 15:01:54 I mean, it's not that weird May 27 15:02:38 I have never been surprised by the behaviour of a simple operator in C May 27 15:03:24 I have May 27 15:03:48 plenty May 27 15:04:23 surprise is a matter of being used to certaiin behaviour May 27 15:04:57 some of the stuff on the page you linked to is also wrong May 27 15:05:34 in my opinion, most of things should have been a syntax error May 27 15:05:46 they can't possibly be a syntax error May 27 15:05:46 *those things May 27 15:05:49 TypeError at runtime, perhaps May 27 15:06:10 in that case javascript is an error May 27 15:06:11 but javascript isn't in the habit of throwing TypeErrors May 27 15:06:22 no, it's just a different philosophy May 27 15:07:18 perl is the same way, except it has separate operators for addition (+) and string concatenation (.) so you're still never surprised by what the operator does May 27 15:08:14 that tiny change makes a huge difference May 27 15:08:22 but sure, perl is plenty weird too May 27 15:08:25 absolutely. I fully agree that was javascript does, having both implicit string<->number conversion _and_ having operator overloading on strings vs numbers is a bad idea May 27 15:08:41 but perl at least has the decency to make a lot of mistakes blow up while parsing May 27 15:09:06 well, with use strict on May 27 15:09:28 well javascript (with 'use strict'; of course) is still way better at that than python at least May 27 15:09:45 oh, I'm no fan of python either May 27 15:10:50 I really hate python's implicit variable scoping May 27 15:11:04 yeah, that's one of the worst parts May 27 15:11:35 another is the complete lack of checking of anything at all May 27 15:11:52 misspell an "attribute"? fine, we'll just make a new one May 27 15:11:53 python's semantics are also extremely obtuse. like, I doubt many python programmers can describe what happens when you write "foo.bar" with any significant amount of detail May 27 15:18:37 in general, I dislike languages where almost anything you might write means _something_ May 27 15:19:18 agreed May 27 15:19:23 simple typos should, imo, be likely to cause an immediate error during compilation/parsing May 27 15:45:34 javascript with 'use strict'; does that to the extent that can be expected from a dynamically typed language May 27 15:45:41 and if you want more, there's TypeScript May 27 16:05:17 TS is an improvement but it's not all that, particularly when one is debugging it. Some daze I wished I'd just written it in JS where I know the warts instead of some automagic introducing new ones. May 27 16:39:01 someone say servo cape? https://github.com/jadonk/beagle-tester/blob/ea2f1b2ab21ed73da70a9c6c7325cf50a526d3e6/beagle-tester.c#L4156 May 27 16:39:54 howdy mru. nice to see you trollin’ these parts. May 27 16:41:07 hi jkridner[m] May 27 16:41:12 mru: where do you eat these days since the pubs are closed? May 27 16:41:35 the pub next-door does take-away food May 27 16:41:44 as does the pizza place a block away May 27 16:41:51 zmatt, er, perl? ;-) May 27 16:42:25 and take-away beer? May 27 16:42:41 actually, yes May 27 16:42:53 but you can buy that in any store too May 27 16:48:19 Some states do drive-through liquor. I always thought that was a bit questionable. May 27 16:49:29 the US has an unhealthy relationship with driving May 27 16:49:46 lol May 27 16:50:01 and for the land of the free, it sure has a lot of weird regulations May 27 16:50:33 We have an unhealthy relationship with a lot of things, including weird regulations. (pout) May 27 16:51:55 The regulations wouldn't be so bad if the unhealthy relationships weren't so high. Regulations are the result of people being nasty or doing things without thought. May 27 16:52:21 regulations are the result of blaming the wrong thing for people's bad behaviour May 27 16:52:51 people don't drink and drive because it's legal to have alcohol in a car, they do it because they're idiots May 27 16:52:59 and they'll keep doing it after you ban alcohol in cars May 27 16:52:59 I'm with mru. Or trying to control what's perceived as bad behaviour instead of figuring out how to work with it. May 27 16:54:10 In CA any bottle of alcohol that's open in a car is an infraction However it's the only state I was in that you go into a drug store and most of the people in line are buying alcohol. May 27 16:55:12 I was one in 10 people ... everyone else had alcohol and I was getting something medically necessary. ... it was a very strange moment. May 27 16:55:27 So i got an update from the vendor May 27 16:55:32 :D May 27 16:55:43 and he gave me a camera shot of what he was using to communicate with the device May 27 16:55:43 https://www.icpdas-usa.com/i_7520.html May 27 16:56:04 Most states open bottles are an infraction. Sales options are per-state, some won't allow any sales outside designated state-run stores. VA was like that for a while. May 27 16:56:05 I can't think of any places here that do both prescription drugs and booze May 27 16:56:12 if they do, it'll be separate queues May 27 16:56:23 i have never seen one of these and it is not what is referenced in the manual. May 27 16:56:32 how is this thing different from an RS232 cord May 27 16:57:01 it's isolated. May 27 16:57:16 here is the specific model May 27 16:57:17 https://ibb.co/VMFhnZ5 May 27 16:58:20 it's also RS485 not RS232 May 27 16:58:24 Cord may be TTL? Lots of "RS232" dingus are actually TTL. May 27 16:58:48 I was hoping MattB0ne was referencing the RS232 side. (grin) May 27 16:58:48 i bought from best buy May 27 16:59:12 and these days TTL rarely means actual TTL May 27 16:59:19 (nods) May 27 17:00:39 yes well TTL acronym has been abused by idiots who drink and drive, I mean sales people. May 27 17:01:01 this is what I have May 27 17:01:02 https://www.bestbuy.com/site/insignia-1-3-usb-to-rs-232-db9-pda-serial-adapter-cable-black/5883029.p?skuId=5883029 May 27 17:01:33 so I am just losing isolation ? between the two May 27 17:01:39 that is 100 bucks of value May 27 17:01:50 the adapter he showing retails for 100+ May 27 17:01:56 Depends. If the other guy is using the other dingus, you have RS485 in there somewhere. May 27 17:02:22 whats a dingus? May 27 17:02:25 lol May 27 17:02:50 well there is the google defintion May 27 17:02:56 Sorry. Generic word for a thing, like a dongle only more generic. May 27 17:03:08 ok May 27 17:03:17 May not be in a dictionary. I haven't looked. May 27 17:03:23 so let me be clear on how I am using this cord May 27 17:03:29 google had it May 27 17:03:38 Ooo. I'll go look. May 27 17:03:42 I am taking my RS232 and using jumper cables May 27 17:03:56 I am connecting to pins 2,3 and 5 May 27 17:04:05 using a female to male jumpers calbes May 27 17:05:14 i plug the female into male pins and male pins into the board. May 27 17:05:18 that should work right? May 27 17:11:10 Might be simplest to have a schematic at this point. Trying to describe connections never works. If peeps don't want that sort of thing here there are other places to ask this same thing. May 27 17:15:59 ok I will sketch something May 27 17:19:54 https://ibb.co/1ZJbHrx May 27 17:20:11 https://ibb.co/68vf15T May 27 17:20:22 https://ibb.co/k1hWftV May 27 17:32:28 Seems plausible long as the levels are right. Do you have an o'scope or a bus pirate? Or if you know it's TTL a logic analyzer should work as well. I generally like to look at things to see they're doing something. May 27 17:38:28 Also your "specific model" image above does not match the wire picture. Fortunately the wire one seems well-labelled enough. If this module needs something config-y to make it use Txd/Rxd you may have problems. May 27 17:40:37 might be good to get a scope handy and look at the signals just to be sure. May 27 17:45:49 MattB0ne: you've connected TxD to TxD and RxD and RxD May 27 17:46:00 instead of cross-connecting them like https://ibb.co/1ZJbHrx shows May 27 17:48:21 (your white wire is connected to TxD on both sides, your yellow wire is connected to RxD on both sides) May 27 17:50:44 this has nice images: http://www.ethernut.de/en/documents/rs232primer.html May 27 17:53:04 Ragnorok: 'Lots of "RS232" dingus are actually TTL' ... I'd hope not, since they're absolutely incompatible... even ignoring the voltage range, they are inverted May 27 17:53:37 I'd certainly be surprised to encounter an USB-to-rs232 "cable" (with male DE-9 connector at the end) that's not actually RS232 May 27 17:53:41 proper rs232 is ±15 V May 27 17:54:36 well, ±3V at minimum May 27 17:54:44 most of those usb adapters with bare wires are 0/3.3 V May 27 17:54:59 I don't think I've ever come across one with actual TTL levels May 27 17:55:13 sure, but we're talking about something with a DE-9 connector here: https://ibb.co/68vf15T May 27 17:55:23 yes, 5 V variants do exist, but I've never needed one May 27 17:55:49 we're not talking low-voltage ("TTL") serial here but proper RS232 May 27 17:56:14 yeah, anything with that connector should be "real" rs232 May 27 17:56:36 the device is RS232, he's testing with an usb-to-rs232 converter, and to hook it up to the beaglebone he has a max3232 breakout May 27 17:57:41 but like I said, he wired it up incorrectly May 27 17:59:30 I've never seen one w/ actual TTL or proper differential levels, but I don't have lots of xp with them. May 27 17:59:45 RS232 is never differential May 27 17:59:48 I was sure I'd seen them cross-connected, which is why I said it looks plausible. huh. May 27 17:59:56 diff is rs422 or rs485 May 27 18:00:26 I think of +/- V as differential. Perhaps that's incorrect. May 27 18:00:31 it is May 27 18:00:39 Okey doke. May 27 18:01:04 the proper term would be NRZ (non-return-to-zero) May 27 18:02:00 but differential signals can be NRZ too May 27 18:02:36 they usually are May 27 18:02:54 yes, that's sort of the point of it May 27 18:04:00 I mean, there's no theoretical obstacle to return to zero, but it would be a weird thing to do May 27 18:04:06 and complicate the receiver design May 27 18:04:28 it would defeat the purpose of using differential in the first place May 27 18:04:33 it wouldn't May 27 18:05:03 you'd still reject all common-mode noise May 27 18:05:06 true May 27 18:06:49 so I checked again May 27 18:07:41 my yellow wire is my Rx on the RS232 May 27 18:07:51 pin 2 on the male end of the RS232 May 27 18:07:58 mru: high-speed CAN uses return-to-zero differential signalling: https://en.wikipedia.org/wiki/File:ISO11898-2.svg May 27 18:08:08 i have that yellow wire going to the Tx on the adapter board May 27 18:08:34 that is what it is supposed to be May 27 18:08:36 crossed up May 27 18:08:41 Rx to Tx and vise versa May 27 18:09:17 MattB0ne: "adapter board" ? I didn't read what you said in detail, I assumed the three images you linked described your setup: PC (using usb-rs232 cable) to EM-100 May 27 18:10:06 https://ibb.co/68vf15T shows yellow = RxD, white = TxD May 27 18:10:14 https://ibb.co/k1hWftV shows yellow = RxD, white = TxD May 27 18:10:17 zmatt: just goes to show that anything that can exist does exist May 27 18:11:27 i agree with your first one May 27 18:11:40 i think the yellow is going to Tx on the second image May 27 18:11:42 mru: they do it to basically make the bus behave like a differential equivalent to an open-drain bus to allow arbitration between multiple transmitters (similar to how i2c does it) May 27 18:12:07 that works, I guess May 27 18:12:27 then again, rs485 also allows multiple drivers on the bus May 27 18:12:41 mru: not simultaneously I think? May 27 18:12:58 what would you expect to read if one drives it logic-low and one drives it logic-high May 27 18:13:02 MattB0ne: the manual disagrees May 27 18:13:15 nothing meaningful, that's for sure May 27 18:14:03 at least where I've seen it, rs485 tends to be used with one master and multiple slaves that only respond when spoken to May 27 18:14:11 mru: right, in this case one state is "dominant" and the other (differential zero) is "recessive", with the dominant state overriding the recessive state May 27 18:15:00 if a transmitter is trying to signal recessive but detects the dominant state (driven by someone else), it has lost arbitration and ceases to transmit May 27 18:15:00 another shot at it May 27 18:15:01 https://ibb.co/k1pPKTS May 27 18:16:36 What's the difference between Gnd & GndC? May 27 18:18:23 i assumed it was ground control May 27 18:18:28 for comms May 27 18:18:33 but I know nothing May 27 18:19:04 yeah, it needs to be connected to major tom May 27 18:19:18 lol Too slow, eye. May 27 18:21:09 MattB0ne: https://i.imgur.com/CyPWyNI.jpg May 27 18:21:17 maybe the manual is wrong May 27 18:22:52 fortunately RS-232 is designed to tolerate short-circuits so you can just try it either way May 27 18:23:47 it's rude to design external interfaces that can't tolerate incorrect connections May 27 18:26:04 unfortunately neither the datasheet nor the manual seems to have any substantial electrical specs such as absolute maximum ratings May 27 18:27:09 MattB0ne: you could also check the adapter board with a multimeter May 27 18:28:37 but yeah, for serious hardware like this I'd certainly expect some decent protection on I/O May 27 18:32:42 MattB0ne: you could also measure the voltage on the pins on the EM100 (relative to signal ground)... if one of them is negative, then that's RxD May 27 18:32:51 but there's a chance both of them will measure positive May 27 18:38:29 a so-called false positive May 27 18:39:06 son of a gun May 27 18:39:11 the schematic is wrong May 27 18:39:21 switched it and now it works May 27 18:39:28 grrrrrr May 27 18:42:31 Mattb0ne: it means the documentation was right however ;) May 27 18:44:39 mru: but yeah... my dad designed industrial hardware for a long time, so even when he designed some non-industrial hw later on, I remember external I/O always looking something like this: https://i.imgur.com/x601G7n.png May 27 18:45:44 overvoltage protection, rc filter, series resistance on driver, ... also a lot of testpoints I just noticed May 27 18:46:38 what would you trust more in a life or death situation though May 27 18:46:48 the manual or what is says on the device. May 27 18:47:00 anyways thanks for the help everyone May 27 18:47:04 as always May 27 18:47:05 Mattb0ne: the manual, since it can be updated to include corrections far more easily than the silkscreen May 27 18:47:37 does this sort of thing happen alot? May 27 18:47:42 mistakes happen May 27 18:47:55 silk screen means labeling on PCB May 27 18:48:01 but they should have included a very clear warning about this in the documentation May 27 18:48:14 I'm not impressed by this manufacturer's documentation May 27 18:49:13 well i guess it is helping cutting my teeth on it May 27 18:49:27 they have other typos too in the firmware etc... May 27 18:49:38 the price was right May 27 18:49:51 though which has a habit of biting me in the ass May 27 18:49:54 yeah the text/graphics printed on the PCB is referred to as silkscreen... regardless of whether it was applied using screen printing (and regardless of the fact that that screen sure as hell isn't made of silk anymore) May 27 18:50:39 going to get lunch and now go through the beagle and the MAX3232 but I feel good about it now May 27 18:51:49 Mattb0ne: I do suggest complaining about this to the manufacturer... mistakes happen, but they should include a large warning about this in the documentation and honestly probably also on a small errata sheet included with the device May 27 18:52:27 will do May 27 18:53:27 it's understandable to make mistakes, it's not okay to cause the customer to waste their time debugging those mistakes once they're already known (which I assume they are given that the docs list them correctly) May 27 18:59:19 like if you did not catch it May 27 18:59:24 I would never of changed it May 27 18:59:43 I need to take manuals more seriously though May 27 19:00:10 I find the less expensive something is, the more likely this sort of thing crops up. May 27 19:00:12 at the very least, the presence of the contradiction between manual and silkscreen means you have a lead to investigate May 27 19:00:24 right May 27 19:00:40 i am a shoe string budget May 27 19:00:47 on a* May 27 19:00:58 but what you say makes sense May 27 19:01:01 Got it. So you trade time for money. (shrug) Been there, done that. May 27 19:01:26 in general, when solving a problem, you shoudl definitely examine the information available and if there's inconsistency in the information at your disposal, investigate to determine the truth May 27 19:01:37 I was pretty proud of myself for doing all the loopback testing May 27 19:01:42 :) May 27 19:01:54 through the steep knowledge gradient I am picking some stuff up May 27 19:01:56 it's useful to learn to be methodical May 27 19:02:20 try to debug small chunks individually instead of wondering why the completed setup (with many unknowns / untested parts) doesn't work May 27 19:02:30 right May 27 19:02:52 I also need to get better handle on schematics May 27 19:03:09 some of the convo in this channel, pull ups pull down etc... May 27 19:03:16 is like a plane over my head May 27 19:03:27 like how you can see a problem spot from a schematic May 27 19:04:01 i guess will come with time. Like how you said my LCD cape was weird May 27 19:04:05 That's just experience. May 27 19:04:21 You know, that thing you have right after you need it. May 27 19:05:00 a pull-up/down just means a (medium to large value, typ 1K or more) resistor connecting the net to the logic supply (for a pull-up) or to ground (for a pull-down) May 27 19:06:19 It pulls the line it's connected to in that direction instead of "floating". Floating is often a Bad Thing! (tm) May 27 19:06:21 to ensure that if nothing is driving the net (e.g. because it's an external input and nothing is connected) it still has some well-defined value (logic-high if pulled up, logic-low if pulled down) May 27 19:11:04 i will get there May 27 19:11:15 i have a lot of projects lines up May 27 19:11:19 lined up May 27 19:11:48 just prepare yourself for more shenanigan and questions May 27 19:27:49 just try to improve your methods of analysis along the way... e.g., you could have found this miswiring yourself if you had checked the documentation more closely, there's a lesson in that ;) May 27 19:31:03 yup May 27 19:31:06 you are right May 27 20:57:56 zmatt have you ever used 4D systems LCD cape with BeagleBone Black? 4.3" or any other variant? May 27 21:01:03 Can you help me figure out if `BB-VIEW-LCD4-01-00A0.dts` DT overlay will work with 4D systems 4.3" cape https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-VIEW-LCD4-01-00A0.dts May 27 21:03:52 lorforlinux: why are you asking me specifically instead of just asking the channel? May 27 21:06:18 If anybody have ever used 4D systems LCD cape with BeagleBone Black, please let me know what Device Tree Overlay you used I am unable to find any valuable info reagarding that. May 27 21:06:18 if it's a proper beaglebone cape its embedded eeprom should identify the correct overlay and it should get automatically loaded May 27 21:08:09 I want create a new DT overlay for new BBAI board which does not support that functionality (i think) May 27 21:09:32 "22:57 < lorforlinux> zmatt have you ever used 4D systems LCD cape with BeagleBone Black?" May 27 21:09:36 you said beaglebone black, not BBAI May 27 21:09:45 BBAI doesn't support overlays at all yet May 27 21:10:55 I supports UBoot overlays right? I wanted to know which of the LCD overlay was used for that Cape so that I can write a similar one for BBAI. May 27 21:11:16 I don't think the bbai u-boot has support for overlays yet no, unless that's changed since I last checked May 27 21:13:42 Nope, I have not used 4D systems LCD cape with BeagleBone Black yet, Albeit that should be the right way to know what DT overlay is required. Thank you will try that. May 27 21:14:49 https://github.com/hendersa/bes-dtb-rebuilder/tree/master/src/arm google found some old (non-overlay) DT files here for the 4dcape-43 and others May 27 21:15:22 * mru finds it odd when people talk about hardware "supporting" things that are purely software features May 27 21:15:38 mru: it's clear what they mean May 27 21:16:11 the BBAI, as a product including the recommend firmware image, does not support dt overlays May 27 21:16:22 * mru also finds it odd when people talk about "the u-boot" for some piece of hardware May 27 21:16:46 again it's clear what's meant: the specific u-boot build that's on the recommended/default firmware images for the bbai May 27 21:16:51 * mru does not run stock images May 27 21:17:13 As there is no dynamic Pinmuxing possible on BBAI we have to assign the pin mode during boot time and UBoot overlays are the way to do that right? May 27 21:17:18 mru: but you'd also ask different questions May 27 21:17:27 I understand what's meant May 27 21:17:39 I still cringe a little May 27 21:18:05 mru: I'd all for being precise when needed, but in this case it'd just be more verbose without adding much May 27 21:18:21 fine May 27 21:20:00 mru: there's a difference between saying the technically correct thing and saying the useful answer for the person asking the question... it's taken time and effort for me to actually do the second rather than the first, which is more my natural default ;) May 27 21:20:28 lorforlinux: glitch-free pin configuration can currently only be done during early-uboot May 27 21:20:29 overlays written for LCD7 -> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_BB-BONE-LCD7-01-00A2.dts & https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_BB-BONE-LCD7-01-00A3.dts May 27 21:21:00 lorforlinux: overlays are simply a way to modularize the Device Tree that u-boot passes to the kernel May 27 21:21:04 don't take everything I say as criticism May 27 21:21:12 mru: I didn't May 27 21:21:30 I might have done the same May 27 21:21:36 while muttering to myself May 27 21:21:37 lorforlinux: I would not say not possible May 27 21:22:12 lorforlinux: pinmux in DT, whether declared in the main dtb or in an overlay, is equivalent to runtime pinmux May 27 21:22:14 from the hints I been hearing - prehaps - suspend, self refresh DDR, remux, resume might work May 27 21:23:18 ds2: yeah that's what I still want to test... have u-boot reenter I/O isolation to perform final muxing of pins based on configuration (perhaps extracted from DT+overlays) May 27 21:23:40 zmatt: is it easier to do in U-boot? May 27 21:23:56 someone at TI seems to think it should work: https://e2e.ti.com/support/processors/f/791/p/855335/3164951 but he said "I have to double check" but he never followed up :P May 27 21:24:05 zmatt: IIRC - Linux had a working self refresh suspend mode May 27 21:24:06 How do i perform the glitch-free pin configuration during early-uboot, can please you provide some pointers on this? May 27 21:24:29 lorforlinux: doing it in SPL should be safe May 27 21:24:33 lorforlinux: I'd first check whether the cape is compatible at all May 27 21:24:45 and figure out the pinmux to use May 27 21:25:24 you may be able to get away with just using DT anyway, it depends on whether the risk of glitches (of "up to several nanoseconds" iirc) during I/O reconfiguration is a problem May 27 21:27:09 Okay I need to do some testing then. May 27 21:27:28 you'll need proper DT for everything other than pinmux anyway May 27 21:27:43 DT is just a big fungus growing on Linux :( May 27 21:28:02 still better than what came before it May 27 21:28:37 mru: ds2 is a board file fan ;) May 27 21:28:51 oh, I know May 27 21:29:16 ds2: I started liking DT :( May 27 21:29:20 lorforlinux: otherwise, board/ti/am57xx/mux_data.h is where u-boot's pinmux is defined May 27 21:29:32 I'm fine with DT May 27 21:29:42 dt in u-boot is a bit messy May 27 21:29:44 and pointless May 27 21:29:47 I agree May 27 21:29:59 u-boot is a bloated mess anyway May 27 21:30:13 tell that to my boss May 27 21:30:15 zmatt: checking it now. May 27 21:30:49 his name is wolfgang May 27 21:32:19 ds2: anyway, if what JJD said is true (in my E2E thread I just linked), it isn't even necessary to put DDR3 into self-refresh May 27 21:34:42 zmatt: did you ever get any clues on how often/big the glitches are? May 27 21:35:28 is this some accidental feature of the chip? May 27 21:37:29 it shouldn't be too hard to verify whether it's true... hook bbx15 up to jtag, halt in u-boot, enable I/O isolation, and see if ddr3 is still accessible May 27 21:37:35 mru: what? May 27 21:37:41 glitching May 27 21:38:04 ds2: nope, I have no mental model of the problem yet. jkridner[m] was trying to get more into available but dunno if he's made any progress with that May 27 21:38:38 maybe someone is embarrassed they forgot to add a flipflop May 27 21:38:40 ;) May 27 21:38:56 mru: it's almost certainly a side-effect of having programmable delay lines on all I/Os May 27 21:39:31 that's also why the glitches can have "substantial" length (assuming you consider a few nanoseconds to be substantial) May 27 21:40:23 a few nanoseconds is upwards of a metre May 27 21:40:25 my guess for why changing mux mode is also a problem is that I think by default the iodelay is configured based on mux mode from internal tables May 27 21:41:03 if that's the case, I wonder if just forcing manual iodelay (set to 0) is a solution for programmable I/O pins that don't need extremely precise timing May 27 21:41:09 I'm getting the impression that configuring one pin makes other pins glitch May 27 21:41:17 I'm pretty sure that's not the case May 27 21:41:24 then what's the problem? May 27 21:41:25 afaik only the pin being reconfigured is affected May 27 21:42:21 then how does DDR come into play? May 27 21:42:27 and that May 27 21:43:01 if the function is reconfigured, it presumably wasn't working before May 27 21:43:49 ds2: my assumption was that I/O isolation applies to all non-jtag I/O, including DDR pins.. that's what the TRM implies, but I'm pretty sure those parts have been copied verbatim from omap4/5 where I/O isolation existed for a completely different reason, so like I said in the E2E thread, that might just be a red herring May 27 21:44:23 so if the TI guy is right, DDR3 pins aren't affected by I/O isolation, then there's no problem entering I/O isolation in the full u-boot (which runs from ddr3 memory) May 27 21:44:24 zmatt: wonder if a more accurate statement is - any muxable pins May 27 21:44:40 AFAIK, the DDR pins can't be muxed May 27 21:45:05 never seen a chip where they could May 27 21:46:24 well the thing is, my suspicion is that I/O isolation has simply been inherited from omap4/5 where it *did* affect emif pins, however a lot has changed and am572x has a different ddr phy, so it could go either way May 27 21:46:45 does TI at least own this new PHY? May 27 21:46:59 i.e. the ability to use it to avoid the iodelay issue is just fortuitous May 27 21:47:01 has it ever not? May 27 21:47:14 they seem to have an aweful lot of them May 27 21:47:33 maybe they are going the USB route and ordered one from the bug free and prefect Mentor IP library :D May 27 21:47:58 aaaaargh May 27 21:48:04 not really, just many generations and variations of the same one I feel like... well, there's two: the old SDRC one and the newer one used with EMIF, but I'd assume they're probably related too May 27 21:49:10 actually it might not be, it could be that SDRC came from the original omap heritage while EMIF I think comes from TI's DSPs May 27 21:49:47 not 100% about all this, it's been a while since I've done archeology on TI's SoC ;) May 27 21:51:31 I suspect TI has a huge pile of random silicon blocks May 27 21:52:08 every time they want to make a new chip, they give the pile a good stir, then put as many shovelfuls as will fit into the new design May 27 21:52:25 https://pastebin.com/n4MmWEPc some notes I had about emif4 instances May 27 21:53:11 I've also seen the phy improve over time... I think hardware leveling actually works nowadays? ;-) May 27 22:00:45 does VTT really work now? May 27 22:05:09 zmatt: does your pinmux chart page cover the pocketbeagle and if so, got the URL handy? May 27 22:11:14 ds2: https://goo.gl/Jkcg0w there are two tabs (after the BBBlue): "Pocket" and "Pocket brief", the latter being more useful probably May 27 22:11:50 thanks May 27 22:12:02 what do you mean by "does VTT really work now" ? May 27 22:14:42 EMIF on at least one of the chips had a very annoying errata on VTT May 27 22:14:50 AM35x I think May 27 22:15:32 nifty.. the PocketBeagle has the right pins for screwing with audio May 27 22:16:01 what does EMIF have to do with VTT ? May 27 22:16:30 VTT is the termination voltage (supply/regulator), which is external to the SoC May 27 22:16:43 hmmm? VTT as in a the automatic temperate compenstion May 27 22:16:58 oh VTP May 27 22:17:12 yes VTP... bad typo. Sorry. May 27 22:17:30 or bad memory actually ;) May 27 22:18:25 did your creator not provide an errata sheet? May 27 22:18:59 yes, that's I got to it May 27 22:19:01 I don't immediately remember anything about a VTP issue, but it might just be too long ago May 27 22:19:20 original thing was based on the OMAP3 but it was decided to go with a AM35 instead May 27 22:19:41 so all of a sudden, EMIF appears instead of SDRC May 27 22:19:59 I find DT a rather practical approach. It might not be very well defined, but it's at least pragmatic with little bloat. May 27 22:20:07 at one point the thought was the AM35 was a fused out O3 May 27 22:23:06 which of the many arguments for DT actually held up in practice? May 27 22:23:42 Sharing code between all the ARM SOCs? Not there. Probally never will be. Avid having 12492134023409318490328409328409328409328 files? well, we have that many if not more DT's May 27 22:25:04 all it has done is introduce yet another binary blob May 27 22:28:49 I rather like that I can just plug in a sub-node somewhere to instantiate a driver for some i2c device May 27 22:29:02 or reconfigure a clock May 27 22:29:09 or clock tree May 27 22:29:18 without having to recompile the kernel May 27 22:29:35 how is that different from recompiling the DT? May 27 22:29:57 being able to instantiate a driver for some I2C device has always been possible before there was DT on ARM May 27 22:30:22 claim's not voided by picking a bad example... May 27 22:30:45 a lot of subsystems allow that May 27 22:31:23 it separates configuration from code. that's a benefit. May 27 22:32:01 that so call benefit is a monkey wrench in the works for debugging May 27 22:32:17 if all you have is an Oops and the kernel sources, you are somewhat screwed May 27 22:33:11 ds2: "being able to instantiate a driver for some I2C device has always been possible" .. you mean at runtime? ew :P May 27 22:33:19 and that won't work if that i2c device has an irq line May 27 22:33:36 and recompiling a dt is 0.1 second May 27 22:34:09 admittedly, you can screw up a device with a bug in the DT just as well as with a bug in a kernel driver ;) May 27 22:34:17 ds2: and AM35xx was wonky yeah, omap3 with various stuff patched into it like ethernet and EMIF May 27 22:34:33 thinkfat_: usually it'll just fail to probe though :P May 27 22:35:07 zmatt: you remember when I mistakenly changed the pinmux of of one of the mmc lines ;) May 27 22:35:23 I have a rather bizarre am35xx problem here May 27 22:35:45 omap3 was wonky enough by itself May 27 22:35:47 once in a while, a kernel mutex just doesn't unlock May 27 22:36:01 and then anything that tries to lock it hangs forever May 27 22:36:02 but nothing compared to omap4 May 27 22:36:18 of course it goes away if lock debugging is enabled May 27 22:36:35 race, race... May 27 22:36:49 it's random mutexes all over the kernel May 27 22:37:01 happens very rarely May 27 22:37:16 but when you have thousands of devices running... May 27 22:37:42 anyway, I'm racing to get some sleep now. May 27 22:38:12 zmatt: yes, at run time May 27 22:38:39 mru: what version? May 27 22:38:55 version of what? May 27 22:41:23 kernel May 27 22:41:30 with the mutex issue May 27 22:41:49 everything we've tried May 27 22:41:53 going back to 3.7 May 27 22:42:16 with or w/o PREEMPT_RT? May 27 22:44:06 without for sure, don't remember if we tried with it on May 27 22:44:39 sometimes PREEMPT_RT fails earlier/more predictably May 27 22:45:36 but why would a mutex just fail to unlock? May 27 22:46:10 either because of a locking bug (failing to unlock), or because the thread holding the mutex is stuck May 27 22:46:24 you misunderstand May 27 22:46:29 I just saw May 27 22:46:31 "random mutexes" May 27 22:46:31 mutex_unlock() doesn't actually unlock it May 27 22:46:32 wtf May 27 22:46:53 exactly May 27 22:47:57 am35xx you say? hmm, so an old cortex-a8 too (r1p7) May 27 22:48:36 yeah May 27 22:48:38 you've checked the SoC errata for anything that sounds like fun I assume? May 27 22:49:36 checked, but could have missed something of course May 27 22:52:17 enabling CONFIG_DEBUG_LOCK_ALLOC makes it go away May 27 22:53:59 CONFIG_DEBUG_LOCK_ALLOC causes the fast-path in mutex_unlock to be bypassed May 27 22:54:12 yep, that's what does the trick May 27 22:54:45 semaphores are affected too May 27 22:55:38 I don't see how that fast-path code can be broken though May 27 22:55:50 i'd say first make it reproducible.. e.g. see if you can make a kernel module that spawns two kernel threads that do nothing but lock and unlock a single shared mutex May 27 22:56:17 don't you think I've tried such things? May 27 22:56:26 that doesn't reproduce it? May 27 22:56:27 ooof May 27 22:56:29 it's almost impossible to trigger it May 27 22:57:30 is this the only weird issue you occasionally see? May 27 22:57:34 running normally, it can take weeks on thousands of devices to find it once May 27 22:58:08 ooof May 27 22:59:03 with the workaround in place, everything is solid May 27 22:59:08 what workaround? May 27 22:59:21 CONFIG_DEBUG_LOCK_ALLOC May 27 22:59:49 the rareness is extremely annoying, it means you can't really test various things to see if they help May 27 23:00:13 a very long time ago, someone left a bunch of debugging option turned on May 27 23:00:23 much later, I got involved May 27 23:01:17 how did you even discover that it's a mutex failing to be unlocked? May 27 23:01:24 that seems like a very specific observation May 27 23:01:47 random processes hang trying to lock the mutex May 27 23:02:46 the various hangcheck timers helpfully give stack traces of that May 27 23:03:54 and the owner of the mutex at such time is some random task that's happily running? May 27 23:04:09 there supposedly is no owner May 27 23:04:16 it's just locked May 27 23:05:07 bypassing the fast-path in mutex_unlock and making no other change fixes it May 27 23:05:27 semaphores can still get stuck then though May 27 23:06:36 do you have CONFIG_DEBUG_MUTEXES enabled too? May 27 23:07:14 that isn't necessary to fix it May 27 23:07:39 no but it does perform sanity-checks on the mutexes hence would help catch corrupted mutexes May 27 23:07:56 oh, I've enabled every conceivable debugging option May 27 23:08:02 anyway, there's no such thing as "just locked" but "no owner" May 27 23:08:16 there shouldn't be May 27 23:08:58 there isn't: __mutex_trylock_fast is just a atomic_long_cmpxchg_acquire(&lock->owner, 0UL, curr) May 27 23:09:25 ok, it's a while since I looked at it May 27 23:10:03 __mutex_unlock_fast is likewise just atomic_long_cmpxchg_release(&lock->owner, curr, 0UL) May 27 23:11:54 maybe the problem has to do with wakeup? May 27 23:13:09 the system will be happily running, except for one task that's stuck at a mutex_lock(), the task that should have unlocked it being nowhere near it May 27 23:14:59 random memory corruption May 27 23:15:07 yeah I thought of that too May 27 23:15:11 that only affects mutexes? May 27 23:15:26 hence 00:57 <@zmatt> is this the only weird issue you occasionally see? May 27 23:15:45 as I said, everything is fine with the fast-path unlock gone May 27 23:15:56 my thought it something weird with load/store-exclusive May 27 23:16:09 that was my thought too May 27 23:16:30 can't find any errata that fit that May 27 23:16:54 though who knows what's lurking in cortex-a8 r1 May 27 23:18:38 no cortex-a8 errata seem to involve load/store exclusive May 27 23:19:43 doesn't mean there aren't any unknown errors May 27 23:19:56 true, but that seems less likely May 27 23:20:05 I did find a brand new one once May 27 23:20:24 arm seems to do a good job at finding errata... some of the errata listed have an extremely high "how the FUCK did you even discover this?" factor May 27 23:22:06 mru: I'm assuming you're not using an SMP kernel? May 27 23:22:15 indeed May 27 23:23:01 "01:05 < mru> bypassing the fast-path in mutex_unlock and making no other change fixes it" May 27 23:23:13 you mean with CONFIG_DEBUG_LOCK_ALLOC disabled? May 27 23:23:21 yes May 27 23:25:02 621766 is the one I found btw May 27 23:25:51 well, I triggered it May 27 23:26:09 someone else had to figure out wtf had happened May 27 23:27:07 hah May 27 23:27:43 that does sound like one that shouldn't be that hard to hit.. the preconditions sound like plenty of neon could would qualify May 27 23:28:03 yeah, but not stupid gcc-4 generated code May 27 23:29:36 so, have you been able to verify what the state of the mutex is (e.g. owner field) when this happens? May 27 23:30:38 as I said, it's a while since I looked at this May 27 23:30:45 I don't remember all the details May 27 23:31:01 there wasn't time to dig deeper May 27 23:31:06 and we had a workaround May 27 23:31:09 fair May 27 23:32:31 if you had a way to reproduce it within reasonable time then I could think of plenty of thinks that might be fruitful to test, but if you can't reaosnably test the impact of a change it's kinda hopeless May 27 23:33:18 or, if it were rare but affecting something focussed (like a specific mutex) then tracing using ETM could be useful May 27 23:34:08 I guess ETM could still be fruitful, I think it can trace memory accesses performed any time the cpu is executing from specific code regions (e.g. from mutex.c if you can ensure the code of that is all close together in memory) May 27 23:34:13 yeah, the difficulty in reproducing it makes it hard to get any information May 27 23:35:13 easy fix: design a new version of the product with a newer SoC ;-) May 27 23:35:22 already done May 27 23:35:25 :D May 27 23:35:36 but there are 20k of those things out there May 27 23:35:39 or more May 27 23:36:27 it was the replacement that had that dead emmc May 27 23:36:34 lorforlinux[m]: oh "nice", that cape has an expansion header that passes-through some P9/P8 pins that it doesn't use... but that includes the pins used by eMMC, so it's adding long stubs to those -.- May 27 23:36:42 won't be an issue for the BBAI of course May 27 23:38:11 I only mentioned it since someone was piling crap on the am35xx May 27 23:38:17 didn't expect anyone to have a solution May 27 23:38:26 heh May 27 23:38:37 never worked with the am35xx myself, or the omap3 for that matter May 27 23:39:30 I did a fair bit with the beagle in the early days May 27 23:42:08 I guess this is the most visually impressive: https://www.youtube.com/watch?v=EprL3PtqDoM May 27 23:42:31 nice May 27 23:43:25 I did the video playback software May 27 23:43:35 someone else built the display May 27 23:47:45 mru: I do wonder if making linux configure the memory to be "non-shareable" instead of "shareable" would have any impact on your mutex issue. iirc this would make the cortex-a8 use normal load/store on the AXI interface for ldrex/strex (while still using its local monitor for exclusion, which is all that matters) May 27 23:49:53 although the TRM says it translates exclusive accesses to non-exclusive ones in the axi2ocp bridge anyway May 27 23:50:19 oh well, I should focus on other things.. you nerd-sniped me :P May 28 00:26:45 only noticed on mutexes May 28 00:30:59 zmatt: In theory all the capes that were made for BBB should work for BBAI with proper configuration of course. Your `Subarctic 2.x pins` spread sheet is very helpful thanks for sharing it :) May 28 00:31:43 lorforlinux: that statement is definitely false May 28 00:32:41 ohh okay May 28 00:33:24 Is this due to the dynamic pinmuxing issue? May 28 00:33:43 no May 28 00:34:08 it's because the BBAI pins do not have the exact same set of functions as the BBB pins, nor could such a thing be reasonably expected May 28 00:34:23 they tried to allow for as much compatibility as possible, but there are limits May 28 00:34:52 for example LCD capes that use 24-color are not supported May 28 00:36:43 :0 I wasn't aware of that May 28 00:36:51 compatibility of mcasp interfaces is also very limited May 28 00:38:30 I should learn more about BBAI before saying anything absurd again :D May 28 00:38:31 the BBB has two mcasp instances (0 and 1), two IOsets for mcasp 0 (one on P9 and one on P8), and quite a bit of flexibility for mcasp 0: https://pastebin.com/raw/37Vr51Wr May 28 00:39:49 while the BBAI also has plenty of mcasp flexibility, most of that isn't pin-compatible with the BBB May 28 00:42:11 * lorforlinux's connection broke now i am lorforlinux3 :( May 28 00:43:36 zmatt: thank you for pointing that out :) May 28 00:47:09 zmatt Now, I am going to find all the buses and other peripheral compatibility between those two boards, your pointers are always helpful :) May 28 00:47:27 the resources exposed on the AI vs BBB are different May 28 00:47:36 you need to find the common set to identify workable capes May 28 00:48:22 that was a close one... @%##@$@#@# flex cable on the SSD popped out :( May 28 00:48:25 McASP intersection: https://pastebin.com/mH0mUL9W May 28 00:51:47 lorforlinux3: my Vayu pins spreadsheet (https://goo.gl/jiazTL) include some sheets that compare BBB and BBAI on a specific interface, specifically "LCDC vs DSS" and "BBB vs BBAI McASP". beware that my peripheral numbering may be off-by-one compared to some other places (e.g. the TRM and DT), see the README sheet May 28 00:52:36 (unlike my pretty polished pins spreadsheet for the BBB and variants, this one has a lot of rough edges and some sheets that are unfinished) May 28 00:55:26 So, BBAI only supports 16 bit displays. May 28 00:56:48 That spreadsheet is very helpful thanks for sharing, do you have any blob/page where you have listed all of your spreadsheets? May 28 01:00:31 I mean, I have lots of spreadsheets :P but as far as public spreadsheets of general utility goes, the single most important is my subarctic (am335x) pins spreadsheet https://goo.gl/Jkcg0w .. and if you're doing low-level stuff my subarctic IRQs https://goo.gl/7YooOO and centaurus/subarctic memory map https://goo.gl/UHF2Fy spreadsheets May 28 01:02:34 and perhaps the vayu pins spreadsheet I already linked, though like I said that one isn't of the same quality (in part because I haven't really done much with the bbx15/bbai (yet)) May 28 01:02:50 Yeah, I am only interested in the public spreadsheets ;) May 28 01:03:25 I mean, I have more that are technically public (in the sense that I've shared links in public places), but most aren't relevant for general audience May 28 01:05:34 vayu pins spreadsheets is very good for me, i appreciate your hard work. May 28 01:06:22 ah I have one more that has a short goo.gl link, but it's really only for people interested in doing kernel hacking or other low-level stuff, information about the subarctic (am335x) L3 interconnect: https://goo.gl/3cleN8 May 28 01:07:16 * lorforlinux3 creating a local file named valuable spreadsheets :) May 28 01:09:14 you can just do "add to my drive" if you have a google account May 28 01:09:51 (File -> Add a shortcut to Drive) May 28 01:11:26 done deal :D May 28 01:16:28 Hey! May 28 01:16:30 Nice. May 28 01:17:14 GenTooMan: I am still working on stopping video to process it in midstream and then save it to file and restart the same stream. May 28 01:18:54 I am going to try w/ moviepy next. May 28 01:25:13 so, i think i fried a pocketbeagle today... May 28 01:25:43 one brief flash of the blue PWR led ... and then nothing May 28 01:26:24 was trying to hook something up to a gpio and pwm ... but maybe lacking sufficient caution May 28 01:28:22 lorforlinux[m]: there, I made a public folder: https://drive.google.com/drive/folders/1-bjuF9U4FYU9KT7C7RFhAa8Ul8mAtJZU May 28 01:31:03 zmatt: thank you so much. BTW, what's vayu? May 28 01:31:09 am572x May 28 01:31:19 ohh May 28 01:31:43 or rather, various am57xx, dra7xx, and tda2xx parts May 28 01:32:26 Is that what TI call's them? May 28 01:32:40 since the same die ends up having a bunch of different part codes (with different efuse programming which determines which features are enabled) May 28 01:32:57 while completely different dies can end up with very similar partnumbers if marketing fancies it May 28 01:33:20 and that's why I prefer the codenames (whenever I happen to know them) over part numbers ;) May 28 01:35:26 OMAP36xx, DM37xx, and AM37xx are all the same die, while the AM35xx isn't the OMAP34xx nor even remotely related to the AM335x May 28 01:36:51 Ahh, I see. this file for dra7xx made things clear `ti/sysbios/family/c66/vayu/Power.h` May 28 01:38:25 basically "vayu", "am57xx", and "dra7xx" can be considered synonyms... more or less (I don't know if vayu is intended to refer only to the original am572x/dra75x/dra74x or the whole family) May 28 01:38:33 except the dra78x is a totally different SoC May 28 01:38:53 just to confuse the enemy May 28 01:39:09 zmatt: When i started working on BBAI I got confused about why we are using dra7 device tree, that was the first time I came to know about this one die different names thing. May 28 01:39:10 (it however is the same thing as the dm50x) May 28 01:39:30 not you made things more clearer :D May 28 01:40:19 who is the enemy here? May 28 01:40:53 lorforlinux: so in my own stuff I just stick to "vayu" and "subarctic" to refer to the SoCs regardless of what settings have been burned into efuse and what part number has been stamped onto it May 28 01:42:13 zmatt: Gotcha May 28 01:43:06 * now you made things more clear :D May 28 02:59:51 Dang. I found psychopy. Neat. Now, I can communicate to the psyche. **** ENDING LOGGING AT Thu May 28 03:00:05 2020