**** BEGIN LOGGING AT Sun Apr 29 03:00:03 2018 Apr 29 03:02:40 hmm Apr 29 03:02:58 there aren't enough ADC's on the BBB for all channels Apr 29 03:05:03 actually there are, but then you can't fit vsync and hsync Apr 29 03:05:30 isn't it red, green, blue, hsync, vsync ? Apr 29 03:05:41 and intensity Apr 29 03:05:54 wait, but RGBI is digital video, not analog Apr 29 03:06:01 it is? Apr 29 03:06:18 Yes it is and TTL 5V also. Apr 29 03:06:45 so it's even easier than i thought Apr 29 03:07:49 you might even be able to do a disgusting trick and feed the video via some external logic into the hdmi framer of the beaglebone via the pins on the P8 header (while keeping those I/Os disabled on the AM335x) Apr 29 03:08:22 i'd like to do it with just a bunch of cables if possible Apr 29 03:08:50 well you'll need to level-shift the 5V to 3.3V anyway Apr 29 03:09:22 you could alternatively use PRU to convert RGBI to RGB565 Apr 29 03:09:50 oh, nm Apr 29 03:09:55 RGBI interface doesn't have a pixel clock Apr 29 03:10:08 so you'll need to do a bit more processing anyway Apr 29 03:10:18 or does it? Apr 29 03:10:36 well there's hsync and vsync clocks Apr 29 03:10:56 those aren't pixel clocks Apr 29 03:11:04 i see Apr 29 03:11:26 I wonder how the timing for RGBI is officially defined then Apr 29 03:14:26 zmatt: what are hsync and vsync? Apr 29 03:14:32 i can't seem to find any info on them Apr 29 03:14:38 are they just binary? Apr 29 03:15:01 hsync is used to indicate where each line begins, vsync indicates where each frame begins Apr 29 03:15:51 so vsync fires, hsync fires, then a bunch of channel pixels, then hsync fires again, etc until the end of the frame? Apr 29 03:16:23 oh well i'll have to actually read a spec if such a thing exists Apr 29 03:17:26 apparently its timing was close to that of NTSC Apr 29 03:20:19 for hsync/vsync, see for example this image of VGA timings: https://www.eevblog.com/forum/projects/make-use-of-an-old-cga-monitor/msg679225/#msg679225 Apr 29 03:21:05 thanks Apr 29 03:23:14 http://www.reenigne.org/misc/cga_timings.gif Apr 29 03:24:05 (yellow is the color burst, only relevant for composite video, not for RGBI) Apr 29 03:24:14 Hey there, I reinstalled the latest Debian image on my BBB. Now the PRU drivers throw an error: Apr 29 03:24:15 [ 0.5] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 ! Apr 29 03:24:17 [ 82.4] beaglelogic pru-beaglelogic: Unable to get pruss handle. Apr 29 03:24:51 does beaglelogic use remoteproc-pru ? Apr 29 03:25:06 otherwise you may need to disable rproc-pru in /boot/uEnv.txt Apr 29 03:25:29 ah let me check that part still confuses me Apr 29 03:30:22 unics: ah and there's another reason to do a little bit of processing by PRU rather than sending the signal directly into the HDMI framer (which could otherwise still be an option if you just reconstruct the pixel clock): I suspect hdmi monitor may get a bit confused if you try to send it video at a resolution of 620x200 pixels Apr 29 03:30:35 *640 Apr 29 03:30:43 you'll probably want to do line duplication Apr 29 03:31:15 ok so now I have: Uboot overlays enabled, audio & video disabled, pru_rproc disabled, cape_universal enables, and then finally uboot_overlay_pru with the beaglelogic-00A0.dtbo firmware Apr 29 03:32:16 uhh, uboot_overlay_pru is meant just for one of the two dtbos listed in uEnv.txt Apr 29 03:32:57 actually, it looks like beaglelogic requires rproc-pru Apr 29 03:33:03 oh ok it was put there by the install script at https://github.com/abhishek-kakkar/BeagleLogic/blob/master/install.sh Apr 29 03:33:41 that's really weird Apr 29 03:33:47 and worthy of a bug report Apr 29 03:34:06 ok, yeah I was hoping not having to rely on the pre-built 3.18 image Apr 29 03:34:17 3.18 ? holy shit that's ancient Apr 29 03:34:52 yeah. I thought that they maybe made some progress on that but development seems stalled. Apr 29 03:35:03 sad for such a nice piece of hardware Apr 29 03:35:42 like I said, the overlay ( https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/beaglelogic-00A0.dts ) seems to depend on remoteproc-pru, so uboot_overlay_pru should enable that Apr 29 03:35:57 the beaglelogic overlay should be put in some other slot Apr 29 03:36:06 I'm a bit puzzled it doesn't setup any pins though Apr 29 03:36:39 [ 80.673572] beaglelogic pru-beaglelogic: Unable to get pruss handle. Apr 29 03:36:41 [ 80.732292] beaglelogic: probe of pru-beaglelogic failed with error -2 Apr 29 03:38:11 yes it's unable to find pruss since it's not enabled by loading the PRU-RPROC overlay Apr 29 03:40:25 ok so I uncommented uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo Apr 29 03:40:26 (my kernel is 4.9.) Apr 29 03:41:08 omg ok I saw my mistake I need the _uio version right? Because I have the bone kernel Apr 29 03:41:32 bone kernel doesn't support remoteproc-pru Apr 29 03:41:56 hence doesn't support (the current version of) beaglelogic Apr 29 03:44:19 unics: btw, depending on your goal for this project, keep in mind that many games designed for CGA expect that the composite NTSC signal is used and use "artifact colors". emulating an RGBI monitor will in that case not produce the desired result Apr 29 03:45:13 thanks for helping me, zmatt Apr 29 03:45:55 i have an old romanian zx spectrum clone called HC90 which has RF and CGA output Apr 29 03:46:04 (creative people have used artifact colors to get 1024-color output on a CGA interface) Apr 29 03:46:09 i could use the RF, but programming a CGA converter is nicer Apr 29 03:46:39 it's definitely doable Apr 29 03:46:42 not trivial, but doable Apr 29 03:47:53 this is what it looks like http://www.nightfallcrew.com/wp-content/gallery/testing-i-c-e-felix-hc-90-zx-spectrum-clone/20160124_104606.jpg Apr 29 03:48:19 it doesn't have a monitor, it's just something the person who took the picture put on it Apr 29 03:48:30 neat Apr 29 03:50:53 still the same applies: if people typically used the RF output, then programs (games mainly) may likely have taken advantage of artifact colors Apr 29 03:54:55 zmatt: i've been meaning to ask, is it possible (without too much hacking) to get MLO to skip u-boot and go straight to linux? Apr 29 03:55:24 yes it's called "falcon boot"... I've never tried it though Apr 29 03:55:31 cool, thanks Apr 29 03:56:01 I think it requires u-boot to prepare a special image for the MLO at a fixed location Apr 29 03:56:04 or something like that Apr 29 03:56:18 thanks Apr 29 04:22:34 unics: fun fact btw: it is possible to select the display PLL as clock source for the PRU subsystem, allowing the pru cores to run exactly synchronous to the display timing. e.g. with a PLL output (= pru core frequency) of 200.454545 MHz and pixel clock divider of /14 you get the desired 315/22 MHz pixel clock of CGA and 14 pru cycles per pixel Apr 29 04:22:39 oh he left Apr 29 04:27:23 that is funny Apr 29 04:27:40 it's ok, zmatt, i can appreciate it Apr 29 04:27:54 those are the only two subsystems i have heavily worked with, anyways. Apr 29 04:28:00 :) Apr 29 04:30:05 have you seen my py-uio project btw? ;) probably openbsd kernel devs would flee in horror at the very notion of what uio stands for, let alone bringing the convenience of directly messing with memory-mapped i/o to python ;) Apr 29 04:31:10 userspace io? Apr 29 04:31:20 yep Apr 29 04:31:25 OH Apr 29 04:31:27 i see what this is doing Apr 29 04:31:31 hahaha, it's cool Apr 29 04:31:39 *nuts* but still pretty cool Apr 29 04:31:56 you mmap() the peripheral's register space and are able to receive irqs from it via the file descriptor Apr 29 04:33:06 and it does all this through the PRU Apr 29 04:33:19 even though it probably un-realtimes it Apr 29 04:33:23 it's clever Apr 29 04:33:44 actually, for many devices it might even be considered more secure than a kernel driver since being able to mess with a specific peripheral usually doesn't affect the rest of the system and it avoids having more driver code in kernelspace Apr 29 04:33:48 eh, no Apr 29 04:34:00 pruss is just one of the peripherals you can use via uio Apr 29 04:34:24 other than that uio doesn't have anything to do with pruss specifically Apr 29 04:35:16 (the "being able to mess with a specific peripheral usually doesn't affect the rest of the system" isn't true for pruss of course since it can access the L3 interconnect, but that's not the case for most peripherals) Apr 29 04:37:16 uio is basically just /dev/mem restricted to one peripheral's address space(s), together with a mechanism to deliver irqs to userspace, and the kernel takes care of power management stuff (enabling the peripheral's clocks) when you open the device Apr 29 05:03:09 oic Apr 29 06:17:38 HI, ANyone litening!! Apr 29 13:14:43 Hi! Apr 29 13:16:54 Can I write to the RAM of the CPU with the PRU Apr 29 14:04:56 bou4: the concepts are fairly well described in the TRM of the AM335x Apr 29 14:08:45 Oh I must have missed that Apr 29 14:18:26 What chapter? Apr 29 14:18:37 Don't see anything about it in the PRU one Apr 29 17:25:27 Hi I'm looking to develop an application using the pru and dsps on the bb-x15. Does anyone know good resources for the x15 Apr 29 17:31:10 hrtq: hmmm, I'd for sure start with the TRM, that's usually quite good basics Apr 29 17:31:41 bou4: sorry, missed your answer. I remember a diagram somewhere that explained the kinds of memory access it can do. Apr 29 17:37:34 bou4: just looked at spruh73p and section 4.3.1.2 seems to explain things? (I never used the PRU myself) Apr 29 17:41:21 tbr: TRM? Apr 29 17:41:47 https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf Apr 29 17:41:48 AM335x and AMIC110 Sitara™ Processors. Technical Reference Manual. Apr 29 17:42:11 (not sure if "p" is the latest revision, it's the one google throws at me) Apr 29 17:42:57 hrtq: err, you want the one for AM572x obviously Apr 29 17:44:25 hrtq: www.ti.com/lit/ug/spruhz6j/spruhz6j.pdf Apr 29 17:47:09 tbr: awesome, yes I will read that first Apr 29 17:47:36 bou4: PRU can access everything. assuming you mean DDR3 memory, you need to ensure a chunk of it is allocated for use by PRU obviously. The uio-pruss driver does this (the size is configurable via module parameter) and exposes the address to userspace Apr 29 17:48:26 ok, far more userfriendly explanation :) Apr 29 17:48:58 my py-uio project includes an example that uses DDR3 memory, https://github.com/mvduin/py-uio/blob/master/pruss-ddr-ping.py Apr 29 17:50:46 We want the fastest way to communicate with de cpu Apr 29 17:51:06 And I read half an hour ago that it is also possible to write to the L3 cache? Apr 29 17:51:14 http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code Apr 29 17:51:18 ddr3 is the slowest way, but offers the largest amount of ram Apr 29 17:51:23 there's no such thing as "L3 cache" Apr 29 17:51:28 PRU_memAccessL3andDDR Apr 29 17:51:35 L3 refers to the L3 interconnect Apr 29 17:52:00 aha! Apr 29 17:52:24 how would you exchange data between PRU and CPU if timing is critical Apr 29 17:52:25 the "network" that connects all the major components of the SoC, including the cpu, pruss, and the ddr3 memory controller Apr 29 17:53:10 that question is too vague Apr 29 17:53:26 I mean, if the CPU is running linux then timing can't be that critical Apr 29 17:56:57 ("PRU can access everything" actually isn't *completely* true, there's 64 KB of ram within the cortex-A8 subsystem itself, and that can only be accessed by the cortex-A8 itself) Apr 29 17:59:49 if your needs are sufficiently modest, just use some of the pruss-local ram as shared memory between pruss and the cpu Apr 29 17:59:55 *pru and the cpu Apr 29 18:00:28 and use interrupts from pru to cpu to avoid the need for polling Apr 29 18:01:09 aha, okay Apr 29 18:01:21 it was this GitHub issue that was leading me to search other possibilities Apr 29 18:01:22 https://github.com/BelaPlatform/Bela/issues/313 Apr 29 18:02:24 reading from non-cached memory in tiny chunks is definitely slow Apr 29 18:02:31 use big neon reads instead Apr 29 18:03:33 I don't know why they think reading from main ram would be any faster. it would more likely be slower Apr 29 18:04:17 Alright Apr 29 18:04:26 Thanks! Apr 29 18:04:31 What I was wondering too Apr 29 18:05:01 Can you expect the McASP's registers to have their [reset = xxxx] value after writing 0x000 to the GBLCTL register? Apr 29 18:05:35 As Bela writes to every McASP register that the initialization procedure requires, even if the value is the same as the reset value Apr 29 18:07:20 no Apr 29 18:07:45 that would make no sense, since those registers need to be configured right before you can start enabling stuff via GBLCTL Apr 29 18:09:47 So writing 0x0000 to GBLCTL doesn't actually reset the McASP? Apr 29 18:10:05 it resets functional logic, not registers Apr 29 18:10:26 So how would one set every register to its reset value? Apr 29 18:10:42 written in the datasheet with [reset = 02h] for example Apr 29 18:11:59 most modules have a reset bit in their sysconfig register. this doesn't seem to be the case for mcasp however Apr 29 18:13:12 using the reset signal from the target agent *might* work Apr 29 18:13:23 otherwise only a system reset works Apr 29 18:14:03 Alrighty! Apr 29 18:15:17 target agents aren't documented in the AM335x TRM for some reason, but each module on an L4 interconnect generally has a TA located immediately after the module itself, see the L4LS sheet of https://goo.gl/UHF2Fy Apr 29 18:15:46 the reset register is a single-byte register located at offset 0x20 that needs to be set to 1 and then back to 0 Apr 29 18:16:24 (do not use a word-write, the bytes at 0x21 and 0x23 are used for other purposes) Apr 29 18:18:23 Okayyy Apr 29 19:11:15 hola Apr 29 19:31:39 Can I find an example somewhere of the contents for the McASP registers for a working configuration? Apr 29 19:31:45 Of 24-bit I2S Apr 29 20:34:58 bou4: correct setup also depends on the hardware connection and codec setup Apr 29 20:36:23 At the moment I am in doubt about the bit delay Apr 29 20:36:35 Wondering if I2S is actually 1-bit delay or 0-bit Apr 29 20:36:56 Bela uses 0-bit delay Apr 29 20:37:17 0-bit delay is not i2s Apr 29 20:37:30 (frame sync delay) Apr 29 20:38:42 Frame sync delay is the delay between the frame sync clock and the data bits in terms of the bit clock? Apr 29 20:39:03 note that if you have a working setup with alsa, you could just dump the config registers via /dev/mem (be sure to have an audio stream running while you do this, otherwise mcasp is inaccessible due to module clocks being disabled) Apr 29 20:39:18 between frame sync (it's not a clock) and first data bit yes Apr 29 20:39:24 Aha, sound like an interesting approach Apr 29 20:40:12 or if you give me the details of what you want I can tell you how to configure it, but there are a lot of relevant variables Apr 29 20:40:49 https://imgur.com/a/2b3dbig Apr 29 20:42:25 This is the protocol I will be using Apr 29 20:42:42 24-bit data at 48 kHz Apr 29 20:43:00 input and output (preferable with serializers that I can loopback) Apr 29 20:43:29 at the moment I'm using axr0 and axr2 for my alsa configuration, but I can't loopback them in hardware Apr 29 20:45:19 loopback in what sense? Apr 29 20:45:28 LRCK is 48kHz, bit clock is 64 times 48 kHz, master clock is 12.288 MHz Apr 29 20:45:36 and which side is generating which clock? Apr 29 20:45:45 All clock generated by the audio codec Apr 29 20:45:49 +s Apr 29 20:45:58 okay, so master clock isn't actually relevant Apr 29 20:46:21 (mcasp only needs one if it's generating other clocks from it) Apr 29 20:46:34 loopback as can be configured by the loopback register Apr 29 20:46:49 (so I can test my setup in a convenient way) Apr 29 20:47:20 right, you need an even/odd pair for that Apr 29 20:48:00 ok, so two slots of 32 bits Apr 29 20:48:22 do you want the 24 bits left- or right-aligned in memory? Apr 29 20:48:35 right-aligned Apr 29 20:48:50 sign-extended? (for input data) Apr 29 20:49:01 (seems to me the most convenient, but please say if not) Apr 29 20:49:06 that depends on you Apr 29 20:49:37 but having a bit of headroom is generally useful Apr 29 20:50:53 Sorry, but I don't understand what you mean by headroom in this situation Apr 29 20:51:14 My not-understanding is clearly my inexperience with this subject at this low level Apr 29 20:51:36 I'm not talking about anything low-level, I'm talking about digital signal processing Apr 29 20:52:45 what do you mean by sign-extension? Apr 29 20:52:56 I thought that every data that gets sent by the codec was unsigned Apr 29 20:53:07 uh, normally it's always signed data Apr 29 20:53:19 Oh, maybe ALSA did the conversion for me Apr 29 20:53:36 So sign-extension is preferred Apr 29 20:54:27 and right-aligning the data effectively means applying a -48 dB gain, which means that intermediate signal processing can temporarily boost the signal without causing clipping Apr 29 20:55:11 if you're going to do all processing in floating-point anyway then it doesn't matter though, and left-aligning is slightly simpler to configure Apr 29 20:55:14 That would be great! Because my convolution caused clipping in some situations Apr 29 20:55:27 Oh, but we do floating-points Apr 29 20:56:01 if the final output is clipping then you need to attenuate the signal obviously Apr 29 20:56:46 if the data is right-aligned you actually need to manually clip the data yourself before sending it to mcasp (if it's left-aligned then the conversion from floating point to integer will take care of that) Apr 29 20:59:50 If left-aligning is the easier way, then I'd choose that Apr 29 21:00:04 In our signal processing we always use floating points between -1 and 1 Apr 29 21:01:31 yeah, so for left-aligned you'd multiply that by 0x80000000 before converting it to integer (and divide it by that after converting from integer to float) Apr 29 21:01:55 and that's an operation I can let the PRU do before sending it to the CPU Apr 29 21:02:31 that sounds awful, it will take pru ages longer to perform that conversion compared to doing it on the cortex-a8 Apr 29 21:02:47 Hmm, oke, bad idea of me Apr 29 21:04:16 I'm pretty sure neon can convert a vector of ints to vector of floats with a single instruction... it can even do the scaling for you Apr 29 21:04:58 vcvt.s32.f32 Qd, Qm, 31 Apr 29 21:05:21 that's float to integer, vcvt.f32.s32 is integer to float Apr 29 21:07:17 Perfect! Apr 29 21:12:07 https://pastebin.com/raw/m9WdHXsX something like this? Apr 29 21:12:17 maybe I should have added comments Apr 29 21:13:16 Thanks! Apr 29 21:13:39 But we're doing 24-bit I2S, does there change a lot with that value instead? Apr 29 21:15:19 that just means the codec ignores the last 8 bits (for tx) / sets them to zero (for rx)... there are still 32 bits per slot, so effectively it's 32-bit i2s Apr 29 21:16:02 So no need to to use the RMASK? Apr 29 21:23:19 you could configure mcasp to explicitly zeroize those bits: https://pastebin.com/raw/M1aEDLt6 Apr 29 21:23:28 also I found one mistake: clk needs 1 << 7 Apr 29 21:24:06 bit 3 of fmt should be configured correctly depending on whether or not you use the mcasp data port Apr 29 21:24:13 Thanks a lot! Apr 29 21:25:46 Sure about the 0xFFFFFF00 and not 0x00FFFFFF? Apr 29 21:26:38 yes since it's left-aligned Apr 29 21:38:56 Aha, I see Apr 29 21:39:18 "after passing through reverse and rotate units" Apr 29 21:41:56 In what way is LJ easier actually? Apr 29 21:43:45 Thanks for all the help already Apr 29 21:54:24 it avoids rotation and sign-extending, it avoids having to configure the transmit and receive sections differently, and it avoids having to manually clip/saturate the values after float->integer conversion before sending it to mcasp Apr 29 21:57:57 btw, in case it's useful, here's my own mcasp header in my eccentric style of C++ : https://liktaanjeneus.nl/mcasp.h.html Apr 29 21:58:20 it includes helper functions that generate correct register values for various common configurations Apr 29 22:00:46 okay now I'm starting to have doubts about bit 7 of clk again... the comment says it's "output edge (opposite of sample edge)" hence I'd assume NEGEDGE is desired, but my constructors for it default to POSEDGE Apr 29 22:01:10 lemme check some other source Apr 29 22:04:46 okay the comment is right, the constructor is wrong Apr 29 22:06:29 fixed Apr 29 22:07:30 (this header mostly served as documentation for me, it never ended up being actually used I think, so it might not even compile) **** ENDING LOGGING AT Mon Apr 30 03:00:06 2018