**** BEGIN LOGGING AT Wed May 02 03:00:04 2018 May 02 03:48:55 https://pastebin.com/ciQEB9Je is another set of software I am using w/ the BBB and L298 w/ this openSource board. May 02 03:49:04 My motors are not moving. Can you help? May 02 03:50:14 https://lh3.googleusercontent.com/-rNBT-OyaXF8/WtfSOJngyRI/AAAAAAAAJ6A/xq8-9J8U71U4jZtrKo-6J3T8PRXq4PImgCLcBGAs/s1600/ForBBB.PNG May 02 03:50:15 ... May 02 03:50:28 This is a photo/schematic of the board I am using w/ the BBB. May 02 03:50:50 I have these two jumpers but I am clueless as to where I should place them now. May 02 08:23:14 good morning fellows. I'm trying to understand the rather slow boot time of my BBG .... please see https://pastebin.com/za7jhVCn - there's an almost 2 minute delay going from line 429 to 430 ... somethings seems to block the boot process there ... any ideas ? May 02 08:24:18 deeler: check journal? (journalctl) May 02 08:25:18 deeler: since it sounds like it's waiting for a timeout, you could also check for which units are in failed state with systemctl --failed May 02 08:26:59 alright; journalctl shows me the same 2 min gap with more detail : May 01 22:39:14 switchhub systemd[1]: dev-ttyGS0.device: Job dev-ttyGS0.device/start timed out. May 02 08:27:26 systemctl: ● roboticscape.service loaded failed failed roboticscape May 02 08:28:02 good one zmatt ! this already gives me a clue May 02 08:28:47 if that roboticscape service (whatever it is) is not relevant to you, disable it with sudo systemctl disable roboticscape.service May 02 08:29:29 not sure about dev-ttyGS0.device ... maybe the roboticscape service has a dependency on it? May 02 08:31:37 also holy hell, it takes more than 21 seconds before it even reaches the point of mounting the root filesystem? damn that sucks May 02 08:31:52 hmm ... i must say, i've been trying to make the BBG as 'lean' as possible, so I wanted to get rid of things I didn't need , so might've broken something there May 02 08:32:24 can those 21 seconds be a slow SD-card? May 02 08:32:35 this doesn't look very lean to me :) this is what I achieved after putting in a bit of effort: https://liktaanjeneus.nl/boot.svg May 02 08:33:09 (you can make such a plot using: systemd-analyze plot >boot.svg ) May 02 08:33:22 hahaha, wat een grappige domain name, spreek jij NL ? May 02 08:34:01 cool May 02 08:34:10 I do, but this is an english-language irc channel May 02 08:34:15 yep May 02 08:34:29 anyway, where are the /opt/scripts/boot called from ? May 02 08:34:54 i've already taken out the autoconfigure-usb* scripts, but then the logs complain about the scripts not found May 02 08:35:08 probably some service file in /etc/systemd/system/ May 02 08:35:40 is there a documentation that explains what these scripts do ? May 02 08:36:16 I'm now apt-get purging the roboticsscape , and will reboot again ...; fingers crossed May 02 08:36:33 lines 360-366 of your paste also look strange to me... something is trying to pull those services in as dependencies, yet the services are masked (i.e. service files in /etc/systemd/system are symlinks to /dev/null) May 02 08:37:16 and a slow sd card wouldn't help obviously May 02 08:37:20 those 360-366 are all packages I removed May 02 08:37:31 a removed package doesn't explain those lines May 02 08:37:45 I don't mind a couple of seconds loss due to slow SD, but can't afford the 2 min timeout May 02 08:44:29 still ...... systemd[1]: Timed out waiting for device dev-ttyGS0.device. May 02 08:45:01 systemctl show dev-ttyGS0.device | grep -P 'WantedBy|RequiredBy' May 02 08:48:59 no output zmatt May 02 08:49:18 also, could you maybe run tree /etc/systemd/system (apt-get install tree if it's not already installed) and put the output in a pastebin ? May 02 08:49:59 (tip: rather than copy-pasting, you can pipe the output into the utility pastebinit if you have it installed) May 02 08:50:39 oh, ok sorry May 02 08:50:46 for? May 02 08:50:57 pasting / spamming here May 02 08:51:10 hm, where/when? May 02 08:52:14 ah, try: systemctl show dev-ttyGS0.device | grep BoundBy May 02 08:52:17 forgot about that one May 02 08:53:00 or just systemctl show dev-ttyGS0.device | pastebinit May 02 08:53:22 what is ttyGS0 anyway? I do vaguely recognize it, but I'm not sure May 02 08:53:31 zmatt: https://pastebin.com/trRREavx May 02 08:53:32 ah gadget serial May 02 08:53:52 so that doesn't exist anymore because you killed the usb gadget setup stuff, but something is still depending on it May 02 08:53:54 gadget serial ... is that usb0/1 related?. May 02 08:53:59 ok May 02 08:54:20 okay you have a ton of services enabled-yet-masked May 02 08:55:21 yeah ... i thought apt-get remove/purge would've taken care of that May 02 08:55:50 for the stuff you removed with apt-get, try fully purging those packages (which also removes any leftover config) May 02 08:56:04 okay, I'll try that May 02 08:56:21 you can find a list of those with dpkg --get-selections | grep deinstall May 02 08:57:28 wonderful ! May 02 08:58:11 so, all the symlinks in the various /etc/systemd/system/*.target.wants directories are enabled units that get automatically pulled in when a particular target is requested May 02 08:58:38 purging .... May 02 08:59:45 most of these targets are implicit part of startup (exceptions include network-online.target, and bluetooth.target I think) May 02 09:00:46 still no sign of whatever is pulling in ttyGS0 though May 02 09:01:14 still purging, i'll give it another reboot to check May 02 09:02:50 you're using ifupdown as network manager I see? keep in mind that (iirc) it blocks startup until it is able to bring network up (including waiting for dhcp if applicable). that may or may not be a concern depending on the application May 02 09:03:37 hm, I've removed 'connman' and just want to use vanilla /etc/network/interfaces (i've set a static address there for eth0) May 02 09:03:42 that's ifupdown May 02 09:03:49 (the config file of) May 02 09:03:55 ah, ok May 02 09:04:45 if you're using a static ip anyway then it doesn't really matter :) May 02 09:05:23 yeah May 02 09:08:02 heh, now the boot seems to take even longer, hope I didn't break it, still no ping May 02 09:09:31 having access to the serial console may be useful when dealing with boot stuff May 02 09:11:51 it's dead May 02 09:12:41 ow! it's not May 02 09:12:44 if you have a sufficiently recent systemd I can actually recommend systemd-networkd over ifupdown btw ... it's easy to configure (e.g. https://pastebin.com/jJYtyZBw for dhcp, https://pastebin.com/xx97YRdi for static ip), lightweight, and handles dynamic changes well May 02 09:13:27 ok... i'm not that familiar yet with systemd, i'll check those for sure May 02 09:14:41 so, what happened? what's journal saying? May 02 09:15:08 and have some of the symlinks in /etc/systemd/system cleared out? May 02 09:15:23 I still don't understand why there are so many masked units May 02 09:15:24 still that pesky ttyGS0 May 02 09:15:31 let alone masked and enabled May 02 09:15:50 i didn't do the /etc/systemd/system yet May 02 09:16:05 you should definitely disable services you don't want btw, e.g. cloud9, node-red, bonescript-autorun May 02 09:16:07 ls: bluetooth.target.wants getty.target.wants network-online.target.wants sshd.service syslog.service dbus-org.bluez.service multi-user.target.wants sockets.target.wants sysinit.target.wants timers.target.wants May 02 09:16:31 please just pastebin the tree May 02 09:16:33 bluetooth ? don't need that May 02 09:16:36 oke May 02 09:17:03 https://pastebin.com/WwA2ZSZB May 02 09:17:06 I think bluetooth.target is only pulled in if bluetooth hardware is detected May 02 09:17:16 yeah May 02 09:17:32 so you can safely ignore bluetooth.target.wants May 02 09:17:45 sockets.target.wants , don't need those May 02 09:18:12 what is 'bonescript' ? May 02 09:18:43 typically symlinks for .socket files are installed by the corresponding service unit, so they should disappear if you systemctl disable bonescript cloud9 node-red May 02 09:19:11 (if you don't specify a suffix for units, it's implicitly .service ) May 02 09:19:26 bonescript is a nodejs thingydoo May 02 09:19:33 ok May 02 09:19:39 for playing with the hardware in javascript via the web interface May 02 09:19:54 systemctl disable bonescript cloud9 node-red says: Failed to disable unit: No such file or directory May 02 09:20:38 what about systemd-udev ... do I need that ? May 02 09:20:43 yes you do! May 02 09:20:52 your system will not boot anymore without it May 02 09:21:01 :-) May 02 09:21:44 do those .socket files actually exist even or are they part of packages you removed? that would explain the error at least May 02 09:21:48 you can also just manually remove them May 02 09:21:58 dbus-daemon ? Isn't this a thing for gui's or windw managers? May 02 09:22:07 absolutely not May 02 09:22:35 it's even used by systemctl to talk to systemd May 02 09:22:48 ok, not touching it then May 02 09:23:02 you probably want to disable the two apt-daily timer units on an embedded system May 02 09:23:07 how can I check those ".sockets" ? May 02 09:23:22 uhh normally symlinks would be colored red if you're broken symlinks May 02 09:23:26 *they're May 02 09:23:40 just with an 'ls -la' ? May 02 09:23:58 no red there May 02 09:24:05 also not in tree May 02 09:24:11 'scuse me, but that sounds a lot starting out with a big image, and then stripping it down in various random places. isn't starting out with a minimal one an option? May 02 09:24:22 LetoThe2nd has a very good point May 02 09:24:50 LetoThe2nd: i started with the 'IoT' image, though that would be slim already May 02 09:25:00 no, iot has a ton of crap May 02 09:25:08 console is the minimal image May 02 09:25:22 yeah, i noticed ... where can i find that console version? May 02 09:25:34 deeler: total opposite. that means "comes with a boatload of stuff people think might be cool for iot-buzzwording" May 02 09:25:48 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_console May 02 09:26:44 if you want to go die-hard you can always start out with openembedded :-P May 02 09:26:59 COOL ! May 02 09:27:37 i'm not that of an expert, but I want something like the debian netinstall , start minimal , add only what's necessary May 02 09:28:05 yeah, then start with the console image May 02 09:28:18 even that probably still has some crap, but much much less of it May 02 09:28:49 to half-quote a famous citation: "crap is just software in the wrong memory" :) May 02 09:28:52 nice one guys ! May 02 09:28:57 lol May 02 09:30:02 if I dd this image to an SD card, what's the minimum size required , i see the image file is only 99mb May 02 09:30:09 also, you can save a significant bit of boot time by disabling initramfs. annoyingly some versions of the kernel package have a bogus dependency on initramfs-tools, but you can still disable it in config file May 02 09:30:39 99mb compressed right? May 02 09:30:55 nevermind, i see the unpacked filename says: 1GB May 02 09:31:09 the uncompressed image size is the minimum size of the sd card, unless you shrink the filesystem using resize2fs May 02 09:31:35 guess 'dd' will just create a 1GB partition, and then I can create the remainder of the sd-card with fdisk May 02 09:33:16 I generally use filesystem images rather than disk images (handle partitioning and u-boot separately in a flasher-script) shrunk to minimum size with resize2fs -M, and after writing the filesystem image expand it to fit the partition May 02 09:33:30 that also reduces time to flash since you're not pointlessly writing zeros May 02 09:34:15 zmatt: that is very discriminating. i demand that you write exactly the same amount of pointless zeros and pointless ones. May 02 09:34:27 lol May 02 09:34:28 :-D May 02 09:40:49 zmatt: that boot graph you showed me, is that with a console image too ? May 02 09:41:24 it's produced by systemd-analyze which comes with systemd May 02 09:41:30 systemd-analyze plot >boot.svg May 02 09:41:51 yes, but are you also using console image rather that IoT ? May 02 09:42:26 our image was once upon a time based on a console image May 02 09:42:48 and I definitely wouldn't want all the crap that's on the iot image :P May 02 09:45:29 that's also what i was looking for May 02 09:46:14 too bad this isn't mentioned on the beaglebone.org page May 02 09:56:34 well the console image isn't really appropriate for most users I guess May 02 11:24:51 so I was still playing around getting that ttyGS0 error fixed, and I believe i found it: commented line "systemctl start serial-getty@ttyGS0.service " in /opt/scripts/boot/am335x_evm.sh May 02 11:25:11 now there's no 2 min timeout in the bootprocess May 02 11:25:54 but weird thing is: the shutdown part seems to take ages .... May 02 11:25:57 oh I entirely disable the service that calls that script May 02 11:26:13 which one is that ? May 02 11:26:43 generic boot something? check in /etc/systemd/system/multi-user.target.wants May 02 11:26:45 do you know a similar thing like journalctl , but that also shows the shutodown of the processes ? May 02 11:27:06 you can have systemd verbosely log what it's doing to the serial console May 02 11:27:27 interesting May 02 11:27:29 that's the best way to debug stuff that happens after journald has stopped May 02 11:27:59 (stuff before that can be found in the persistent journal on eMMC, if enabled) May 02 11:28:12 nah, i disabled emmc May 02 11:28:48 eh, sd card I mean May 02 11:28:51 root filesystem May 02 11:28:55 oh May 02 11:29:23 I said eMMC out of habit... I always boot from eMMC :P May 02 11:29:52 me too preferably, but i needed the pins May 02 11:33:37 depending on whether you need *all* of its pins... I realized some time ago that it's probably possible to configure it to use a 4-bit interface (just like sd card) hence free up the d4-d7 pins May 02 11:33:45 never tested it though May 02 11:34:59 yeah, i'm using all of them :) 72 inputs May 02 11:35:14 that's a lot of inputs May 02 11:35:20 it is May 02 11:40:32 too much crap indeed, to many scripts that start other scripts, I'll just go with that console image now May 02 11:42:09 even the console image has these bits though I think... but you can just disable that service that calls into /opt/scripts/yadayada May 02 11:43:56 okay! noted May 02 12:36:12 zmatt, I looked into configuring the network with systemd, like the example u showed me, what do I need to do now with /etc/network/interfaces for it not to conflict? May 02 13:29:23 hello May 02 13:38:52 Hi, I have a problem with UART.setup ("UART1"). May 02 13:44:19 guys? May 02 13:44:57 well, if you would actually state your problem, or at least some context, then *maybe* someone would step up. May 02 13:46:18 UART.setup ("UART1"). Traceback (most recent call last): File " ", line 1, in Runtime Error: Unable to export UART channel. May 02 13:48:54 still trying to speed up the boot process, I found that "networking.service" takes over 45 seconds ..... https://pastebin.com/58rmSMkB May 02 13:49:19 that's a bit long just to get the network up isn't it ? not using DHCP May 02 13:49:34 Bony_: as you're still not giving any context, i have to *GUESS* that you are hitting: https://groups.google.com/forum/#!topic/beagleboard/FNhmP38i-5I May 02 13:54:24 What do I need to provide everything? May 02 13:56:23 we do not have the slightest clue what board, what os,... not even where you are typing that? just remember: we are not standing behind you, not looking over your shoulder. May 02 14:02:56 I opened the topic on Google.group: https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-blue/1A70EHR9UI4 May 02 14:07:39 well then whats the problem? the Uarts are all there as far as i can see, from the device list. so have you actually checked if that library function (are you using the adafruit stuff??) is still supported? May 02 14:08:34 found it : "systemctl disable udhcp" solved it May 02 14:10:00 me? May 02 14:10:16 Bony_: yes? May 02 14:10:41 what? May 02 14:10:56 Bony_: -> well then whats the problem? the Uarts are all there as far as i can see, from the device list. so have you actually checked if that library function (are you using the adafruit stuff??) is still supported? May 02 14:12:42 I didn't understand... May 02 14:14:19 Bony_: you still have not said what you are doing. so 1) are you really using the adafruit library? 2) have you checked (the library documentation!) if that function is really still supported? the first link i gave you strongly suggests that it is not. 3) the device list looks very much as if all uarts are there and happily waiting. May 02 14:16:24 I use python: import Adafruit_BBIO.UART as UART UART.setup("UART1") May 02 14:35:17 KotH: the other channel requires your presence apparently May 02 15:18:02 last time I checked Adafruit_BBIO.UART was broken May 02 15:19:49 (and not useful anyway) May 02 16:26:10 is there a way to tell if you're on a BBB? wanted to have it check if its running on a BBB and if it isnt to not run the commands, but to just output what the action would be May 02 16:27:14 if(b.isBBB){ b.digitalwrite() } else { console.log("pin x set to high") } May 02 17:28:52 Does my device tree need an entry for the McASP even though I am talking to it via the McASP? May 02 17:28:58 PRU* May 02 18:11:16 bou4: well you could declare it there to have the kernel enable the module in PRCM for you May 02 18:14:45 PRCM? May 02 18:14:52 power/reset/clock management May 02 18:15:24 Oh, without that the PRU will not be able to talk to it? May 02 18:15:54 correct, if a module is disabled then any access to it will fault May 02 18:16:28 it should suffice to do something like &mcasp0 { ti,no-idle; }; May 02 18:16:40 I don't even think you need to set status="okay"; May 02 18:17:19 the ti,no-idle; property will tell the kernel to keep the module enabled at all times May 02 18:18:16 Is it hard to enable it in the PRU? May 02 18:20:09 not really, just impolite... and if the kernel discovers that prcm settings changed behind its back it will get upset and complain loudly... though I don't think it would ever discover it in this case May 02 18:20:37 at the same time, adding that one property to the DT is trivial May 02 18:20:47 Alright, I will add it to the DT May 02 18:21:19 Besides that, there is nothing stopping the communication between PRU and McASP? May 02 18:22:06 with ti,no-idle you've made it the kernel's responsibility to ensure McASP is accessible and functional May 02 18:22:30 (regardless of whether that access is done from the cortex-a8 or pruss) May 02 18:22:55 Perfect May 02 18:24:23 Is there a difference in https://pastebin.com/JcqGBXTc ? May 02 18:26:17 the latter locates the node by label, the former by path May 02 18:26:31 also the former is needlessly complex, you could just specify "/ocp" as target-path May 02 18:26:49 What if ocp is non-existent? May 02 18:27:00 I assume the former will work, but the latter won't May 02 18:27:46 yes but for the ocp node that's not relevant since the system wouldn't be functional without it May 02 18:28:04 similar thing goes for most peripherals, since you're relying on various definitions having already been made in the base DT May 02 18:28:28 Do I have the same certainty about the sound node? May 02 18:28:57 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/commit/26a9a6e46dadb0c576565b8e5593aec2122a12f3 May 02 18:29:01 Because I refactored this May 02 18:29:44 no, the sound node is normally created by the DT fragment that defines the "soundcard" for the platform... I don't think the sound node is even labeled at all generally May 02 18:30:48 that commit looks like a mistake to me May 02 18:30:51 So I definitely need to revert that commit May 02 18:30:57 yes May 02 18:31:39 Fixed it, thanks May 02 18:32:26 My ALSA device tree is finished and correct May 02 18:32:39 But I think my PRU device tree got some few errors in it May 02 18:34:32 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/devicetree/beaglebone-black-codec-pru.dts May 02 18:34:54 Not every pinmux gets referenced May 02 18:37:04 btw I think it's somewhat preferred nowadays to structure a simple-audio-card sound node like this, with the cpu-codec link in a simple-audio-card,dai-link subnode: https://pastebin.com/YBS1awrH (this was changed to allow multiple cpu-codec links) May 02 18:39:21 Perfect, I will add that May 02 18:39:27 please remove those #address-cells / #size-cells properties. those should be configured correctly in the base tree and it's not appropriate to override them (even though you're setting them to the values they already have) May 02 18:39:47 and use target=<&ocp> May 02 18:41:05 I think I added them because dtc was complaining May 02 18:41:27 the complaint is wrong, suppress it by passing a suitable flag to dtc May 02 18:42:01 Alrighttt May 02 18:42:11 And how would I best reference the pinmuxes? May 02 18:43:08 pru is accessing the mcasp and the gpio ? May 02 18:43:43 reference them from the pruss node then May 02 18:43:45 gpio is accessed by the cpu through the sysfs May 02 18:44:09 then use a gpio-helper to setup the gpio and export it via sysfs May 02 18:44:17 and stick the pinctrl reference on that May 02 18:44:44 gpio-of-helper I mean May 02 18:45:39 alrighty, I will fix that in a minute! May 02 18:45:56 my alsa device tree is overcommented :p May 02 18:46:05 also, I hope I have already mentioned I have some utils to make overlays a bit less obnoxious to write? May 02 18:47:14 yesss, you did, but then I need to ship that tool with my project May 02 18:47:35 is that a problem? May 02 18:49:16 goh, not really May 02 18:53:20 being able to write &i2c1 { ... }; instead of / { fragment@1 { target=<&i2c1>; __overlay__ { ... }; }; }; seems worth it to me ;-) May 02 19:01:15 what is the point of system-clock-frequency of a CODEC sub-node? May 02 19:02:49 you use either it or clocks = <&some_clock>; to indicate the master clock of the codec, when relevant May 02 19:03:37 (master clock provided to it, or in some cases generated by it) May 02 19:03:50 but because the codec is master of the FCLK and SCLK, the exact frequency doesn't really matter May 02 19:04:21 because the McASP doesn't use it, if I understood a conversation of ours earlier May 02 19:04:24 the driver still needs to know it to be able to configure the codec correctly May 02 19:04:49 (to produce the desired bitclock rate) May 02 19:05:31 oke, than I used the wrong value in my original DT May 02 19:05:41 i thought it was the rate of the crystal May 02 19:05:49 which is twice the rate of the mclk May 02 19:06:02 hmm May 02 19:06:34 that's the sort of situation where I'd check the codec driver to see what exactly is done with the info :) May 02 19:06:49 But it is possible to configure the codec to have the same frequency for the crystal as the mclk, so that's probably why it worked May 02 19:06:56 cs4271 right? May 02 19:07:00 correct May 02 19:07:06 cs4272* May 02 19:07:10 but they are compatible May 02 19:07:22 the difference is in the analog circuitry (differential vs single-ended) May 02 19:09:35 it seems to me that when the osc is used, mclk is equal to the oscillator frequency May 02 19:10:11 oh, maybe not May 02 19:10:59 yeah okay there's an optional /2 divider May 02 19:11:13 correct, but the /2 divider is default May 02 19:15:00 yeah it seems that system-clock-frequency in that case just determines whether the MCLK output is oscillator freq or oscillator freq / 2 May 02 19:16:12 and indicates what the oscillator freq is obviously (it has a limited range so there's no ambiguity) May 02 19:19:10 specifically, the codec looks up which settings to use based on: 1. whether codec is master of slave 2. whether sample rate is below 50 kHz (single rate), 50-100 kHz (double rate), or above 100 kHz (quad rate) and 3. the mclk / fs ratio (where mclk is as specified in DT) May 02 19:24:50 Alright, on what source code did you derive that reasoning? May 02 19:25:25 sound/soc/codecs/cs4271.c May 02 19:25:50 (while having the datasheet open at the same time :P ) May 02 19:26:38 aha, i see! May 02 19:28:31 and sampling rate gets defined by ALSA, not by the device tree May 02 19:29:25 yeah samplerate is specified by userspace (constrained by what the hw supports) May 02 19:31:31 okay, perfect! May 02 19:36:22 but now I am in dubio about setting mclk-fs May 02 19:36:39 is it relevant? is mclk even used for anything in your setup? May 02 19:37:03 because setting that effectively constrainst the samplerates, I think May 02 19:37:08 no May 02 19:37:25 oh wait May 02 19:37:54 yeah it does May 02 19:38:19 if mclk=osc/2 then you can't run at quad rate May 02 19:38:24 but... who cares May 02 19:40:19 yeah, there isn't a mclk / fs that supports all modes May 02 19:40:29 ? May 02 19:40:59 if you use mclk=osc (i.e. 512 * 48 kHz) then all modes are supported May 02 19:41:00 https://imgur.com/a/pPpJ0W8 May 02 19:41:18 in the DT you specify mclk-fs May 02 19:41:32 which is actually the same as mclk / lrck May 02 19:41:48 oh that property, I'm pretty sure that's ignored May 02 19:42:16 that's probably just for setups where mclk is programmable May 02 19:42:18 it isn't here May 02 19:42:34 alright, removed it :p May 02 19:47:40 I am starting to think the driver will also ignore the system-clock-frequency DT entry May 02 19:47:49 no it won't May 02 19:47:55 is there a way to see how the DT maps to the driver? May 02 19:48:17 simple-audio-card will indirectly invoke set_dai_sysclk May 02 19:48:18 snd_soc_component_get_drvdata() ? May 02 19:49:07 i.e. cs4271_set_dai_sysclk() in this case May 02 19:51:41 asoc_simple_card_parse_clk() in sound/soc/generic/simple-card-utils.c is where the system clock properties are read from DT May 02 19:51:59 and asoc_simple_card_init_dai() in the same file passes that value to snd_soc_dai_set_sysclk() May 02 19:53:23 (which is in sound/soc/soc-core.c and dispatches it to set_sysclk on the driver May 02 19:53:26 ) May 02 19:54:55 aha, I start to understand! thanks a lot May 02 19:55:13 and at first sight I don't see mclk-fs anywhere May 02 19:55:59 the property is read in generic/simple-card.c May 02 19:58:15 okay it's not being ignored, it's actively harmful in your situation May 02 19:58:59 it seems to override system-clock-frequency? May 02 19:59:10 yes it looks like it to me May 02 20:02:34 Yes, so I should use 24576000 as system-clock-frequency May 02 20:02:43 This way all sample rates are possible May 02 20:02:51 Magnific May 02 20:03:17 yes, where "all" means "48 kHz or something pointlessly high" ;-) May 02 20:07:16 audiophiles won't like what you say :p May 02 20:08:35 bon, alsa device tree is finished, now pru :p May 02 20:08:59 (we're using two back-ends for playing audio) May 02 20:09:02 yeah I know high sample rates are a fad May 02 20:09:13 one using alsa is already working May 02 20:09:25 the other using the PRU (as already explained) is a work in progress May 02 20:09:26 (even though they're more likely to decrease audio quality than increase it) May 02 20:09:39 because of bit errors? May 02 20:09:51 no May 02 20:10:21 and I'm slightly exaggerating maybe... it only decreases quality in specific circumstances May 02 20:10:24 higher sampling rates do mean, you are less likely to suffer from aliasing because of bad filtering May 02 20:10:39 although codecs often have worse specs at double and quad rate than at single rate May 02 20:10:43 i phrased that incorrectly May 02 20:11:53 and audio filters require 2-4 times as much computational power for every doubling of the sample rate, which means that given a certain amount of computational power, some kind of trade-off will be made or corners will be cut May 02 20:12:22 and we need all the computational power we can have for our convolution May 02 20:12:30 impulse responses longer than 10 seconds are the target May 02 20:13:44 https://www.youtube.com/watch?v=0Ebnue1a4vc May 02 20:13:47 Bela already does this May 02 20:14:06 twice the sample rate means your impulse response is twice as long (when measured in samples) *and* you have twice as many samples to be filtered May 02 20:14:11 uh, that isnt' bela May 02 20:14:13 hence 4x the cost May 02 20:16:10 (actually I don't think the 4x is true in your situation because of the FFT-based approach, but still) May 02 20:40:27 dtc --in-format dts --out-format dtb --warning no-unit_address_vs_reg --warning no-avoid_default_addr_size --symbols beaglebone-black-codec-alsa.dts --out beaglebone-black-codec-alsa.dtbo beaglebone-black-codec-alsa.dtbo: Warning (reg_format): "reg" property in /fragment@1/__overlay__/cs4271@10 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) May 02 20:40:33 i assume I can safely ignore that? May 02 20:40:57 (that's because of deleting the #address-cells and #size-cells) May 02 20:41:25 yes May 02 20:42:06 are overlays not that good supported? May 02 20:43:32 if you want to *actually* check your overlay, write it like a customization of the main dts, i.e. do #include "am335x-boneblack-uboot.dts" followed by the desired DT fragments, and compile that with warnings enabled May 02 20:43:46 the same file without the #include can then be turned into an overlay using my script May 02 20:44:25 there's no way for dtc to actually validate an overlay by itself May 02 20:44:47 so to be honest the /plugin/; directive should just have disabled all warnings May 02 20:45:56 ok, thanks for all the advice May 02 20:46:05 i hope i am not that much of a burden May 02 20:46:08 nah May 02 20:46:17 if you were I'd just start ignoring you May 02 20:46:40 haha, i know what signs to look for :p May 02 20:48:08 can I assume that the gpio node exists? May 02 20:48:14 "the gpio node" ? May 02 20:48:24 https://pastebin.com/raw/CPiC2CnB May 02 20:48:49 no you're *creating* such a node May 02 20:48:59 the name doesn't matter, as long as it doesn't conflict with an existing node May 02 20:58:22 typically I'd expect only the top-level of a DT fragment to reference an existing node, i.e. I'd expect all child nodes that appear in it to be newly created nodes. Of course if nodes with the same path already exist, they will be merged, but I'd consider it bad style to do that on purpose unless you have to May 02 20:59:59 e.g. if I really wanted to modify an existing unlabeled node at the path /gpio then I'd write the fragment like this: &{/gpio} { ... }; May 02 21:04:54 where do i find the documentation for gpio-of-helper? May 02 21:04:57 and okayyy May 02 21:11:21 is there no doc for it in devicetree/bindings ? otherwise just see the comments in https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi May 02 21:16:24 that is one hell of a fantastic document] May 02 21:33:14 my DT's are finished, thanks for all the help! May 02 21:43:59 you're welcome! May 02 21:45:05 hmm, but it seems that I got a duplicate entry May 02 21:45:19 https://pastebin.com/raw/UZNuX4pc May 02 21:45:52 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/device-tree/beaglebone-black-codec-pru.dts May 02 21:46:08 debian@beaglebone:/boot$ uname -a Linux beaglebone 4.9.82-ti-r102 #1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018 armv7l GNU/Linux May 02 21:46:42 I'll admit I was a bit confused as to why you're including the full declaration for pruss in your overlay, but I was assuming you're using it *instead of* enabling pruss via the standard overlay May 02 21:46:53 but it looks like you actually have remoteproc-pru enabled at the same time May 02 21:47:00 that's not going to work May 02 21:47:41 hmm, I copied the standard overlay into mine May 02 21:47:59 because i only want to be dependent of 1 dt overlay May 02 21:49:20 but you need to ensure the correct setting for uboot_overlay_pru regardless, even if it's "should not be set" May 02 21:50:11 hmm May 02 21:50:35 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/pru/boot/uEnv-pru.txt May 02 21:50:40 this is what i use for uEnv May 02 21:51:06 (i don't know what the last line means, but i didn't want to strip it from the original) May 02 21:51:41 ohh, update your kernel May 02 21:52:06 aha, that's why it used to work May 02 21:53:54 or actually... hmm, huh, hmm May 02 21:56:04 yeah, it was fixed in 4.9.83-ti-r104 May 02 21:56:27 what was the bug? May 02 21:56:44 remoteproc-pru being enabled in the base dts May 02 21:56:52 aha, interesting May 02 21:57:02 instead of leaving it to the overlay May 02 21:57:19 why do they ship a buggy kernel with the default image? May 02 22:01:10 *shrug* it probably wasn't considered important enough to publish a new image. it only affects uio-pruss users and many of them use a -bone kernel I think May 02 22:01:44 (before u-boot overlays you had to customize the main .dts to get uio-pruss working on a -ti kernel) May 02 22:02:21 brb May 02 22:06:40 makes sense May 03 01:22:14 set_ your eyes on the autonomous hair cut robot! the flowbeagle! **** ENDING LOGGING AT Thu May 03 03:00:05 2018