**** BEGIN LOGGING AT Sat Jun 23 03:00:01 2018 Jun 23 04:00:22 e Jun 23 11:48:29 need help first time user Jun 23 11:49:50 bought a beagle bone black and board the seems to be not responding to example program from the initial startup page Jun 23 11:49:56 what do you need help with? Jun 23 11:50:17 blinking USR led not working Jun 23 11:50:37 example programs seems to be not responding with the board Jun 23 11:50:53 regardless of that, you might want to consider to update to the latest firmware Jun 23 11:51:17 OK.. didn't do that Jun 23 11:51:32 http://beagleboard.org/latest-images Jun 23 11:52:39 what is the difference between with graphical and no garaphical? Jun 23 11:52:51 can i use the terminal on both? Jun 23 11:53:34 graphical means graphical desktop on HDMI Jun 23 11:55:21 K...thanks for responding will contact once i update the latest firmware Jun 23 11:55:32 good luck :) Jun 23 18:16:55 Hello guys. Quick question. Does BBB output sound with HDMI? Should I care when buying HDMI to VGA if it has sound as well? Jun 23 18:18:18 I believe it should... Jun 23 18:18:55 anyvody tested? Jun 23 18:18:58 b* Jun 23 18:25:17 yeah it supports audio over hdmi Jun 23 18:26:26 zmatt, ok, thank you! buying it right now Jun 23 18:30:01 jkridner[m]: that reminds me... since sometimes people show up looking for projects (for GSoC or such?)... right now 4 pins are occupied whenever hdmi audio is enabled: 1 for the audio osc and 3 for the i2s interface. however, mcasp could also directly produce s/pdif output and the hdmi framer supports this as input Jun 23 18:31:51 jkridner[m]: using spdif as transport merely requires a small configuration change in the hdmi framer and some DT changes on the mcasp side, so it should be reasonably approachable, and it would reduce the number of pins used by hdmi audio to 2 (audio osc + spdif) Jun 23 18:34:45 zmatt: is that a layout change, or just config/routing/setup/ Jun 23 18:35:52 no hw change, it's just a matter of config Jun 23 18:35:58 ooh cool Jun 23 18:36:22 liberate the i2s for a secondary sound i/f!? :D Jun 23 18:36:51 actually .. I'm guessing thats probably not a go-er Jun 23 18:37:09 there's two mcasp's no, anyway Jun 23 18:38:46 mcasp0 would still be in use for the spdif output. it does support multiple spdif outputs at the same time, although they'd share metadata and I don't think the mcasp driver supports it in a convenient way Jun 23 18:39:07 the receive section could be used independently, although again the mcasp driver doesn't support that very well right now Jun 23 18:39:28 and yeah mcasp1 is available too, although a rather limited set of pins Jun 23 18:41:56 :) Jun 23 18:54:54 veremitz: https://pastebin.com/raw/Hq5URXqj here are some notes on the McASP possibilities on the BBB Jun 23 18:55:17 :thumbsup: ta .. just gonna grab some fish'n'chips :D bbiaf!! Jun 23 18:55:19 this is written purely from a hw perspective, regardless of what the linux mcasp driver supports currently Jun 23 19:03:26 if configured to spdif, only P9.25 and P9.28 would be in use for hdmi audio. in particular, hdmi audio would no longer conflict with spi 1 Jun 23 19:04:26 anyway, I'm afk too Jun 23 19:32:25 is there a way to carve off 1MB or so of contiguous physical memory for DMA in the DTS for a cape? Jun 23 19:33:33 I'm hoping for something more elegant than setting `mem=511M` in the kernel cmdline, loading cmem with the address of the last 1M and then allocating Jun 23 19:43:05 looks like this should be possible: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt?h=v4.18-rc1 Jun 23 19:48:28 wiley: what are you actually trying to do? I mean, normally DMA transfers are handled by the kernel, and a kernel driver can simply allocate memory for DMA with the appropriate API Jun 23 19:50:13 if you're using PRU to handle the dma, the uio-pruss driver already allocates a chunk of contiguous physical memory you can use freely, and its size is configurable via a kernel parameter Jun 23 19:50:22 I have a cape where the PRUs are running external hardware and I need to have memory around to pass large buffers of commands to them Jun 23 19:50:45 I'm also using PRU RPROC, not UIO :\ Jun 23 19:52:21 I think rproc-pru is mostly meant to be used to allow interaction between a kernel driver and pru firmware. if you're using it purely from userspace, rproc-pru just seems to be more cumbersome and limited than uio-pruss Jun 23 19:52:51 yea, looks like uio_pruss takes extram_pool_sz but pru_rproc doesn't Jun 23 19:53:10 still, doesn't rproc-pru also allocate ddr3 memory? I'm pretty sure it does Jun 23 19:53:39 I'm interacting from userspace but the full message-passing model that rproc brings makes it much easier to add new capabilities to the PRU firmware Jun 23 19:54:26 you're right that I could do the same things with UIO, but with UIO I'm basically stuck rebuilding the message-passing capabilities TI already built if I want to get any sort of flexibility in how the PRU and CPU communicate Jun 23 19:55:11 it also sounds like a lot of usually-unnecessary complicated and overhead, and a waste of the tiny amount of instruction memory PRU has (2048 instructions per core) Jun 23 19:55:31 *complication Jun 23 19:56:18 anyway, that message passing obviously uses a chunk of shared external memory, so of course it allocates external memory :) Jun 23 19:56:27 and it seems implausible the amount is hardcoded in the kernel Jun 23 19:57:56 so the challenge I have is that because RPROC copies messages between normal DRAM and PRU RAM to keep the access speeds deterministic after the initial message-receive, it deals with small messages (<512 bytes, as I recall) Jun 23 19:58:31 that's fine for passing commands and results, but I also have situations where the command needs to come with hundreds to thousands of bytes of data, which needs to stay in CPU RAM and be passed to the PRU by physical address Jun 23 19:58:32 yup, reading ddr3 memory from pru is slooooow Jun 23 19:58:50 (and has unpredictable timing) Jun 23 20:00:10 I have trouble imagining why you would need that Jun 23 20:00:44 the cape is a 3d printer/CNC controller and I need to pass long lists of which motors need to step at which times :) Jun 23 20:02:54 hmm, and streaming the data to pru from the ARM side isn't an option? Jun 23 20:05:02 so Jun 23 20:05:49 the initial design that's currently in use was just to take the block that UIO allocated and essentially use it as a circular buffer of fixed-format commands Jun 23 20:06:50 yup. if pru ram is too small to allow sufficient buffering and performance isn't very important then that sounds like a sane approach Jun 23 20:07:02 that works, but the usermode code to try and synchronize with the PRU is mostly incomprehensible, getting any sort of bidirectional communication is a pain, and there's a certain amount of nondeterminism because the PRU reads everything ever from main memory Jun 23 20:07:38 bidirectional communication is definitely the biggest pain - we have operations where we really want to get some sort of detailed completion message from the PRU, but that doesn't really fit into this model Jun 23 20:09:26 so I started working on a replacement and I have something working with RPROC + CMEM, and I'm debating where to take it next Jun 23 20:09:54 lots of solutions for that. if pru writes a copy of its read-pointer back to shared memory you can easily determine when pru is done with a received message (and you need this anyway to avoid accidently overflowing the ring buffer). for short reply data, pru could write info back into the command message before advancing its read-pointer. for verbose reply messaging you could just use a second ... Jun 23 20:10:00 ...ringbuffer for reply messages Jun 23 20:10:45 rewriting the message passing bits to stay on top of UIO is definitely a possibility, but TI's stuff does make this very convenient and it's not really clear to me that rewriting their framework would result in something more performant Jun 23 20:11:27 note that rpmsg is open source so you don't need to rewrite it if you don't want to Jun 23 20:13:19 though I suspect improving on its performance is not going to be hard :P Jun 23 20:13:35 it's really that bad? Jun 23 20:14:00 you'd think that an IO library from the company designing the hardware would do fairly well in general... Jun 23 20:14:11 lol Jun 23 20:14:30 or am I just naive? :) Jun 23 20:15:05 RPMsg isn't written for PRU. it's the linux virtio_rp_msg system (designed for communication between a VM and its host) ported to SYS/BIOS (originally for TI's DSPs) Jun 23 20:15:24 expect zero tuning for pru Jun 23 20:18:09 at least, that's the impression I got Jun 23 20:18:18 like i said, I'm not that deeply into it Jun 23 20:19:07 interesting... Jun 23 20:20:41 I prefer uio-pruss, pru assembly over C (especially after having seen the awful output of TI's C compiler), and efficient application-specific solutions over a piece of generic bloatware. this is in part because pru has such limited code space, and because doing otherwise means you lose PRU's absolute determinism, which is one of its big features imho Jun 23 20:21:33 but of course different applications and priorities may call for different trade-offs Jun 23 20:53:26 wiley: are you using a RT kernel in your project? Jun 23 20:57:01 no Jun 23 20:57:31 haven't really looked much into it, though Jun 23 20:58:07 all our timing constraints are on the PRU and we don't generally have problems with the CPU keeping up with the soft-real-time workload to keep the PRU fed Jun 23 21:03:41 is there any general guidance on when an RT kernel should be used? Jun 23 21:07:29 I don't know.. only saw a video, where xenomai was used for 3d printing Jun 23 22:00:42 xenomai is a very different beast though Jun 23 22:03:13 wiley: an rt kernel improves the worst-case latency between a real-time thread becoming runnable (e.g. whatever event it's blocked on happens) and it actually running, and it turns most interrupt handlers into kernel threads hence allows you to assign priorities to them (along with your rt threads) to minimize the amount of interruption your rt threads may face Jun 23 22:03:49 at the expense of making the kernel overall less efficient, and sometimes buggier Jun 23 22:04:06 interesting Jun 23 22:05:11 I suspect that wouldn't work too well for us because we're running a python-based printer web UI, a python/C/EGL touchscreen UI, and python/C++ control daemon that's actually generating all the data for the PRU Jun 23 22:05:49 and I'm imagining that trying to make python's "threading" model fit sanely into any sort of priority scheme would be... questionable Jun 23 22:08:55 yeah typically you'll want to implement your rt threads in C/C++. an example use-case would be streaming your large command lists to pru via a small ringbuffer in pru memory (to keep pru from having to do slow reads to ddr). such a thread only needs to access memory and receive an irq from pruss, hence its priority could be raised above everything apart from the kernel driver that delivers the irq Jun 23 22:11:03 on a non-rt kernel such a thread would still experience potentially lengthy random delays due to interrupts happening, while on an rt kernel you could simply raise the priority of this thread (and the one belonging to the relevant kernel driver) above basically all interrupts **** ENDING LOGGING AT Sun Jun 24 03:00:00 2018