**** BEGIN LOGGING AT Tue May 26 02:59:57 2020 May 26 12:24:27 m May 26 12:51:22 I upgraded my bbblack from Jesse to Buster on the weekend. I noticed something quite strange. Whatever is running on it is interfering with the rederer on my Visio TV when I stream videos from Netflix. Not only that I think it tried to get into my router pnp configuration for some reason. Is that possible? May 26 13:06:35 that sounds unlikely May 26 13:07:21 if something is blasting out upnp crap, there's no telling how other devices will react May 26 13:07:35 as if the original pnp wasn't bad enough May 26 13:08:44 ehm, what? May 26 13:09:19 remember isapnp? May 26 13:09:36 upnp has a way worse rep than it deserves. it also has absolutely nothing to do with bios pnp May 26 13:09:46 I know that May 26 13:09:58 and no I don't really, I was a mac user in those days May 26 13:10:02 it's just ironic to choose the same name as something so reviled May 26 13:11:02 anyway, if something is discovering the "smart" TV's renderer and telling it to show something, that could disconnect a netflix stream (or anything else that's playing) May 26 13:11:03 I mean, "plug and play" is a pretty general term May 26 13:11:18 and has it ever lived up to its promise? May 26 13:12:05 and the beaglebone isn't going to be looking for MediaRenderer devices, let alone attempt to show something on them May 26 13:12:17 not the beaglebone per se, no May 26 13:12:24 but software running on it could May 26 13:12:35 unsolicited? no May 26 13:12:39 it _could_ May 26 13:12:44 not saying it should May 26 13:13:28 anyhow, a quick network sniff should reveal that May 26 13:42:55 I upgraded my bbblack from Jesse to Buster on the weekend. I noticed something quite strange. Whatever is running on it is interfering with the rederer on my Visio TV when I stream videos from Netflix. Not only that I think it tried to get into my router pnp configuration for some reason. Is that possible? May 26 13:43:05 you already said that May 26 13:43:25 I know, but I didn't get an answer in a long time May 26 13:43:26 anyway, what is the TV doing, and why do you suspect the beaglebone? May 26 13:45:12 The tv's renderer freezes it's video but the subtitles keep updating. so, obviouly, there is a port that gets clobbered. This happens when my bbb is connected on the same hub. Problem persists until I reset my router. The ROKU unit works perfectly well. May 26 13:45:28 This is about the strangest thing I have ever seen. May 26 13:45:45 Power off the bbb and all is well... May 26 13:46:41 I meant to say that the roku works pefectly well no matter what. May 26 13:46:44 could there be some ip/mac conflict? May 26 13:48:06 No. My router manages all addresses. I was wondering if the bbb, being an IoT, tries to acquire control of devices it sees on the private side of the router. May 26 13:48:28 it really shouldn't May 26 13:48:31 I can't imagine it does May 26 13:48:46 if it does then that would be a serious screw-up and immediate grounds for a bug-report May 26 13:48:47 as discussed, it's possible but unlikely unless you deliberately set it up that way May 26 13:49:01 Yeah but I don't know what is under the hood. May 26 13:49:45 I disabled uPNP on the router and blocked a call home to connman.net issued by the bbb when it starts up May 26 13:50:02 wtf connman does a call home? May 26 13:50:21 yep, look at your journalctl after a boot May 26 13:50:24 connman tries to do an http get of ipv4.connman.net to check for internet access May 26 13:50:28 bloody annoying May 26 13:50:32 ahh May 26 13:50:38 that actually makes sense May 26 13:50:39 harmless though May 26 13:50:42 yeah May 26 13:51:05 it's trying to determine which port actually offers internet access and not merely intranet May 26 13:51:22 connman does a lot of things, most of them deeply misguided May 26 13:51:31 lol yes, such as ntp May 26 13:51:36 I don't use connman myself May 26 13:51:42 and dhcp May 26 13:51:55 I mean, connman is a network manager, of course it does dhcp May 26 13:52:02 for everthing sane it does, there's a better standalone option May 26 13:52:11 but its dhcp is weird May 26 13:52:15 ah May 26 13:52:17 lol May 26 13:52:32 I use systemd-networkd myself and am quite happy with it May 26 13:52:37 It is ok for it to try to manage the interface but calling outside my network is not good manners. I don't know who is listening at the other end and I know someone does. So it had me worried May 26 13:52:46 and god help you if you have an unstable wifi connection May 26 13:52:55 DopeyOne: well it makes sense for what it does May 26 13:52:57 three strikes and you're out for good May 26 13:53:02 the thing is, I don't think connman makes sense on the BBB May 26 13:53:09 connman never makes sense May 26 13:53:20 I only touch it when paid to May 26 13:53:25 lol May 26 13:53:29 heh May 26 13:53:42 isn't it like for android phones or such? it feels like it belongs there anyway May 26 13:53:50 maybe May 26 13:53:52 I don't know May 26 13:53:56 I don't use it May 26 13:54:04 I wish nobody used it May 26 13:54:13 I have no idea why the bbb uses it May 26 13:54:33 probably because people think there has to be a manager for everything May 26 13:54:41 sure but use systemd-networkd then May 26 13:54:48 it already uses systemd anyway so nothing to install May 26 13:54:51 easy to configure May 26 13:54:57 * mru does not touch systemd even if paid to May 26 13:55:06 Ok guys, I said enough. I will keep digging on that Visio problem. As far as connman goes, I have nothing good to say about it but it seems to work ok. May 26 13:55:20 mru: that's up to you, but most linux systems do use it, including the bbb May 26 13:55:33 not my bbb May 26 13:55:35 I just want to make sure I didn't bring a trojan inside my network. May 26 13:55:45 mru: I'm talking about the default images obviously May 26 13:55:57 yeah, not putting those on customer systems May 26 13:56:32 me neither, although I have no issues with systemd and we actively make use of the features it provides May 26 13:56:55 this has a beaglebone inside: https://www.victronenergy.com/panel-systems-remote-monitoring/venus-gx May 26 14:02:27 we make speakers with beaglebones inside them (although we'll probably eventually switch to a custom pcb using the osd335x) May 26 14:19:55 sounds like some fancy speakers May 26 14:21:08 €5K/speaker May 26 14:21:28 my speakers have just a few passive components May 26 14:22:53 5k can be a lot or a little depending on who you ask May 26 14:23:00 there are 500k speakers May 26 14:23:07 for audiophools with more money than sense May 26 14:23:10 yep May 26 14:23:51 I hate to ask but do you guys have a url to a ticket system so I can put in a bug report against the buster release? May 26 14:24:01 5k for an active speaker isn't totally insane May 26 14:24:11 DopeyOne: https://github.com/beagleboard/Latest-Images/issues May 26 14:24:28 Thank you much! May 26 14:24:40 mru: we actually got a "Best Value" award on some (iirc chineses) high-end audio expo :P May 26 14:25:09 what speakers are we talking about here? May 26 14:25:12 like you said, 10K for a pair of speakers isn't even that much in some market segments May 26 14:25:20 Dutch & Dutch 8C May 26 14:25:27 ah, I've heard of thsoe May 26 14:25:41 pretty much only good things May 26 14:25:50 :D May 26 14:26:36 yeah I'm definitely not an audiophile myself, I'm just a code monkey, but apparently our speaker is pretty decent May 26 14:26:42 I guess you've seen (pictures of) wilson speakers May 26 14:26:53 don't know what's worse, the price or the ugly May 26 14:27:05 lemme google them May 26 14:27:12 my god they're hideous May 26 14:27:24 and 800k or something May 26 14:28:03 in my opinion, it's not possible for a speaker to be good enough to justify that price May 26 14:28:32 mru: au contraire. May 26 14:28:39 I mean, they're ugly and expensive so I guess they're considered to be art objects? May 26 14:28:44 :P May 26 14:29:01 mru: i am absolutely convinced that there should be speakers for 1M$ and up. May 26 14:29:10 for home use, I mean May 26 14:29:29 for stadium rock, it's a different thing May 26 14:29:31 mru: sure, what else? no sane PA company would buy that. May 26 14:30:18 my speakers cost me £1.5k for a pair, and my friends think I'm crazy to spend that much May 26 14:31:17 the audiophile market has some real nutty stuff though May 26 14:31:34 nutty doesn't begin to describe it May 26 14:31:34 mru: i have the strong opinion that highly overpriced luxury goods are one of the very rare "perfect" business models. because there are only winners. imagine somebody buys a goldplated speaker for 1M$. there are two happy people involved. one because having sold it and getting a lot of money, the other because having bought something so exclusive that it polishes the ego. no loser, nobody feels ripped May 26 14:31:40 off. May 26 14:32:24 how do you feel about a rather ugly and mundane-looking $600 ethernet switch? May 26 14:32:32 a 100 Mbps ethernet switch May 26 14:32:41 mru: way too cheap. May 26 14:32:47 like a 0.65 kg piece of rock to connect to your power ground, for €325 May 26 14:32:51 https://www.akikoaudio.com/en/akiko-audio/akiko-audio-audio-accessories/368-akiko-audio-triple-ac-enhancer-english May 26 14:33:01 zmatt: still too cheap. May 26 14:33:05 lol May 26 14:33:09 if you want a laugh, go look up synergistic research May 26 14:33:34 or quantum purifiers May 26 14:34:09 i mean, stuff in the couple of 100 bucks range is mostly just trying to rip somebody off. which i absolutely despise. but imagine selling a slab of concrete to ground your power for 25k$? May 26 14:34:20 exactly May 26 14:34:43 somebody who is willing to buy that amount certainly does not care about the money anymore. May 26 14:34:44 the insanely priced stuff is still ripping people off, but only those who deserve it May 26 14:34:55 lol May 26 14:35:16 it does have a dark side though May 26 14:35:21 which is? May 26 14:35:31 it normalises the idea that ludicrously priced things are good May 26 14:35:41 and enables the lower-priced rip-offs to exist at all May 26 14:36:10 like the lobster on the menu that makes the £40 steak look cheap May 26 14:36:31 can we take a moment to mention audiophile ethernet cables? XD May 26 14:36:44 _directional_ audiophile ethernet cables May 26 14:37:03 mru: you got a small point there. May 26 14:37:16 mru: which i will happily ignore im my future ramblings on that topic! May 26 14:37:32 like you never ignored me before May 26 14:38:24 mru: hey at least i'm being honest about it. May 26 14:40:39 lol May 26 14:41:35 zmatt: we've known each other for quite some time by now :) May 26 14:43:49 to the extent one knows a person by occasionally talking about technical subjects. (especially with my memory, I rarely remember with whom I talked about what) May 26 14:46:00 zmatt: nah, i meant me and mru. the heckling has tradition. May 26 14:46:21 ah, I was confused by your statement May 26 14:46:23 10 years or so May 26 14:46:31 now it makes more sense May 26 14:46:39 language-- May 26 14:47:58 :) May 26 14:48:05 mru: yeah something like that. May 26 16:34:27 hm, reparenting a timers clock seems to be a bit difficult... May 26 16:34:56 fclk, I mean May 26 16:35:03 you mean something like this: https://github.com/mvduin/py-uio/blob/master/dts/lcdc.dtsi#L17-L32 ? May 26 16:35:55 obviously this only works if the assigned-clock allows such reconfiguration May 26 16:36:05 but the timer clocks should May 26 16:37:28 not through dt, but through api function May 26 16:37:40 pretty sure this has kernel APIs as well May 26 16:38:02 yes, omap_dm_timer_set_source May 26 16:38:16 no I mean generic kernel APIs May 26 16:38:34 what does omap_dm_timer_set_source do? does it wrap the generic kernel API ? May 26 16:38:38 yes May 26 16:38:49 some safety checks for ancient platforms May 26 16:38:55 ah yeah, I see May 26 16:39:10 and translating OMAP_TIMER_SRC_EXT_CLK to a char* May 26 16:39:46 which I already hacked to use "tclkin_ck" instead of "timer_ext_clk" May 26 16:40:08 which is a good hint to just use the generic kernel API :P May 26 16:40:13 tclkin_ck is listed as possible parent in the device tree, too, and I get no error ... May 26 16:40:56 btw, make sure tclkin's pin is configured and a clock is present on it before switching over the timer May 26 16:41:14 but when I then inquire the clock rate, it says 24MHz instead of the 10MHz that is listed in the device tree for tclkin_ck May 26 16:41:42 odd May 26 16:41:51 and that's true, the timer is running with a 24MHz source clock, or chrony would complain loudly May 26 16:44:45 any way to see the actual clock tree? maybe in debugfs? May 26 16:45:15 hmm, I've used tclkin, but only via assigned-clocks and using the uio_pdrv_genirq driver for the timer May 26 16:45:34 yeah /sys/kernel/debug/clk iirc May 26 16:46:19 /sys/kernel/debug/clk/clk_summary shows it as a tree May 26 16:46:32 yeah, found it May 26 16:46:43 and sure enough it's not on tclkin_ck May 26 16:47:16 so, the reparenting silently failed May 26 16:47:27 assigned-clocks you said? May 26 16:47:34 in DT yeah May 26 16:49:15 so, I could reference &timer4 in an overlay and set, what, assigned-clocks = <&tclkin_ck>; ? May 26 16:49:26 or with assigned-clock-parents? May 26 16:49:47 I used this for some test: https://pastebin.com/raw/VCqt2Zgh May 26 16:50:23 ah, that makes sense, halfway May 26 16:50:32 what about "assigned-clock-rates"? May 26 16:50:52 that's for changing clock dividers or PLLs May 26 16:50:59 not applicable here May 26 16:51:42 (but assigned-clocks{,-parents,-rates} are requires to be parallel arrays, with <0> for the unused entries) May 26 16:58:06 so all three must exist May 26 16:59:10 oh nice. now it doesn't boot any more ;) May 26 16:59:17 lol May 26 16:59:34 that might be an indication of partial success May 26 16:59:46 or of a typo May 26 17:02:09 can I tell uboot to not load overlays? May 26 17:02:23 via the serial console you mean? May 26 17:02:27 yes May 26 17:03:13 hm, I can just kill "load_overlay" May 26 17:03:41 or loadoverlay it is May 26 17:03:47 what I did if I wanted to bypass things is just manually perform the minimum set of commands to boot: https://pastebin.com/qFv8uW8q May 26 17:03:53 optionally modifying the steps as needed May 26 17:04:29 note: this doesn't bother loading an initrd since beaglebones generally don't need one May 26 17:10:44 well May 26 17:10:53 not so easy it seems May 26 17:11:01 hmm? May 26 17:11:11 this may be outdated though May 26 17:11:42 these commands are for u-boot a few years back, dunno if anything important has changed May 26 17:13:09 I'm trying to find information in the chat logs at livelogs, but search foo has yet to reveal a way to search those logs. Is there one I'm missing? May 26 17:13:34 I log locally and grep those May 26 17:13:46 Had I that option I would have. Hence livelogs. May 26 17:14:11 use google? May 26 17:15:32 ask me to grep my logs for you? May 26 17:15:36 There we are. I couldn't find that for some reason. (grimace) It's been like a monday. May 26 17:15:45 lol May 26 17:15:52 I will if I fail abysmally otherwise. May 26 17:16:37 I'm trying to avoid relying on you for every little thing I want to do. May 26 17:16:48 I appreciate that May 26 18:05:23 Hello people May 26 18:05:35 i have questions May 26 18:05:47 about life and the universe in general May 26 18:06:00 but for now I will narrow the scope to com ports May 26 18:06:34 I am connecting to a device that is plugged into a Win 10 box May 26 18:06:45 I am going two different ways May 26 18:07:01 one through a micro USB port, which shows as COM9 May 26 18:07:35 and a RS232 cord that is connected to the Tx, Rx and GND pins on the device that shows as COM10 May 26 18:07:55 if I open up COM10 in putty it opens but I cannot get a response from the device May 26 18:08:43 if I open the COM9 port in putty it works. Now COM9 is the same port that the gui configure tool uses. Is there a way to compare COM9 vs COM10 and find out why one works and one doesnt May 26 18:08:49 is it a driver issue? May 26 18:10:50 Connect the COM10 card to something else and verify it's working? May 26 18:11:07 or do a loopback test May 26 18:13:07 Ragnorok: Thor reference? and not sure how to connect the COM10 thing to something else May 26 18:13:40 zmatt: how could i loopback in this scenario? cord is working that was checked. May 26 18:14:10 connect a wire between rx and tx, type in the terminal window May 26 18:14:10 oh wait I misunderstood what you were saying May 26 18:14:36 connecting the device itself via usb means you're not actually using a serial connection at any point May 26 18:14:48 it's just a simulated serial port via usb May 26 18:15:02 so that means none of the serial-port related settings are relevant May 26 18:15:37 ok so I cannot really leverage anything from the COM9 then May 26 18:15:39 darn May 26 18:15:48 thought I was close May 26 18:16:10 yeah the fact that it works via usb doesn't say anything about how close you are to getting it to work via serial May 26 18:16:25 the most common serial port errors are pin connections and bit rate May 26 18:16:31 although really it's probably something obvious, some setting being wrong May 26 18:16:33 indeed May 26 18:17:28 most things use 115200 8n1 May 26 18:18:03 certainly should be the default for anything running on a beaglebone May 26 18:18:22 it supports 9600 baud up to 460800 May 26 18:18:32 depending on how you configure it May 26 18:18:45 (8n1 in all cases, but that's standard) May 26 18:18:56 yes, but the default console setting in u-boot and kernel is 115200 May 26 18:19:04 this isn't about a console May 26 18:19:18 he wants to control some device from the bbb May 26 18:19:23 oh, bad assumption on my part May 26 18:19:34 (though he's first testing with a pc) May 26 18:19:45 MattB0ne: Been using this nick over 30 yrs; it's Norse mythos by accident. (shrug) I was going to chime in but they're paying attention faster than I am. lol It is a Virtual Monday for me, and making up for lost time. May 26 18:20:16 ha May 26 18:20:17 I thought he was trying to connect a win pc to a beagle using something appearing as com9 May 26 18:20:32 this is a load cell digitizer May 26 18:21:26 also, if you ever do end up having to do anything of substance via the bbb's serial console, especially if you want to use vim, I'd recommend reconfiguring things to use 460800 baud, I even recompiled my u-boot for that. since, this may be surprising, using a baudrate that's 4 times higher makes the console 4 times as fast May 26 18:21:31 :P May 26 18:22:38 I usually try to get ethernet working first, then use that for anything serious May 26 18:23:32 of course, something that doesn't work May 26 18:23:34 absolutely, but sometimes the serial console can be handy when debugging boot issues or network issues May 26 18:23:40 like when they forgot to connect the phy clock May 26 18:23:46 lol May 26 18:23:47 or miswired the phy reset May 26 18:24:18 MattB0ne: is its device address (get/set via the "AD" command) set to zero ? May 26 18:24:33 or connected two of the mii rx pins to multiple things May 26 18:24:55 mru: sounds like it would be been worthwhile to double-check those schematics before making a prototype :P May 26 18:25:13 they started sending them to me for review May 26 18:29:38 MattB0ne: browsing the "Communication Setup" chapter of the manual, the only two that seem relevant are Baud-Rate (set to whatever you want to use) and Device Address (set to zero) May 26 18:31:10 and maybe Full-Duplex (set to 1), although I think it should work in both states as long as you don't try to send a command while it's still sending a reply to the previous command May 26 18:51:40 zmatt: let me check May 26 18:54:09 address AD is set to zero May 26 18:54:24 baud rate 9600 May 26 18:56:17 grrr May 26 18:56:25 going to headbutt this thing May 26 19:05:16 I'm not sure that would help May 26 19:05:52 please post a video May 26 19:05:57 haha May 26 19:07:39 that reminds me of someone who said the power led was "on fire" .. I suspect it was just poor translation, but in the event that it isn't I would definitely say that's a situation where I'd encourage priorizing making a video over extinguishing the fire May 26 19:08:43 lp0 on fire May 26 19:11:37 stop bits May 26 19:11:41 can I set to 0 May 26 19:12:14 you can't have 0 stop bits, the minimum is 1 May 26 19:13:00 1 seems to be the most commonly used May 26 19:13:15 yeah more than 1 stop bit is generally not necessary nowadays May 26 19:34:39 ok, I'm back in... "setenv -f capeloadoverlay" did the trick eventually, it prevented the broken cape overlay from being loaded May 26 19:35:09 now, back to finding out why the clock cannot be reparented May 26 19:35:35 I'm guessing, if the timer is already active/enabled, reparenting will fail May 26 19:37:55 oh you were trying to do this on the default system clocksource? May 26 19:38:24 yes, but I think before registering it May 26 19:38:27 you may want to use a different timer and switch to it at runtime May 26 19:38:30 ah, yes, I did May 26 19:38:49 since the default system clocksource is setup during very early initialization May 26 19:39:00 cannot, actually... May 26 19:39:05 ? May 26 19:39:14 the clocksource is in a module May 26 19:39:23 it will switch when it becomes available May 26 19:39:34 ah ok it's not the default clocksource at early boot, ok May 26 19:39:39 no May 26 19:40:06 so, nothing informative on the console w.r.t. why it failed to boot? May 26 19:40:17 (remove the "quiet" cmdline option for more messages if needed) May 26 20:00:06 ok, errno -22 .. May 26 20:00:12 when trying to reparent the clock May 26 20:00:59 EINVAL May 26 20:01:06 indeed... May 26 20:03:56 ok, slowly that makes sense May 26 20:04:12 not the error, but the behavior I'm seeing May 26 20:05:09 there's only one way the dmtimer api can return silently with no error messge, which is when there's no parents available May 26 20:05:56 that would yield an EINVAL from clk_set_parent(), which is what I'm seeing when using the kernel api directly May 26 20:06:02 now the question is, why is it so? May 26 20:07:59 since with debugfs I can clearly see that tclkin_ck is one of the possible parents for timer4_fck May 26 20:08:27 and in fact I've had no trouble reparenting timer5_fck May 26 20:08:33 to tclkin_ck May 26 20:08:54 (timers 4-7 are all equivalent) May 26 20:09:25 why is the debugfs in disagreement with the kernel internal structures? May 26 20:09:42 is it? May 26 20:10:02 I don't really know much about the clock framework May 26 20:14:19 well yes, the debugfs lists 3 possibly parents by name May 26 20:14:58 correct May 26 20:15:09 well, then lets do some printk debugging in the clock core... May 26 20:18:03 this is what my subarctic/prcm.h header says about the timer clock selection: https://pastebin.com/nqFc5JJf May 26 20:23:09 [ 2787.880074] clk_core_set_parent_nolock: clk tclkin_ck can not be parent of clk l4_per_cm:clk:0074:0 May 26 20:23:11 heh May 26 20:23:17 lol what May 26 20:23:21 I'm trying to reparent the wrong clock May 26 20:23:23 yes indeed May 26 20:23:44 dynamic_debug is such a nice feature ;) May 26 20:23:51 yes indeed :D May 26 20:24:43 so, I guess the dmtimer api is just as broken as my code ;) and nobody is using these functions, apparently :-))) May 26 20:24:48 I want psychic debug May 26 20:25:01 it should print exactly the information I need to debug the problem May 26 20:25:17 not transmit it directly to your brain? May 26 20:25:34 maybe I have an rs232 implant May 26 20:40:00 hello i have been trying to walkthrough beaglebone PRU and started with this exemple i found on this site https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/05/14/coding-for-the-beaglebone-pru-with-c-in-2019 May 26 20:40:26 but when i enter this command " echo 'start' > state " May 26 20:40:46 i get this error it return "-bash: echo: write error: Invalid argument" May 26 20:41:15 i want to know to fix this error May 26 20:42:37 one problem I see is that they're assuming that pru0 is remoteproc1, while in fact there's no guarantee that this is true May 26 20:45:57 the latest bb-customizations package should create symlinks at a stable location, let me check May 26 20:46:25 i already talked with you about another problem and you helped me through it May 26 20:46:56 your name seems vaguely familiar yeah (though I generally don't remember who I helped with what) May 26 20:47:04 i flashed the board and you gave me instructions to set the remoteproc May 26 20:47:28 hah, it crashed ;) May 26 20:48:11 and now i have it like this debian@beaglebone:/sys/class/remoteproc$ ls May 26 20:48:45 if you update the bb-customizations package to the latest version ("sudo apt update && sudo apt install bb-customizations", requires internet access) then you should have stable symlinks in /dev/remoteproc/ May 26 20:49:01 I don't know if you just tried to paste something multi-line, but if so: that doesn't work. use a paste service like pastebin.com May 26 20:51:01 if you're sure you're using the right remoteproc device, then 1. check the state ("cat state") before trying to change it... for example, you can't start a core if it's already running, and you can't stop a core if it's already stopped May 26 20:53:09 hm May 26 20:57:29 ok, 'tis a bit weird now May 26 20:58:11 zmatt: it works if I manually clk_get("timer4_fck") and then reparent that to tclkin_ck May 26 20:59:27 but, the "fclk" resource in the plaform device points to the actual selected clock, not to the virtual "_fck" May 26 21:01:10 now I only need to find out why the kernel crashes when it starts using the tclkin_ck. I guess i messed up the pin mux, or the clock is not really reaching the pin, or something May 26 21:15:12 when i use the cat state command "cat state" i get offline May 26 21:15:28 cd .. May 26 21:15:43 has the firmware property been set correctly? May 26 21:15:53 zmatt: hm, your overlay-utils seem to be in slight disagreement with the BBB SRM about how processor pins are attached to P9.41 May 26 21:15:57 also, check kernel log for errors when tring to start it May 26 21:16:10 thinkfat: elaborate? May 26 21:17:06 I have two constants for the two processor pins that attach to P9.41: https://github.com/mvduin/overlay-utils/blob/master/include/bone/pins.h#L104-L105 May 26 21:17:46 include/bone/pins.h, the define for P9_41a,b, the SRM says D14 is io0.20 May 26 21:18:26 the comments behind P9_41a suggest otherwise May 26 21:19:15 good catch May 26 21:19:41 yeah the two comments are swapped May 26 21:19:42 not saying yours is wrong... May 26 21:19:44 I think? May 26 21:19:51 partially May 26 21:20:02 lol what even happened there May 26 21:20:24 okay it's just the cpu balls that are swapped May 26 21:20:31 i.e. the least relevant part of the comment May 26 21:20:45 damn May 26 21:20:50 in kernel log i get the following May 26 21:20:59 now I need to look for an actual reason for the kernel crashing May 26 21:21:00 May 26 21:04:31 beaglebone kernel: [ 62.588329] pru-rproc May 26 21:21:01 523.411585] remoteproc May 26 21:21:12 amine3: don't paste multiline output into chat May 26 21:21:18 use a paste service like pastebin.com May 26 21:21:21 I already said that before May 26 21:21:30 clearly, the timer module has no fclk, because I'm getting an async abort May 26 21:21:40 https://pastebin.com/tQCmP83j May 26 21:21:44 but I'm also quite sure that there's a 10MHz clock May 26 21:21:54 thinkfat: wait no, there's more swapped May 26 21:22:56 ehh, huh May 26 21:23:56 P9_41a is the one you need for tclkin (mode 2) unless my spreadsheet is wrong too May 26 21:25:30 no, that's fine. I used P9_41b and that clearly didn't work. I matched the CPU ball with the SRM but you just confirmed that they're swapped May 26 21:25:47 so P9_41a is probably correct May 26 21:26:19 I just fixed the comment and push it May 26 21:30:15 now show-pins is no more confused May 26 21:30:25 I was complaining about an invalid mode on the pin May 26 21:30:46 :) May 26 21:30:49 which is true, D13 has no valid mode 2 May 26 21:31:11 yeah I never use the cpu balls as identifier, so that's why this slipped through May 26 21:31:27 I use the pin number (i.e. index into the pinmux array) May 26 21:31:33 which isn't package-dependent May 26 21:32:27 oohkay May 26 21:32:29 it seems to work May 26 21:33:12 \o\ May 26 21:33:14 /o/ May 26 21:33:16 \o/ May 26 21:36:33 ok, so now I have a system clocksource that is locked to gps time May 26 21:37:36 and therefore no longer locked to every other timer on the system, including the one used for network packet timestamping :) May 26 21:37:57 yep... May 26 21:38:09 it'll be interesting to see the effect of that May 26 21:38:37 now, waiting for UTC May 26 21:57:35 ok, chrony is happy May 26 21:57:44 System time : 0.000000000 seconds fast of NTP time May 26 21:57:46 :-) May 26 21:58:16 Frequency : 0.000 ppm fast May 26 21:58:32 I wonder if you can tell chrony that system time is frequency-locked to GPS so it will not even consider messing with the frequency May 26 21:58:34 since the frequency is from the gpsdo, that's the expected outcome May 26 21:58:50 actually never mind May 26 22:00:04 you'll have to use ntpdate or something instead of chrony, or I think you can use chrony is an ntpdate-like way (i.e. just perform a single time-correction jump and then exit) May 26 22:01:01 if you keep it running, even if it is able to determine the time offset to correct more accurately, the only way to slew the system time to that improved offset is by changing the frequency May 26 22:01:20 but changing the frequency would completely negate any benefit from using tclkin in the first place May 26 22:01:53 yes.. May 26 22:12:42 well, chrony is now only distributing the system time, which is what a stratum-1 server should do. May 26 22:12:57 ah right May 26 22:13:17 well May 26 22:13:18 I mean May 26 22:13:35 isn't it still responsible for syncing system time to your gps? May 26 22:13:44 and as far as ptp goes, the phc clock was anyway never locked to the system time, so phc2sys just has to do its job May 26 22:14:08 zmatt: yes, it is. it's just gotten a very, very easy job now ;) May 26 22:14:23 not really, especially not since it doesn't know that May 26 22:14:55 it still needs the system time to converge to gps time, not merely be frequency-locked to it May 26 22:15:01 and by doing so, it ends up frequency-unlocked May 26 22:15:50 but it will never find any difference May 26 22:16:13 after the initial "step" to adjust the system time, there will be no drift May 26 22:16:37 assuming the initial step is accurate enough to not improve by multiple measurements over time May 26 22:17:37 and also assuming there's no noise that could make it believe an adjustment is appropriate May 26 22:17:47 both of these could very well be true, it depends on how your setup works May 26 22:57:11 so, eventually it turned out that my friends' bbb was somehow broken. he ordered a new one and it runs now successfully as a ptp grandmaster for some Dante AoIP devices May 26 23:08:44 sweeet! **** ENDING LOGGING AT Wed May 27 03:04:13 2020