**** BEGIN LOGGING AT Thu Mar 16 03:00:03 2017 Mar 16 04:03:37 sup dan, do u like robots Mar 16 04:36:10 Hello, I've done some searching and can't seem to find an answer to whether or not the BBB can decode H264 on the GPU. If it can be done I would like an example or documentaion on how to use it. Mar 16 05:25:13 Anyone knows where we can buy the Robotics Cape from http://strawsondesign.com/? Mar 16 06:00:57 gudenau: the GPU does OpenGL ES 1 and OpenGL ES 2 ... to me this doesn't seem particularly useful for decoding H264, but I might just be lacking in creativity ;) Mar 16 06:02:21 well, it could do colorspace conversion I guess Mar 16 06:04:59 I saw some things say yes and others no so I decided to ask here. Guess this isn't the board for this project. Maybe a later one. Mar 16 06:05:19 the beagleboard-x15 has hardware video en-/decoding Mar 16 06:06:47 the BBB however is quite limited in video capability, it focusses more on interfacing with hardware Mar 16 06:08:48 That's incredibly overkill and expensive for this. I mainly need h264 and a couple native USB devices. The current version is using a Pi Zero but I need to get another port for USB host. Mar 16 06:10:55 have you checked to see if there's a NEON-optimized H264 decoder, and whether it might perform well enough? Mar 16 06:12:17 Not sure what NEON is, new to the ARM stuff. Isn't there a Java mode in ARM? Mar 16 06:12:17 for some neon workloads the cortex-a8 can apparently be up to 4 times faster than a cortex-a7 running at the same clock speed Mar 16 06:13:22 Neon is also known as the "Advanced SIMD Extension" by ARM, i.e. vector instructions Mar 16 06:13:54 Ahh, fun stuff then. I'll have to look into that. Mar 16 06:16:46 on the cortex-a8 neon has another big benefit: addresses for neon loads are known well in advance due to how the pipeline has been made, allowing it to hide data fetch latency to some degree Mar 16 06:17:30 I need 60hz but I don't recall the resolution at the moment. Mar 16 06:18:01 I don't have any numbers anyhow Mar 16 06:18:57 apparently ffmpeg makes use of neon for various codecs Mar 16 06:20:57 Good thing I'm already using libavI suppose. Thanks for the pointer at least, got research to do. Goodbye. Mar 16 06:21:06 it would also be a good idea to make sure it's compiled specifically targeting the cortex-a8 (-mcpu=cortex-a8 -mfpu=neon) instead of generic compiler settings Mar 16 06:27:20 and of course it does matter a lot what resolution, profile, bitrate Mar 16 07:49:40 thinkfat: powering down the PLLs in ds1 is perfectly valid Mar 16 07:51:33 ds1 keeps peripherals powered hence they don't lose state, but it still turns off the main osc hence keeping PLLs powered is not useful Mar 16 07:51:57 also, good morning :) Mar 16 07:59:54 zmatt: ok, thanks for the hint Mar 16 08:00:12 zmatt: ddr pll however must be kept, i guess, unless DDR is in self refresh. Mar 16 08:00:34 zmatt: then it looks like I need to keep hunting for that bug. Mar 16 08:00:47 zmatt: it's a pity the starterware for the beaglebone is in such a bad shape Mar 16 08:01:05 it is in self-refresh Mar 16 08:01:20 starterware is awful Mar 16 08:03:51 zmatt: true about main oscillator and plls Mar 16 08:09:40 I just got the bbblue and have run across this problem with the leds test. https://github.com/jadonk/bonescript/issues/116 Mar 16 08:11:06 I'll probably try loading an older distro image for now. Mar 16 08:12:14 sounds like people solved it by *upgrading* Mar 16 08:12:19 also a fix has been released Mar 16 09:12:43 Ok sweet, I figured out how to install that patch. The leds blink now. Hello World! Mar 16 09:13:28 And with that, I'm done for the evening. Cheers! Mar 16 09:56:56 Hello guys, has anyone tried to use the WiFi Mesh capabilities (802.11s) of the WL18xx of the BBB Wireless and BBGreen Wireless? Mar 16 10:08:52 * KotH did B.A.T.M.A.N. with a wl1271... it worked oke Mar 16 10:08:55 ok* Mar 16 11:10:15 zmatt: hm, does a clockdomain wakeup take time? Is it required to poll the status to be sure a clock domain is enabled? Mar 16 11:47:03 zmatt: now, isn't that nice. Mar 16 11:47:48 zmatt: WKUP_L4_CLK is gated when the WKUP clock domain is put in SW_SLEEP by the M3 Mar 16 11:48:40 zmatt: I need to explicitly wait for it to come back after the clock domain is woken up, or the next access to the control module by the M3 causes a bus fault Mar 16 12:22:16 that sounds reasonable.... it didn't previously? how does it manage to not-crash for other people? Mar 16 14:51:53 zmatt: not sure Mar 16 14:57:37 zmatt: in DS0 case, there is more code between clockdm wakeup and pll powerup. Mar 16 15:23:16 zmatt: hmm, how can MPU_WAKE be a wakeup source in "standby" when MPU power domain is OFF? Mar 16 15:30:11 zmatt: another question, can any peripheral in the wkup clock domain cause a wakeup event if the clock domain doesn't sleep? Mar 16 15:36:39 zmatt: simple answer: no Mar 16 15:38:14 another puzzle solved Mar 16 16:02:36 hello Mar 16 16:03:10 got a blue yesterday and want to build the balancing robot Mar 16 16:03:51 should i try to find the kit or just source some parts. will servo motors work or where can you find the optical encoders. need more info Mar 16 17:45:08 jesv, I used LEGO motors :-) Mar 16 17:45:09 http://lechnology.com/2017/03/using-lego-mindstorms-motors-with-beaglebone-blue/ Mar 16 17:45:28 I build a balancing bot with it, but didn't write anything up about it yet Mar 16 17:45:44 *built Mar 16 18:03:09 thinkfat: MPU_WAKE comes from the INTC which sneakily does not reside in PD_MPU Mar 16 18:05:04 thinkfat: to answer your question: yes, clockdomain wakeup takes time, although the typical pattern is "set clock domain(s) to SW_WKUP; enable module(s); wait until modules are ready" Mar 16 18:06:15 thinkfat: the clock domain doesn't need an explicit test in that case because it's already implicitly done by waiting for modules in that clock domain to become ready Mar 16 18:10:05 thinkfat: the peripherals in PD_WKUP all have dedicated wakeup signals I think, but some peripherals may be incapable of asserting that wakeup if their clock is gated Mar 16 18:14:43 thinkfat: although, looking at the list of wkup domain peripherals, I think all of these can generate a wakeup with either no clock at all or just the 32kHz clock active Mar 16 18:16:35 thinkfat: btw table 8-28 "Power Domain of Various Modules" shows that the MPU interrupt controller and the digital portion of the MPU PLL live in PD_WKUP Mar 16 18:19:30 thinkfat: iirc it too is capable of generating async wakeup when fully clock-gated Mar 16 18:57:47 Hi. I created a binary for the PRU on my beagle bone green with CCS 7 using this tutorial on my Ubuntu Laptop: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_1:_Toggle_LED_with_PRU_GPO Mar 16 18:57:47 At step 8 I don't know where to find the PRU_CAPE.gel file and how to launch the debugger. Do I have to install CCS on my beaglebone and compile it from there? Mar 16 19:22:29 Hey NTQ ! you can compile the PRU programm without CCS . https://www.zeekhuge.me/post/ptp_blinky/ Mar 16 19:23:42 zeekhuge: Nice. I didn't found that link before. I will take a look. Mar 16 19:24:33 But still CCS is a good IDE for things like this. I use it also for programming the Tiva C Connected Launchpad and various AVR devices. Mar 16 19:28:52 NTQ: they're using JTAG to run a PRU program, a little bit overkill Mar 16 19:30:47 lol, the NOTE at the top of the section you linked to: "however, if the kernel loads prior to our connection to the ARM in CCS then you may experience issues with the debugger." (this is correct) "These are primarily caused by the kernel enabling the MMU." (this is absolute complete nonsense) Mar 16 19:31:40 Because I own the beagle bone green I did not have HDMI. So I assume I can ignore the section for disabling the HDMI cape? Mar 16 19:33:33 correct Mar 16 19:33:55 obviously a dtb named "boneblack" should not be used on the bonegreen Mar 16 19:36:43 At the moment I don't know what you mean with dtb but maybe I can figure out it by myself. Mar 16 19:38:21 zeekhuge: that statement about the resistor is not quite right, the min resistor value is (3.3 V - voltage drop of LED) / 8 mA. :) Mar 16 19:38:59 NTQ: the setting that's being changed there was labeled "dtb", which is also the suffix of the filename you configure there Mar 16 19:39:43 (device tree blob) Mar 16 20:43:36 hello! Mar 16 20:43:41 is sysfs not parallel? Mar 16 20:44:21 i tried to update 6 files in parallel and gained no speadup at all Mar 16 20:45:50 the cortex-a8 is a single-core processor Mar 16 20:46:15 doing stuff in parallel is only useful if the tasks block on external events Mar 16 20:46:59 thought it would block on external events Mar 16 20:47:20 and did not really realise that it's singlecore Mar 16 20:48:21 what were the 6 "files" ? (the right word in case of sysfs is actually "attributes") Mar 16 20:48:40 pwm duty_cycle zmatt Mar 16 20:49:18 I seriously doubt that blocks on anything, the time it costs is probably entirely overhead Mar 16 20:50:00 well, then i probably have to use /dev/mem Mar 16 20:50:04 no other choice ;-) Mar 16 20:51:06 I thought you had already established that? :) (taking "/dev/mem" to be an abbreviation for anything that allows peripheral registers to be mmap()ed, including UIO) Mar 16 20:51:39 no. did some further testing today. Mar 16 20:51:42 alternatively feel free to investigate how on earth updating a single register can take such a long time Mar 16 20:51:51 how are you doing the sysfs writes btw? Mar 16 20:52:07 i do it from erlang zmatt Mar 16 20:52:19 so doing it in parallel was a quite "natural" decision to speed up things^^ Mar 16 20:52:20 that also sounds like it's not going to help Mar 16 20:52:39 what won't help zmatt? Mar 16 20:52:59 erlang is fairly high-level is it not? I'm not that hugely familiar with it Mar 16 20:53:08 yeah. it runs in a VM Mar 16 20:53:41 so probably i have to interface with C stuff to get memory access. but that's doable Mar 16 20:54:29 but you can't really draw conclusions from your benchmark then either Mar 16 20:54:43 what do you mean? Mar 16 20:55:01 well that's why I asked "how are you doing the sysfs writes?" Mar 16 20:55:18 I hope you're not opening and closing the attribute each time you want to update it Mar 16 20:55:37 it should be a single pwrite() call Mar 16 20:59:36 erlang functions are stateless, so i cannot easily share a filehandler Mar 16 20:59:37 a single write() call per update works too afaik Mar 16 21:01:02 I'm not familiar with erlang, but presumably it has ways of dealing with the hard reality of a stateful external world Mar 16 21:01:28 and it obviously needs to keep sockets and pipes open across calls Mar 16 21:01:32 stdin/stdout Mar 16 21:01:32 etc Mar 16 21:02:26 yeah. that's handled by the VM Mar 16 21:02:27 or just do the benchmark in C, then you know how much of the overhead is due to erlang Mar 16 21:02:50 since using /dev/mem with an erlang wrapper is presumably going to suffer the same overhead Mar 16 21:03:10 zmatt: i linked yesterday to somebody who did the benchmark in C but for GPIO pins Mar 16 21:03:27 he achieved 3-4kHz Mar 16 21:03:36 which is different kernel code being invoked, so not necessarily quite the same result Mar 16 21:03:51 although I suspect you can expect a similar order of magnitude Mar 16 21:04:51 the thing is, since it's orders of magnitude too slow, a few % difference between your erlang benchmark and a C benchmark already implies the erlang overhead is enough to slow things down by orders of magnitude :) Mar 16 21:07:14 zeekhuge: I just did the apt-cache search command and there is no package beginning with linux-image--ti- Mar 16 21:07:29 i think i start working on the C binding tomorrow. the GPIO guy got a speedup by the factor of 1000 zmatt Mar 16 21:07:40 i *hope* i also can experience that^^ Mar 16 21:07:47 At the moment there is Debian GNU/Linux 8 installed, using Kernel version 4.4.9-ti-r25 Mar 16 21:08:57 numerical example: if you'd reach 3000 updates/s in erlang vs 4000 updates/s in C then that would imply that the time per update from erlang is: 200 ns (actual write) + 250 us (kernel overhead) + 83 us (erlang overhead) Mar 16 21:09:45 NTQ: it looks like you forgot to fill in a kernel version there? Mar 16 21:10:04 e.g. linux-image-4.4.54-ti-r93 Mar 16 21:11:04 nextloop: so then using /dev/mem might remove the kernel overhead, but 200 ns + 83 us is still 83 us (rounded to working precision :P ) Mar 16 21:11:05 Because at the moment kernel 4.4.9-ti-r25 is running I will install firmware and headers from this one Mar 16 21:12:28 zmatt: it may even lower the erlang overhead, as file IO is always costly and implies context switching to the kernel. Mar 16 21:12:45 nextloop: that part is the same when done from C Mar 16 21:13:00 a syscall isn't actually quite a "context switch" Mar 16 21:13:08 depending on how you use the word Mar 16 21:13:25 switching between threads is more expensive then doing a syscall Mar 16 21:14:06 but it has to switch to the "kernel thread" (i am no kernel expert) Mar 16 21:14:36 if done wisely, I could simply stay within the erlang VM Mar 16 21:15:46 the kernel isn't a thread. there do exist kernel threads, but those are like separate processes (and even show up as such when you do e.g. "ps f -fe") Mar 16 21:16:27 i believe that the actual write is a lot shorter. i mean it's setting a register. the GPIO-guy also got those massive speedups by leaving away sysfs abstraction Mar 16 21:17:22 the kernel is ever-present, you just can't access the memory that belongs to it (but the reason is "access denied", not "memory not mapped") Mar 16 21:17:34 that depends on how much overhead erlang has :) Mar 16 21:17:47 especially if they love threads Mar 16 21:18:21 (unless they're e.g. cooperative threads made in userspace rather than "real" threads) Mar 16 21:18:49 but I agree it should be a lot faster Mar 16 21:18:58 yeah. userspace threads. very lightweight. Mar 16 21:21:37 potentially interesting to read would be attempts by people to get mmap in erlang -> http://erlang.org/pipermail/erlang-questions/2013-June/074178.html Mar 16 21:22:37 zmatt: well what can I say. without wkup clockdomain in sleep, no uart0 wakeup by m3 Mar 16 21:22:56 empirically proven ;) Mar 16 21:23:19 thanks zmatt Mar 16 21:23:22 for the link Mar 16 21:23:22 the first reply seems to indicate it's possible, and I disagree with his objection: yes accessing mmap()ed memory in its full generality in all situations/platforms is unpredictable, but if you limit the scope then it's easy enough to get guarantees Mar 16 21:23:53 thinkfat: I'd be far more suspicious of whether the uart driver correctly setup the uart for wakeup signalling Mar 16 21:24:43 thinkfat: if you're using 8250-omap, be sure to also test omap-serial Mar 16 21:25:28 I'd estimate the probability of omap-serial getting it right to be much higher than for 8250-omap Mar 16 21:25:39 (I checked neither however) Mar 16 21:27:13 zmatt: https://github.com/hiroeorz/gpio-erlang has written a C binding for erlang for raspberry pi GPIO pins Mar 16 21:27:31 so probably i can reuse that Mar 16 21:28:57 nextloop: uh oh... #include Mar 16 21:29:05 * zmatt keeps reading Mar 16 21:29:40 * nextloop did not dive deeper than readme Mar 16 21:29:57 very nice error handling... https://github.com/hiroeorz/gpio-erlang/blob/master/c_src/gpio_drv.c#L140-L143 Mar 16 21:31:13 printf to stdout instead of stderr, no inclusion of the actual error message (%m), and then exit the whole process with exit(255) Mar 16 21:32:44 note btw that one of the benefits of UIO over /dev/mem is that you can setup the ownership/permissions of uio devices via udev, so programs don't need to run as root to use it Mar 16 21:33:16 * zmatt always tries to avoid running stuff unnecessarily as root Mar 16 21:34:57 sudo chown 777 /dev/mem ^^ Mar 16 21:35:17 try it :) Mar 16 21:35:28 better not Mar 16 21:35:44 /dev/mem has an explicit check for root privileges Mar 16 21:36:52 (also, you meant chmod, not chown) Mar 16 21:38:07 err chmod off course Mar 16 21:38:28 it's late^^ Mar 16 21:38:42 that driver uses "driver_async" for everything Mar 16 21:39:41 that's going to be slow Mar 16 21:40:10 hope i can do better Mar 16 21:43:14 thanks for your help zmatt. i call it a day now! Mar 16 21:43:17 in case you ever end up asking on an erlang forum/mailing list and someone raises the "unpredictable time" objection: the problem doesn't really exist for memory-mapped I/O Mar 16 21:43:54 as extra precaution you could include the MAP_POPULATE call in mmap() but I'm not sure it even does anything in this case Mar 16 22:02:33 I just dist-upgraded debian on my beaglebone and ran out of space several times. Before I can go though zeekhuge's tutorial I have to look vor packages that consume too much space. Mar 16 22:13:20 and probably reinstall the packages where the error occurred, long live apt Mar 16 22:14:26 tip for the future: if you're low on free space, perform large upgrades in stages instead of one big dist-upgrade Mar 16 22:15:12 keeping the system uptodate helps to avoid big updates, removing unnecessary crap does too Mar 16 22:21:45 Danlikesrobots do and apt-get update && apt-get upgrade Mar 16 22:23:22 zmatt: It would be nice to find out which packages are unnecessary for my application. ;-) Mar 16 22:31:56 zeekhuge: Unfortunaly you deploy.sh script is not working correctly because the binary clpru is not located at /usr/share/ti/cgt-pru/bin/clpru but in /usr/bin/clpru Mar 16 22:32:30 NTQ: which is why I prefer to begin with a clean system and install things as I go along, which is generally easier than removing unnecessary crap from a system Mar 16 22:37:23 I linked the binaries the other way around. Now it compiles fine but the LED is not blinking. hm. Mar 16 22:38:38 sorry, it works. I connected the wrong pin ;-) Mar 16 22:44:45 how would one easily play some audio to an external speaker on beaglebone blue? Mar 16 22:46:02 i2s dac Mar 16 22:46:19 or is it.. erm...the other protocol... Mar 16 22:47:19 * ver|laptop points at zmatt .. he's the audio guy lol :p Mar 16 22:47:25 sorry zmatt lol Mar 16 22:52:03 not when "easily" is in the sentence :P Mar 16 22:53:18 Now that I am able to to let the LED blink the next step would be to send data to the host CPU to write this down to a file :-D Mar 16 22:53:33 But that's a project for an other day. It's midnight here in Germany Mar 16 23:05:50 the night is yet young then. :) Mar 16 23:07:24 indeed Mar 16 23:36:51 lol zmatt i'm over in ##electronics evangelizing UIO, you know somebody is like "but but but muh memory protections" Mar 16 23:41:02 exactly, uio lets you use peripherals from within userspace processes, thus ensuring crappy driver code (like most drivers are) cannot mess up the whole system like it can when in the kernel :) Mar 16 23:41:38 memory protection is indeed a good reason for using uio Mar 16 23:41:55 (that's probably not what they meant, but an excellent way to twist it ;) Mar 16 23:49:07 apparently the guy who was arguing with me had already pissed off the ops and ended up getting temp-banned O_O Mar 16 23:49:20 i basically said like.. sure... if you're building a app for your nuclear reactor... maybe write the driver in C Mar 16 23:49:25 on a kernel level Mar 16 23:49:35 but the suggestion was for someone who just wanted to test SPI across Pi's Mar 16 23:51:13 if you're building an app for a nuclear reactor, I'd hope you'd be using something like UIO, but with linux replaced by a safety-certified rtos Mar 16 23:52:51 using uio generally makes things safer, not less safe. the only exception is if the peripheral has bus mastering capability, then the story changes Mar 16 23:53:47 (for that, see VFIO) Mar 16 23:54:51 I don't really understand why VFIO is a separate thing, instead of just being an enhanced version of UIO Mar 17 02:39:09 Is JST-ZH the correct name for the motor connectors on the BB Blue? Trying to track some down so I can wire up my motors **** ENDING LOGGING AT Fri Mar 17 03:00:01 2017