**** BEGIN LOGGING AT Mon Jun 22 02:59:57 2020 Jun 22 05:49:12 Hello all, Jun 22 05:50:41 can any one suggest me cable and antenna for BB AI ?1. UFL to SMA cable2. SMA antenna Jun 22 05:50:52 can any one suggest me cable and antenna for BB AI ?1. UFL to SMA cable2. SMA antenna Jun 22 05:52:39 we have close box we have to take place antenna outside of box so that's why we required this stuff Jun 22 05:57:17 I mean, just google "u.fl antenna" ? Jun 22 06:13:51 thanks for the detailed explanation. Will try a few things and will get back Jun 22 11:26:27 m Jun 22 12:07:01 m 2 u Jun 22 12:09:58 zmatt that's too obvious (humour) I've noticed that the proliferation of micro rf connectors has made a convoluted offering of antenna’s. SMA happens to be the most common (that might be robust) connector. Jun 22 12:28:00 I have piles of antennas and cables with various connectors, yet I never seem to have one with the type and gender I need at the momemnt Jun 22 15:15:29 Hi everyone, is it possible to connect beaglebone black to a knx bus? Jun 22 15:29:01 Enrico48: it only depends on the effort you are willing to take. Jun 22 15:29:38 it has obviously been done: https://ing-budde.de/?product=ibbcape-ko Jun 22 16:17:37 Enrico48: "possible" is really vague, almost anything is "possible" Jun 22 16:17:56 based on some googling it seems "knx bus" is also vague since they specify multiple totally different physical layers Jun 22 16:23:02 holy shit, the (freely downloadable) spec is 100 MB of documents Jun 22 16:32:03 aaand he's gone Jun 22 16:37:25 Anychance someone here has a recommendation for a board / project similar to PRUDAQ? I'm in need of a portable, reasonably low-power / low-heat unit that I can use for continuously capturing in the low kHz to ~5MHz range for later analysis. I'd like to use one of my BBBs since it fits the size/electrical/compute requirements. I've got a few SDR type devices, but none of them quite meet my prefered specs. Jun 22 16:40:47 For instance, a HackRF that I can just use without the RF frontend, but it's only 8bit samples, which is less than ideal. I've got a RedPitaya which would be perfect, but it's in use on another project, and it's a bit more capable than what I need. Something like PRUDAQ would be perfect, but getting the board is an issue given that don't have the time/bandwidth ATM to deal with assembly, (and don't trust my soldering). Jun 22 16:41:36 I don't suppose the integrated adc is suitable? Jun 22 16:42:05 hmm it probably doesn't have the bandwidth Jun 22 16:43:24 it definitely doesn't Jun 22 16:48:03 zmatt: Yeah, whatever it is will need its own ADC. If I had time to roll my own, I'd just do that, but as it sits I may just use the HackRF and deal with the reduced sample depth. Jun 22 16:49:23 I've spent a good bit of time poking around at options over the past couple days, but thought I should at least pose the question here in case anyone had a suggestion. Jun 22 16:50:29 you can get extra bits of resolution by oversampling and low-pass filtering, if it supports a substantially higher samplerate than needed for your bandwidth (and the input has about 1 lsb of noise, or you can arrange to inject it) Jun 22 16:51:11 zmatt: can I detech a really slow PWM with a multimeter or do I need an osciloscope Jun 22 16:51:33 MattB0ne: I mean, if it's slow enough then you can obviously use a multimeter Jun 22 16:51:52 (how slow depends on how fast the multimeter responds to changes in voltage) Jun 22 16:52:07 i slowed the PWM to 1 hz Jun 22 16:52:38 if your multimeter updates substantially faster than 1 Hz then that is fine Jun 22 16:53:08 that is a good question i got a 10 dollar homedepot one Jun 22 16:53:13 At 1Hz you could reasonably use an LED or similar indicator. Jun 22 16:53:18 yeah indeed Jun 22 16:53:22 that would work better Jun 22 16:53:29 so no guarantee Jun 22 16:53:35 ok Jun 22 16:53:42 good suggestion Jun 22 16:53:47 I mean, you can just look at the screen of your multimeter to see how fast it updates if you stick the leads onto something Jun 22 16:54:02 and the PWM coming from the ecap would be 3.3V Jun 22 16:54:09 for the up Jun 22 16:54:14 but led + suitable series resistor is probably a ton more convenient than a multimeter Jun 22 16:54:26 more informative, easier to read, responds instantly Jun 22 16:54:27 great Jun 22 16:54:32 Unless you need to verify the voltage or some such, which presumably you don't. Also, some multimeters (usually > $10 models) have good duty cycle options, or basic frequency counters. Jun 22 16:55:05 and you can test the pwm output at the proper frequency in that case since even if it's too fast to see it blink, you'll see the led vary in intensity Jun 22 17:00:54 it's for the jrk right? so it doesn't actually care about duty cycle % but about the actual pulse width, which should be between 400 us and 2600 us at a frequency between 10 and 150 Hz. so if you use the max frequency of 150 Hz, that range is between 6% and 39% duty cycle Jun 22 17:04:24 ecap period of 1333333 cycles (MAXIMUM = 1333332), duty cycle value (COMPARE) between 80000 and 520000 Jun 22 17:05:23 I switched to this https://www.amazon.com/NOYITO-High-power-2-Channel-Instantaneous-Capability/dp/B082VS65BZ/ Jun 22 17:05:38 zmatt: Looks like KiwiSDR may actually suit my needs perfectly, initial impressions show it to be well suited, and better bit depth. A bit pricey, but for the right HW, it's worth it. Jun 22 17:06:09 still should not matter, though I wonder if I need to do something to the other P9_42. Reemember how since 41 was split I only got half power Jun 22 17:06:35 "half power", what are you even talking about? Jun 22 17:07:31 you were seeing a disconnected input at an intermediate voltage due to a pull-up/pull-down conflict Jun 22 17:07:32 When I was troubleshooting the P9_41 Jun 22 17:07:34 this is an output Jun 22 17:07:50 pull-up/down is irrelevant once the ecap is configured to pwm mode Jun 22 17:07:55 ok Jun 22 17:07:55 since the pin will be driven Jun 22 17:08:03 as always, confirm your pinmux with show-pins Jun 22 17:08:03 nevermind then Jun 22 17:08:07 i did Jun 22 17:08:12 is shows ecap Jun 22 17:08:24 pru ecap Jun 22 17:08:24 can you pastebin its output? Jun 22 17:08:30 sure Jun 22 17:09:07 and where's the documentation for this randomass board you're now using for some reason? Jun 22 17:09:59 also, it requires two pwm outputs Jun 22 17:10:48 https://pastebin.com/aafbiW5y Jun 22 17:11:09 two for direction control Jun 22 17:11:19 I can just ground the other and go in one direction Jun 22 17:11:31 didn't you need bidirectional control? Jun 22 17:11:37 eventually Jun 22 17:11:44 for now one way is good Jun 22 17:12:04 well then eventually you're going to need two pwm outputs, which you can't get from ecap :P Jun 22 17:12:12 lol Jun 22 17:12:23 i will be older and wiser then Jun 22 17:12:28 hopefully =) Jun 22 17:12:38 and that will magically fix the problem? Jun 22 17:13:44 possibly Jun 22 17:13:49 i still have the JRK Jun 22 17:14:05 i switched because of the voltage thing. I did not know it did not matter Jun 22 17:14:13 I Wanted to ditch the logic shifter Jun 22 17:14:25 but I can put back based on what you said today Jun 22 17:14:49 And if you don't need to switch direction "quickly" then you can get by with an additional logic output. Only a single PWM needed. Jun 22 17:14:58 oh does the jrk require 5V on its pwm input? Jun 22 17:15:10 it has 5V logic Jun 22 17:15:27 Can alos use a single pwm with a 50% off config with a standard H bridge Jun 22 17:15:32 *also Jun 22 17:15:57 i wouldnt really Jun 22 17:16:01 RobertClean: that would require external logic, or a board that has separate direction and pwm inputs Jun 22 17:16:02 so that could work maybe Jun 22 17:16:17 Yes it would Jun 22 17:16:37 right now getting it to spin in one direction in a controlled fashion is the plan Jun 22 17:16:42 did my pin config look ok Jun 22 17:16:59 the latter is not this board, the former is more complicated than using pwm 0A and 0B on P9.29 + P9.31 Jun 22 17:17:04 But if you're already doing point to point wiring then adding some logic or a simple PLD isn't a big addition Jun 22 17:17:39 RobertClean: you don't know MattB0ne's history with hardware and wiring stuff up :P Jun 22 17:17:55 he speaks the truth!!! Jun 22 17:18:09 True enough that. Jun 22 17:18:18 I am a electronic dunce Jun 22 17:18:22 working on it though Jun 22 17:18:23 Yep, turns out the KiwiSDR will be perfect. It is more than I wanted to spend for a single unit, but it gets the job done, and will provide a more plug-and-play solution than dealing with any of it myself. Plus it leaves the USB free for external storage. Jun 22 17:18:26 like, it's a miracle his beaglebone hasn't burst into flames yet Jun 22 17:18:43 TY all. (I mean... for nothing, but still TY :P ) Jun 22 17:19:10 IanWizard: :) Jun 22 17:20:07 well I am on my second Jun 22 17:20:13 to be fair Jun 22 17:20:36 anyways enough self deprecation Jun 22 17:20:42 so my pin config looks good? Jun 22 17:21:00 IanWizard: given that you wanted something fairly obscure with fairly specific needs, some known-working off-the-shelf hardware sounds like a good idea even if it's a bit more expensive, I suspect cheaper hacky solutions could be more misery than it's worth Jun 22 17:21:35 MattB0ne: well it shows that you still don't understand the concept of avoiding a pull-up/down conflict on a bit Jun 22 17:21:52 which won't matter hugely once the ecap is configured as output, but still Jun 22 17:22:49 ok I can fix that should I set the other P9_42 to another mode or just pull it up Jun 22 17:23:06 i guess it doesnt matter since it will be masked by the ecap Jun 22 17:23:12 PIN_INPUT_PULLUP with mode 7, same as for P9_41A Jun 22 17:23:48 yeah but that's only once ecap is configured, and it's trivial to just do it right Jun 22 17:24:09 note btw that you can actually monitor the ecap output via gpio 3.18 Jun 22 17:25:51 BTW MattBone, have you an Oscilloscope? If you're driving a motor you are going to need to be careful about inductive kick (and regen). Jun 22 17:26:21 well the motor driver boards should deal with that Jun 22 17:26:46 I am in the market for a scope looking at craiglist Jun 22 17:26:55 zmatt, hopefully on the drive lines but they fundamentally cannot on the power lines Jun 22 17:27:23 MattB0ne: you can monitor the gpio e.g. with watch -n 0.1 -d cat /sys/class/gpio/gpio$((3*32+18))/value Jun 22 17:27:41 RobertClean: ?? Jun 22 17:28:19 oh you mean if you accidently use the motor as a generator Jun 22 17:28:37 Regen and inductive kick occur mostly on the power bus and can then couple through the rest of the system (worst case they can blow up the power inputs) Jun 22 17:28:54 hmm, they don't protect against that? that sounds really awful Jun 22 17:29:11 I don't see why a board would not protect against that Jun 22 17:29:13 zmatt, for regen, yep. Basically if you slow down too fast. That's all you needto do Jun 22 17:30:17 zmatt fundamentally they cannot. If they add a series diode (or equiv) then the bus rises locally on the Hbridge. Basically a halt and catch fire. Jun 22 17:30:59 You could add braking resistors but only full fledged drives are likely to have that and only as an extra cost option Jun 22 17:31:30 The final solution is to disable the PWM on overvoltage and freewheel the motor, losing control. Jun 22 17:32:06 In the latter two cases you still get feedback onto the power bus Jun 22 17:33:22 I'm trying to visualize the situation... like I know how each component works in theory but I don't really work with motors myself so this isn't stuff fresh in my mind Jun 22 17:34:10 If you are running on a power supply then you have little buffer for regen. A battery helps (although broken wire is a potential issue) but batteries do have limits on how large a current they can safel accept. Jun 22 17:34:11 but yeah it makes sense the driver brakes by regenerating onto the power supply, like you say where else is it going to dump the energy and not catch fire Jun 22 17:35:35 A big (ish) battery is best for initial testing. And PbS would be safer than Li-ion. Jun 22 17:36:23 You need to protect the power input to your logic. Also isolation on the logic lines feeding to the H-bridge is highly recommended Jun 22 17:37:12 these all sound like great suggestions. I wish MattB0ne good luck with it :D Jun 22 17:38:53 MattB0ne: so, what I said previously about power supplies... yeah that probably doesn't hold when the thing it's supposed to supply tries to shove power back into the supply, which is exactly what happens when you brake a motor, and I hadn't thought about that Jun 22 17:40:08 Heh, that's why extra logic didn't particularly phase me. But, yeah, mixing power and low voltage logic has a fair number of pitfalls. Jun 22 17:40:52 i saw some things about putting a diode and capcitor in parallel to block back emf stuff Jun 22 17:40:54 with the jrk he had a level shifter at least Jun 22 17:41:33 a diode and capacitor in parallel? you probably saw that wrong :P Jun 22 17:42:02 (between the 3.3V of the BBB and the logic supply of the motor controller) Jun 22 17:42:09 something in parallel Jun 22 17:42:12 but i dunno Jun 22 17:42:17 right now Jun 22 17:42:24 what is in front of me Jun 22 17:42:30 is getting this motor spinning Jun 22 17:42:46 eventually some of this dialog will seep in Jun 22 17:43:02 Maybe Zener or transorb in parallel with cap? That would be part of a circuit. Jun 22 17:44:16 MattB0ne: so, what exactly are you trying to make in the first place, and how have you ended up with the job of making this without having any knowledge in any domain relevant for this project? :P Jun 22 17:44:28 because I got the impression it's more than just a pet hobby project Jun 22 17:44:51 but maybe that impression is mistaken Jun 22 17:45:09 i am a grad student Jun 22 17:45:15 in biomedical engineering Jun 22 17:45:20 ugh, another failed BBE Jun 22 17:45:35 i study osteoarthritis Jun 22 17:45:38 apparently the same emmc fault as the last one Jun 22 17:45:49 I needed a machine to compress tissues Jun 22 17:45:53 so hear I am Jun 22 17:46:11 I dont mind learning this stuff since I wanted to make some things anyway Jun 22 17:46:24 but I have one circuits class under my belt Jun 22 17:46:26 and that is it Jun 22 17:46:37 and not much of it stuck I think Jun 22 17:46:51 Wouldn't a stepper motor be better for that? Jun 22 17:46:52 my undergrad was ME Jun 22 17:47:00 so wasnt important Jun 22 17:47:05 to say heat transfer Jun 22 17:47:06 or thermo Jun 22 17:47:13 and now biochem Jun 22 17:47:15 etc,,, Jun 22 17:47:24 i fault the degree program Jun 22 17:47:25 mru: ah you're using BBEs? I wonder if they ever fixed the glaring power sequencing issue Jun 22 17:47:50 there's a glaring power sequencing issue? Jun 22 17:48:17 Mat, if this for a grad project do you have enough budget to get a proper drive controller? Jun 22 17:48:30 depends Jun 22 17:48:34 how much we talking Jun 22 17:48:54 in regards to stepper motor Jun 22 17:48:54 Get something controlled by CAN or Ethernet and work at a higher level of abstraction rather than re-inventing the wheel? Jun 22 17:48:59 it would not be fast enough i htink Jun 22 17:49:35 that this motor will be doing is moving an N52 magnet near a responsive lid Jun 22 17:49:35 How fast do you need, both of those can be fast. I prefer CAN for determinisom but neither are slow Jun 22 17:49:49 I need it to handle 1-2 hz of cylcing Jun 22 17:49:57 Oh, that's slow Jun 22 17:50:03 biologically Jun 22 17:50:08 that is fast Jun 22 17:50:10 think running Jun 22 17:50:14 but I get ya Jun 22 17:50:24 they will need to tollerate some load Jun 22 17:50:39 i got a shitty gear motor from servocity Jun 22 17:50:46 mru: ah there are newer schematics, lemme see Jun 22 17:50:54 i mean I cannot spend 1000s since this is one aim of my thesis Jun 22 17:51:07 https://www.robotdigg.com/product/900/CANOpen-protocol-GECKO-stepper-controller Jun 22 17:51:39 A possibility but I don't know anything about it. More to give you ideas on what you might look for Jun 22 17:52:28 mru: the enable-signal for VDD_3V3 is SYS_5V Jun 22 17:52:40 I once bought a box of surplus steppers for about $10. This would be bigger motors I think. Jun 22 17:52:40 (for the VDD_3V3 regulator) Jun 22 17:53:21 You should be able to get 10's ms response times and full load changes of under 100mS I would thnk Jun 22 17:53:39 How much rotation would be something to look at Jun 22 17:55:06 mru: it's a bit weird, they have a power tree on page 2 which doesn't actually resemble the rest of the schematic Jun 22 17:56:28 that's friendly Jun 22 17:56:45 looks like the power tree is just bogus, neither the supplies nor components it refers to exist Jun 22 17:57:01 I would need a lot of cycles though Jun 22 17:57:09 that is what I was worried about with steppers Jun 22 17:57:36 mru: there's just VDD_3V3A and VDD_3V3, with the latter being equivalent to VDD_3V3B on the BBB, except for using SYS_5V as both LDO supply and LDO enable Jun 22 17:59:28 dunno what the implications are for the on-board stuff, but any external hardware driving a BBE pin high (powered from the 3.3V on the cape header) during power-up will be an abs max violation for quite a few miliseconds Jun 22 17:59:40 Another avenue (this for PM motors). Can also find BLDC (Pr PM synchronous/PMSM, same thing under different names) drives. Jun 22 18:00:57 Unless you are going through a gear then I don't see that steppers are inherently less long lasting. The components are fundamentally different. Specific models will vary quite a bit. Jun 22 18:04:07 Grad students (or their supervisors) tend to view their labour as free. Try to limit that, reinventing items outside of what your studying is a less than helpful diversion even when it's necessary Jun 22 18:05:34 good point Jun 22 18:05:48 though this sort of scratches a curiosity Jun 22 18:05:53 so I dont mind Jun 22 18:06:26 Now there's the grad student trap ;) Been there lol Jun 22 18:06:34 though the learning curve is very steep Jun 22 18:11:23 indeed Jun 22 18:11:45 I will shop around I think all these optins do require me to get this PWM pin working Jun 22 18:11:58 zmatt: I just fixed the conflicts Jun 22 18:12:41 I like learning new things Jun 22 18:12:48 and embedded systems is empowering Jun 22 18:13:08 getting a foothold though rough espcially if you are not starting from CS or EE it seems Jun 22 18:13:25 I am going to make a website Jun 22 18:13:35 beaglebone heads Jun 22 18:14:01 for electronically challenge Jun 22 18:14:11 it will do wonders in preserving zmatts sanity Jun 22 18:14:14 lol Jun 22 18:14:20 Actually, the ones I linked to should just require CAN (so a standard CAPE should work) Still a lot to learn from software and comms but the motor side works and you may be able to use some canned SW to check that everything is working before you write SW. There's a lot to be said for knowing that it's only your SW at issue. Jun 22 18:14:31 zmatt: well, that doesn't seem good Jun 22 18:16:46 zmatt: do you happen to know if the bbe serial number includes a date code? Jun 22 19:06:27 mru: for all beaglebone variants, eeprom bytes 0x10-0x11 should be the week number in decimal, bytes 0x12-0x13 the last two digits of the year in decimal Jun 22 19:08:34 all I have right now is a photo of the sticker Jun 22 19:08:53 stickers tend to vary by manufacturer Jun 22 19:08:54 "0419BBE...." Jun 22 19:09:01 that should be 2019 week 4 Jun 22 19:09:06 could be Jun 22 19:09:15 but it _could_ be something else Jun 22 19:10:46 so, the serial number in eeprom for beaglebone black is wwyyBBBKnnnn where ww=week(decimal), yy=year(decimal), nnnn=serial(hex) Jun 22 19:11:15 this is likely the same scheme then Jun 22 19:12:35 and I have at least one beaglebone with that on a sticker (though most BBBs use a totally different scheme on the sticker, which is also in bytes 0x50-0x66 of eeprom: 400524+1301+nnnnnn+yyww where yy and ww as before, and nnnnnn the same serial but now in decimal) Jun 22 19:13:14 both broken BBEs have 0419 Jun 22 19:14:45 * DarrenMLH sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/SicCLXJzyyWHyxtKACbOFNXS > Jun 22 19:14:54 we actually keep eeprom contents, mac address, and emmc cid of all beaglebones we use in a db, just in case Jun 22 19:20:23 DarrenMLH: try to avoid typing a long multi-line message in the future, the gateway or whatever it is you're using is turning it into a link, which means far fewer people will read it Jun 22 19:21:44 DarrenMLH: it sounds like it has more to do with Windows than with the BBB, especially if flashing a clean image onto sd card didn't help Jun 22 19:22:03 but I'm not sure, it sounds very odd Jun 22 19:22:20 zmatt: Thank you for letting me know, and sorry about that. Is there a better format for me to use? Or should I just break the message into smaller messages? Jun 22 19:23:03 yep, just line by line. it's a chat, not a forum Jun 22 19:23:05 and I agree, it does seem like an issue with Windows. I am not sure if the PocketBeagle is being assigned a different IP address for some reason, or if it could be something else Jun 22 19:23:30 well the thing is that the IP is statically assigned, at least on the pocketbeagle's side Jun 22 19:24:03 so maybe IPv4 isn't working at all right now for you (on the interface to the pocketbeagle) and using "beaglebone" as hostname actually ends up using link-local ipv6 Jun 22 19:26:17 Oh that is very strange then. To be honest, I do not have too much experience with networking but what you have mentioned seems to be a good starting point for researching this. Jun 22 19:26:22 I'll also try using a different computer and report back on the results. Thank you -- I appreciate your help. Jun 22 19:27:04 You might also try using a serial console in addition to ethernet. Maybe the IP address is changing Jun 22 19:27:20 in addition to usb you mean Jun 22 19:27:24 the pocketbeagle has no ethernet Jun 22 19:27:39 Ah, yes in that case Jun 22 19:27:47 but on a fresh image that really isn't a worry Jun 22 19:27:54 its usb interfaces use static IPs Jun 22 19:28:08 so whatever is going wrong is on the windows side Jun 22 19:28:36 Be a double check on the USB though if the serial is available. Jun 22 19:28:48 RobertClean: but he can log in via ssh Jun 22 19:28:52 just not by ip Jun 22 19:28:55 Static IPs should be robust in and of themselves though Jun 22 19:29:11 DarrenMLH: beaglebone.local may also work in the browser Jun 22 19:29:37 .local doesn't work on windows Jun 22 19:29:53 Even on firefox and chrome it's dissappeared Jun 22 19:30:03 DarrenMLH: check in your network connections, for the network interface representing the pocketbeagle that your PC is set to automatically obtain an IP address Jun 22 19:30:25 As of the latests updates. Caused me some headaches figuring that out Jun 22 19:30:26 RobertClean: well the story is a bit weird, Windows 10 has an mDNS implementation and apparently it does work for some people Jun 22 19:30:58 but I wouldn't be surprised if it also conflicts with the ad-hoc solutions done e.g. by browsers Jun 22 19:31:25 zmatt, I think it's only available if you use the app interface. I sort of got the impression it may be going away even there Jun 22 19:31:32 even on linux Chrome will open its own mDNS socket instead of using Avahi Jun 22 19:31:59 Cerainly is was working for me a week ago and then no more Jun 22 19:34:54 RobertClean: like, a microsoft article from two weeks ago mentions, in the context of some miracast feature they added, "Windows 10 will attempt to resolve the device's hostname via standard DNS, as well as via multicast DNS (mDNS)" Jun 22 19:35:36 but yeah, it's really not super clear Jun 22 19:38:11 zmatt RobertClean : I think I have resolved the problem! Last week, I ran through some configurations to allow my PocketBeagle to access the internet via the USB connection. Jun 22 19:38:25 that sounds like a great way to break things Jun 22 19:38:49 I followed zmatt's advice to look at the IPv4 address in the network connections and found, under IPv4, I had it set to use "192.168.7.2" as opposed to "192.168.7.1" (as the tutorial recommended) Jun 22 19:39:02 Changed it back and everything works now Jun 22 19:39:55 that will definitely break your ipv4 networking yes Jun 22 19:40:31 zmatt: I know :/ , I figured the worst I could do is mess up stuff on the debian image and reflash if necessary, but I guess that wasn't the case. Everything is looking good now (with both Cloud9 and Putty) -- thank you again for the advice! Jun 22 19:41:06 (it's not merely a "recommendation", it's the only possible IPv4 address your computer can use on the usb networking interface that will allow successful IPv4 communication with the pocketbeagle) Jun 22 19:44:58 mru: I've checked with my BBE: the code on the sticker is bytes 0x10 - 0x1f of the EEPROM Jun 22 19:46:00 so it's week and year as suspected Jun 22 19:46:33 yep should be Jun 22 20:57:41 This new kernel enables remoteproc, but I need uio. Sadly I've utterly failed to discover how remoteproc even gets loaded, much less attempt to prevent it. (pout) Jun 22 20:58:02 Ragnorok: it's not kernel-dependent, you configure which one you want in /boot/uEnv.txt Jun 22 20:58:09 at least, typically Jun 22 20:58:14 when using u-boot overlays Jun 22 20:58:29 I thought it was part of the dtbs? Jun 22 20:58:52 just checking, is this for BBB + board, or a custom board entirely? Jun 22 20:59:01 Black & board. Jun 22 20:59:05 ok Jun 22 21:00:17 so, on non-ancient BBB images, typically uboot overlays are enabled which basically modularizes the DT. u-boot will load a fairly minimal dtb and then apply overlays onto them based on settings in /boot/uEnv.txt, before passing the final dt to the kernel Jun 22 21:00:31 Every overlay and dtb is commented out in uEnv. It must be defaulting in the scripts. But even so I would have expected to find it in the dtbs, if it's an overlay. Jun 22 21:01:05 dtbs being all the things (dtsi, dts, etc) in that dir. Jun 22 21:01:10 oh if you've disabled u-boot overlays then you'll get the monolithic/legacy dtb, it's possible that remoteproc is enabled by default in that Jun 22 21:01:30 which is easy enough to switch back to uio Jun 22 21:01:50 https://github.com/mvduin/overlay-utils/blob/master/uio-pruss.dtsi Jun 22 21:01:54 Well I haven't specifically disabled them. (wry grin) Jun 22 21:02:07 commented out = disabled Jun 22 21:02:40 you should probably consider using an overlay, since it means you can do kernel upgrades without having to recompile your dtb again Jun 22 21:02:42 I hear ya. They are clearly disabled. I just didn't do it/didn't know enough to know that was "disabled". Jun 22 21:03:16 so what are you trying to do exactly, did you upgrade only the kernel or start with a newer image? Jun 22 21:03:22 I will consider it once I understand what the heck is even happening. I'm still not there yet. Jun 22 21:04:46 I upgraded only the kernel and it stopped loading modules. I got some PoC work done with the new kernel to demonstrate it does what the old one wouldn't. Now I'm trying to use someone else's device tree mods from three years ago to update the DT for the new kernel. Old was 4.1.19, new is 4.19.50. Jun 22 21:05:22 Until last Wed or so I knew a device tree existed and little else. Jun 22 21:05:48 and that someone unfortunately took an existing .dts and modified it, instead of #including it and adding some fragments to override what needs to be overridden? Jun 22 21:06:06 Precisely. Jun 22 21:06:42 I did build the virgin dtb and load it, so I know I can at least get that far. lol Jun 22 21:07:49 what you should probably consider is getting the bbb into its modern default configuration for /boot/uEnv.txt (without your custom board attached initially), after updating u-boot and the overlays package Jun 22 21:08:10 Which probably only means I can read kernel version numbers, but there it is. I figured I'd try to incrementally do things based on what documentation I have. Jun 22 21:09:29 Ok. I'll have to jury rig power. It gets that from the custom board. Would it be okay to just not configure the board-specific stuff, update uboot, and migrate that way? Jun 22 21:09:55 I mean, if you pull the bbb off the board can't you just power it via usb? Jun 22 21:10:17 or put the same system onto a fresh bbb Jun 22 21:10:18 Oh. Sure. I keep forgetting it does that. I pretty much never use USB to power anything. Jun 22 21:10:45 for testing it's a pretty convenient way to power it Jun 22 21:11:20 I currently have no fresh BBB available, as I'm working from home for the pandemic. The boxes of new ones are an hour from here. Guess I could drive over and get one. Jun 22 21:11:43 I mean, if you can experiment with this one then that's fine of course Jun 22 21:11:54 Sure. I'll see what I can figure out. Thanks! Jun 22 21:12:36 so, lemme check what you'd need to do to get dt into default state Jun 22 21:13:04 The dts/sources that are in the kernel source don't qualify? Jun 22 21:13:21 they're not really relevant, you won't be touching those Jun 22 21:13:26 Oh. Ok. Jun 22 21:13:38 those dtbs are installed as part of the kernel package Jun 22 21:14:34 which is also why I suggest an overlay as probably being more convenient than a custom dtb (even though I use custom dtbs myself): you can usually keep the overlay the same even while switching between kernel versions Jun 22 21:15:06 what debian release in your system anyway? I hope it's at least stretch and not still jessie or something? Jun 22 21:15:10 *is your system Jun 22 21:15:16 I understand. I'm not sure we'll ever do that again, but that doesn't matter. Much time as I'm throwing at this I'm happy to do overlays if that's simpler. Jun 22 21:15:43 It is still jessie. Jun 22 21:15:46 yeah and if you use my overlay utils you can very easily switch between overlay and custom dts anyway Jun 22 21:15:49 oof Jun 22 21:16:19 so what version of the bb-cape-overlays package does apt want to give you? Jun 22 21:16:43 Try to install that and see, is that what you're asking? Jun 22 21:16:56 apt-get update && apt-cache policy bb-cape-overlays Jun 22 21:17:26 At least I already had update running. lol Jun 22 21:18:48 what my overlay-utils ( https://github.com/mvduin/overlay-utils ) does is take snippets of normal DT source (like you'd have in a normal dts or dtsi file) and turn it into an overlay (by preprocessing it into overlay syntax with a perl script before running it through dtc) Jun 22 21:18:55 Candidate is 4.4.50190630 Jun 22 21:19:22 Installed is none Jun 22 21:19:42 2019 etc, not 5019 Jun 22 21:20:15 and for historical reasons my macros are different, but you can just over include/ from bb.org-overlays or BeagleBoard-DeviceTrees if you prefer Jun 22 21:20:21 *just copy over Jun 22 21:20:26 oh god Jun 22 21:21:48 now I'm not so sure anymore since everything on your system is presumably ancient and I don't know how things might interact Jun 22 21:22:15 so maybe sticking with a custom dtb is safer for now Jun 22 21:23:11 lol Roit toe. Jun 22 21:23:28 are you using BeagleBoard-DeviceTrees as base git repository to build your custom dtb ? Jun 22 21:24:09 No. I snagged the kernel source and I've been using that. Jun 22 21:24:28 that sounds very inconvenient and terrible for version control and maintainability Jun 22 21:24:42 https://github.com/beagleboard/BeagleBoard-DeviceTrees/ Jun 22 21:24:59 That's what prior dude's instructions said to do. It has certainl been tragedy itself for maintainability. lol Jun 22 21:25:13 this is synced from kernel sources (select branch corresponding to your kernel series, e.g. v4.19.x-ti) Jun 22 21:25:32 Okey doke. Jun 22 21:25:53 create a new .dts file with a custom name in src/arm/ Jun 22 21:27:04 and you could just start with: https://pastebin.com/6nsDWGwX Jun 22 21:27:30 Nicely simple. Let me get all this set up and we'll see what happens. Jun 22 21:27:41 then "make src/arm/my-custom-board.dtb" Jun 22 21:28:11 and you should have something equivalent to am335x-boneblack.dtb except with uio-pruss instead of remoteproc-pru Jun 22 21:28:41 stick it into /boot/dtbs/ and set dtb=my-custom-board.dtb Jun 22 21:28:45 in /boot/uEnv.txt Jun 22 21:28:51 Roit toe. Thanks! Jun 22 21:29:21 by sticking it into /boot/dtbs/ instead of the kernel-version-dependent subdirectory you'll at least be able to perform minor kernel version upgrades without hassle Jun 22 21:30:29 instead of downloading that uio-pruss.dtsi (and saving it as src/arm/am335x-uio-pruss.dtsi to name it a bit more specifically) and #including it you could of course also copy-paste its contents into your .dts, but modularizing into files can be nice for maintainability Jun 22 21:31:03 #include is of course, just like in C, literally equivalent to the contents of that file just being dumped into the spot of the #include Jun 22 21:31:33 The one we were using is in /boot/dtbs. It didn't work when I upgraded. Jun 22 21:31:46 you upgraded several major kernel versions Jun 22 21:31:49 I said minor kernel version upgrades Jun 22 21:32:07 I 4 to major and anything less to be minor. Jun 22 21:32:32 for the linux kernel the first digit means nothing, "4.19" is the major version Jun 22 21:32:40 Apparenly that's not the case. Okey doke. Jun 22 21:33:10 but you're right, my terminology is technically wrong Jun 22 21:33:20 I should say patchlevels or something Jun 22 21:33:31 but for practical purposes, 4.19 is the major version :P Jun 22 21:33:43 Doesn't matter. wrt to what we mean, you are the authority. 4.19 is the major verion. Jun 22 21:33:49 2.5 was fun Jun 22 21:36:59 Ragnorok: even though this example of a custom dts is for the bbai, you may find it enlightening since I've annotated it with narration of how it's incrementally making the DT: https://pastebin.com/DdZEL2u0 Jun 22 21:37:16 Thanks! Jun 22 21:37:32 oh what that snippet does in lines 5-8, you should do that in your custom dts too Jun 22 21:37:47 it'll let you easily figure out at runtime what dtb your system is actually running on Jun 22 21:38:08 (by finding that property in /proc/device-tree/chosen/ ) Jun 22 21:38:52 Schweet. Jun 22 21:39:15 Ragnorok: don't pay any attention to &cape_pins_default in that pastebin, it's a horror that's only relevant for bbai (and the sooner it's gone the better) Jun 22 21:39:18 ;) Jun 22 21:39:28 lol Jun 22 21:39:55 normally pinmux nodes are created for, and attached to, individual devices that need pinmux Jun 22 21:40:02 not a big blob of misc pinmux Jun 22 21:41:46 for examples of DT customization snippets for the BBB, you can probably find some interesting ones in overlay-utils, e.g. https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi is a really simple one. just ignore the USES_PIN lines and keep in mind my headers/macros are different Jun 22 21:49:56 Ragnorok: https://pastebin.com/VLfEkGbw example of custom .dts with the uart4 example integrated (using mainline macros) Jun 22 21:50:15 Thanks! Getting lots of new links to peruse. (grin) Jun 22 21:51:21 you can swap the &uart4 { .. }; block and its pinmux declaration block if you prefer that aesthetically Jun 22 21:51:36 (&node_references inside <> are allowed to be forward references) Jun 22 21:52:46 I really do like my pinmux macros more than the mainline ones :P conciseness++ Jun 22 21:54:34 I generally prefer concise. First I have to learn to crawl. Jun 22 21:55:22 Or maybe even what these long bendy things are for. Jun 22 21:55:37 in this case it makes more sense to use the mainline macros Jun 22 22:02:11 Ah well. Quittin' time here. Lots to flounder around with on the 'morrow. Thanks again! Jun 22 23:01:46 interesting, if you keep doing consecutive stores from PRU to L3 in the absence of downstream congestion you will eventually (once the fifo of the PRUSS->L3 bridge is full) end up with 1 stall cycle per store: https://docs.google.com/spreadsheets/d/e/2PACX-1vSupO4NOb1r0maJtV9zfsTbh-rWGgi0CzfVbbR1HWbmxGqMQHQ9znejos1mwqDqy0IYcz5TEzw-bDUv/pubhtml?gid=121259833&single=true Jun 22 23:02:21 while if you do non-consecutive stores then the bridge can keep up Jun 23 02:49:17 I've been busy on another project. The SBC called the C.H.I.P. Currently runs Debian 8.11. Originally from NTC Next Thing Computer. I am helping with new OS Debian 20.04. Jun 23 02:56:00 there's no such thing as debian 20.04, you probably mean ubuntu 20.04 **** ENDING LOGGING AT Tue Jun 23 03:03:14 2020