**** BEGIN LOGGING AT Tue Oct 30 02:59:59 2018
Oct 30 03:00:24 <suprothunderbolt> no. I'm not sure how to do that. Is there an example anywhere that has the cpu as master?
Oct 30 03:01:08 <suprothunderbolt> i'm not sure if you just point the frame-master at mcasp_0
Oct 30 03:01:23 <zmatt> you point it at the cpu{} node of the dai-link
Oct 30 03:01:30 <zmatt> instead of the codec{} node
Oct 30 03:01:41 <zmatt> and you move the clocks property over too
Oct 30 03:01:47 <zmatt> see e.g. https://pastebin.com/raw/FVYLdQHG
Oct 30 03:02:25 <zmatt> or https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-HDMI-TDA998x-00A0.dts#L117-L127
Oct 30 03:04:07 <suprothunderbolt> mmm. I'll give it a go. Not sure how it'll work given the sample rate requested won't be provided by the 24mhz clock without the PLL doing something unless i'm misunderstanding
Oct 30 03:05:44 <zmatt> it would provide bitclock by dividing the 24.576 MHz audio oscillator clock that's on its hclkx input
Oct 30 03:06:35 <zmatt> that's why it needs the clocks-property pointing at the audio osc clock
Oct 30 03:07:34 <suprothunderbolt> ahh I was just confused by the hclk = internal 24000000 on the asp output
Oct 30 03:09:26 <zmatt> that's because it was in slave mode and had no use for an external hclk
Oct 30 03:10:47 <suprothunderbolt> yep
Oct 30 03:11:02 <suprothunderbolt> okay now configued for cpu master mode
Oct 30 03:11:03 <suprothunderbolt> arecord: set_params:1363: Unable to install hw params:
Oct 30 03:11:21 <suprothunderbolt> arecord fails but the card exists
Oct 30 03:11:51 <zmatt> can you pastebin what your soundcard looks like in dt right now?
Oct 30 03:12:48 <suprothunderbolt> https://paste.debian.net/1049659/
Oct 30 03:15:37 <zmatt> what format did you specify for arecord?
Oct 30 03:15:55 <zmatt> (although explicit specification shouldn't be required)
Oct 30 03:17:09 <suprothunderbolt> S32_LE and 16
Oct 30 03:17:27 <suprothunderbolt> arecord -vvv -c4 -f S32_LE -r 48000 -D hw:0,0 /dev/null
Oct 30 03:19:55 <zmatt> hmm it looks like adau1977 might actually require tdm specification for > 2 channels
Oct 30 03:20:58 <suprothunderbolt> oh in the i2c codec section or in the simple audio section?
Oct 30 03:21:09 <zmatt> simple audio
Oct 30 03:21:21 <zmatt> the dai-tdm- stuff
Oct 30 03:21:48 <zmatt> but I'm not completely sure, it's all not terribly clear
Oct 30 03:22:05 <suprothunderbolt> yeah, they also mention requiring a rx mask
Oct 30 03:22:24 <suprothunderbolt> but i'm not sure if that is required in the cpu and codec section or if one should be tx
Oct 30 03:22:41 <zmatt> rx_mask and tx_mask are required to be zero
Oct 30 03:22:49 <zmatt> no wait
Oct 30 03:22:56 <zmatt> sorry, rx_mask must be non-zero
Oct 30 03:22:59 <zmatt> tx_mask must be zero
Oct 30 03:23:12 <zmatt> codec section
Oct 30 03:23:44 <suprothunderbolt> they suggest an rx mask like 0x0F but the DT masks I've seen look like <1 1 1 1>
Oct 30 03:24:02 <zmatt> it's all really weird to me too, especially since the slot width and number of slots obviously affect everyone on the dai
Oct 30 03:24:41 <suprothunderbolt> yeah. Yeah but weird that mcasp doesn't specify a slot width
Oct 30 03:24:50 <suprothunderbolt> so somewhere needs to...
Oct 30 03:25:14 <zmatt> well under normal circumstances that should be negotiated with the codec
Oct 30 03:25:21 <zmatt> but ugh it's all a mess in asoc
Oct 30 03:25:47 <suprothunderbolt> <1 1 1 1> the right mask though ?
Oct 30 03:25:48 <zmatt> and I can confirm the mask is an array of boolean, i.e. <1 1 1 1>
Oct 30 03:25:55 <suprothunderbolt> ahh cool
Oct 30 03:28:56 <zmatt> if you're feeling adventurous, you can also try cherry-picking this commit and rebuilding the kernel: https://github.com/dutchanddutch/bb-kernel/commit/6d02c63ab0017e1c6588e745fb16c8632aa61b01
Oct 30 03:29:19 <suprothunderbolt> i'm feeling like making this work and that might correlate ;)
Oct 30 03:29:26 <suprothunderbolt> so interesting thing...
Oct 30 03:29:50 <suprothunderbolt> I've added the TDM masks etc and now it does create the driver
Oct 30 03:29:54 <suprothunderbolt> but still doesn't work
Oct 30 03:30:20 <zmatt> that commit includes a change which I think will fix the issue of mcasp not configuring any slots when the codec was master
Oct 30 03:30:59 <zmatt> meh
Oct 30 03:31:57 <zmatt> at this point I'd be getting more and more tempted to force mcasp into fixed configuration and setup the codec from userspace ;-)
Oct 30 03:33:27 <suprothunderbolt> what's the advantage of that?
Oct 30 03:33:34 <suprothunderbolt> and I'm really not sure how to do that :)
Oct 30 03:33:58 <suprothunderbolt> though given my general experience with autodiscovery i do like forced to fixed config :)
Oct 30 03:34:55 <zmatt> the advantage is not having to guess what you need to put in DT to convince all parties to do the right thing, or dig through kernel code to figure out what the codec wants.  and you could try different settings just by perfoming i2c writes, no reboots
Oct 30 03:35:46 <suprothunderbolt> ahh neat
Oct 30 03:36:19 <suprothunderbolt> this patch does look worth a go.
Oct 30 03:36:32 <suprothunderbolt> though it blows my mind a little that it's a patch against patch files...
Oct 30 03:36:47 <suprothunderbolt> that makes me a bit uncomfortable...
Oct 30 03:37:27 <zmatt> well that's because the bb-kernel repo contains a directory with patches and scripts that patch and build the kernel
Oct 30 03:37:52 <zmatt> it can be more convenient to manage patch collections on top of the ever-moving linux kernel that way
Oct 30 03:38:23 <zmatt> more importantly, it's simply rcn's kernel build repo in which I added my own stuff
Oct 30 03:39:31 <zmatt> you should be able to clone rcn's bb-kernel repo, cherry-pick that commit from my repo on top of it and build the kernel package using the scripts
Oct 30 03:40:37 <zmatt> if you haven't used rcn's build repos yet, here are some notes: https://pastebin.com/raw/eLhrp1Hg
Oct 30 03:42:19 <suprothunderbolt> I've built from that repo
Oct 30 03:42:23 <zmatt> ok
Oct 30 03:43:12 <suprothunderbolt> I'm a bit confused that it'll have to revert that patch, patch the patch and the apply.
Oct 30 03:43:29 <zmatt> ??
Oct 30 03:43:32 <zmatt> what do you mean?
Oct 30 03:43:44 <suprothunderbolt> well I've already applied all those patches
Oct 30 03:44:00 <suprothunderbolt> to the kernel that's there.
Oct 30 03:44:01 <zmatt> oh is this one already in rcn's tree? my bad
Oct 30 03:44:07 <suprothunderbolt> oh no
Oct 30 03:44:22 <suprothunderbolt> it might be, but i mean I've already built a kernel
Oct 30 03:44:29 <suprothunderbolt> so the kernel source is already patched
Oct 30 03:45:03 <zmatt> right, so you can either use ./build_deb.sh and just let the script recreate the patched tree completely
Oct 30 03:45:33 <zmatt> actually the other thing I was gonna suggest is a bad idea
Oct 30 03:45:51 <suprothunderbolt> i think I've been doing the bad idea way :)
Oct 30 03:46:11 <zmatt> try to manually apply the patches inside the KERNEL tree? :P
Oct 30 03:46:35 <zmatt> because yeah, if I only added patches then you could just git-am those
Oct 30 03:46:38 <suprothunderbolt> I applied changes to the source to get the ADAU1977 codec working, and added a touch screen driver
Oct 30 03:46:57 <zmatt> ah, and you haven't extracted those into a patch yet
Oct 30 03:47:08 <suprothunderbolt> and I just changed those files directly
Oct 30 03:47:09 <suprothunderbolt> yeah
Oct 30 03:47:38 <zmatt> so, git commit, git format-patch into patches/local, and add "dir 'local'" to patch.sh
Oct 30 03:47:41 <zmatt> :)
Oct 30 03:47:49 <suprothunderbolt> because I thought, I'm fine with this kernel, happy to lock down things here instead of weird git patch thing I don't understand :)
Oct 30 03:48:03 <suprothunderbolt> which sounds massively scary in the overwriting work I've done kind of way.
Oct 30 03:48:17 <suprothunderbolt> ahh okay.
Oct 30 03:48:21 <suprothunderbolt> makes sense
Oct 30 03:48:44 <zmatt> yeah you'll need to get your patches in a safe place before doing ./build_deb.sh again
Oct 30 03:49:48 <zmatt> of course, even if something bad happens, you can always recover your stuff using git reflog, as long as you've committed it
Oct 30 03:51:12 <zmatt> I haven't dug deeply into how rcn's scripts work or anything, but in practice they seem to work fine
Oct 30 03:51:53 <suprothunderbolt> I'm a bit confused on one bit of that workflow... so you git commit the changes into the actual kernel files and then does git format-patch remove those changes from the files?
Oct 30 03:51:53 <zmatt> and I generally require little effort to rebase my stuff onto the latest upstream commit
Oct 30 03:52:26 <zmatt> well committing there isn't a requirement, but it's an easy way to make a nice patch
Oct 30 03:52:37 <zmatt> and to keep your work in progress safe
Oct 30 03:52:56 <suprothunderbolt> okay, I'm just confused that it'd then included everything the rest of the patch changed
Oct 30 03:53:23 <zmatt> well I do try to keep unrelated changes in separate commits
Oct 30 03:53:42 <suprothunderbolt> i mean changes that the patch script did from other people
Oct 30 03:53:44 <zmatt> and if necessary use git rebase -i and such to tweak those commits into being nice patches
Oct 30 03:54:01 <zmatt> I'm confused, what do you mean
Oct 30 03:54:09 <zmatt> the patch script imports patches as git commits
Oct 30 03:54:18 <suprothunderbolt> ahh okay
Oct 30 03:54:30 <suprothunderbolt> so it doesn't just pipe patches to patch
Oct 30 03:54:46 <suprothunderbolt> so git knows about them
Oct 30 03:54:47 <zmatt> of course not
Oct 30 03:54:50 <zmatt> ew
Oct 30 03:55:08 <zmatt> if you check with git status, the only changes you'll see are the ones you made yourself
Oct 30 03:55:17 <suprothunderbolt> yeah, i thought that sounded bonkers but I'm not familar with non-simple git usecases
Oct 30 03:55:18 <zmatt> all the patches are in the commit history
Oct 30 04:21:46 <zmatt> suprothunderbolt: since I badly needed to make proper patches myself, I've made notes on what I did, to illustrate the workflow
Oct 30 04:23:32 <suprothunderbolt> nice. I think i might stick to dodgy and lazy for the moment but proper workflow does sound nice :)
Oct 30 04:24:53 <zmatt> https://pastebin.com/raw/Fin0z0bx
Oct 30 04:25:12 <zmatt> just in case it's useful as illustration
Oct 30 04:25:57 <suprothunderbolt> cheers, thanks
Oct 30 04:29:30 <zmatt> and build complete, and pushed to github, woop
Oct 30 04:36:40 <zmatt> and tagged... I often forget tagging
Oct 30 06:21:11 <suprothunderbolt> i hope you're asleep by now but the codec is now working well!
**** BEGIN LOGGING AT Tue Oct 30 06:23:09 2018
Oct 30 06:23:47 <zmatt> cool!
Oct 30 06:23:52 <zmatt> what did the trick?
Oct 30 06:26:31 <suprothunderbolt> that patch
Oct 30 06:26:52 <suprothunderbolt> oh though I also specified the tdm slot masks etc too
Oct 30 06:27:07 <suprothunderbolt> all 4 channels work and sound correct!
Oct 30 06:27:20 <suprothunderbolt> zmatt: thanks for all your hep
Oct 30 06:27:23 <suprothunderbolt> help :)
Oct 30 06:27:34 <zmatt> \o/
Oct 30 06:27:53 <suprothunderbolt> all my hardware issues are now solved. :) Now onto running things on it!
Oct 30 06:28:12 <zmatt> maybe I should try to clean up and upstream my fixes at some point :P
Oct 30 06:28:36 <suprothunderbolt> I think I should push my touch screen stuff to github
Oct 30 06:29:00 <suprothunderbolt> and post about the -j gcc flag issue on win 10.
Oct 30 06:29:37 <suprothunderbolt> screen still looks a little dodgy so I'm going to poke around with the timings a little to see if that helps and generate some test images
Oct 30 06:32:04 <zmatt> had you tried make -j with the sources in your homedir instead of in /mnt/c ?
Oct 30 06:33:07 <suprothunderbolt> I haven't checked that yet, focused on getting the codec working!
Oct 30 06:33:33 <suprothunderbolt> I think you're right it'll fix it though, it really sounds like a filesystem issue with concurrent access
Oct 30 06:34:18 <zmatt> drvfs is somewhat magic
Oct 30 06:34:24 <suprothunderbolt> I'm generating a few test images to see if I can improve the screen look
Oct 30 06:34:37 <suprothunderbolt> yeah I'm amazed all that magic works at all
Oct 30 06:42:50 <suprothunderbolt> ahh.. i think this test pattern suggests that some of my lines might be connected wrong...
Oct 30 06:42:56 <suprothunderbolt> for the lcd
**** BEGIN LOGGING AT Tue Oct 30 06:50:27 2018
Oct 30 07:35:50 <zmatt> I want C++20 already damnit... https://pastebin.com/nHrKe45C
Oct 30 07:45:03 <LetoThe2nd> zmatt: hrhr
Oct 30 07:46:26 <zmatt> it's kinda insane it's taken so long to be able to have the compiler 1. implement memberwise comparison of structs for you  2. generate the whole assortment of comparison operators from a single three-way (strcmp-like) comparison
Oct 30 07:48:29 <LetoThe2nd> zmatt: actually i don't see the spaceship operator to be super useful in my daily life. but once metaclasses touch ground, i will celebrate.
Oct 30 08:03:08 <zmatt> metaclasses? you mean concepts?
Oct 30 08:04:41 <LetoThe2nd> zmatt: no, i mean metaclasses. concepts are of course nice too. metaclasses are nowhere near c++20, more like c++26 or such
Oct 30 08:05:20 <LetoThe2nd> zmatt: herb sutter started it off with https://www.youtube.com/watch?v=6nsyX37nsRs
**** BEGIN LOGGING AT Tue Oct 30 08:34:28 2018
Oct 30 09:15:15 <zmatt> veremitz: https://www.molex.com/molex/products/family?key=minispox
Oct 30 09:29:30 <lokesh> hlp
Oct 30 09:29:33 <lokesh> help
Oct 30 10:15:56 <charlie5> :D ... just cross-compiled an Ada hello program, rsynced it to BB blue and it runs fine
Oct 30 10:16:06 <charlie5> debian@beaglebone:~$ ./hello
Oct 30 10:16:07 <charlie5> Hello Beagle !
Oct 30 10:17:31 <LetoThe2nd> charlie5: \o/
Oct 30 10:17:59 <LetoThe2nd> obligatory hint: i take it that you already documented on elinux.org? ;-)
Oct 30 10:18:31 <charlie5> LetoThe2nd: i did a little happy dance
Oct 30 10:18:46 <charlie5> ... but have not documented on elinux.org
Oct 30 10:18:58 * charlie5 will try
Oct 30 10:20:12 <LetoThe2nd> charlie5: our eternal gratitude will be following your every step :-D
Oct 30 10:21:01 <charlie5> :)
Oct 30 10:23:29 <charlie5> next is to recode rc_blink in Ada using my (draft/daft) ada binding to librobotcontrol
Oct 30 13:36:48 <veremitz> zmatt: oh it *is* a molex .. tyvm
Oct 30 14:30:14 <Stove> Yo. I want one but they are kinda hard to get..
Oct 30 14:35:11 <zmatt> ?
Oct 30 14:35:23 <zmatt> one what?
Oct 30 14:35:54 <Stove> beagleboard x15
Oct 30 14:37:04 <zmatt> jkridner[m]: the homepage seems to be broken?
Oct 30 14:37:43 <zmatt> Stove: digikey has a ton of them in stock
Oct 30 14:37:55 <zmatt> so does arrow
Oct 30 14:38:14 <zmatt> mouser has them in stock too
Oct 30 14:39:17 <Stove> Yeah but I'm in europe and mouser sucks
Oct 30 14:39:30 <Stove> mouser literally won't let you select text on their website
Oct 30 14:39:43 <zmatt> uhh, seems to work for me
Oct 30 14:39:45 <Stove> arrow is a distrituber too?
Oct 30 14:40:10 <Stove> check this out
Oct 30 14:40:12 <Stove> https://eu.mouser.com/ProductDetail/Beagleboard-by-PTI/BeagleBoard-X15?qs=uj7TeyS2Sj8estI5sHZOxA==
Oct 30 14:40:17 <zmatt> https://www.arrow.com/en/products/beagleboardx15/beagleboardorg
Oct 30 14:40:19 <Stove> damn
Oct 30 14:40:21 <Stove> not it works
Oct 30 14:40:35 <Stove> had it comfirm by someone yesterday even
Oct 30 14:41:00 <Stove> is it really worth the price?
Oct 30 14:41:06 <Stove> I actually wanted a helios 4 thing
Oct 30 14:41:14 <zmatt> that's a rather subjective question
Oct 30 14:41:19 <Stove> just to make a nas and run plex and rtorrent
Oct 30 14:41:49 <Stove> Not THAT subjective, you can compare it to competitors and stuff.
Oct 30 14:42:07 <zmatt> yes but it all depends on what criteria are important to you
Oct 30 14:42:20 <Stove> price
Oct 30 14:42:25 <Stove> price is important to me
Oct 30 14:42:41 <zmatt> I'm sure there are plenty of cheaper chinese boards
Oct 30 14:42:53 <Stove> not with good IO
Oct 30 14:43:11 <Stove> are there chinese boards with AM5728
Oct 30 14:43:12 <Stove> ?
Oct 30 14:43:28 <zmatt> define "good IO" ?
Oct 30 14:44:33 <Stove> >100Mbps transfer rate for 3 drives in raid
Oct 30 14:45:01 <Stove> I have it on a rpi now and since it only has one usb port basically, it's slow
Oct 30 14:45:08 <Stove> also plex barely works on it
Oct 30 14:45:14 <Stove> but it does
Oct 30 14:45:23 <zmatt> so, things where the beagleboards and beaglebones shine are: TI is very open (thousands of pages of SoC documentation), hardware design is open, nice capabilities for real-time I/O via PRUSS
Oct 30 14:46:46 <Stove> PRU = DSP?
Oct 30 14:46:55 <zmatt> but they're usually not the cheapest nor performance monsters, relatively
Oct 30 14:46:57 <zmatt> no
Oct 30 14:47:41 <Stove> and there's variants
Oct 30 14:47:45 <Stove> like black and green, what's that about?
Oct 30 14:47:47 <zmatt> PRU cores are simple risc processors with deterministic timing and ultra low latency I/O (basically pins wired nearly straight to registers)
Oct 30 14:48:37 <zmatt> AM335x (the SoC used on the beaglebones) has one PRUSS instance, consisting of two PRU cores + local ram and peripherals, while the AM572x has two PRUSS instances
Oct 30 14:49:07 <Stove> So what do you use it for?
Oct 30 14:49:11 <zmatt> yeah there are a bunch of variants and derivative... the green (by Seeed) is a one without hdmi
Oct 30 14:50:03 <zmatt> I'm not a huge fan of the green and definitely not one of the green-wireless... Seeed should have put more thought into the modifications they did :)
Oct 30 14:50:12 <zmatt> we embed them in our products
Oct 30 14:50:37 <zmatt> (a beaglebone black)
Oct 30 14:50:49 <Stove> Do you want to say which company or not?
Oct 30 14:51:00 <zmatt> https://dutchdutch.com/
Oct 30 14:51:25 <Stove> Alright, thanks for the help zmatt.
Oct 30 14:52:16 <zmatt> btw, you said 3 drives in raid... connected how?
Oct 30 14:52:40 <Stove> I was thinking usb3, ye I know it's not ideal
Oct 30 14:53:01 <Stove> but there are literally no boards with sata besides helios4 which is never available
Oct 30 14:53:34 <zmatt> note that the usb3 ports on the x15 are all downstream on a single integrated hub
Oct 30 14:53:43 <zmatt> so they'll share bandwidth
Oct 30 14:53:46 <Stove> usb3 hub at least right?
Oct 30 14:53:58 <zmatt> yes
Oct 30 14:54:06 <Stove> mm
Oct 30 14:54:08 <zmatt> (TUSB8041)
Oct 30 14:54:15 <zmatt> am572x has sata
Oct 30 14:54:17 <Stove> I expected them to be independent
Oct 30 14:56:15 <Stove> should have just gotten a qnap arm thing
Oct 30 14:56:31 <zmatt> yeah I suspect the am572x might not be an optimal fit for your application
Oct 30 14:57:33 <zmatt> it might still work fine of course, but if you're basically just looking for a nas/server then I suspect there are boards with better price/performance ratio out there
Oct 30 14:58:36 <Stove> Yeah you're right.
Oct 30 14:59:00 <zmatt> and a lot of the cool functionality of the x15 will end up unused
Oct 30 15:13:27 <kremlin> m
Oct 30 20:26:27 <zmatt> thinkfat: this sounds familiar... https://e2e.ti.com/support/processors/f/791/t/740138 ;-)
Oct 30 20:29:22 <thinkfat> zmatt: indeed, somewhat familiar...
Oct 30 20:54:07 <zmatt> pff, e2e is awful to browse since they've merged the forums for all their processors into one extremely high volume forum
Oct 30 21:02:35 <zmatt> whoa, since when are there AM65xx SoCs
Oct 30 21:38:06 <William_Engelhar> Hello, is this a room or a person?
Oct 30 21:38:17 <zmatt> it's an irc channel
Oct 30 21:38:50 <zmatt> so yeah, a chat room
Oct 30 21:39:09 <William_Engelhar> Looked like it.  I'm trying to find a DIN mount metal enclosure for the BBB Rev c that allows room for a cape.
Oct 30 21:39:42 <William_Engelhar> The only one I've ever found is no longer being sold by the mfg: https://www.logicsupply.com/bb100-orange/
Oct 30 21:40:02 <William_Engelhar> And it's more of a frame than an enclosure.
Oct 30 21:41:18 <William_Engelhar> I've also contacted EmbeddedGlow to see if they offer a tall version: https://embeddedglow.com/items/BC3/BC3.php
Oct 30 21:42:51 <zmatt> no idea, sorry
Oct 30 21:43:28 <William_Engelhar> Its probably going to be a custom job.  Just taking one more look before I give up.
Oct 30 22:26:54 <zmatt> interesting that the new AM65xx uses the Cortex-A53, which is substantially slower (per MHz) than the cortex-a15
Oct 31 02:14:02 <zmatt> neat, rseq (restartable sequences) introduced in kernel 4.18 enable a variety of per-cpu datastructure updates to be implemented lock-free
Oct 31 02:14:34 <zmatt> which, on a uniprocessor like the cortex-a8 simply means "enable a variety of datastructure updates to be implemented lock-free"
**** ENDING LOGGING AT Wed Oct 31 02:59:58 2018