**** BEGIN LOGGING AT Wed Nov 15 03:00:02 2017 Nov 15 05:39:16 hi Nov 15 05:40:05 Hello Nov 15 07:43:34 hey guys, anyone here that is familiar with mcasp on bbb? Nov 15 07:48:00 to interface TLV320AIC3104 to BBB, is it really necessary to connect GPIO3_21(mcasp0_ahclkx) to mclk of codec? or is it possible to feed external osc 12MHz to mclk (like some capes do)? Nov 15 09:00:57 microdevel: there are lots of ways to do audio clocking (though not all of them supported by the mcasp driver) Nov 15 09:04:43 microdevel: here are some of my notes on the subject: https://pastebin.com/raw/7ibHvBB9 Nov 15 09:10:49 but in general mcasp and the codec will need to use the same audio system clock (mclk/hclk), provided either by the bbb's 24.576 MHz osc or by external hw, unless the codec is configured as master (for clk and fs) and the mcasp as slave, in which case mcasp doesn't need hclk Nov 15 09:14:37 zmatt, appreciate your help! https://pastebin.com/3RZ2JWj4 for a detailed description of my problem Nov 15 09:17:05 it is possible to connect multiple audio codecs to one mcasp, although it may be less convenient to do so since linux will view it as a single multi-channel codec Nov 15 09:19:17 it seems both your codecs can operate in master or slave mode, so you have a lot of flexibility Nov 15 09:19:42 (okay the bluetooth chip isn't a codec strictly speaking, but you know what I mean) Nov 15 09:19:49 sure Nov 15 09:20:51 i was just wondering because some designs use external osc. instead of using mcasp0_ahclkx so i was hoping that it might not be necessary Nov 15 09:20:55 mcasp1 (if used) should probably only be used in slave mode, since there's no way to feed it a decent master clock Nov 15 09:21:32 if mcasp operates in slave mode, hclk is not used Nov 15 09:22:55 ok this explains why some audio capes use hclk (MCASP master, TLV320 slave) and others dont (MCASP slave, TLV320 master)? Nov 15 09:24:13 using the hclk of the bbb slightly reduces the BOM since you can then use the 24.576 MHz osc already present on the beaglebone Nov 15 09:24:53 it also allows audio output to go to both hdmi and audio cape Nov 15 09:26:05 ok but if i do use hdmi and audio cape, linux will again see only one codec Nov 15 09:26:15 but, as you determined, disabling the bbb's audio osc and configuring mcasp0 in slave mode allows P9.25 to be reclaimed for other purposes Nov 15 09:26:51 zmatt, this is my only way to get bluetooth audio working at all Nov 15 09:27:16 if i cant free P9.25 i have no other way to connect bluetooh audio i guess Nov 15 09:28:11 how to find out if tlv320aic3 driver supports mcasp0 slave mode? Nov 15 09:29:17 well you could connect both codecs to mcasp0 Nov 15 09:30:10 the source code? :) I'd be surprised if it didn't though Nov 15 09:31:49 yeah it looks like the tlv320aic3x driver is pretty featureful Nov 15 09:32:05 ok sure, source code is last resort ;) Nov 15 09:32:25 take a look at https://imagebin.ca/v/3hMZ0xDni60x , BBGW also uses MCASP in slave Nov 15 09:34:32 on a design without MII, you could bring up MCASP1 in master mode Nov 15 09:34:50 ah wait TLV320AIC3104 is the tlv320aic31xx driver, not tlv320aic3x Nov 15 09:35:08 yes it is 31xx Nov 15 09:35:58 that's unusual... it actually looks like it *only* supports master mode for the codec (i.e. slave mode for mcasp) Nov 15 09:36:13 lemme double-check that Nov 15 09:36:26 possibly the naming is confusing here Nov 15 09:37:19 nope, that's what it says... codec is master Nov 15 09:37:25 in my docs, TLV320AIC3x supports 3104 Nov 15 09:37:42 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.61-ti-r76/sound/soc/codecs/tlv320aic31xx.c#L917-L925 Nov 15 09:37:59 oh Nov 15 09:38:01 hum Nov 15 09:38:16 okay then what the fuck is the tlv320aic31xx driver for Nov 15 09:38:31 ohh, 3111 Nov 15 09:38:46 really good choice of naming there -.- Nov 15 09:39:09 okay well the 3x driver supports both master and slave mode: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.61-ti-r76/sound/soc/codecs/tlv320aic3x.c#L1251-L1263 Nov 15 09:39:35 yeah, thats the document i have here Nov 15 09:40:18 which also explains why some capes use the same driver but schematics show that codec is master and mcasp is slave Nov 15 09:40:32 so, would just be a matter of adapting devicetree right? Nov 15 09:40:37 yes Nov 15 09:40:46 guess i can figure that out Nov 15 09:41:10 seems that most bluetooth chips are master by the way Nov 15 09:41:18 don't know why Nov 15 09:41:53 I'm not sure how audio clocking is handled in case of bluetooth anyway Nov 15 09:42:28 according to specs it is just a I2S interface Nov 15 09:43:05 I mean over bluetooth itself, not the interface between cpu and bluetooth chip :) Nov 15 09:43:25 certainly making the bluetooth chip master seems like the better choice Nov 15 09:43:32 that must be part of bluez(or any other) stack Nov 15 09:45:11 so, after digging a bit into the subject, you agree that MCASP0 slave, MCASP1 slave is the best solution? Nov 15 09:45:27 looks like it yes Nov 15 09:45:56 if i connect both chips to mcasp0, maybe bluez is confused because there's only one audio codec visible to linux (as you stated) Nov 15 09:47:47 actually wait, you would definitely have to declare both codecs... maybe I just had a mindfart and there wouldn't be any problem with connecting both to one mcasp... and yet I really have the feeling I've had issues with that in the past, but I just don't recall the details Nov 15 09:48:39 no worries, for me also having separate mcasps feels better Nov 15 09:48:46 yeah Nov 15 09:49:30 but wasnt able to achieve that unless releasing P9.25 which automatically means TLV320 master, mcasp0 slave Nov 15 09:49:44 yes, but that's no problem Nov 15 09:50:17 so i guess for the hardware point of view, i have a good solution! software issues will be faced when prototype is here :D Nov 15 09:50:41 hehe Nov 15 09:50:49 that sounds familiar Nov 15 09:50:53 back to altium designer :D Nov 15 09:51:02 (I ended up having to patch the mcasp driver for our setup) Nov 15 09:51:23 that would be my personal nightmare (lack of time) Nov 15 09:51:46 well, fortunately Nov 15 09:52:16 well, fortunately my patches are public, and some even integrated by rcn... don't think any of them are of use to you though Nov 15 09:52:43 but i think it is already supported, usomiq audio cape uses the codec, the same driver but obviously codec as master Nov 15 09:52:57 yes it looks like you should be fine Nov 15 09:52:59 only problem is i couldnt find a dts file Nov 15 09:53:07 so this might be challenging Nov 15 09:53:45 but maybe just define pin muxing and tell the driver it has to run in mcasp0 slave mode Nov 15 09:54:43 there are 'frame-master' and 'bitclock-master' properties on the dai-link node that point to either the 'cpu' or 'codec' child node of the link Nov 15 09:54:55 that's how you select which one is master Nov 15 09:55:15 so it "might" be straightforward :D Nov 15 09:56:07 but you seem to be really keen to mcasp, not many people are i guess Nov 15 09:57:27 and a 'clock' property on the 'codec' child node of the dai-link should point to the audio master clock (declare as fixed clock or reuse an existing one) Nov 15 09:57:38 'clocks' property, sorry Nov 15 09:58:40 just another idea - would it be possible to use CLKOUT2 (P9_41A) to feed MCLK and use mcasp0 as master? Nov 15 09:58:42 I'm pretty familiar with mcasp, less so with alsa but I was forced to learn to get our stuff working :) Nov 15 09:59:04 what stuff we talk about? is it on the market? Nov 15 09:59:34 http://dutchdutch.com/ Nov 15 10:00:40 wow, looks great :) you guys arent interested in building some car hifi products? Nov 15 10:02:13 there are two problems with that idea: one is that 24 MHz is a really strange value to use as audio system clock (it results in a 46.875 kHz sample rate), and clkout2 has unknown phase relative to mcasp0 signals which might be trouble for the codec (or might not, depends on the codec) Nov 15 10:03:11 the first problem is the bigger one... it's why the beaglebone has a separate audio osc Nov 15 10:03:11 ahh, thanks for that hint. i thought clkout2 was in sync. Nov 15 10:04:07 but anyway i have seen an audio design using clkout2 :D there might be many approaches Nov 15 10:04:23 but i need the one that causes less trouble Nov 15 10:04:57 some codecs accept bitclock with arbitrary phase relative to the system clock Nov 15 10:05:40 ok this is why Nov 15 10:06:01 hello Nov 15 10:06:01 anyway, i guess ill give the two slave model a go Nov 15 10:06:56 do you mind if we stay in touch? also would be interested in your business Nov 15 10:07:39 you should email info@ for that... I'm just a code monkey :) Nov 15 10:09:10 ok, sure will do. but maybe when prototype is there, i might need a mcasp genius again Nov 15 10:09:13 and I always lurk here Nov 15 10:09:32 ok, so ill try to find you here Nov 15 10:10:10 and if you ever come to munich, tell me so i can buy you some pitchers of beer Nov 15 10:10:46 hehe, I don't drink beer, but thanks :) Nov 15 10:11:01 whatever you have sir Nov 15 10:11:26 whoever calls it a pitcher in munich...? Nov 15 10:11:51 :D is MASS international? only for those who have been to oktoberfest Nov 15 10:12:34 maß is universal Nov 15 10:12:56 yeah shouldbe Nov 15 10:13:10 zmatt, thanks for your time, really appreciate it Nov 15 10:19:41 np :) Nov 15 15:02:13 Hi, I have a little issue with my beaglebone Black : I cannot install package ==> Reading package lists... Error! E: gzread: Read error (-3: : incorrect data check) E: The package lists or status file could not be parsed or opened. Nov 15 15:02:46 Does anybody knows what is wrong ? Nov 15 15:03:24 It seems that the board hasn't acces to internet while I can do a ping on google Nov 15 15:04:23 try apt-get update to refresh the package lists? Nov 15 15:04:40 Hello you again :) Nov 15 15:04:55 I start whit it Nov 15 15:05:03 started Nov 15 15:05:26 and that works okay? Nov 15 15:05:40 the updating process run well but I still cannot intall anything after this Nov 15 15:05:52 yes Nov 15 15:06:42 damn, that sucks... since it's saying either package lists or status file is corrupt... if it's not a package list then it has to be the status file :-/ Nov 15 15:07:21 although, apt-get update doesn't download package lists if it thinks it's uptodate.. may be worth trying to delete the package lists and try apt-get update again Nov 15 15:07:58 sudo rm /var/lib/apt/lists/* Nov 15 15:09:11 (if the status file somehow has gotten corrupted you're pretty screwed I think) Nov 15 15:09:34 yes we've tried it to Nov 15 15:09:55 Reading package lists... Error! E: gzread: Read error (-3: : incorrect data check) E: The package lists or status file could not be parsed or opened. Err http://httpredir.debian.org jessie/non-free armhf Packages Err http://httpredir.debian.org jessie/main armhf Packages Get:17 http://httpredir.debian.org jessie/main armhf Packages [6,645 kB] W: GPG error: http://security.debian.org jessie/updates InRelease: The following si Nov 15 15:10:22 please don't paste multiline text into irc! it's unreadable and gets truncated. use a paste service like pastebin.com Nov 15 15:10:59 ok ! thank you for the tip Nov 15 15:13:29 incorrect data check) E: The package lists or status file could not be parsed or opened. Err http://httpredir.debian.org jessie/non-free armhf Packages Err http://httpredir.debian.org jessie/main armhf Packages Get:17 http://httpredir.debian.org jessie/main armhf Packages [6,645 kB] W: GPG error: http://security.debian.org jessie/updates InRelease: The following signatures were invalid: BADSIG 9D6D Nov 15 15:13:38 sorry wrong test Nov 15 15:14:11 https://pastebin.com/print/U22HE7bU Nov 15 15:16:32 uhh, no, try again (you just pasted a chunk of irc text instead of the actual terminal output, and managed to give an invalid link which was fortunately fixable by removing the "/print") Nov 15 15:18:21 https://pastebin.com/U22HE7bU Nov 15 15:18:41 that's still the same paste Nov 15 15:19:20 so this is the correct link I know you had it but I'm getting familiar whith Nov 15 15:19:38 pastebin... don't judge me :p Nov 15 15:21:28 Ho, so what do you want I don't understand ? Nov 15 15:21:41 based on this small fragment it's starting to look more like some kind of issue with one of the package listings itself, but it's hard to say without the full output Nov 15 15:21:47 the actual output of the apt command Nov 15 15:22:02 not a small portion of it mashed into a single line Nov 15 15:22:12 ho ! ok Nov 15 15:22:15 just a sec Nov 15 15:22:57 (actual output of apt-get update first, since that already seems to be failing) Nov 15 15:24:16 https://pastebin.com/4pzxd2XN Nov 15 15:25:53 uhh, the fragment you pasted earlier also mentioned a GPG error Nov 15 15:26:05 I don't see that one in this output Nov 15 15:27:28 Ussualy It look the same I don't really know what I pasted earlier I was using it for the fisrt time. What do you recommend me to do ? Nov 15 15:28:15 I don't know what is a GPG erro btw ... :/ Nov 15 15:28:25 r Nov 15 15:31:19 signature check failed, presumably due to corrupted content or because the repository files were being updated and you tried to fetch them at an unfortunate time Nov 15 15:31:42 can you try apt-get update again to see if the output is different? Nov 15 15:33:11 ok I just Googled it : thanks anyway. Yes I'm doing it and I send the checkout to you Nov 15 15:33:38 output I meant Nov 15 15:34:27 https://pastebin.com/dz3BegcC Nov 15 15:35:10 I said It was the same but actually each time the output is different. Nov 15 15:40:59 When I do it from another BBB (whith the wireless) it works Nov 15 15:43:07 can you try: apt-get update -o Acquire::CompressionTypes::Order::=gz Nov 15 15:45:53 (it shouldn't be the solution, since I think that bug should have been fixed a long time ago already, but it's worth a try anyway) Nov 15 15:46:34 HI again Nov 15 15:46:36 done Nov 15 15:46:40 I have the same error Nov 15 15:48:19 apt-get install apt (just in case the package lists that were successfully downloaded suffice to be able to upgrade apt to the latest version) Nov 15 15:49:33 https://pastebin.com/kNDWJmbq Nov 15 15:49:43 :'( Nov 15 15:50:29 hey, I thought we told it to fetch .gz package lists... Nov 15 15:51:00 try removing /var/lib/apt/lists/*.xz and do apt-get update -o Acquire::CompressionTypes::Order::=gz Nov 15 15:51:31 then try the install again Nov 15 15:51:38 ok Nov 15 15:52:10 Thanks for your help I don't know how I would do without !! Nov 15 15:52:56 well the simple strategy would be "well, looks like my system is fucked, I'll just reflash" :) Nov 15 15:53:15 might actually have been faster too Nov 15 15:53:43 But I have reflashed many time ! Nov 15 15:53:50 an uptodate image? Nov 15 15:54:11 no but an image that works well on my wireless Nov 15 15:54:20 today as I'm doing the same command Nov 15 15:54:27 that is quite odd Nov 15 15:54:36 yes Nov 15 15:55:10 I usualy try to reflash when I'm stuck Nov 15 15:55:24 I'm not sure how that difference in internet connectivity could be causing this Nov 15 15:56:04 It seems that the BBBwireless has acces to the depository while the BBB doesn't Nov 15 15:56:11 unless there's somehow a transparent http proxy or something like that in the way of your bbb's internet connectivity Nov 15 15:56:32 well, the bbb can clearly access the repository, and even download most of the files Nov 15 15:57:37 yes I know but when I try to download a specific package it says package unknown Nov 15 15:57:55 are both boards running the same image? Nov 15 15:57:59 while the bbbwireless download it Nov 15 15:58:03 yes Nov 15 15:58:15 which package? Nov 15 15:58:37 I don't know buffer for exemple Nov 15 15:58:37 or avconv Nov 15 15:58:47 that's because your bbb still hasn't been able to successfully download all package lists Nov 15 15:58:54 yes Nov 15 15:59:05 although I'm not sure why it would give "package unknown" in some cases and https://pastebin.com/kNDWJmbq in others Nov 15 15:59:21 ah, incomplete index Nov 15 15:59:44 tbr: "Hash Sum mismatch" Nov 15 15:59:45 yes yes yes Nov 15 16:00:27 but what I really don't understand is why bbb has this problem while your bbb-wireless running the same image doesn't Nov 15 16:01:12 I'd like to able to answer too :) Nov 15 16:01:38 inspite of the fact I tryed to reflash several times Nov 15 16:01:49 one thing you can do however as a temporary workaround is just copying the contents of /var/lib/apt/lists from your bbb-wireless to your bbb Nov 15 16:02:37 Ok :D Nov 15 16:02:44 How can I do this ? Nov 15 16:02:45 e.g. rsync -av bbb-wireless:/var/lib/apt/lists/ /var/lib/apt/lists/ (perform command on your bbb, replace "bbb-wireless" by hostname or ip of your bbb-wireless) Nov 15 16:03:45 and then try apt-get installing apt (to upgrade it just in case) or whatever package you wanted Nov 15 16:04:03 oh wait, that requires being able to ssh as root Nov 15 16:04:04 uhh Nov 15 16:04:19 rsync -av debian@bbb-wireless:/var/lib/apt/lists/ /var/lib/apt/lists/ should work too Nov 15 16:07:09 hello, I have a question about PRU Nov 15 16:10:05 How can I make my BBB's PRU read bits? I'm receiving from a CAN transceiver, so I don't think I'd need voltage conversion Nov 15 16:26:26 Hi same problem I'm affraid Nov 15 16:26:27 https://pastebin.com/wuQM3Wqs Nov 15 17:50:04 sigh... he did apt-get update again instead of just installing the package he wanted -.- Nov 15 17:52:07 apt dotherightthing Nov 15 17:56:04 holy shit, that Infineon RSALib fail is pretty epic... (yes I know it's already a month old, I don't really follow news usually :P ) Nov 15 18:04:20 hi, i just install the last OS version on my BBB. Now in ssh aks for a password. What is the default password? Nov 15 18:05:27 http://lmgtfy.com/?q=beaglebone+default+password Nov 15 18:06:59 (top search result should be beagleboard.org/getting-started which contains uptodate info. beware of random other sites that may have very old info) Nov 15 18:08:06 well, i was there but i could not find any solution Nov 15 18:09:42 ehm, if you search for "password" on that page you get exactly two hits.. the first being the wifi password for beaglebone variants that have wifi, and the second hit is the username and password for logging in Nov 15 18:11:35 you are rigth, just sorry. I am tired. Thanks Nov 15 18:11:41 :) Nov 15 19:58:37 hi i am trying to connect to my BBB over a different neywork, i think i need to delete certificates becaise I cannot login via SSH unless I switch back to the original network, does anyone know if that is correct, deleting certificates, or if there is a better way to resolve? Nov 15 20:04:37 uhh what? Nov 15 20:05:42 under normal circumstances, ssh does not involve certificates of any sort Nov 15 20:05:54 (it does support them, but it's a pretty obscure feature) Nov 15 20:06:08 zmatt: i am connecting to bbb over a new network with the same certificate but a new host ip address, i get connection refused Nov 15 20:06:19 known hosts? Nov 15 20:06:22 "connection refused" is a network problem Nov 15 20:06:56 other computers on same network that have never connected before can connect, and i can ping Nov 15 20:07:39 known_hosts may complain if you've previously connected to a different device on that same ip, but it should also tell you the command to fix it Nov 15 20:07:58 also, that's why using hostnames instead of ips is generally useful :) Nov 15 20:11:35 anyway, I'm afk for a bit, bbl Nov 15 20:25:03 how do i delete all previous ssh login known-hosts and certificates? i can't find known_hosts on my BBB Nov 15 21:37:28 Hey guys, I'm trying to move a PRU project from uio to RemoteProc. I've figured out mmap()ing memory to just share memory between the ARM and the PRU, is there a way for me to just use virtio to kick the ARM from the PRU to let it know something is waiting in memory for it without doing the entire RPMsg dance? Alternately, is there still a way to send interrupts to the ARM (I mean, I know there is on the PRU side, but can I catch the interrupt in userspace Nov 15 21:38:50 I know there were files that you were able at one point to poll() for interrupts, but those seem to not be present on my BB green Nov 15 21:39:43 I would prefer the latter *so long as it's unlikely to become obsolete again* Nov 15 21:54:47 why not just stick with uio-pruss? it's not going anywhere afaik Nov 15 21:55:14 I'd like something that works out of the box on newer beagles Nov 15 21:55:41 both are equally well supported, in the latest images you can toggle between them with a one-line change in /boot/uEnv.txt Nov 15 21:55:48 hmmm Nov 15 21:56:35 actually, I think uio is slightly better supported since (afaik) the -ti kernel series support both while the -bone kernel series only support uio-pruss Nov 15 21:57:34 (unless remoteproc-pru has been added to -bone at some point... I don't actually care about it so I haven't kept track) Nov 15 22:00:23 Another reason I'm interested in remoteproc is that the ability to write in both asm and C for more readable code is appealing. As I understand it, you can only do that with clpru, and you can only do uio with pasm. Nov 15 22:01:38 What's the one line change though? Nov 15 22:07:44 clpru produces an ELF file by default, but it shouldn't be problematic to dump the raw code and data sections from that and load those via uio Nov 15 22:08:31 well there are two lines actually, one to enable uio-pruss and one to enable remoteproc-pru, and you simply uncomment the one you want Nov 15 22:09:45 https://pastebin.com/raw/hM72Qumx these are the relevant lines Nov 15 22:10:47 I've actually considered making a nicer userspace lib for using uio-pruss, including a simple ELF loader, but haven't gotten around to it Nov 15 22:13:48 huh, I don't have either, but apparently I'm running rproc, since my examples work Nov 15 22:14:19 you're probably not using a sufficiently recent image Nov 15 22:14:50 (you can find the date of the image you're using in /etc/dogtag ) Nov 15 22:15:22 kernel is 4.4.9-ti, dogtag is BeagleBoard.org Debian Image 2016-05-13 Nov 15 22:15:52 oh yeah that's really old Nov 15 22:16:37 * n8vi realizes what time it is Nov 15 22:16:40 I guess that must have been during the period where remoteproc-pru was enabled by default Nov 15 22:16:42 yikes, time to go home Nov 15 22:17:06 Okay, well, I'll try a newer image and see how that looks Nov 15 22:17:11 thanks for your help Nov 15 22:17:27 np Nov 15 23:14:04 Hi. I have a BB Black doing some GPIO. It has been working great but recently changed behavior with respect to GPIO exports after a kernel upgrade. Nov 15 23:14:57 Previously I was using linux-4.9.30-ti-r38 from the beagleboard GitHub repo, along with config-pin and the DTBs from this version of the bb.org-overlays repo: https://github.com/beagleboard/bb.org-overlays/tree/edfda8e03bc5476e82e7dae45f26eb5692e02ec0 Nov 15 23:15:22 The system runs this script at boot. Worked fine for months with that kernel. https://gist.github.com/dhess/e0378728b362340543dade1e931e2235 Nov 15 23:15:52 Here are the system's slots. The BB Black has a Logic Supply CBB Relay cape attached. https://gist.github.com/dhess/75c1b54336b058a2704a343c42622bef Nov 15 23:17:35 Anyway, I just upgraded to the linux-4.9.59-ti-r73 kernel, and now nearly all of the GPIO pins that used to be exported are no longer present, so that config-pin script is complaining: "WARNING: GPIO pin not exported, cannot set direction or value!" when it runs those config-pin statements Nov 15 23:18:23 Now only gpio12 and gpio13 are exported automatically after the system comes up. Nov 15 23:19:03 None of the other BB or DTS overlay stuff has changed, only the kernel. Nov 15 23:19:22 Anyone have an idea of what might have caused all of the GPIO pins to no longer be exported after boot? Nov 15 23:20:24 presumably loading the cape-universal overlay failed Nov 15 23:20:31 I'm able to get things running again by just explicitly exporting all of the pins I need in init scripts, but I'd like to understand what changed anyway Nov 15 23:20:46 zmatt: yeah I saw something about that, let me look at the dmesg. Nov 15 23:21:00 although... then config-pin shouldn't work at all, hmm Nov 15 23:21:12 inspecting dmesg is definitely a good start in any case Nov 15 23:21:44 https://gist.github.com/dhess/07d24411bd886de319d60e8f00102525 Nov 15 23:21:46 that's the dmesg Nov 15 23:22:54 huh, you have a FAT boot partition? Nov 15 23:22:58 My uboot is also set up to load a cape DTB, I think, but again, that hasn't changed Nov 15 23:23:03 (unrelated, just a bit surprising) Nov 15 23:23:30 zmatt: yes, I think so. I believe that was necessary to get this BB working with NixOS Nov 15 23:23:44 maybe the installer wanted it, I don't recall. Nov 15 23:24:08 okay this is odd Nov 15 23:24:31 it says it loaded it into slot 4, yet it looks like config-pin is trying to load it again each time Nov 15 23:24:58 zmatt: My script does that first thing, before it runs the config-pin statements. Nov 15 23:25:35 yes I saw that Nov 15 23:26:06 but clearly config-pin doesn't think it's loaded hence tries to load it Nov 15 23:26:10 ahh Nov 15 23:26:44 So I should mention I have since also updated config-pin etc. from the latest bb.org-overlays commit, so that's now the latest. However, there's no difference in behavior. Nov 15 23:28:00 zmatt: any idea why gpio12 and gpio13 would be auto-exported, but not any other pins, after this kernel upgrade? Nov 15 23:28:33 something is clearly going very wrong with loading the cape-universal overlay, but as usual for capemgr there are no useful diagnostics Nov 15 23:30:27 zmatt: I saw something on an old, closed Github issue about only being able to load one universal cape and only being able to do it once. Is that still the case? Nov 15 23:30:37 though to be honest I'm rather surprised that you ever had cape-universal working at the same time as an actual cape Nov 15 23:31:04 uhh, of course cape-universal can only be loaded once? Nov 15 23:31:20 it also can't be successfully unloaded, it's just way too invasive Nov 15 23:31:30 zmatt: ok, good to know. I wasn't aware of that. Nov 15 23:32:45 zmatt: so given that I only really need this to work with that CBB Relay cape (all of my GPIO goes through its relays or pins that it has broken out), should I not be loading the universal cape at all? Nov 15 23:32:57 honestly it's something of a miracle that something as invasive as cape-universal can be loaded at runtime as an overlay at all :) I wonder if that's maybe not getting tested much anymore since u-boot overlays are being used Nov 15 23:35:59 I'm looking at the overlay for that cape to see what it even does Nov 15 23:37:31 okay I have no idea how or why you were ever able to load cape-universal at the same time, these two overlays absolutely conflict Nov 15 23:37:52 zmatt: the other overlay being the CBB Relay one? Nov 15 23:37:54 yes Nov 15 23:38:25 zmatt: ok, now I am not loading that in any of my script anywhere. So how is that being loaded? Nov 15 23:38:34 config-pin loads it Nov 15 23:38:37 ahh Nov 15 23:38:49 config-pin is the setup utility for cape-universal Nov 15 23:38:51 right Nov 15 23:39:29 if you only need gpio, then you can also just get rid of that CBB-Relay overlay and just use cape-universal Nov 15 23:39:30 sorry, just to be clear -- I meant that I am not loading the CBB Relay cape myself. Did you mean that config-pin is loading the CBB Relay cape, or cape-universal? Nov 15 23:39:50 overlays for capes are automatically loaded Nov 15 23:40:10 zmatt: Right. So how do I "get rid of" the CBB relay overlay? Nov 15 23:40:28 that would be fine. I was effectively ignoring it anyway Nov 15 23:41:07 simplest way is probably deleting/renaming the overlay itself ( /lib/firmware/CBB-Relay-00A0.dtbo ) Nov 15 23:41:22 there might be a more elegant way but I'm not really all that familiar with capemgr Nov 15 23:41:26 Hmm. Nov 15 23:41:40 Maybe there's a way to blacklist them Nov 15 23:41:48 one would hope Nov 15 23:42:12 ok that's a useful hint. Let me see what I can do Nov 15 23:43:19 huh, it does not appear to exist. Nov 15 23:44:03 wait, check slots? Nov 15 23:44:28 maybe I misinterpreted what the kernel log is saying Nov 15 23:44:28 it does not exist: [ 4.451271] bone_capemgr bone_capemgr: loader: failed to load slot-0 CBB-Relay:00A0 (prio 0) Nov 15 23:44:32 right Nov 15 23:44:33 okay Nov 15 23:44:51 well, then I do understand why you could load cape-universal, and I'm not sure why it's failing for you now :) Nov 15 23:44:57 slots are here: https://gist.github.com/dhess/75c1b54336b058a2704a343c42622bef Nov 15 23:45:34 yeah the Logic Supply people stopped supporting the CBB Relay board a few years ago and never updated their DTS files for whatever changes were made Nov 15 23:46:24 well, that's not really a problem when using cape-universal Nov 15 23:46:25 which is why I ended up looking into the universal cape stuff in the first place. I just identified the pins that the CBB Relay cape used and hard-wiring them and their behavior into my scripts. Nov 15 23:46:28 right Nov 15 23:47:12 no idea why it's not working for you since the upgrade Nov 15 23:47:13 zmatt: so cape-universal is loaded but it's not exporting all the cape-universal pins Nov 15 23:47:21 that is effectively what's happening? Nov 15 23:47:23 is it exporting any gpios? Nov 15 23:47:28 yes, gpio12 and gpio13 Nov 15 23:47:35 okay so basically almost none Nov 15 23:47:56 are those special? Used by eMMC or something? Nov 15 23:48:08 if they were then they wouldn't be exported Nov 15 23:48:14 hmm Nov 15 23:48:17 * zmatt looks them up Nov 15 23:48:45 Does Robert C Nelson ever come on here? Nov 15 23:49:08 he used to, but unfortunately he stopped coming here Nov 15 23:49:17 uhh what Nov 15 23:49:31 gpio12 and gpio13 make absolutely zero sense to be exported at all Nov 15 23:50:15 that's P9.20 and P9.19 ... the pins used for the i2c bus that's used for cape detection Nov 15 23:50:49 something really weird is going on Nov 15 23:54:03 zmatt: well thanks for your assistance. You've helped me narrow down the issues a bit! Nov 15 23:54:27 you're welcome... and good luck hunting :) Nov 15 23:54:30 I'll pull out another BB and set it up for some testing. I can work around these issues in production by just explicitly exporting the 2 pins I need to use Nov 15 23:54:44 the board itself still seems to be working just fine Nov 15 23:55:35 zmatt: are you using BeagleBones for any sort of GPIO etc.? Nov 15 23:56:03 we use all sorts of functionality of the bbb Nov 15 23:56:27 zmatt: do you use the beagleboard kernels, or mainline? Nov 15 23:56:51 currently the 4.9-bone series with some patches and custom config Nov 15 23:57:18 and are you using the cape manager stuff? Nov 15 23:57:21 (some of my patches have actually been merged back in by rcn) Nov 15 23:57:33 no, I'm not using overlays at all Nov 15 23:57:45 custom dt Nov 15 23:58:21 zmatt: ahh. How do you get that loaded? I don't know much about this and have just relied to date on capemgr doing The Right Thing. Nov 15 23:59:49 Between uboot, capemanager, dts/dtb, etc. it's all quite confusing :) Nov 16 00:00:12 you can set the 'dtb' variable in /boot/uEnv.txt to override the default dtb loaded by u-boot Nov 16 00:00:19 dts = device tree source code Nov 16 00:00:56 dtb = device tree blob (compiled dts) Nov 16 00:01:00 dtbo = dtb overlay Nov 16 00:01:51 capemanager is a mechanism to load overlays at runtime + a system to detect capes via i2c and automatically loading the appropriate overlay Nov 16 00:02:28 u-boot is responsible for loading the main dtb, making any last-minute changes, and passing it to the kernel when handing over execution Nov 16 00:02:29 OK. And if nothing else overrides what u-boot does, that device tree is in effect after boot? Nov 16 00:02:46 ahhhh that is what the O means in dtbo. OK, that makes sense. Nov 16 00:03:06 u-boot detects the board id and picks which dtb to load based on that Nov 16 00:03:19 e.g. am335x-boneblack.dtb Nov 16 00:03:23 right right Nov 16 00:04:15 recently u-boot gained the ability to load and apply overlays to the device tree before it's passed to the kernel Nov 16 00:04:36 when enabled, this replaces capemgr Nov 16 00:04:43 is there a way, after boot, to figure out what u-boot loaded? Nov 16 00:04:52 something in /proc maybe? Nov 16 00:05:17 you can inspect the device tree itself via /proc/device-tree Nov 16 00:06:03 zmatt: does /proc/device-tree have a file that lists which DTs and DTOs were loaded? Nov 16 00:06:04 there's afaik no way to find the name of the dtb that u-boot loaded since it's not passed to the kernel Nov 16 00:06:07 ok Nov 16 00:06:31 because for the life of me I cannot find the uboot stuff anywhere on this system Nov 16 00:06:48 of course the filename should appear in u-boot's output on the serial console Nov 16 00:06:55 I think Nov 16 00:07:14 It's been awhile since I've had to do anything with this since it has been working so well, and I've been hacking on Jetson stuff recently and now it's all jumbled up in my memory :) Nov 16 00:07:39 u-boot normally lives in the space between the partition table and the first partition Nov 16 00:07:49 or alternatively it can reside in a FAT boot partition Nov 16 00:09:00 hmm it must be on the eMMC Nov 16 00:09:02 also, an sd card can boot even if there's no u-boot on it at all since in that case it'll fall back to the u-boot on eMMC Nov 16 00:09:14 actually no, I'm saying that wrong Nov 16 00:10:02 u-boot on eMMC (if any) actually takes precedence over u-boot on SD (if any) Nov 16 00:10:04 I'm only seeing extlinux on here Nov 16 00:10:09 wtf Nov 16 00:11:54 if you want to know if your card is actually bootable, try powering on the bbb while holding down the S2 button (the button nearest to the card slot). you can let go as soon as the power led has turned on Nov 16 00:12:13 zmatt: without capemanager, is there any way to load a DTB at runtime? Nov 16 00:12:28 dtbo you mean, and yes there is, via configfs Nov 16 00:13:14 zmatt: actually I really meant a DTB, not an overlay. Nov 16 00:13:33 or is that hard-wired at boot? Nov 16 00:13:47 the dtb is what's passed to the kernel when it begins execution Nov 16 00:14:03 yeah it's weird that you can't see what that was after boot Nov 16 00:14:17 I'm not sure there *is* a DTB on this system because I can't find uboot anywhere Nov 16 00:14:34 dtbs should live in /boot/dtbs Nov 16 00:14:56 zmatt: yeah NixOS is weird, nothing lives any place you'd normally expect :) Nov 16 00:15:10 extlinux is setting the FDTDIR variable Nov 16 00:15:55 ahh there they are, the DTBs Nov 16 00:16:22 yeah I'm sure there used to be some uboot stuff that chose which one of these to load. where did it go.... Nov 16 00:16:36 well, if you're using a weird system then you'll need to figure that stuff out yourself :) Nov 16 00:16:44 try: dd if=/dev/mmcblk0 skip=256 count=1 | hexdump -C Nov 16 00:16:46 zmatt: yeah :) Nov 16 00:17:15 all 00 Nov 16 00:17:39 try powering on with S2 button held down Nov 16 00:18:44 zmatt: eh can't on this system. It's currently running some things and it's outdoors. PITA to mess with. I'll grab another identical board+cape and mess around with that Nov 16 00:18:48 okay Nov 16 00:19:21 thanks again, though, you've been a great help. I have a better understanding of the boot process and how the DTBs and DTBOs are meant to work. Nov 16 00:19:23 anyway, like I said, u-boot on eMMC actually takes precedence over u-boot on SD. so unless you wiped eMMC, you're probably using the u-boot that's stored there Nov 16 00:19:46 yeah there was definitely some uboot stuff on here originally. I just don't know where it is Nov 16 00:20:18 if it's not too ancient, it lives invisibly between the partition map and the rootfs partition on eMMC Nov 16 00:20:22 zmatt: what does your /proc/device-tree/name say? Nov 16 00:20:31 blank Nov 16 00:20:41 ok good :) Nov 16 00:20:48 as I would expect from the name of the root node Nov 16 00:21:21 I was hoping that would have the name of the DTS/DTB Nov 16 00:21:22 note that the kernel doesn't know the name of the dtb since u-boot passes the *contents* of the dtb to the kernel, not its name Nov 16 00:21:39 sure but it could certainly put that somewhere in the metadata Nov 16 00:21:50 which would be helpful right now :) Nov 16 00:22:02 if it does, it would be somewhere in /proc/device-tree/chosen Nov 16 00:22:20 but I'm pretty sure it doesn't Nov 16 00:22:42 you are correct Nov 16 00:23:04 but if you're using a beaglebone black and you haven't overridden the dtb in /boot/uEnv.txt then it's "am335x-boneblack.dtb" Nov 16 00:23:19 the model file says TI AM335x BeagleBone Black Nov 16 00:23:23 which is good at least Nov 16 00:24:20 zmatt: yeah I *may* have changed that in order not to load the HDMI support. Had a short or two because of that damned mini-HDMI connector. Nov 16 00:24:33 but that would have been the extent of it Nov 16 00:24:46 that used to require overriding which dtb is loaded yes Nov 16 00:24:55 I should have gotten a Green :\ Nov 16 00:25:00 (since u-boot overlays it has become a bit more modular) Nov 16 00:25:02 zmatt: oh really, how can you do that now? Nov 16 00:25:07 oh. Yeah I haven't messed with those at all. Nov 16 00:25:29 zmatt: where is the Git repo where uboot overlays are maintained? Nov 16 00:25:43 I should look to see if anyone's done one for this CBB Relay board Nov 16 00:25:44 here's someone's /boot/uEnv.txt from a recent image: https://pastebin.com/JVr005Cf Nov 16 00:25:59 you can see things like disable_uboot_overlay_video Nov 16 00:26:07 oh yeah that's nice! Nov 16 00:26:19 overlays for capes and such are still exactly the same files Nov 16 00:26:35 zmatt: so that "enable_uboot_cape_universal" effectively does the same thing as the cape manager universal cape? Nov 16 00:26:56 but loaded by u-boot and applied to the dtb before it's passed to the kernel, instead of being loaded by the kernel and applied to the "live" device-tree Nov 16 00:27:01 zmatt: ahh I see. So uboot can now deal with dtbo files, then? Nov 16 00:27:06 zmatt: cool, got it. Nov 16 00:27:26 oh right here I see it loading a DTBO Nov 16 00:27:38 zmatt: oh hey, which kernel are you using at the moment, anyway? Nov 16 00:27:39 and yes, enable_uboot_cape_universal loads cape-universal... I think that's handled somewhat special, made more modular Nov 16 00:28:01 you already asked :) 00:56 < zmatt> currently the 4.9-bone series with some patches and custom config Nov 16 00:28:19 yes, I meant what's the uname of the kernel you're patching? Nov 16 00:28:25 4.9.58-bone7 Nov 16 00:28:28 great thanks Nov 16 00:28:53 err.. is 4.9-bone different than Robert's beagleboard.org series? Nov 16 00:29:13 his are 4.9.58-rxx-ti Nov 16 00:29:19 he makes both Nov 16 00:29:20 or -ti-rxx Nov 16 00:29:29 zmatt: interesting. What is the difference? Nov 16 00:29:37 the PRU stuff? Nov 16 00:30:04 -bone is somewhat closer to mainline, and its config more tailored specifically to the beaglebone Nov 16 00:30:29 zmatt: does -bone have capemanager? Nov 16 00:30:36 while -ti has more patches from TI's kernel tree (incl remoteproc-pru), and is configured to support multiple boards including beaglebone and beagleboard-x15 Nov 16 00:30:47 both do Nov 16 00:30:49 I see. Maybe I should switch. Nov 16 00:31:15 are the X15s actually shipping now? Nov 16 00:31:35 a month now I think? Nov 16 00:31:42 I wanted one for a build server. Eventually I just got a Jetson TK1 Nov 16 00:31:54 zmatt: wow cool! Nov 16 00:32:00 why would you use that for a build server instead of using a beefy x86 system? Nov 16 00:32:36 The cross-compiling story for NixOS is not great. Also, most of the user-space software my BeagleBone runs is written in Haskell, and Haskell cross-compiling pretty much doesn't work. Nov 16 00:32:49 okay, fair enough Nov 16 00:32:51 it does if you're very circumspect about the libraries you use. Nov 16 00:33:08 so yes, it blows and I have to compile natively. Even on the TK1 it is slooooooooow. Nov 16 00:33:29 yeah I actually dev on the beaglebone but use distcc to distibute the actual compilation to our build server Nov 16 00:33:39 so while a cross-compiler is being used, nothing actually notices that Nov 16 00:33:53 interesting. Nov 16 00:34:02 preprocessing and linking is still done on the bbb, so no libs need to be installed on the build server Nov 16 00:34:59 (preprocessing can be delegated too when using distcc-pump, but it has startup overhead which makes it not worth it for small/incremental compiles) Nov 16 00:35:47 So distcc knows how to invoke gcc-cross-arm or whatever when it's running on the target platform? Nov 16 00:36:12 just make sure that build server and beaglebone use roughly the same gcc, and it should be invoked as arm-linux-gnueabihf-gcc or whatever Nov 16 00:36:25 I did not know that. That's a clever hack. Nov 16 00:36:26 no unfortunately it just uses the compiler name :/ Nov 16 00:36:38 I wish it did something more clever based on arch, but it doesn't Nov 16 00:37:20 as a workaround, I just made /usr/local/bin/{gcc,g++} tiny shell scripts :) Nov 16 00:40:17 well whatever works :) Nov 16 00:40:37 zmatt: what are you using your BBs for, if you can talk about it? Nov 16 00:41:42 they're embedded in our products... http://dutchdutch.com/ Nov 16 00:42:01 holy shit that looks awesome! Nov 16 00:42:44 :) Nov 16 00:43:01 you might just have gotten another customer ;) Nov 16 00:45:11 yeah these are amazing. Nov 16 00:45:39 :D Nov 16 00:45:54 not exactly within everyone's budget though Nov 16 00:47:34 BTW there are a couple of broken links. On the http://dutchdutch.com/studio page, the Pro Fidelity and Studio links at the bottom (under the Our Series heading) takes me to http://dutchdutch.com/undefined Nov 16 00:47:47 probably not your department but pass it on :) Nov 16 00:48:16 yeah I'll drop it on slack Nov 16 00:50:00 sometime early next year I'll be in the market for monitors. I will definitely be looking at these. Nov 16 00:50:11 where is some documentation on this Clerk software? Nov 16 00:51:51 I think internal docs are still being worked on, hehe Nov 16 00:51:58 ok :) Nov 16 00:52:45 if you mean end-user docs, I doubt there will ever be any. it's a complete mystery to me why an internal software component is even being mentioned on the website, but well... as you said, not my department Nov 16 00:53:30 zmatt: well the site mentions how you have the "controls at your fingertips" or something like that, so it would be helpful if there were *some* kind of information about what kind of controls :) But again I'm sure that's not your department. Nov 16 00:53:59 the idea of a network-controlled speaker is really cool, but of course you'd want to know what exactly you can do with it! Nov 16 00:54:33 it has an app yes, still heavily being worked on though but the basics work already I think Nov 16 00:54:49 hopefully in addition to an app there Nov 16 00:54:56 's a nice geeky REST api or something :) Nov 16 00:55:47 I have this dream to eliminate an AV receiver from my home theater system. Powered speakers with an API would go a long way towards that :) Nov 16 00:58:04 I don't exclude the possibility, we're all geeks here Nov 16 01:01:07 especially if a customer expresses an interest :) Nov 16 01:02:29 the firmware is still being continuously improved anyway, e.g. network streaming is a thing being worked on Nov 16 01:04:28 Streaming would be cool. Nov 16 01:42:20 zmatt: ahh, on NixOS, uBoot uses the fdtfile uBoot environment variable to determine which DTB to load. Nov 16 01:42:24 that is why I couldn't find it. Nov 16 01:42:56 the uEnv.txt stuff is apprently a Debian (?) patch to uBoot. Nov 16 01:43:03 and not present on NixOS Nov 16 01:43:30 I wonder if there's a package that lets you view/set uboot env variables from user space Nov 16 01:43:46 rcn uses a customized u-boot for the beaglebone.org images Nov 16 01:43:53 uboot-envtools :) Nov 16 01:44:03 zmatt: Interesting, I wonder what's different. Nov 16 01:44:23 zmatt: is that a recent change? Like last 4 months or so? Nov 16 01:44:36 no Nov 16 01:44:38 ok Nov 16 01:44:53 I mean, u-boot has changed, e.g. u-boot overlays is new Nov 16 01:45:01 I've been using whatever uboot came with this BB and it has been working fine to date, so that probably isn't related Nov 16 01:45:05 zmatt: right. Nov 16 01:46:13 I will try to packge up a new uboot later, something that can load the overlays Nov 16 01:46:30 yes, so regardless of what NixOS' opinions are how stuff should be, things should still be in a place where the u-boot on eMMC looks for it :) Nov 16 01:46:47 it tries various things though for backward-compat reasons Nov 16 01:47:44 Come to think of it I'm pretty sure the uboot on this board came from Debian originally. Nov 16 01:47:44 easiest would probably be to flash the latest stretch image to eMMC... then you also have a reference system to study/inspect Nov 16 01:48:41 zmatt: so the universal[an...] cape stuff, that's an overlay and not a device tree? Nov 16 01:50:14 I'm not sure what you're asking Nov 16 01:50:43 the system uses only one device tree, and it can be patched using overlays Nov 16 01:50:49 zmatt: Sorry. uBoot will first load a DTB file like am335x-boneblack.dtb, right? Nov 16 01:51:13 yes Nov 16 01:52:08 zmatt: And then, in the past, before uBoot supported overlays, you would load, say, cape-universal from user space using the capemanager, right? Nov 16 01:53:02 yes, normally done by one of the boot scripts Nov 16 01:53:30 zmatt: so that means cape-universal is an overlay, not a stand-alone device tree Nov 16 01:53:36 yes Nov 16 01:54:00 zmatt: ok cool. And now that uBoot supports overlays, you can just tell it to load cape-univerasl itself and you don't need capemanager? Nov 16 01:54:05 (or, in some cases it can be already included in the main device tree... this is currently done for pocketbone for some reason) Nov 16 01:54:37 yes, same with other overlays Nov 16 01:55:18 zmatt: Great. Roughly when did uBoot start supporting loading overlays on its own? Nov 16 01:56:00 I'm pretty sure I recall that the uBoot on my BB had stuff to load cape-universal etc. I just didn't understand the difference between that and the DTB files. Nov 16 01:56:16 so it might be new enough and I could just skip this capemanager stuff. Nov 16 01:56:19 I'm pretty sure that since u-boot overlays it actually loads a very basic version of the main dtb -- no optional functionality like eMMC or hdmi, and then applies overlays for such functionality based on uEnv.txt config Nov 16 01:56:35 hmm Nov 16 01:56:43 u-boot overlays is very very recent Nov 16 01:57:16 ok. That's weird, then. I wonder what the universal stuff was for. Maybe it was pre-merged as you alluded to earlier (a la pocketbone) Nov 16 01:57:33 "the universal stuff" ? Nov 16 01:57:48 cape-universal, cape-universala, cape-universaln, etc. Nov 16 01:58:01 those are the overlays Nov 16 01:58:11 variants of the cape-universal overlay I mean Nov 16 01:58:14 yes. Nov 16 01:58:34 ... so? Nov 16 01:59:01 Sorry, I'm clearly not getting across my thinking and it's not really that important. I was just wondering "out loud" so to speak. Nov 16 01:59:45 I'm pretty certain that the uboot config on the BeagleBone had references to cape-universal and the other cape overlays. So I was wondering if the uBoot on that BB was in fact recent enough to load those overlays and I just wasn't aware of it. Nov 16 02:00:07 It sounds like it was not recent enough for that, so I'm not sure what that was for. Nov 16 02:00:14 it doesn't really matter. Nov 16 02:00:23 huh Pocketbone is cool. I hadn't heard of that. Nov 16 02:00:38 no, I'm pretty sure that just passes info via the kernel cmdline to initramfs Nov 16 02:00:50 but I've never really dug into it since I don't use capemgr Nov 16 02:00:52 zmatt: ahhhhhh *that* makess sense Nov 16 02:01:46 zmatt: does recent mainline DTC support this notion you were speaking of where you can pre-compile overlays into the DTB? Nov 16 02:03:27 I have no idea if there's a tool to apply an overlay to a dtb "offline", but of course anything you can do in an overlay you can also do in the main dt (since an overlay is nothing but a patch to it) Nov 16 02:05:05 Sure. I was just curious if dtc can do it at compile time rather than porting the overlay to the DT by hand. Nov 16 02:05:05 a better question is why the hell dtc requires the hideous structure of overlays to be written manually instead of just accepting the same format it normally would... I actually fixed that by sticking a small perl script in the pipeline between cpp and dtc Nov 16 02:05:57 I have no idea how to write a DTS or DTO. The whole thing looks like serious voodoo. Nov 16 02:06:29 most of the example .dtsi files in https://github.com/mvduin/overlay-utils can either be #included into the main dts or compiled into an overlay using the Makefile Nov 16 02:06:57 ahh Nov 16 02:08:11 each block just references some existing node and then puts some child nodes and/or properties in it, which are merged into the DT Nov 16 02:08:39 yeah conceptually it makes sense, but then there's all the pinmux stuf etc and it gets complicated really quickly :) Nov 16 02:09:06 it's a bit tedious, but not that hard once you get the hang of it Nov 16 02:09:25 making some useful constants and macros instead of magic hex numbers helps a lot for pinmux :) Nov 16 02:09:46 it's tempting to try to fix the old CBB Relay DTS stuff so that it works with the modern tools. My understanding is that it doesn't work anymore for some reason. Nov 16 02:11:48 e.g. compare https://github.com/mvduin/overlay-utils/blob/master/spi1.dtsi#L14-L25 with roughly equivalent https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-SPIDEV1-00A0.dts#L31-L45 Nov 16 02:11:49 zmatt: Without needing to going into any detail, I assume you're using the PRUs on the BB for these speakers? Nov 16 02:11:55 not yet currently Nov 16 02:12:23 zmatt: Do you have a toolchain in mind yet for when the time comes to use the PRUs? Nov 16 02:12:32 pasm Nov 16 02:12:33 I have something starred on GitHub I think Nov 16 02:12:34 pasm Nov 16 02:12:37 ok I'll check that out Nov 16 02:13:14 it's in https://github.com/beagleboard/am335x_pru_package Nov 16 02:13:25 yeah just found that :) Nov 16 02:13:33 thanks! I had indeed already starred that. Nov 16 02:13:52 pasm is a pretty feature-rich assembler Nov 16 02:14:01 I don't really have any need for it at the moment, just thought it might be fun to play with Nov 16 02:14:56 zmatt: I assume the first one of those DTSIs you linked is the "simpler" one? :) Nov 16 02:15:44 the first one is my version, the second one is an overlay from bb.org Nov 16 02:15:56 the highlighted lines are more or less equivalent Nov 16 02:15:57 well it's shorter anyway! Nov 16 02:16:00 ahh ok Nov 16 02:16:45 zmatt: the DTSI basically declares, these are the pins used by this cape (or whatever), their initial states, capabilities, etc, correct? Nov 16 02:16:48 the bb.org overlay is longer since it also declares actual spi devices, mine just sets up the bus Nov 16 02:16:55 got it Nov 16 02:18:19 it's also uglier due to the weirdass structure of overlays (the fragment nodes and __overlay__ child node) while in my case that's taken care of by the bin/dtsi-to-overlay script used by my makefile Nov 16 02:18:40 oh interesting, in some of these DTSI files , you assume a certain device is hooked up to this pin or that one. Nov 16 02:18:50 and I use constants for the pin numbers and macros for the magic values used for pinmux Nov 16 02:18:51 that's a cool idea. Nov 16 02:19:12 they're various examples yes Nov 16 02:19:22 the main purpose of the device tree is to describe the hardware to linux Nov 16 02:20:09 note that my spi0.dtsi example (unlike the spi1.dtsi) does also include an example node for an SPI device connected to the spi0 bus Nov 16 02:21:10 to help understanding: &foo references a node labeled with foo: Nov 16 02:21:55 and <> surround integers (32-bit, big endian) or arrays thereof Nov 16 02:23:02 zmatt: what's the mechanism for loading these overlays via configfs? Nov 16 02:23:16 do you just cat them to a special file? Nov 16 02:23:29 see the {add,rm}-overlay and list-overlays utils in the bin dir of the same repo Nov 16 02:23:48 no it's not quite as simple Nov 16 02:23:54 oh perfect Nov 16 02:26:58 zmatt: so I've got this app and it wants to use say gpio47 as an input, and the CBB Relay board pre-configures it as a pull-up input. I could write an overlay that, when loaded, does all that configuration for the app and the app only needs to start reading /sys/class/gpio/gpio47/value... is that right? Nov 16 02:27:30 at the moment I'm doing all of that in this config-pin script Nov 16 02:28:10 yeah, you can use a gpio-of-helper device to preconfigure gpios, and attach pinmux to that node Nov 16 02:28:39 I also use an udev rule to create convenient symlinks based on the node names in dt Nov 16 02:28:42 that sounds awesome. Nov 16 02:28:58 well I'm glad I had this bug and came here today, I've learned a ton :) Nov 16 02:29:39 using an overlay would be a lot more robust than the ad-hoc stuff I'm doing now. Also potentially more secure as I can just pre-configure this stuff at boot Nov 16 02:29:54 is there a way to lock down the overlays so that they can't be changed anymore? Nov 16 02:29:58 until reboot obvs Nov 16 02:30:10 /changed/loaded/ Nov 16 02:31:39 https://pastebin.com/raw/UueSPmQg here's an example of how gpios can be declared Nov 16 02:32:32 ahh very cool Nov 16 02:32:49 the macros I use for pinmux are non-standard (you can find headers for it in my overlay-utils project), though I think bb.org eventually started using similar macros (but not the same syntax) Nov 16 02:33:30 and yes iirc there's a way to lock down loading of overlays Nov 16 02:34:00 Thank you sir! Nov 16 02:34:30 look around in /sys/kernel/config/device-tree/ Nov 16 02:34:36 there might be a property there Nov 16 02:34:53 (I don't have a bbb handy with overlay support enabled so I can't check) Nov 16 02:38:09 btw, if you're curious to see what real-world advanced pru code written in pasm looks like, syntactically (making use of the more advanced features like structs and scopes), the firmware for the various pru cores scattered around Keystone processors can be found online, e.g. this one for the Packet Accelerator subsystem: https://git.ti.com/keystone-rtos/pa-lld/blobs/master/fw/v1/classify1.p Nov 16 02:41:06 my understanding is that the PRUs are quite well documented, and the main problem is how to get the program running on the PRU and manage it from Linux. Nov 16 02:41:50 well, uio-pruss allows you to simply mmap() the whole subsystem Nov 16 02:41:51 Is that accurate? Nov 16 02:42:03 Huh. That's kinda hacky but I guess it could work :) Nov 16 02:43:10 and each interrupt line from pruss to the cortex-a8 is exposed as a device file which you can stick into an event loop of your choice Nov 16 02:43:37 oh interesting. Nov 16 02:44:50 this isn't just limited to pruss btw, there's also a generic uio driver (uio_pdrv_genirq) which you can use to similar mmap() some peripheral's memory(-mapped i/o) space and receive irqs from it via file descriptor Nov 16 02:45:09 *similarly Nov 16 02:45:57 reminds me about the DMA stuff, maybe I can work on that sometime next week. Nov 16 02:45:58 quite useful if you want a peripheral that has no kernel driver or a crappy one and you don't feel like writing a better one Nov 16 02:46:49 (I for one generally prefer working in userspace over working in the kernel) Nov 16 02:51:57 It's so nice to have well-documented hardware like the BB. It's the main reason I haven't switched to RPi. Need to reward companies doing things the right way. Nov 16 02:52:40 yeah, the SoC on the rpi doesn't even have a product page at broadcom, let alone actual documentation Nov 16 02:52:41 I do hope the Beagle folks ship something aarch64-based soon, though! Nov 16 02:52:54 very unlikely Nov 16 02:53:06 zmatt: you think not? How come? Nov 16 02:54:07 oh wow, Mouser has 331 X15s in stock. Hmm.... Nov 16 02:54:08 because TI doesn't produce any arm64 SoC currently Nov 16 02:54:19 zmatt: surely they will at some point? Nov 16 02:54:32 or are they getting out of the business? Nov 16 02:54:50 they probably will "at some point", but that's a vague term :) Nov 16 02:55:16 I don't get the impression that using the latest-and-hottest cores is particularly important for their primary target markets (automotive and industrial) Nov 16 02:55:47 ok so you meant "very unlikely" about the "soon" part of my statement, not the general idea :) Nov 16 02:56:59 zmatt: I dunno, automotive is pretty fast-moving and increasingly demanding these days, with everyone racing to self-driving/automated-assist vehicles. Nov 16 02:57:06 their flagship am57/dra7/tda2 product uses the cortex-A15, which is actually quite old (the third cortex-A processor ARM designed I think), while the tda3 doesn't even include any cortex-A core Nov 16 02:57:25 yes, they have dedicated cores for vision processing Nov 16 02:57:28 they're not ARM cores Nov 16 02:58:13 sure, probably GPUs, but the other general-purpose demands will scale with that. Managing more memory, etc. Nov 16 02:58:30 unfortunately those cores (EVEs) are disabled on the am572x :/ **** ENDING LOGGING AT Thu Nov 16 03:00:01 2017