**** BEGIN LOGGING AT Fri Aug 12 02:59:58 2016 Aug 12 03:10:09 hmm Aug 12 03:10:26 the am335x CLKSEL/M2 registers allow you to select some seemingly impossibly fast clocks Aug 12 03:10:31 in the range of dozens of GHz Aug 12 03:10:43 at least, that is what the java clock tree tool is telling me Aug 12 03:11:28 zmatt: around? Aug 12 03:13:58 kremlin, I would guess that’s some ambitious futureproofing. I would guess that not all those modes are supported. What the designers anticipate a chip will do and what it winds up doing are often two different things. I would stick to what the Datasheet tells you are allowed values. Aug 12 03:16:47 Tenacious-Techhu: i am using values allowed by the TRM Aug 12 04:09:10 kremlin: pll config has a long list of constraints Aug 12 04:09:21 are these noted somewhere? Aug 12 04:09:33 im following the restratins in the TRM Aug 12 04:09:40 check the datasheet Aug 12 04:09:44 k Aug 12 04:11:19 also, max dco frequency of a PLL is 2 GHz Aug 12 04:12:39 (for both types of PLLs used, across all devices I'm sufficiently familiar with to make statements about) Aug 12 04:14:13 :) Aug 12 04:15:29 ok actually in later devices they bumped the limit slightly to 2.8 GHz Aug 12 04:16:09 but e.g. to run the cortex-A15 at 1.5 GHz on the omap5, the /2 divider normally present is disabled and replaced by a duty cycle corrector Aug 12 04:18:24 also, I just discovered the prcm of the am335x is even more poorly "designed" (more like ductaped together) than I previously thought Aug 12 04:18:33 how so? Aug 12 04:18:36 ive been battling it all day Aug 12 04:21:35 I've been playing a bit with it in response to questions about what can wake the processor up from standby (PD_MPU = off, PD_PER = on) Aug 12 04:21:45 (the answer btw is: any irq) Aug 12 04:22:43 discovered lots of... interesting... behaviours in the process Aug 12 04:24:25 so, for example Aug 12 04:25:00 subarctic only uses modulemode 0 (disabled) and 2 (enabled), needless to say a mode 1 (auto) also exists on e.g. omaps Aug 12 04:25:28 alright Aug 12 04:25:31 so far so good Aug 12 04:25:53 I think any given module only uses 1 or 2, just depending on the module (but don't hold me to it, maybe there are modules supporting both) Aug 12 04:26:54 2 means the clock domain is woken up (if allowed), the module's functional clocks are enabled and its interface(s) are connected Aug 12 04:27:25 as long as it's in 2 the clock domain can't enter sleep Aug 12 04:28:39 1 otoh means the module doesn't force the clock domain to stay active, rather it just disconnects/connects the module when the clock domain sleeps/wakes Aug 12 04:28:54 in theory it should remain operational while disconnected Aug 12 04:29:49 now the am335x on paper only uses modulemode 2, but in fact for many modules it turns out this *behaves* as if it were modulemode 1 Aug 12 04:30:35 geez, that is...interesting Aug 12 04:31:37 wait, #beaglebone is not the official irc channle for beaglebone? Aug 12 04:31:46 the gpio modules are among them, which aligns with the a remark in the TRM that any gpio can be used to wake the system from sleep Aug 12 04:31:53 CygniX: no, this is. welcome! Aug 12 04:32:10 lol, I have been there for months, wondering zmatt, thanks Aug 12 04:32:28 I was curious, because I thought the community was much bigger Aug 12 04:33:41 kremlin: except for one little detail: the functional clock of the gpios *is* their interface clock, hence sleeping the l4ls clock domain freezes the gpio modules, making them unable to generate any irq Aug 12 04:34:09 which sort of precludes chance of wakeup Aug 12 04:34:28 yes. only gpio0 is capable of async wakeup Aug 12 04:35:10 (it's also on l4wkup instead of l4ls) Aug 12 04:37:17 next part was the puzzle how the system could wake up: if the cortex-a8 is disabled, and the cortex-m3 doesn't receive irqs from gpio1-3 Aug 12 04:37:25 yeah Aug 12 04:38:07 this seemed straightforward: the interrupt controller of the cortex-a8 is actually not on PD_MPU but in PD_WKUP Aug 12 04:38:45 (not in the "core" power domain as the MPU chapter claims, that documentation has simply been copied from the omap3 without correcting it for all differences) Aug 12 04:40:28 and whaddyaknow, that actually works: whenever the arm intc signals an irq to the cortex-a8 (whether on or off), an irq of the m3 is asserted Aug 12 04:41:06 hmm Aug 12 04:43:06 on the other hand, I'm not entirely clear why we needed that m3 in the first place since the irq also seems to cause the MPU to assert a wakeup request to prcm which proceeds to enable the power domain, clock domain, and module... even though all are set unabiguously to "off" Aug 12 04:43:41 ah no wait, not power Aug 12 04:43:50 actually yes, power also Aug 12 04:44:29 if power isn't cut (but the module and clock domain are) then the cortex-a8 actually continues to function fine Aug 12 04:44:51 I have a little prog that toggles leds in response to an irq from a pushbutton... works, no prob Aug 12 04:45:38 this is pretty bad since it initially looked to me like the interaction between the a8 and m3 was a beautiful race-free hand-off Aug 12 04:46:14 a8 makes sure relevant irqs are enabled and the m3 is informed on desired power state Aug 12 04:46:38 sets its own module mode to "disabled" causing prcm to request it to enter idle mode Aug 12 04:46:43 executes WFI Aug 12 04:47:45 and either 1. the processor successfully enters wfi-suspend, acknowledges idle to prcm which now transitions the module to "disabled", and issues irq to cortex-m3 Aug 12 04:48:26 or 2. the processor received an irq while doing this, falls through the wfi, and proceeds with the wakeup steps Aug 12 04:48:56 this now turns out to be wrong on two fronts Aug 12 04:49:39 even if the module successfully disables, it will reenable on its own! Aug 12 04:50:14 and the irq received by the m3 isn't even on "a8 has been disabled", it turns out to be "a8 executed wfi" Aug 12 04:50:33 argh argh argh -.- Aug 12 04:50:54 I want to strangle the idiot who implemented this Aug 12 06:06:43 ah, the modulemode behaviour is actually consistent with documentation... never mind that part then :P Aug 12 06:21:50 zmatt: I'm finally back from vacation, and I noticed your tiler patches. nice =). do you have plans to clean them up? Aug 12 07:07:04 spi0 works fine on stock debian; I'm trying to get it to work with a buildroot image without success. I managed to get /dev/spidev1.{0,1} appear but nothing comes out og the pins. what can I check? Aug 12 09:03:45 I have recently installed the latest BBB Debian on the emmc, but I cant seem to locate the uEnv.txt file for adding and removing overlays. Anyone know how I can access it? Aug 12 09:08:58 have you looked in /boot? Aug 12 09:18:59 tbr thanks, It seems its using U-boot_partitioning_layour_2.0. So I cant follow any tutorials on how to disable the "cape_universal" and add e.g. SPI0 Aug 12 09:19:51 all #exactsteps pertaining to some old setup obviously won't work Aug 12 09:58:26 tomba: yo yo, welcome back :) Aug 12 09:59:13 tomba: well first I need to get things working at least good enough for demo purposes and to be able to benchmark the impact of tiler on real applications Aug 12 10:00:08 the https://github.com/mvduin/linux/commits/patch/tiler-fbdev was my first attempt Aug 12 10:02:54 the first two commits of that patch series might actually be in upstreamable quality, that's why they have no XXX in the commit message and have a signed-off, but I haven't attempted to upstream them yet Aug 12 10:03:37 yep. I had a very quick look at the patches, but before I can really say anything, I should read about ARM caching and memory management... Aug 12 10:03:57 btw, are you aware of the errata I mentioned in the pyra list? that may make tiler unusable, if you want reliable system Aug 12 10:04:10 really, that's stuff you should have known about already :P Aug 12 10:04:37 I'm not on the list, still need to figure out how to subscribe Aug 12 10:04:44 which of the various errata? :P Aug 12 10:05:11 I mean, the cortex-a15 alone also has nice ones, at least one without workaround iirc Aug 12 10:05:17 i878 - "MPU Lockup With Concurrent DMM and EMIF Aug 12 10:05:18 Accesses" Aug 12 10:06:25 ah that one Aug 12 10:07:54 I'm slightly worried about it, but that's one more reason to get it in a state where we can try real-world applications to see whether it's something you hit easily or not Aug 12 10:08:47 we can hit that when accessing DMM registers. that has been proven, and in TI kernel we've changed the tiler driver to access DMM registers with sDMA Aug 12 10:08:58 (I didn't actually know the errata is there for omap5, until recently) Aug 12 10:10:15 well, overall the omap5 and vayu are very very similar (modulo some large IP blocks, but those don't affect the overall architecture much) Aug 12 10:11:03 I haven't seen a lockup myself yet Aug 12 10:12:31 but so far I've mostly done things like benchmarks, which access only EMIF or only DMM (although the second core will probably do EMIF accesses now and then even if "idle") Aug 12 10:14:29 if you like worrying, there's still https://patchwork.kernel.org/patch/6960921/ also (for which I also haven't enabled the workaround currently) Aug 12 10:15:30 and there's ARM erratum 799271, which has no workaround at all... but "In a two core configuration without ACE, the erratum is believed to be very rare." Aug 12 10:15:58 sometimes I wonder how these things work at all... Aug 12 10:16:34 uhuh, the cortex-a8 was still understandable and pretty straightforward Aug 12 10:17:12 and, in the last revision (r3p2) pretty much bug-free... the last few ones haven't been fixed probably because noone cared enough to be worth the money and risk Aug 12 10:18:08 the cortex-a15 errata make very interesting reading as they give much more insight into how that thing works than the extremely limited scraps of info in the deficient TRM Aug 12 10:18:49 but my main conclusion is that you have no hope whatsoever of constructing a useful mental model of what's going on inside one Aug 12 10:22:54 shame on TI though for making TILER incapable of handling WRAP-mode bursts... I mean it already internally has to break up large bursts and is documented to be able to split wrong-strided 2d bursts into separate 1d bursts, how hard could it have been to split a wrap-burst into two sequential bursts? :/ Aug 12 10:25:45 granted, I would never have seen it coming that the cortex-a15 uses wrap-bursts for non-cacheable reads, but it also would have been nice to have the option of making tiler memory cacheable (with explicit cleaning), which its lack of wrap-bursts will break across all cpus Aug 12 11:00:40 tomba: btw, when testing the tiler-fbdev patch branch, you may want to configure the kernel with no framebuffer console :) Aug 12 11:30:41 tomba: I recently sent a status/summary email to nikolaus, I'll forward you a copy since it may be useful as overview of the patches I've done (it also has a slightly frustrated rant on working in kernelspace, which is included for free :P ) Aug 12 11:30:59 zmatt: sounds good =) Aug 12 11:46:40 zmatt: any chance you could share your status/summary with me, too? bradfa@gmail Aug 12 11:55:26 sure, why not. keep in mind that it was originally private communication so I speak a bit more freely than I would on a mailing list Aug 12 12:16:18 but more eyeballs is always better of course, bugs should get shallower any moment now ;) Aug 12 12:18:52 tomba: I suspect btw that 90%-100% of all cases of apps reading the framebuffer could be covered by providing a fast buffer-to-buffer copy function (using dma to avoid the cpu limitations for tiler access) Aug 12 12:23:38 there's also clearly still much more opportunity to exploit the capabilities of PAT, e.g. to allow userspace to perform the sort of trickery that that omap_gem_roll does. there'd be non-trivial amounts of checking and tracking involved though Aug 12 14:33:20 Hi there, I want to use a BBB as a server and am updating the software and tidying up the ports at the moment. I am using the latest debian image from: https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz I found out that connmand and init are listening on ports. First at all: Am I usnig the right Image for the BBB? Where can I find documentation, what they are listening for? Here's the Aug 12 14:33:20 output of netstat -tulpn https://paste.debian.net/788687/ Aug 12 14:37:42 Quick question: I have just enabled SPi with the "echo BB-SPIDEV0 > $SLOTS" and I have both spi devices in the /dev folder. But when I look at the pingroups there are none SPIs.. What could have gone wrong? Aug 12 15:15:38 Hi. Is there work going on to support the latest Linux kernel, which is 4.7 right now? Aug 12 15:15:45 Is upstreaming taking place? Aug 12 15:20:05 PaulePanter: are you familiar with RCN's work? Aug 12 15:22:36 PaulePanter: I'd expect a vanilla kernel to *just work* nowadays. Aug 12 15:22:54 tbr: Awesome. I am not familiar anymore. I just read https://beagleboard.org/latest-images. Aug 12 15:23:19 … and saw that on the shipped device from Farnell there was an image from December 2015 with Linux 3.18. Aug 12 15:23:39 I’ll test some more. But I need to find a microSD card first. Aug 12 15:29:17 * PaulePanter notes that Debian 8.5 (Jessie/stable) ships by default with Linux 3.16. Aug 12 15:31:36 PaulePanter: I've seen images that use 4.4.x by default Aug 12 15:32:47 Yeah, as written, that probably the image from May 2016, which I do not run yet. Aug 12 15:32:48 bbl Aug 12 15:41:52 PaulePanter: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options Aug 12 16:01:12 knicklux: I'm guessing connman is acting as a dns proxy Aug 12 16:01:35 knicklux: init (i.e. systemd) is almost certainly listening on behalf of some socket-activated service Aug 12 16:01:52 try connecting to that port and check netstat again Aug 12 16:02:21 or check systemctl list-sockets Aug 12 16:02:50 just shut-down the machine ^^ need to go ;) but thaks! i'll try it Aug 12 16:11:23 oh duh the connman listeners are all on localhost Aug 12 16:11:52 and resolv.conf will probably point to 127.0.0.1 Aug 12 16:13:05 yeah I think both he and I were fooled by the visual similarity of an IPv6 localhost-listener and an IPv6 all-hosts listener Aug 12 16:13:17 or at least I was Aug 12 16:14:12 PaulePanter: note that you can simply install a new kernel, no need to install a whole new image Aug 12 16:14:45 I'd still recommend using a -bone or -ti kernel though, even though work is continually ongoing to get stuff mainlined Aug 12 16:16:32 latest kernels are 4.7-bone2 and 4.8-rc1-bone1 Aug 12 16:17:11 older kernel series also still frequently get updates, see https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Aug 12 16:18:23 rcn's debian repo is included in the default list of repositories on his images, so you can install a new kernel simply using apt Aug 12 19:18:09 jkridner: do you know if repos.rcn-ee.com is still up to date ? Aug 12 19:18:24 seems to be offline and i tried it a couple of weeks ago and it was down also Aug 12 19:30:04 Hello, I'm beginner and I have one bbb rev c and one ftdi serial ttl 232 usb cable. How should I use ftdi cable? advice please. Aug 12 19:31:56 and also i'm an archlinux user. Aug 12 19:32:10 arpanet: http://dave.cheney.net/2013/09/22/two-point-five-ways-to-access-the-serial-console-on-your-beaglebone-black Aug 12 19:40:02 afd: thank you but when i typed "sudo screen /dev/ttyUSB0 115200" there's no action. Aug 12 19:41:19 ah so many gotchas :D Aug 12 19:41:22 arpanet: what are you expecting? is the board booted? Aug 12 19:41:42 login access Aug 12 19:43:02 arpanet: hmmm what boot image are you using? Aug 12 19:43:37 afd: blue light on usr0,2,3 and pwr, i just bought debian preinstalled from adafruit Aug 12 19:44:29 no configuration, yet. this is my first time. Aug 12 19:44:34 arpanet: I'd start with the basics, hook up HDMI and see if you are booting at all Aug 12 19:45:16 well, i have only cable and board. Aug 12 19:56:29 zmatt: Thank you for all the hints. I’ll try that. Aug 12 20:04:55 afd: anyway thank you. Aug 12 20:32:41 jkridner, is there an ETA on the Beaglebone Blue? Aug 12 21:29:27 is it normal for the cdc_ether to use the macaddress of the ethernet port on the BBB? Aug 12 21:29:50 * my usb0 is now showing up on ubuntu as enx{macaddr} Aug 12 21:31:07 on the bbb eth0 Link encap:Ethernet HWaddr c8:a0:30:ac:56:02 Aug 12 21:31:28 and on my ubuntu pc it should up as enxc8a030ac5603 Aug 12 21:31:50 however the bbb shows usb0 as this: Aug 12 21:31:53 usb0 Link encap:Ethernet HWaddr 1a:6d:42:73:ae:26 Aug 12 21:32:15 right now i have it running debian jessie on the bbb Aug 12 21:32:21 and ubuntu 15.10 on the intel pc Aug 12 21:33:15 right at the moment i don't even have the ethernet cable plugged in, just the usb cable Aug 12 21:33:35 but it doesn't matter if i have it plugged in or not Aug 12 21:52:39 sounds a bit like a gadget driver peculiarity **** ENDING LOGGING AT Sat Aug 13 02:59:59 2016