**** BEGIN LOGGING AT Sun Oct 06 02:59:57 2019
Oct 06 03:29:34 <set_> Is using matplotlib, pandas, and numpy and/or scipy too "heavy"/consume too many resources for the BBBW?
Oct 06 03:36:29 <set_> Well...I think pandas is out.
Oct 06 03:37:09 <set_> Is pandas out on the BBAI?
Oct 06 03:42:15 <set_> Forget it. pip3 install pandas and not apt.
Oct 06 03:42:16 <set_> Sheesh.
Oct 06 04:19:46 <nickc890[m]> is anyone here? i have a question
Oct 06 04:21:10 <nickc890[m]> Do you have to use 1 amps or will 2,5 work for powering beaglebone?
Oct 06 04:21:58 <zmatt> 2A or more is recommended, but I think 1A probably still works
Oct 06 04:22:11 <zmatt> depends a bit on what you do with it of course
Oct 06 04:22:25 <nickc890[m]> Is there anything where malfunction if you give too much power
Oct 06 04:22:46 <nickc890[m]> Like where wont read mciro sd’s?
Oct 06 04:23:11 <zmatt> that's not how electricity works, the current rating of a supply indicates how much the device can draw from the supply, it can't force it down the device's throat
Oct 06 04:23:51 <nickc890[m]> Yeah... because mine wouldnt take Micro SD’s I gave it 2.5 amps
Oct 06 04:24:11 <nickc890[m]> It wouldnt read the images and install on beaglebone
Oct 06 04:24:18 <zmatt> that sounds odd
Oct 06 04:24:43 <nickc890[m]> Yeah I sent back beaglbone I think might been the reader on it
Oct 06 04:24:49 <zmatt> if the power supply is insufficient I'd expect the board to simply power off
Oct 06 04:25:10 <nickc890[m]> Yeah and that did not happen where it would shut off
Oct 06 04:26:11 <zmatt> the only things I can imagine that might behave erratically (without powering off entirely) if the power supply is insufficient is the usb host port, and *maybe* the hdmi output
Oct 06 04:26:13 <nickc890[m]> Im guessing was manufacture defect where wouldnt read microsd’s
Oct 06 04:26:42 <nickc890[m]> Mine does t have HdMi out port.
Oct 06 04:27:21 <nickc890[m]> Raspberry pi’s have HDMI out port though
Oct 06 04:27:21 <zmatt> ah it's a beaglebone green?  you should try to be specific about which board you have exactly when asking questions
Oct 06 04:27:41 <zmatt> beaglebone black and beaglebone black wireless have HDMI output
Oct 06 04:27:44 <nickc890[m]> Beaglebone blscks dont have HDMI out either
Oct 06 04:27:47 <zmatt> they do
Oct 06 04:27:58 <zmatt> there's a micro-HDMI port on it
Oct 06 04:28:04 <nickc890[m]> One I had didnt and was beaglebone black
Oct 06 04:28:11 <nickc890[m]> Oh micro
Oct 06 04:28:35 <nickc890[m]> Thats why. I wasnt for sure I was confused
Oct 06 04:29:28 <nickc890[m]> Well I just ordered me a green because thay black one I got had a manufacture defect
Oct 06 04:29:57 <zmatt> has it been confirmed to be a defect? :P
Oct 06 04:30:25 <nickc890[m]> Idk I spent all week trying get take image .iso and install iy
Oct 06 04:30:55 <nickc890[m]> It was ridiculous
Oct 06 04:31:01 <zmatt> (the images don't have an .iso suffix :P )
Oct 06 04:31:31 <nickc890[m]> Idk zi formstted card for linux and still didny take what had on it
Oct 06 04:31:48 <zmatt> well if you came here before you sent it back it would probably not have been too hard to confirm whether or not it was a hardware defect
Oct 06 04:32:12 <zmatt> I have no idea what that sentence means
Oct 06 04:32:17 <nickc890[m]> Next time Ill just come here
Oct 06 04:32:40 <nickc890[m]> I had formatted microsd for linux I was saying
Oct 06 04:32:58 <zmatt> formatting the card is irrelevant since you overwrite it entirely by the image
Oct 06 04:33:12 <zmatt> which undoes any formatting previously done
Oct 06 04:33:19 <nickc890[m]> Do you got skype because when have issue could just call you
Oct 06 04:33:25 <zmatt> no
Oct 06 04:33:37 <nickc890[m]> Hmm darn.
Oct 06 04:33:58 <nickc890[m]> Yeah I did format card so ruined what had on it before
Oct 06 04:34:00 <zmatt> even if I did, I'm not your personal assistant.  when you have questions, just ask them here in this channel and have patience since it can take quite a while for someone to respond
Oct 06 04:34:28 <nickc890[m]> K.
Oct 06 04:34:49 <nickc890[m]> Do you know what kiwisdr is
Oct 06 04:34:56 <nickc890[m]> Im trying get that work on my beaglebone
Oct 06 04:34:59 <zmatt> never heard of it
Oct 06 04:35:18 <set_> Radio!
Oct 06 04:35:39 <nickc890[m]> https://www.seeedstudio.com/KiwiSDR-Board-p-2723.html
Oct 06 04:35:46 <nickc890[m]> Its that basically
Oct 06 04:35:50 <zmatt> yes I already found it, I know how google works :P
Oct 06 04:36:08 <nickc890[m]> Yeah but works with beaglebone
Oct 06 04:36:19 <zmatt> that's what it says yes
Oct 06 04:36:23 <nickc890[m]> But trying get os on microsd having maybe issues with that
Oct 06 04:37:03 <nickc890[m]> I tried make bootable thr microsd with image file
Oct 06 04:37:59 <nickc890[m]> That might be my issue is I dont know how do it correctly
Oct 06 04:38:57 <zmatt> maybe should have bought the kit (kiwisdr + beaglebone green), then the software comes preinstalled :P
Oct 06 04:39:23 <zmatt> seems the procedure is pretty straightforward
Oct 06 04:39:26 <nickc890[m]> Maybe but I dont have $300
Oct 06 04:39:48 <nickc890[m]> What you mesn strsightfoward you make microsd bootable
Oct 06 04:40:15 <zmatt> if I could find the software image...
Oct 06 04:40:25 <nickc890[m]> A beagles a lot cheaper alone so.. you got weigh your costs. explain straighfoward
Oct 06 04:40:43 <zmatt> oh they ask a lot more for the kit than the parts of that kit? that's dumb
Oct 06 04:41:01 <zmatt> oh what
Oct 06 04:41:05 <nickc890[m]> See... kits $300 haha
Oct 06 04:41:27 <zmatt> apparently the kiwisdr comes with an sd card that can be used to flash the software onto beaglebones
Oct 06 04:41:31 <nickc890[m]> A kit with beaglebone prrindtalled is $400
Oct 06 04:42:18 <nickc890[m]> Yeah but I formatted that Microsd because agent was working with I thought told me format it but I jumped gun to wuick
Oct 06 04:42:23 <nickc890[m]> Quick I mean
Oct 06 04:42:27 <zmatt> -.-
Oct 06 04:42:39 <zmatt> okay so you'll have to fix the sd card first
Oct 06 04:43:04 <nickc890[m]> Yeah so need flash new OS on it which on kiwi’s website
Oct 06 04:43:11 <zmatt> yeah, this is the link they gave: https://www.dropbox.com/s/bf5yl3qd2tvm216/KiwiSDR_v1.46_BBB_Debian_8.4.img.xz?dl=1
Oct 06 04:43:23 <zmatt> I suggest using etcher (etcher.io) to write it to sd card
Oct 06 04:43:28 <nickc890[m]> Then have make botable right
Oct 06 04:43:38 <zmatt> you just install the image to sd card and that's it
Oct 06 04:43:50 <zmatt> there are no additional steps
Oct 06 04:43:59 <nickc890[m]> I thought you have make bootable
Oct 06 04:44:03 <zmatt> (for preparing the sd card that is)
Oct 06 04:44:04 <nickc890[m]> You cannot drag drop file
Oct 06 04:44:25 <nickc890[m]> TO the sd you have make bootsble iso on sd correct
Oct 06 04:44:39 <zmatt> if you use etcher to write the .img.xz file to sd card, it will bootable
Oct 06 04:45:02 <nickc890[m]> Yeah and have to export xz correct
Oct 06 04:45:09 <zmatt> (you can also use other tools, but etcher makes it easy)
Oct 06 04:45:12 <nickc890[m]> Then you use etcher
Oct 06 04:45:13 <mrpackethead> happy, happy, happy. http://6phrweatherstation.s3-website-ap-southeast-2.amazonaws.com/
Oct 06 04:45:18 <zmatt> you don't need to expand the .xs, etcher accepts .img.xz directly
Oct 06 04:45:22 <mrpackethead> GreenGrass+ Beagle
Oct 06 04:45:30 <nickc890[m]> Oh okay
Oct 06 04:45:52 <nickc890[m]> Is etecher best way go then
Oct 06 04:46:07 <zmatt> just download file, use etcher to write it to sd card, and that's all you need to do to fix the sd card
Oct 06 04:46:24 <zmatt> then follow the quick start instructions for flashing the beaglebone
Oct 06 04:46:26 <nickc890[m]> Okay sounds like a plan
Oct 06 04:46:57 <nickc890[m]> I wasnt using etcher before that might been readon why didnt install on beaglebone
Oct 06 04:47:12 <zmatt> like I said, you can use other tools, but etcher just makes it easy
Oct 06 04:47:53 <nickc890[m]> Is etcher a windows only tool or does work on mac
Oct 06 04:48:33 <zmatt> why are you asking that when the answer is on the etcher.io homepage?
Oct 06 04:48:41 <zmatt> "Cross Platform"
Oct 06 04:48:58 <zmatt> mac, windows, linux
Oct 06 04:49:35 <nickc890[m]> Okay nice. I just wanted hear because you knew most about this subject matter
Oct 06 04:50:50 <nickc890[m]> Thanks for the help. Ill come back if run into issues.
Oct 06 04:52:04 <desttinghim[m]> Back again, this time I am trying to get an i2s dac to output sound. The IC is a pcm5102
Oct 06 04:56:23 <desttinghim[m]> I'm not even sure if I have the pins connected correctly
Oct 06 04:57:53 <zmatt> sounds rough
Oct 06 04:59:15 <desttinghim[m]> Yeah, I don't have anything specific to ask yet
Oct 06 04:59:35 <zmatt> yeah since you haven't provided any information on how you connected it or how you tried to configure its DT, I assumed you were merely looking for moral support
Oct 06 05:00:03 <desttinghim[m]> https://www.amazon.com/Diymore-PCM5102-Decoder-32-bit-PCM1794/dp/B06XD9LKG3/ref=pd_cp_328_1/142-8432758-8957117?_encoding=UTF8&pd_rd_i=B06XD9LKG3&pd_rd_r=4445db26-fe35-4c28-ba38-68b95065b722&pd_rd_w=4HBzt&pd_rd_wg=A4d8g&pf_rd_p=ef4dc990-a9ca-4945-ae0b-f8d549198ed6&pf_rd_r=A7XVQX5S5AQWETHE3449&psc=1&refRID=A7XVQX5S5AQWETHE3449
Oct 06 05:00:13 <desttinghim[m]> This is the specific breakout I am using
Oct 06 05:00:32 <desttinghim[m]> The pi hookup guide isn't particularily helpful
Oct 06 05:01:45 <zmatt> lovely how the title contains two random other DACs at the end
Oct 06 05:02:52 <zmatt> looks like a pretty straightforward breakout though
Oct 06 05:03:23 <desttinghim[m]> Yeah, I've just got to wrap my head around BBB i2s
Oct 06 05:03:23 <desttinghim[m]> https://hifiduino.wordpress.com/2014/03/10/beaglebone-black-for-audio/
Oct 06 05:03:47 <zmatt> and the part number in the title is wrong, the photo clearly shows it's a PCM5102A, not a PCM5102
Oct 06 05:03:49 <desttinghim[m]> I'm using the pins indicated in this post as I understand them
Oct 06 05:04:29 <desttinghim[m]> amazon is a weird place
Oct 06 05:04:38 <zmatt> the second line of that table is already wrong, woohoo
Oct 06 05:04:53 <desttinghim[m]> oh boy
Oct 06 05:05:07 <zmatt> well, not very wrong I guess, it just depends
Oct 06 05:06:36 <zmatt> the BBB can support any reasonable sample rate if the codec (rather than the BBB) is the bck/lrck master or a suitable master clock is provided externally
Oct 06 05:08:49 <zmatt> (regarding the pmic) "However I2C access to the chip seems not easy at this moment" ... it actually is, you can just use i2cget/i2cset from userspace
Oct 06 05:09:35 <zmatt> although I think it'll need root privileges to do so (as safety measure because the address is already claimed by a kernel driver)
Oct 06 05:11:34 <desttinghim[m]> I was mostly looking at the pin header reference
Oct 06 05:11:44 <zmatt> desttinghim[m]: these are the notes I found in my pastebin account regarding audio: https://pastebin.com/37Vr51Wr https://pastebin.com/VmHHXagD https://pastebin.com/NNiYJqHF  (I doubt the last one is of any importance to you)
Oct 06 05:11:45 <desttinghim[m]> https://hifiduino.files.wordpress.com/2014/03/i2spins.jpg
Oct 06 05:11:55 <zmatt> the first one has lots of details regarding pinout
Oct 06 05:12:24 <zmatt> oh you'll want to view that first one in raw format to make tabs align properly
Oct 06 05:12:30 <zmatt> i.e. https://pastebin.com/raw/37Vr51Wr
Oct 06 05:12:47 <zmatt> (pastebin wrongly assumes a tab width of 4 spaces, the browser correctly assumes a tab width of 8 spaces)
Oct 06 05:17:05 <desttinghim[m]> Okay, so I have connected the pins like so:
Oct 06 05:17:24 <zmatt> (beware that the mcasp linux driver currently only supports synchronized tx/rx sections, hence the rx hclk/clk/fs pins won't be used)
Oct 06 05:17:30 <desttinghim[m]> P9.28 -> DIN
Oct 06 05:17:51 <desttinghim[m]> P9.29 -> LCK
Oct 06 05:18:02 <desttinghim[m]> P9.31 -> BCK
Oct 06 05:18:43 <desttinghim[m]> VCC and XMT to 3.3v and everything else to ground
Oct 06 05:18:59 <zmatt> huh, this breakout doesn't have SCK pinned out?
Oct 06 05:19:08 <zmatt> what's the codec using as master clock then?
Oct 06 05:19:24 <zmatt> oh unless "SCL" is a typo for SCK
Oct 06 05:19:52 <zmatt> yeah that must be it, the pcm5102a doesn't have an i2c interface
Oct 06 05:20:08 <desttinghim[m]> That sounds reasonable
Oct 06 05:20:42 <desttinghim[m]> Does that mean P9.25 -> SCL?
Oct 06 05:21:08 <zmatt> yeah
Oct 06 05:26:42 <desttinghim[m]> Okay, so the second pastebin is a device tree overlay for simple sound card
Oct 06 05:26:59 <zmatt> yes, and the bbb has to be master
Oct 06 05:27:04 <zmatt> (for this codec)
Oct 06 05:27:48 <desttinghim[m]> So I can remove the else clause
Oct 06 05:28:15 <zmatt> indeed
Oct 06 05:28:25 <desttinghim[m]> What does `dai-link` mean
Oct 06 05:28:37 <zmatt> digital audio interface link
Oct 06 05:29:00 <zmatt> i.e. a digital audio interface connection between two components
Oct 06 05:29:10 <desttinghim[m]> that makes sense
Oct 06 05:29:24 <zmatt> (your "sound card" can have multiple of such links)
Oct 06 05:30:00 <desttinghim[m]> Can the compatible and name fields be changed?
Oct 06 05:30:11 <desttinghim[m]> e.g. name to "PCM5102A"
Oct 06 05:30:39 <zmatt> you can name it whatever you want, the "compatible"-string indicates the driver to be used hence must not be changed
Oct 06 05:31:14 <zmatt> note that you will also need to declare the codec in DT (which DT snippet references as &codec )
Oct 06 05:31:38 <zmatt> (you can use a different label if you want and change the &codec reference accordingly)
Oct 06 05:32:31 <zmatt> interesting the SCK is actually optional for this codec
Oct 06 05:32:39 <zmatt> it has an integrated PLL
Oct 06 05:35:02 <desttinghim[m]> DT = device tree? By codec you are referring to the IC (pcm5102a)?
Oct 06 05:35:17 <zmatt> yes
Oct 06 05:35:22 <zmatt> (on both)
Oct 06 05:36:52 <desttinghim[m]> Oops, screwed up that configuration
Oct 06 05:37:04 <desttinghim[m]> Time to get out the SD card
Oct 06 05:37:09 <zmatt> lol
Oct 06 05:37:33 <desttinghim[m]> Okay, so I need to look for pcm5102a drivers in the linux kernel is what I am getting from this
Oct 06 05:37:55 <zmatt> preferably yes
Oct 06 05:38:01 <desttinghim[m]> And then change &codec to &pcm5102a if it exists?
Oct 06 05:38:49 <zmatt> you can use whatever label you want, it's just used to have a DT property refer to another DT node, they're not used by the kernel in any way
Oct 06 05:39:04 <zmatt> the only requirement on labels is that they're unique across the DT
Oct 06 05:39:24 <zmatt> (and they must be valid C identifiers, i.e. alphanumeric and underscores only, may not start with a digit)
Oct 06 05:39:44 <zmatt> &foo    refers to a node labeled with   foo:
Oct 06 05:40:47 <zmatt> (see also https://pastebin.com/XC8vB33d for more general info about DT)
Oct 06 05:45:17 <desttinghim[m]> Sorry for all the dumb questions, how device trees work still hasn't clicked for me yet
Oct 06 05:45:38 <zmatt> no worries
Oct 06 05:45:58 <desttinghim[m]> Do I need to set &codec equal to something outside of the root / { }?
Oct 06 05:47:38 <zmatt> you'll need to create a node for your codec (since it's not on any bus, putting it in / is fine), label it with something (e.g. codec: or whatever you like) and then use that reference (e.g. &codec) in place of &codec
Oct 06 05:48:32 <zmatt> (if the codec had i2c control, you'd make it a child node of the appropriate i2c controller instead)
Oct 06 05:49:48 <desttinghim[m]> Oh, is that what the third pastebin link was showing?
Oct 06 05:49:53 <zmatt> nope
Oct 06 05:50:21 <desttinghim[m]> Ok, it was showing 3 different ways of setting the clock rate
Oct 06 05:51:38 <zmatt> the system clock rate yeah, but you should just reference the BBB's audio osc (which is defined in the base DT), which is what my simple audio card example already does
Oct 06 05:52:31 <zmatt> mcasp0 itself will also need some configuration
Oct 06 05:52:37 <desttinghim[m]> So the codec node is seperate from the sound node e.g. sound { }; codec { };
Oct 06 05:52:43 <zmatt> yes
Oct 06 05:53:59 <zmatt> three nodes are involved: the cpu side (&mcasp0, defined in the base DT but you'll stlil need a &mcasp0 { .. }; block in your overlay to configure it), the codec, and the soundcard which ties them together
Oct 06 05:54:26 <zmatt> oh and a pinmux node for mcasp I guess
Oct 06 05:55:26 <zmatt> there are probably examples out there somewhere, I'm a bit too energyless right now to search for or make one
Oct 06 05:57:21 <desttinghim[m]> No problem, you've been super helpful already
Oct 06 05:57:57 <desttinghim[m]> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-univ-audio-00A0.dts
Oct 06 05:58:42 <desttinghim[m]> Is this similar to what the pinmux node will be like?
Oct 06 05:59:18 <zmatt> ugh, for learning anything about DT, you really don't want to look at cape-universal stuff as example :P
Oct 06 05:59:37 <zmatt> look for some audio cape or something
Oct 06 05:59:48 <desttinghim[m]> I'll keep that in mind then
Oct 06 06:01:05 <zmatt> btw, for a summary of how the hideous overlay syntax (as seen in bb.org-overlays) corresponds to normal DT syntax (as used by the base DT and by my overlay-utils), see: https://pastebin.com/b8kZfhRG
Oct 06 06:02:26 <desttinghim[m]> Ah. I was wondering what all those fragment@0 and such were about
Oct 06 06:02:56 <zmatt> yeah I don't understand why dtc doesn't just have a flag to generate that shit for you, instead of forcing you to write it out manually
Oct 06 06:03:07 <desttinghim[m]> Wow, you're right about the syntax being hideous
Oct 06 06:03:10 <zmatt> my overlay-utils uses a perl script to perform the transformation
Oct 06 06:04:28 <desttinghim[m]> I've been using that for building all of the dtsi files I've been trying to write
Oct 06 06:04:54 <zmatt> yeah I don't get why anyone would want to write out overlays manually
Oct 06 06:06:00 <zmatt> the benefit of overlay-utils is that the files you write as input can equally well be #included into a main DT, so if you want you can switch between using a custom main DT and using overlays
Oct 06 06:06:09 <zmatt> *another benefit
Oct 06 06:09:41 <desttinghim[m]> Overlays = boot time configuration, custom main dt = compile time?
Oct 06 06:10:11 <zmatt> yeah, u-boot loads a main dt and optionally applies overlays to them before passing the result to the kernel
Oct 06 06:10:54 <zmatt> I mean, in both cases the configuration is done by putting compiled DT files in the appropriate place and configuring /boot/uEnv.txt
Oct 06 06:11:39 <zmatt> overlays however grant modularity (but are more limited in what you can do and the amount of error-checking that dtc can do, hence mistakes usually end up in boot failure)
Oct 06 06:11:54 <zmatt> overlays are especially nice for cape autodetection
Oct 06 06:12:03 <desttinghim[m]> Ok
Oct 06 06:13:01 <desttinghim[m]> I'm planning on making a portable music player, so I'll want to use a custom dt at some point I suspect
Oct 06 06:14:20 <zmatt> maybe, you don't have to
Oct 06 06:14:39 <zmatt> another benefit of overlays is that it decouples your changes from the kernel-version-dependent base DT
Oct 06 06:14:59 <zmatt> (in theory DTs should be kernel-independent, but in practice that's often not really true)
Oct 06 06:15:24 <desttinghim[m]> I see
Oct 06 06:51:21 <desttinghim[m]> zmatt: I think I found a useful reference http://www.ti.com/lit/an/sprac97/sprac97.pdf
Oct 06 06:51:42 <desttinghim[m]> Once I get back home im going to try it
Oct 06 06:53:04 <desttinghim[m]> Has a device tree fragment example in 4.2.3 on pages 13-14
Oct 06 06:53:06 <zmatt> looks like they're not actually using a pcm5102a though
Oct 06 06:53:16 <zmatt> they're just abusing it as a generic codec driver
Oct 06 06:53:21 <zmatt> (after modification)
Oct 06 06:53:32 <zmatt> I actually made a generic codec driver for a similar purpose
Oct 06 06:54:06 <zmatt> some of the example still applies
Oct 06 06:54:35 <zmatt> but they're using mcasp as slave and receiver, you're using it as master and transmitter
Oct 06 06:54:44 <zmatt> so some changes will be needed
Oct 06 06:57:06 <mrpackethead2> change? nooooo.
Oct 06 08:09:22 <desttinghim[m]> I am pretty sure I need to change the values in pinctrl-single,pins but I don't know what those values mean
Oct 06 08:09:42 <desttinghim[m]> I found this pdf that explains the pinmuxes http://www.ofitselfso.com/BeagleNotes/pinmux.pdf
Oct 06 08:09:56 <zmatt> desttinghim[m]: you shouldn't use magic hex values anyway, use macros
Oct 06 08:10:05 <zmatt> look at some of the other examples in overlay-utils
Oct 06 08:10:39 <desttinghim[m]> USES_PIN?
Oct 06 08:10:51 <zmatt> (note: the pinmux macros in overlay-utils are different (and I think maybe older) than the ones in mainline)
Oct 06 08:10:59 <zmatt> no, those are just to avoiding conflict with cape-universal
Oct 06 08:11:28 <desttinghim[m]> PIN_IN_PULLUP and etc?
Oct 06 08:14:41 <zmatt> https://pastebin.com/raw/w3ZkiD8x   this is an example from one of my own DTs
Oct 06 08:15:00 <zmatt> which differs from what you need in a number of ways, but it does show an example for pinmux
Oct 06 08:15:29 <zmatt> (note btw that PIN_IO_ and PIN_IN_ are actually synonyms, I just provide both of them for documentation purposes)
Oct 06 08:16:00 <zmatt> in your case AUDIO_IN would be false, AUDIO_OUT_MASTER would be true
Oct 06 08:16:51 <zmatt> NUM_SLOTS is 2, NUM_BITS is irrelevant since you don't need that in your DT (I need it because I'm using my dummy codec ("tdm-audio") driver)
Oct 06 08:17:16 <zmatt> instead of my "dsp" block you'd have your codec block
Oct 06 08:19:08 <zmatt> which doesn't seem to require any configuration: https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/pcm5102a.txt ... although I'm pretty sure that example is wrong: you still need #sound-dai-cells = <0>;
Oct 06 08:22:32 <zmatt> and of course you'll need to adjust the pinmux block for the pins you want to use... as well as the mode used (the P8 ioset for mcasp0 uses mode 3/4, the P9 ioset uses mode 0/2, see https://pastebin.com/raw/37Vr51Wr )
Oct 06 08:24:04 <zmatt> for the tx clk/fs pins it *may* (depending on how the linux driver configures mcasp exactly) be essential to use PIN_IO_ rather than PIN_OUT_ ... in general, when in doubt using PIN_IO_ is the safest, it always works
Oct 06 08:26:32 <zmatt> likewise when in doubt enable pull-up or -down, preferably matching whatever the default pull is for that pin.  for pins that are always driven (by either BBB or external hardware) using NOPULL may save a tiny bit of power consumption.
Oct 06 08:27:44 <zmatt> the main things to avoid are: having NOPULL on a pin that may be undriven and has no external pull-up/down, and using internal pull in a direction that opposes external pulls (which are present on P8.31-P8.46)
Oct 06 08:28:30 <zmatt> desttinghim[m]: sorry for the overwhelming info dump... just save it all and consume at your leasure ;)
Oct 06 08:29:51 <desttinghim[m]> Don't worry about it. Trying to parse the new paste and combine it with the TI example
Oct 06 08:30:45 <desttinghim[m]> And figuring out the mcasp0 pins
Oct 06 08:35:11 <zmatt> desttinghim[m]: https://pastebin.com/raw/XCmYvnRF
Oct 06 08:35:24 <zmatt> would be my suggestion
Oct 06 08:35:55 <desttinghim[m]> I have a worrying number of tabs open
Oct 06 08:36:48 <zmatt> at times I've had so many tabs open that not even the tab icons were visible anymore
Oct 06 08:37:37 <zmatt> at the moment I have only 49 tabs open though
Oct 06 08:38:03 <desttinghim[m]> I'm using IceCat atm (rebranded firefox) and it just lets me scroll when too many appear
Oct 06 08:38:19 <desttinghim[m]> *only* 49 tabs
Oct 06 08:40:17 <desttinghim[m]> I have 45
Oct 06 08:40:47 * tbr laughs at those puny numbers
Oct 06 08:41:18 <desttinghim[m]> but i usually cull the number of tabs i have open on a regular basis
Oct 06 08:54:15 <desttinghim[m]> Well, I got it compiling
Oct 06 08:54:33 <zmatt> want me to glance at it?
Oct 06 08:54:59 <desttinghim[m]> sure, let me put it on pastebin
Oct 06 08:55:41 <desttinghim[m]> https://pastebin.com/aeYupf3L
Oct 06 08:56:28 <zmatt> you're missing a label on your pcm5102a node
Oct 06 08:57:44 <zmatt> to be able to refer to it with &pcm5102a you need to label it with pcm5102a:
Oct 06 08:58:11 <zmatt> (alternatively you could refer to it by full path, &{/pcm5102a} )
Oct 06 08:58:25 <zmatt> (but for some reason I've never seen that syntax used in the wild)
Oct 06 08:59:11 <desttinghim[m]> Didn't realize I needed the label, thanks
Oct 06 08:59:33 <desttinghim[m]> The full syntax seems sucky
Oct 06 08:59:51 <zmatt> node names merely uniquely identify a node within its parent node
Oct 06 09:00:09 <zmatt> while labels are used for being able to refer to a node from anywhere
Oct 06 09:00:28 <desttinghim[m]> ah
Oct 06 09:00:48 <desttinghim[m]> I just need to add this to /boot/uEnv.txt then
Oct 06 09:01:16 <desttinghim[m]> uboot_overlay_addr5=/lib/firmware/pcm5102a.dtbo
Oct 06 09:01:33 <desttinghim[m]> the addr5 can be anything from 4 to 7, right?
Oct 06 09:01:39 <zmatt> this is why for the pinmux node I use asp0 as node name but asp0_pins as label: putting "pins" in the node name would be silly since it's already a child node of the pinmux controller... what else would it be.  but the label needs to be globally meaningful
Oct 06 09:01:43 <zmatt> yes
Oct 06 09:02:01 <desttinghim[m]> alright rebooting
Oct 06 09:02:09 <zmatt> oh wait
Oct 06 09:02:19 <zmatt> no never mind, I was looking at the wrong tab
Oct 06 09:02:55 <desttinghim[m]> Well I did something wrong
Oct 06 09:03:02 <zmatt> I would use larger values for tx/rx-num-evt in &mcasp0
Oct 06 09:03:04 <zmatt> I use 32
Oct 06 09:03:22 <zmatt> boot failure?
Oct 06 09:03:59 <desttinghim[m]> yeah
Oct 06 09:05:07 <zmatt> oh hum maybe &audio_osc_ck is wrong
Oct 06 09:05:18 <zmatt> what's it called then...
Oct 06 09:06:29 <zmatt> ah it's called &clk_mcasp0
Oct 06 09:06:46 <zmatt> which seems like a weird name for it, but ok
Oct 06 09:08:26 <zmatt> at least I hope that's part of the main DT even when HDMI-audio is disabled
Oct 06 09:08:33 <zmatt> oh that reminds me, disable HDMI audio!
Oct 06 09:09:28 <zmatt> you know something, I think it's actually not part of the base DT... which seems really weird to me since the audio osc is obviously a fixed part of the BBB
Oct 06 09:11:14 <zmatt> desttinghim[m]: also, either add USES_PIN statements for each pin used, or disable cape-universal in /boot/uEnv.txt ... the USES_PIN lines are required for compatibility with cape-universal
Oct 06 09:11:42 <desttinghim[m]> okay
Oct 06 09:11:52 <zmatt> and I think you'll need to copy-paste these two nodes (as children of /): https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-HDMI-TDA998x-00A0.dts#L108-L119
Oct 06 09:16:17 <desttinghim[m]> https://github.com/desttinghim/overlay-utils/blob/master/pcm5102a.dtsi
Oct 06 09:18:24 <zmatt> and maybe in the enable-gpios property of clk_mcasp0 replace the "0" by ACTIVE_HIGH so you actually know what it means :P
Oct 06 09:18:29 <zmatt> but that's just cosmetic
Oct 06 09:18:59 <zmatt> what's the clock-names doing in the codec of the dai-link ?
Oct 06 09:19:12 <zmatt> clock-names belongs together with clocks
Oct 06 09:20:33 <desttinghim[m]> I was looking at the ti doc for that
Oct 06 09:20:48 <zmatt> in general, a -names property gives the names of a sequence of things given in some other property, or sequence of properties, in the same node
Oct 06 09:22:21 <zmatt> e.g. pinctrl-names = "default"; says that pinctrl state 0 is named "default", and the pinctrl-0 property contains the pinctrl node(s) for it
Oct 06 09:24:06 <desttinghim[m]> I see
Oct 06 09:24:11 <zmatt> clock-names = "mclk"; together wih clocks = <&clk_mcasp0>; says that the "mclk" clock for the cpu side of this dai-link is &clk_mcasp0
Oct 06 09:26:04 <desttinghim[m]> ok, I pushed the changes to github, going to try it again
Oct 06 09:26:05 <desttinghim[m]> I disabled the audio and video overlays
Oct 06 09:26:29 <zmatt> sorry I should have been clearer, the clock-names is needed, it was just in the wrong place
Oct 06 09:27:00 <zmatt> actually is it needed?
Oct 06 09:27:05 <zmatt> did I have it in my example?
Oct 06 09:27:09 <zmatt> if not, then it's not needed :P
Oct 06 09:27:40 <zmatt> it's not needed
Oct 06 09:27:43 <zmatt> never mind me, I was babbling
Oct 06 09:27:51 <desttinghim[m]> It booted
Oct 06 09:27:54 <zmatt> \o/
Oct 06 09:28:20 <desttinghim[m]> Unfortuantely, no sound cards are detected :(
Oct 06 09:28:40 <zmatt> odd, check kernel log for errors?
Oct 06 09:29:07 <zmatt> also  grep PCM5102 /boot/config-$(uname -r)
Oct 06 09:30:08 <desttinghim[m]> CONFIG_SND_SOC_PCM5102A=y
Oct 06 09:30:15 <zmatt> ok good
Oct 06 09:31:07 <zmatt> also remove simple-audio-card,format in your sound node... format is specified in the dai-link
Oct 06 09:31:44 <zmatt> simple-audio-card,format is part of an older style of configuring simple-audio-card that only supports a single dai-link
Oct 06 09:32:19 <zmatt> (so basically the contents of the dai-link would be dumped into the sound node, with everything given the "simple-audio-card," prefix)
Oct 06 09:33:44 <desttinghim[m]> ok
Oct 06 09:34:12 <desttinghim[m]> it doesn't look like there's anything in the kernel logs
Oct 06 09:34:26 <zmatt> hmm
Oct 06 09:36:41 <zmatt> can you pastebin: ls /sys/bus/platform/devices/
Oct 06 09:39:02 <desttinghim[m]> https://pastebin.com/bQvQxV3Z
Oct 06 09:40:17 <zmatt> that's odd, none of your devices showed up
Oct 06 09:40:37 <zmatt> not even mcasp0
Oct 06 09:41:31 <zmatt> and even merely &mcasp0 { status = "okay"; }; should already be enough for it to show up (unless there's a probe failure, but then I'd expect some error in the kernel log)
Oct 06 09:42:38 <zmatt> your USES_PIN declarations weren't applied either
Oct 06 09:42:44 <zmatt> it looks like the entire overlay wasn't used
Oct 06 09:43:12 <zmatt> which strikes me as odd, as far as I know u-boot either applies the overlay, or boot fails
Oct 06 09:44:27 <desttinghim[m]> that is strange
Oct 06 09:45:45 <zmatt> (but it's quite possible I don't know everything about error cases in u-boot's overlay code)
Oct 06 09:46:03 <zmatt> I don't suppose you have a serial console cable to check u-boot's output?
Oct 06 09:47:58 <desttinghim[m]> Oct  6 09:02:11 beaglebone kernel: [    1.607682] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping ok
Oct 06 09:48:10 <desttinghim[m]> It's because I'm done and forgot to uncomment the line to enable it
Oct 06 09:48:42 <zmatt> :P
Oct 06 09:52:42 <desttinghim> zmatt, matrix died on me for some reason
Oct 06 09:52:56 <desttinghim> I forgot to uncomment the line in uEnv.txt
Oct 06 09:53:07 <zmatt> yeah that line still got through
Oct 06 09:53:22 <zmatt> my response was mere silent judgement ;)
Oct 06 09:53:45 <desttinghim> Now there are kernel errors \o/
Oct 06 09:53:53 <zmatt> progress \o/
Oct 06 09:54:25 <desttinghim> https://pastebin.com/9mAqjhzy
Oct 06 09:54:45 <zmatt> oh that's odd
Oct 06 09:56:18 <zmatt> I'd say it's a bug for that property to be missing in the base DT, but you can always just set it yourself: add   #sound-dai-cells = <0>;   to the &mcasp0 { .. }; block
Oct 06 10:02:29 <desttinghim> now there's a sound device
Oct 06 10:02:43 <desttinghim> time to try playing some music!
Oct 06 10:04:10 <desttinghim> Well, that didn't work
Oct 06 10:04:20 <desttinghim> But at least I can see the device now
Oct 06 10:25:51 <desttinghim> thanks for all the help zmatt
Oct 06 11:00:30 <zmatt> you're welcome
**** ENDING LOGGING AT Mon Oct 07 02:59:57 2019