**** BEGIN LOGGING AT Wed Mar 23 02:59:59 2016 Mar 23 05:25:13 Hi!! Mar 23 05:25:15 Does BeagleBone Black support Java Swing Applications? Mar 23 08:08:31 Does BeagleBone Black support Java Swing Applications? Mar 23 09:01:07 Who uses the xds100v2? Mar 23 09:12:01 snowstaff: i got one Mar 23 09:22:09 my BBB is not start when i attach it to CPU using USB Mar 23 09:27:19 RMD_: so what were you doing before this problem occureredred? Mar 23 09:32:23 occurred, even Mar 23 09:37:05 hello everybody, I cant connect to my beaglebone black anymore via putty through ip 192.168.7.2 Mar 23 09:40:35 i just connect the BBB to cpu using minicom -s interface but it is not going uo tp login page of BBB BBB Mar 23 09:48:10 RMD_: minicom into which device? Mar 23 09:48:26 elhe: what did you do before that happened? are the LEDs blinking? Mar 23 09:49:35 yes led is blinking but not show the debian login page Mar 23 09:51:15 sorry led is not blinking and not shown the debian login page Mar 23 09:54:38 RMD_: so none of the four LEDs are on? What about the one next to the power port? Mar 23 10:14:16 leds blinking, and had a power outage Mar 23 10:26:30 elhe: does the network interface show up? Mar 23 10:31:23 What low-cost JTAG emulator is best to buy? Mar 23 10:32:05 there's that tincantools device Mar 23 10:32:19 and if you don't mind very slow, a bus pirate will do too, I hear Mar 23 10:33:47 What about this - TMS320-XDS100-V3? Mar 23 10:38:03 tbr: it shows the Linux USB Ethernet/RNDIS Gadget in the device manager Mar 23 10:38:56 tbr: and on com5 the Gadget Serial Mar 23 10:41:22 or TMDSEMU100v2U-20T? Mar 23 10:41:26 elhe: you could try accessing it over the serial interface (also works with putty) Mar 23 10:49:27 ok it works over serial and everything in the etc/networks/interfaces is as it was Mar 23 10:58:44 if the problem persists over reboots, then I don't know Mar 23 10:59:21 you could try setting an IP manually on the PC side (192.168.7.1, IIRC) Mar 23 11:00:52 hi does someone know if the 2 SPI BB can be interconnected (when HDMI disabled) Mar 23 11:11:39 tbr: it persists over reboots, but additionaly when I try to make a new file it says no space left on device. Is this a symptom of anything ? How can I make sure Im on the sd card and not on the mmc Mar 23 11:14:30 elhe: ah, maybe it's just an overflowing filesystem then Mar 23 11:14:55 elhe: you could try cleaning up, or removing unused packages Mar 23 11:20:34 tbr: it says, that /dev/mmcblk0p1 is 100% used Mar 23 11:22:24 and the tempfs is 0 % used Mar 23 12:12:00 Hi guys, so this my first time using BBB, I've installed the Adafruit_BBIO.GPIO Python library, I am trying to turn a led on Pin 12 (Port 9) or P9. However, it doesn't seem to workas all i did was http://pastebin.com/HuHxyx27 , So any idea why the Python script didn't work? Mar 23 12:17:08 UPDATE: well, I had to use root permission to make it run with Python, I don't know why, but it works like that. Mar 23 12:24:20 That's weird. Mar 23 12:24:50 Well, maybe not; you're directly accessing GPIO, so perhaps they want that restricted to admin. Not sure; I'm new to BBB myself. Mar 23 12:28:01 @Nevyn|Work: When creating the gpio60 for Pin12 on Port 9, in /sys/class/gpio I had to switch to root also Mar 23 12:29:29 But I like it! However you have to beware when using root permissions Mar 23 12:31:59 houssam: does it work if you sudo run it? Mar 23 12:32:34 Yes yes! All I did was running the python script with sudo! Mar 23 12:32:53 without sudo nothing works! Mar 23 12:33:03 Well, that's good - at least you don't have to be logged in as root Mar 23 12:33:17 Yeah Mar 23 12:34:08 houssam: https://github.com/adafruit/adafruit-beaglebone-io-python/issues/36 Mar 23 12:38:08 I was just going to send this! I prefer not to change anything in the default code of event_gpio.c as the guy said. Mar 23 12:38:27 just use sudo when required, that's safe! Mar 23 12:38:29 Ithink Mar 23 12:40:39 If any thing should be patched, is adding some error handling like notif msg to run python scripts as root. Mar 23 14:35:09 hi, anyone know how to link a .cmd file in CCS? Mar 23 14:41:33 tbr: The solution indeed was making room on the sd card+# Mar 23 14:50:37 i'm experiencing problems with uart1_txd on embest bbb rev-C. i have capes using uart1 as 232, none of them working as expected. can't seem to see anything flowing between uart1_txd and gnd while making requests. are there any known problems? Mar 23 14:51:22 i got it, nvm Mar 23 14:53:17 elhe: glad yougot it solved Mar 23 15:08:13 tbr: thanks again Mar 23 15:10:28 np Mar 23 15:11:15 hi, did something change with linux defconfig for AM335X? I don't see it in arch/arm/configs Mar 23 15:13:22 wasn't the general arm defconfig preferable nowadays (I don't know, I don't follow that) Mar 23 15:16:35 ok, maybe it is, last time I did this was when 4.0 came out Mar 23 15:26:32 maciejjo: normally easiest is to use rcn-ee's build scripts Mar 23 15:27:33 does it do anything special? Mar 23 15:27:38 where you can do ./build_deb.sh and voila you end up with something equivalent to the -bone or -ti kernel debs Mar 23 15:29:08 ok, good to know for future use, but now I want to assemble everythig "by hand" Mar 23 15:29:16 uboot, linux rootfs Mar 23 15:29:35 as an excercise Mar 23 15:29:44 well it does everything necessary to go from a mainline kernel + pile of patches + config file -> compiled kernel/modules/dtbs (optionally wrapped in deb) Mar 23 15:30:27 bbb is not supported with upstream kernel w/o patching? Mar 23 15:32:21 maciejjo: vanilla should work Mar 23 15:32:25 it probably is nowdays yes Mar 23 15:32:43 maciejjo: the patches just add a few conveniences that didn't reach upstream release yet Mar 23 15:32:46 you won't have capemgr obviously Mar 23 15:33:02 ok, don't need Mar 23 15:33:03 last time I checked the number of patches was surprisingly small Mar 23 15:33:15 tbr: and reversed one annoying upstream change :P Mar 23 15:33:35 heh Mar 23 15:34:39 are devicetree overlays supported in new kernels? I read somewhere they are not Mar 23 15:35:18 I thought they were (via the configfs mechanism) but I'm not sure... Mar 23 15:36:17 ok, I will check it later Mar 23 15:36:18 you can btw find all patched kernel trees from rcn-ee here -> https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Mar 23 15:36:36 ok, cool Mar 23 15:39:05 this is the build scripts/patches repo for the -bone kernels (you need to select the appropriate kernel series from the branches) -> https://github.com/RobertCNelson/bb-kernel Mar 23 15:40:32 same for -ti kernel series -> https://github.com/RobertCNelson/ti-linux-kernel-dev Mar 23 16:02:04 w Mar 23 16:04:32 hello I have a bbb and I cant get it to flash the eMMC Mar 23 16:53:46 kremlin: you pass it to the linker... e.g. clpru -z blah.cmd Mar 23 16:53:54 i got it :) Mar 23 16:53:59 btw Mar 23 16:54:07 the hex output format really saved my ass. thanks for that suggestion Mar 23 16:55:45 I'm still weirded out by the "bin.cmd" file that's included with ti-cgt-pru_2.1.1 which looks like a linker file but is syntactically invalid as far as I can tell Mar 23 16:55:52 im still not clear on what the .t01/.x01/etc files are Mar 23 16:56:46 ahh wait that's not a linker file, it's a hexpru file Mar 23 17:35:31 hmm Mar 23 17:36:21 i'm debugging the PRU through CCS & a jtag USB header. my code that generated a PWM signal via the egpio pins doesn't work anymore and i think it's because i haven't done the device tree overlay stuff like i did when the chip was running linux and not being debugged Mar 23 17:36:29 anyone know how to account for this in my code? Mar 23 17:37:04 I don't see any immediate reason for why that would be Mar 23 17:37:24 i just have inline asm setting r30 bit 15 up and down in sequence Mar 23 17:37:32 up, down, JMP back to up Mar 23 17:37:35 but nothing on my scope Mar 23 17:37:45 P8, pin #11 Mar 23 17:37:50 is the correct pinmux setup ? Mar 23 17:38:02 that is what i think is wrong Mar 23 17:38:09 but i don't know how to fix it other than through linux Mar 23 17:41:20 well, you can check my pins spreadsheet https://goo.gl/Jkcg0w ... either the BBB tab for a long list, or the P8 tab for an overview of that expansion header Mar 23 17:41:46 I've seen C code somewhere that does it directly, but that may have been for 'nix as well. Sadly I don't recall specifics. Mar 23 17:41:57 notice that P8.11 has "pru 0 out 15" as function 6 (column header F6) Mar 23 17:42:42 yes Mar 23 17:42:54 i have a printout of the one from the SRM taped to my desk Mar 23 17:43:02 it'd be great if i could just do this through uboot Mar 23 17:43:11 since i have that up on the FTDI Mar 23 17:43:44 I made a spiffy class for the padconf registers https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/ctrl.h#L19 ... there's no way in hell that a TI compiler will support it (it needs gcc 5) but you can use it to see what the bit layout is Mar 23 17:44:29 in this case you want mode 6, and the rest doesn't hugely matter Mar 23 17:44:59 ah cool! thanks Mar 23 17:46:12 so you write 0x6 to index 13 (offset 0x34) of the padconf array in the control module Mar 23 17:47:47 for inputs you'd also want rx_en set (bit 5) Mar 23 17:48:24 unless you're explicitly trying to micro-optimize power consumption, it's safe to always enable rx_en Mar 23 17:49:42 I also recommend leaving pull enabled in the reset-default direction Mar 23 17:50:29 note that setting pinmux cannot be done by a PRU core itself Mar 23 17:51:11 gotcha Mar 23 17:51:14 yes, i have two projects Mar 23 17:51:30 you cannot actually init. the PRU without first initializing the ARM core Mar 23 17:52:00 well, via jtag you could of course, but indeed the a8 is always the boot processor Mar 23 17:53:01 of course it might be desirable to setup PRU R30 *before* you enable pinmux Mar 23 17:53:10 to avoid driving random values Mar 23 17:54:10 the reason pru cannot do pinmux is because pru reads/writes are always unprivileged, and the control module ignores unprivileged writes Mar 23 17:58:57 (if you really really need it there's always a dirty hack you can do: have a privileged initiator setup EDMA with a QDMA channel and a PRU-triggerable DMA channel from PRU memory to the QDMA descriptor Mar 23 17:59:01 ) Mar 23 18:00:53 (a chain-linked regular DMA channel would also work instead of using QDMA) Mar 23 18:01:07 whoa Mar 23 18:01:14 that is probably overkill for what im trying to do Mar 23 18:02:17 yes, but it would give PRU a generic mechanism to perform privileged DMA transfers from anywhere to anywhere ;) Mar 23 18:02:30 (in the background, while PRU can do other things) Mar 23 18:14:42 btw, useful to know: the --ram_model (short: -cr) option implies that all global variables are initialized at load-time, hence if you simply restart the PRU core they won't get reinitialized, you need to reload instead. The alternative is --rom_model which initializes all non-constant global variables at program startup (from an initialization table in the .cinit section) Mar 23 18:17:01 The PRU seems neat but I can't think of anything to do with it currently. Mar 23 18:17:03 also, I noticed that the standard linker map rudely allocates "far" memory at 0x80000000 .... if there's anything running on the cortex-a8 it is most likely not going to appreciate that Mar 23 18:18:50 MathOnNapkins: I had the same problem for quite some time Mar 23 18:20:14 then came the moment I needed to man-in-the-middle an SPI bus Mar 23 18:21:03 (to let some other SPI master think it can directly communicate with a chip that's actually on our SPI bus) Mar 23 18:22:47 I thought about using it as something to offload data from a photodetector array (1 dimensional), but judging from the docs I would need to employ a UART as the PRU doesn't have enough input pins (13? 14?) to accept the data in parallel (16 bits wide). Mar 23 18:24:50 both PRU cores have 17 inputs, though not all are pinned out on the BBB Mar 23 18:25:45 you could however have each core receive 8 bits Mar 23 18:32:19 (and use xin/xout 14 to pass it to the other core) Mar 23 18:50:07 The broadside interface is pretty neat. Don't use it, but it's pretty neat. Mar 23 18:52:23 MathOnNapkins: Imo if one doesn't need low-latency access to data the PRU has little use. I also thought PRUs had like 30 inputs? I'm using none, so I wouldn't know. Mar 23 18:55:01 I thought about working around it but tabled it I'm looking at FPGAs instead as our company is currently using CPLDs and I think we build a lot more flexible product with more modern parts. Mar 23 18:55:08 *we could Mar 23 18:55:57 those tend to be fairly expensive though right? Mar 23 18:56:12 The larger ones can be ridiculously expensive Mar 23 18:56:21 even the smaller ones Mar 23 18:56:44 Xilinx has a SoC that integrates a Dual Core Arm processor and an FPGA of reasonable size for about $57 called the Zynq Mar 23 18:56:54 I'm currently looking at that, don't know if we'll end up using it Mar 23 18:57:00 an am3356 is around $13 in low qty Mar 23 18:57:30 Yeah, a cost benefit analysis is definitely in order Mar 23 18:59:22 btw my pins spreadsheet (http://goo.gl/Jkcg0w) also has PRU tab showing various pru pins and where they can be found... I've marked the BBB pins already used by eMMC in purple so they can be avoided, I'm about to also colorize BBB pins that conflict with hdmi output (for those people that care) Mar 23 18:59:35 Most of the price of that part is probably the programmable logic. A low end Artix 7 is $32 Mar 23 19:00:15 But if we can fit everything into a lower end part we will Mar 23 19:00:54 right, while PRUSS is about $2-$3 since the AM335x versions with PRUSS disabled are cheaper by that amount iirc (again in low qty) Mar 23 19:06:23 Do you know if PRU is able to initiate DMA to other RAM sections? Part of why I wasn't too enthused about using it was that it seemed to have a limited amount of RAM to work with. Mar 23 19:06:43 PRU can access everything Mar 23 19:07:01 oh? Well that's +10 points for house PRU Mar 23 19:07:13 I'll have to give it another look Mar 23 19:07:38 It's just slower if it's off-PRUSS. Mar 23 19:07:47 Ah Mar 23 19:07:49 obviously, slower and non-deterministic Mar 23 19:07:58 quantum ram? Mar 23 19:08:03 timing Mar 23 19:08:17 There are no timing guarantees whatsoever? Mar 23 19:08:25 But it works fine, if ultimate performance isn't a criteria. Mar 23 19:08:50 I just don't want to ever miss data coming in from this other part (the detector) Mar 23 19:08:59 I want to get it cached away to a large RAM buffer ASAP Mar 23 19:09:20 That's what I'm doing, but it's low data rate by today's standards. Mar 23 19:09:47 if other initiators (e.g. the cortex-a8) are also accessing RAM you may need to look carefully into prioritization / latency settings Mar 23 19:09:54 Uh, I think this is probably 4096 bytes / 300 microseconds or so Mar 23 19:10:22 What does that work out to... Mar 23 19:11:55 13 MiB / sec or so? Mar 23 19:12:06 there's also the 64 KB of on-chip SRAM btw Mar 23 19:12:26 I'm at 2 bytes every 125us. Just shy of glacial. Yours is one byte every 14.6 PRU CPU cycles. Mar 23 19:13:16 That's also on the upper extreme for us in terms of bandwidth and the low end for latency between samples Mar 23 19:13:34 Reality usually has looser requirements Mar 23 19:13:34 MathOnNapkins: it depends a bit on what the cortex-a8 is doing and how EMIF is configured Mar 23 19:13:38 Natch parallel would give a lot more time. Mar 23 19:13:58 hrm Mar 23 19:15:06 Well thank folks I appreciate the information (and attempts to get me to commit to the PRUSS dark side :) ) Mar 23 19:15:07 recently people have traced display glitches to LCDC underflows happening due to its DMA reads hanging out for too long in EMIF's command queue Mar 23 19:15:14 I will have to do a bit more homework to figure out if this is feasible Mar 23 19:15:33 then again, LCDC is fairly high rate, its fifo is small, and people were able to solve it by fiddling with EMIF settings Mar 23 19:17:04 they also managed to solve it by running the cortex-a8 at a lower frequency Mar 23 19:18:22 it *should* be possible to strictly prioritize PRU requests in EMIF, but the documentation on its prioritization settings is... sub-optimal Mar 23 19:19:48 Well, our systems are pretty much headless, display glitches be damned Mar 23 19:19:50 One is happy to be of service. (grin) Mar 23 19:22:16 MathOnNapkins: point was: lcdc requests to EMIF were getting stalled due to heavy EMIF traffic from cortex-a8 Mar 23 19:22:32 if it can happen to lcdc, it can happen to pru Mar 23 19:22:45 ohhhhhhhh Mar 23 19:22:47 durp Mar 23 19:23:27 So develop an light weight that throttles the Cortex-A8, got it :) Mar 23 19:23:32 *lightweight OS Mar 23 19:23:50 **a Mar 23 19:23:50 like I said, underclocking (to 800 MHz iirc) the cortex-a8 already solved the problem Mar 23 19:24:28 I must have been disconnected when you said that, it's not in my scrollback Mar 23 19:25:28 I thought typical OS settings kept it clocked under that anyway? Mar 23 19:25:34 (In terms of Linux) Mar 23 19:25:43 on a BBB it'll be 1 GHz Mar 23 19:25:57 public ROM sets it up at 500 MHz Mar 23 19:26:22 u-boot yanks it up (depending on which board is detected) Mar 23 19:26:41 Which board as in BBB versus BBW? Mar 23 19:27:08 Are we calling it BBW? (white) Mar 23 19:27:10 versus evm and various other am335x boards Mar 23 19:27:12 I can't remember Mar 23 19:27:15 ah Mar 23 19:27:30 yeah BBW is typical abbreviation Mar 23 19:28:22 setting PR_OLD_COUNT in emif to a low value also avoids high latencies (potentially at the cost of lower average efficiency/throughput) Mar 23 19:31:49 in theory it should also be possible to prioritize PRU specifically, but the relevant settings are not extremely clear (and it's tricky to confirm they're doing their job) Mar 23 19:36:00 and there are L3 statistics collectors that can measure request latencies and I think even make histograms of them, but they're not documented at all in the TRM. I still hope to to get them to work some day based on their (poor) documentation in other TI SoCs Mar 23 19:39:35 Hi, I need to change the resolution on my DS18B20 one-wire temperature sensors. Does anyone know off hand if ther is a BBB program to do this? All I can find are arduino scripts ... Mar 23 19:44:19 if you already have a way to communicate with it, it can't be that hard to write the config register instead of reading the temperature registers? Mar 23 19:45:37 Hurm. init S appears to have boned my beaglebone. Interesting. Mar 23 19:45:51 Ragnorok: ? Mar 23 19:46:36 yeah, I'm looking at getting down low with the data sheet and doing it all myself - so far I've had my data spoon fed through owfs Mar 23 19:47:39 I did an init S and now it won't boot. Well I take that back. It does boot, but ssh doesn't work, which may be an artifact of S, which I thought was single-user mode. Serial console doesn't let me login either, though, so I'm not certain how to recover. Mar 23 19:48:07 power cycle? Mar 23 19:48:14 Did. Twice. Mar 23 19:48:21 that's weird Mar 23 19:48:37 I actually expected a cold boot to fix it, as it were. Mar 23 19:48:43 so would I Mar 23 19:48:57 My recollection is init S shouldn't be permanent. Mar 23 19:49:03 correct Mar 23 19:49:21 so what's the console output show? Mar 23 19:50:06 I have the static IP hack in, because we need static IP. Let me pastebin it or so. Mar 23 19:50:58 a. since when is normal configuration considered a "hack" ? b. what's that got to do with the console output? Mar 23 19:53:21 a. I assumed editing a cryptic script in /opt/scripts/boot, in numerous places, had to be a hack. b. Possibly nothing. I simple provide that information in case it's relevant. Mar 23 19:53:29 http://pastebin.com/brdG5cBp Mar 23 19:55:02 I'm a bit confused why the normal 7.2 USB IP doesn't appear, and those 3. IPs are definitly not normal. Mar 23 19:55:39 but, you can login the console now right? Mar 23 19:55:56 So I popped the SD I was booting from and tried the eMMC. It won't boot at all. Nope. Console is dead. I get to the login and it won't respond. Mar 23 19:56:53 Another power cycle and eMMC boots, but console is still not responding. Mar 23 19:57:28 Keeps tossing out net eth0: phy .... not found on slave 1. Mar 23 19:57:30 why are you showing me a boot log if it's not the one from the boot that's having problems? Mar 23 19:57:37 that message is harmless Mar 23 19:57:52 All boots are having problems. I'll put the SD back in so I'm using that one. Mar 23 19:59:00 Ok. Back to the one I pastebin-ed. Login unresponsive. It did however print my IP & the USB IP this time, and they ar both correct. Mar 23 19:59:07 also be very careful since it seems you're not using UUID-based rootfs, hence if SD is inserted there's a risk booting a mixed system (kernel and initramfs from one, rootfs from the other) Mar 23 19:59:42 Interesting. Hasn't happened so far, but that doesn't mean it's not happening now. Mar 23 19:59:52 Console & SSH both unresponsive. Mar 23 20:00:28 you get a login prompt yet console unresponsive? are you sure you don't accidently have hardware flow control (rts/cts) enabled? Mar 23 20:00:42 It isn't, but I'll double-check. Mar 23 20:01:09 115200 N81 no partiy no flow control. Mar 23 20:01:21 I guess N is no parity. (grin) Mar 23 20:04:10 There we go. It lives! I'd switched cables to a segment w/ DHCP when I tried eMMC boot. Right cable gives me ssh. Mar 23 20:04:56 Console is still dead though. Weirdness. Mar 23 20:05:24 as for the scripts in /opt/scripts/boot .. no idea, I don't use them Mar 23 20:05:46 I presume there is a better way to do static IP but so far I haven't found it. Mar 23 20:06:13 The used to be normal /etc/network/interfaces has no effect. Mar 23 20:06:29 I think mainline images now use connman as network manager Mar 23 20:06:33 I know nothing about it though Mar 23 20:06:46 Ok. I'll research "conman" and see what happens. Mar 23 20:06:57 I use systemd-networkd but for that you need debian stretch since jessie's systemd is too old Mar 23 20:07:00 connman Mar 23 20:07:00 not conman Mar 23 20:07:07 Roit. Mar 23 20:07:53 I liked interfaces. It was simple and repeatable. Apparently others didn't. (shrug) Mar 23 20:09:45 it resulted in terrible boot time Mar 23 20:09:52 if eth wasn't plugged in Mar 23 20:09:58 Ah. Interesting. Mar 23 20:10:06 because it was completely synchronous Mar 23 20:10:33 Makes sense. I guess I never it w/o a cable. Mar 23 20:10:54 I now use systemd-networkd which is also really easy but responds nicely to dynamic changes (and plays well with its sibling services such as systemd-timesyncd) Mar 23 20:11:17 ls Mar 23 20:11:24 What version is stretch? Mar 23 20:11:50 which os is best to port in Beagle Mar 23 20:12:06 zmatt: timesyncd has pretty _nasty_ clock behaviour btw. Mar 23 20:12:06 Ragnorok: https://www.debian.org/releases/ Mar 23 20:12:14 Spidler: in what sense? Mar 23 20:12:15 ( chrony isn't better ) Mar 23 20:12:20 Clock jitter Mar 23 20:12:26 It's stepping it in weird ways. Mar 23 20:12:38 zmatt: Ugh. That won't work for me I don't think. Maybe later. Mar 23 20:13:02 Ragnorok: all our beagles run stretch, never had any problems Mar 23 20:13:26 all mine run Jessie, no weird issues there either :) Mar 23 20:13:27 Cool. You're more versed than I, I wager, in BBB operation. Mar 23 20:13:49 We run NM over systemd-networkd due to being on Jessie Mar 23 20:13:58 Spidler: well, whenever I use a jessie system I do sooner or later run into the "fuck, this doesn't work yet since is too old" Mar 23 20:14:13 and Fedora didn't act very well on BBB for some reason, didn't have time to dig there Mar 23 20:14:30 zmatt: Yeah. Or "shit, they backported something rather than fixing it, STAB STAB STAB" Mar 23 20:14:59 If all the times I had frustrations against Debian ended up with me building Stabbing-over-IP , most of the debian maintainers would be dead by now. Mar 23 20:15:00 Spidler: but you're saying timesyncd *steps* the clock? it doesn't implement the ntpd clock sync algorithm? Mar 23 20:15:03 zmatt: So you're running generic Debian, not a -boneNN version? Mar 23 20:15:27 Ragnorok: ehh, what do you mean by that? Mar 23 20:15:44 Just a plain distro without all the BBB specific bits. Mar 23 20:16:06 I started with rcn-ee's latest (at the time) console image, removed some crap, upgraded to stretch, then installed and configured things as desired Mar 23 20:16:27 Ah, ok. Mar 23 20:16:40 zmatt: they call adjtime, but... Not very pretty. Mar 23 20:17:17 ew, it's an SNTP client, not an NTP client... never realized that Mar 23 20:17:17 zmatt: they step it with up to 0.4 seconds at the time. Mar 23 20:17:35 and seriously.. 0.4 seconds is FUCKING HUGE. Mar 23 20:17:42 yes, it is Mar 23 20:17:58 https://github.com/systemd/systemd/blob/master/src/timesync/timesyncd-manager.c <-- source here Mar 23 20:19:18 SAme with chrony btw. Mar 23 20:19:49 chrony uses adjtime and doesn't step Mar 23 20:19:53 I liked how it made sure the clock would at least be monotonic if you cold reboot, and automatically responded to network up Mar 23 20:19:58 yea Mar 23 20:20:00 Me too Mar 23 20:20:03 except for the initial sync Mar 23 20:20:07 I really like that. Mar 23 20:20:51 anything that uses adjtime instead of adjtimex isn't an NTP implementation :P Mar 23 20:21:21 my BBB running chrony has offsets between -0.64 us and +0.52 us 99.8% of the time Mar 23 20:21:35 I'm sad that PHK seems to have stopped his work on ntimed :( Mar 23 20:22:03 And the alternative seems to be ESR code. And I don't volounteer to touch code that ESR is involved in Mar 23 20:22:18 lol Mar 23 20:22:36 Seriously, the man is a personification of toxic ego. Mar 23 20:23:03 Spidler: your topic is drifting, check your internal clock Mar 23 20:23:22 ddrown: Yeah, I should go back to ranting about json :) Mar 23 20:23:28 ddrown: can't, adjtime() can't do frequency adjustment Mar 23 20:23:48 zmatt: oh you're right, I was thinking of adjtimex Mar 23 20:24:32 Mmm Mar 23 20:24:47 Spidler: so remind me why we're not using the reference ntp implementation? (and perhaps patch it to do aforementioned two things that are nice about systemd-timesyncd) Mar 23 20:24:55 I think the correct approach would be to make timesyncd a proper ntp implementation. Mar 23 20:25:21 zmatt: Because ntp reference is 370k lines of code and assumes server mode by default, and has some other absurd issues. Mar 23 20:25:28 right Mar 23 20:25:44 It also does it's own string and memory manipulations Mar 23 20:26:32 can we yank out the actual clock sync code? since that is really non-trivial and well-tested Mar 23 20:27:04 note btw that having a client be able to act as a simple NTP server can be quite useful at times Mar 23 20:27:45 Probably. Mar 23 20:28:11 though I guess it could just as easily be a separate service Mar 23 20:28:12 I'd probably look at kidnapping the ntimed time sync / calc code and merge into timesyncd Mar 23 20:28:47 why ntimed rather than ntpd ? Mar 23 20:29:07 ~4k loc, better timekeeping than ntpd, modern C code base Mar 23 20:29:27 sounds good Mar 23 20:29:35 https://github.com/bsdphk/Ntimed Mar 23 20:30:19 He Mar 23 20:30:30 He's still blogging though, so it might not be totally dead. Mar 23 20:35:51 20160220 I am getting very close to releasing the next version of Ntimed-client Mar 23 20:44:24 Yeaps Mar 23 20:45:17 But I'm not impressed by his HTTPS timekeeping thing. MEH. Mar 23 20:45:24 TLS already _has_ exact timestamps Mar 23 20:46:16 maybe you should mention that (by itself non-obvious) fact to him Mar 23 20:46:33 https://github.com/ioerror/tlsdate Mar 23 20:48:10 still, the worst possible time-mismanagement I've ever seen was some GPS navigation device which didn't know the time... you had to manually set the system time for it to be able to show ETAs and such Mar 23 20:48:23 .... That.. sounds just absurd Mar 23 20:48:39 If you have a GPS reciever you have, by definition, accurate timekeeping... Mar 23 20:48:43 I know Mar 23 20:48:53 in fact, that's pretty much all there's in a GPS signal Mar 23 20:49:31 (that and reports on potential nuclear explosions, but I think that's transmitted on a different frequency) Mar 23 20:49:58 Haha Mar 23 20:56:58 bah. google groups breaks gpg signatures on mails sent to lists :( Mar 23 21:30:05 Spidler: he knows about tlsdate... but the TLS-layer timestamp is also only 32-bit, and some implementations fill it with random bytes Mar 23 21:31:56 Ah right Mar 23 21:32:06 So instead parsing timestamps in a text format... *shudder* Mar 23 21:32:38 ok, I'm off. tata. Mar 23 21:45:13 hello Mar 23 21:45:56 I've booted this image from sdcard "Debian 8.3 (BeagleBone, BeagleBone Black, SeeedStudio BeagleBone Green, element14 BeagleBone Black Industrial, Arrow BeagleBone Black Industrial - 4GB SD) 2016-01-24" Mar 23 21:46:11 But hdmi is not working (monitor says no signal) Mar 23 21:46:25 do i have to flash the emmc in order to get hdmi? Mar 23 21:46:44 i'm using a 5v 2a adapter Mar 23 21:46:54 beaglebone black, btw Mar 23 21:48:19 hdmi worked when i simply booted off the emmc as it shipped Mar 23 21:49:15 i'm going to try debian 7.9 too Mar 23 22:02:21 toby1: do you have a kernel log? Mar 23 22:07:24 also, be slightly careful when trying different images/kernels: merely rebooting does not reset the HDMI framer, so sometimes some configuration can be leftover from a previously booted kernel Mar 23 22:07:38 only power cycling resets the hdmi framer Mar 23 22:07:56 i unplugged and then plugged in the adapter Mar 23 22:08:07 yes that'll do ;) Mar 23 22:08:40 but it's worth knowing this subtle fact when trying to figure out a hdmi issue and switching between kernels to try to figure out when it appears Mar 23 22:08:56 zmatt: you were asking for dmesg? Mar 23 22:08:59 yeah Mar 23 22:09:26 hold on a sec, i'm writing the image with 8.3 again, 7.9 seems to work fine but it also seems to be the exact same on it shipped on the emmc with Mar 23 22:09:52 I also have a utility which dumps a fair amount of state of the lcd controller: http://gerbil.xs4all.nl/lcd-util.tgz Mar 23 22:10:07 ok thanks i'll check it out Mar 23 22:10:10 note that eMMC vs SD shouldn't matter Mar 23 22:16:39 zmatt, here you go http://pastebin.com/td75UbCb Mar 23 22:17:20 hold on, that paste is wrong Mar 23 22:19:08 http://pastebin.com/R631pmKD zmatt Mar 23 22:22:22 hmm Mar 23 22:22:42 [ 18.599500] tilcdc 4830e000.lcdc: No connectors reported connected with modes Mar 23 22:23:03 what does that mean? Mar 23 22:23:28 not sure Mar 23 22:23:51 can you try to see if unplugging/replugging hdmi causes any events in the kernel log? Mar 23 22:24:25 sure Mar 23 22:27:50 zmatt: there are no new events when doing that Mar 23 22:28:11 weird. as a workaround you can also try forcing lcdc to enable with a particular resolution by adding a suitable "video=" option to the kernel cmdline ("cmdline" variable set somewhere in /boot/uEnv.txt) Mar 23 22:28:31 e.g. I've used video=HDMI-A-1:1440x1080R@50e on some occasion Mar 23 22:29:13 to force 1440x1080 resolution on a 1920x1080 monitor Mar 23 22:29:49 the R means reduced blanking... I expect most lcd screens are fine with it and it reduces the pixel clock rate Mar 23 22:29:58 the final e is force-enable Mar 23 22:31:02 I'm afk for a while... if you're still around later I can see if I can help you hunt down the cause of the problem Mar 23 22:31:58 http://pastebin.com/1ze4sTTB zmatt, this is new Mar 23 22:32:43 toby1: just for fun, try a non-RT kernel Mar 23 22:32:47 just in case Mar 23 22:32:54 ok Mar 23 22:33:20 sudo apt-get update && sudo apt-get install linux-image-4.1.18-ti-r54 Mar 23 22:33:24 for example Mar 23 22:33:54 afk now Mar 23 22:34:08 thank you very much Mar 23 23:33:53 ray123 **** ENDING LOGGING AT Thu Mar 24 02:59:58 2016